[Intel-gfx] ✓ Fi.CI.BAT: success for Adding NV12 support for SKL display (rev2)

[Patchwork]

== Series Details ==

Series: Adding NV12 support for SKL display (rev2)
URL   : https://patchwork.freedesktop.org/series/25377/
State : success

== Summary ==

Series 25377v2 Adding NV12 support for SKL display
https://patchwork.freedesktop.org/api/1.0/series/25377/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125 +1
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:468s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:481s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:570s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:548s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:496s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:583s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:433s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:422s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:457s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:515s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:576s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:569s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:509s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:500s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:502s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:620s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:1   skip:29  
time:404s
fi-skl-6700hq failed to connect after reboot

28880958b7cd59f14172c942d82182acf104d880 drm-tip: 2017y-06m-19d-21h-07m-06s UTC 
integration manifest
a1e41f9 drm/i915: Add NV12 support to intel_framebuffer_init
67b6ec5 drm/i915: Add NV12 as supported format for sprite plane
ddacd16 drm/i915: Add NV12 as supported format for primary plane
73530b8 drm/i915: Upscale scaler max scale for NV12
facfc33 drm/i915: Update format_is_yuv() to include NV12
96b69cc drm/i915: Set scaler mode for NV12
cebb4ae drm/i915: Add render decompression support
2c7382b drm/i915: Implement .get_format_info() hook for CCS

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4991/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/8] drm/i915: Set scaler mode for NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling

v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler

v3: Rebased (me)

Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_atomic.c | 8 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 41ddd25..5c3b120 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6390,6 +6390,7 @@ enum {
 #define PS_SCALER_MODE_MASK (3 << 28)
 #define PS_SCALER_MODE_DYN  (0 << 28)
 #define PS_SCALER_MODE_HQ  (1 << 28)
+#define PS_SCALER_MODE_NV12 (2 << 28)
 #define PS_PLANE_SEL_MASK  (7 << 25)
 #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
 #define PS_FILTER_MASK (3 << 23)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..808f8e6 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -325,7 +325,13 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
}
 
/* set scaler mode */
-   if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+   if (plane_state && plane_state->base.fb &&
+   plane_state->base.fb->format->format ==
+   DRM_FORMAT_NV12) {
+   DRM_ERROR("NV12 format setting scaler mode\n");
+   scaler_state->scalers[*scaler_id].mode =
+   PS_SCALER_MODE_NV12;
+   } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
scaler_state->scalers[*scaler_id].mode = 0;
} else if (num_scalers_need == 1 && intel_crtc->pipe != PIPE_C) 
{
/*
-- 
1.9.1

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

[Intel-gfx] [PATCH 4/8] drm/i915: Update format_is_yuv() to include NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 to format_is_yuv() function and
made it available for both primary and sprite planes

v2:
-Use intel_ prefix for format_is_yuv (Ville)

v3: Rebased (me)

Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 3e4549a..fba8f02 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -41,13 +41,14 @@
 #include "i915_drv.h"
 
 static bool
-format_is_yuv(uint32_t format)
+intel_format_is_yuv(uint32_t format)
 {
switch (format) {
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_NV12:
return true;
default:
return false;
@@ -336,7 +337,7 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct 
intel_flip_work *work
enum plane_id plane_id = plane->id;
 
/* Seems RGB data bypasses the CSC always */
-   if (!format_is_yuv(format))
+   if (!intel_format_is_yuv(format))
return;
 
/*
@@ -900,7 +901,7 @@ static u32 g4x_sprite_ctl(const struct intel_crtc_state 
*crtc_state,
src_y = src->y1 >> 16;
src_h = drm_rect_height(src) >> 16;
 
-   if (format_is_yuv(fb->format->format)) {
+   if (intel_format_is_yuv(fb->format->format)) {
src_x &= ~1;
src_w &= ~1;
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 8/8] drm/i915: Add NV12 support to intel_framebuffer_init

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 83b20fd..56fd9ae 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14765,6 +14765,10 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_GEN(dev_priv) >= 9)
+   break;
+   goto err;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
&format_name));
-- 
1.9.1

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

[Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported format for sprite plane

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index d4665d2..2a388b6f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1074,10 +1074,13 @@ int intel_sprite_set_colorkey(struct drm_device *dev, 
void *data,
DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_ABGR2101010,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
 };
 
 struct intel_plane *
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/8] drm/i915: Add render decompression support

[Vidya Srinivas]

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.

Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.

Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
 but it works.

 Also not all planes will be capable of scanning out compressed 
surfaces,
 and eg. 90/270 degree rotation is not supported in combination 
with
 decompression either.

 This patch may contain work from at least the following people:
 * Vandana Kannan 
 * Daniel Vetter 
 * Ben Widawsky 

v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
Put the AUX register defines to the correct place
Fix up the slightly bogus rotation check
v4: Use I915_WRITE_FW() due to plane update locking changes
s/return -EINVAL/goto err/ in intel_framebuffer_init()
Eliminate a bunch hardcoded numbers in CCS code

Cc: Paulo Zanoni 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjä 
Reviewed-by: Ben Widawsky  (v1)
---
 drivers/gpu/drm/i915/i915_reg.h  |  23 
 drivers/gpu/drm/i915/intel_display.c | 241 ---
 drivers/gpu/drm/i915/intel_pm.c  |  29 -
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 4 files changed, 279 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c8647cf..41ddd25 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6106,6 +6106,10 @@ enum {
 #define _PLANE_KEYMSK_2_A  0x70298
 #define _PLANE_KEYMAX_1_A  0x701a0
 #define _PLANE_KEYMAX_2_A  0x702a0
+#define _PLANE_AUX_DIST_1_A0x701c0
+#define _PLANE_AUX_DIST_2_A0x702c0
+#define _PLANE_AUX_OFFSET_1_A  0x701c4
+#define _PLANE_AUX_OFFSET_2_A  0x702c4
 #define _PLANE_COLOR_CTL_1_A   0x701CC /* GLK+ */
 #define _PLANE_COLOR_CTL_2_A   0x702CC /* GLK+ */
 #define _PLANE_COLOR_CTL_3_A   0x703CC /* GLK+ */
@@ -6212,6 +6216,24 @@ enum {
 #define PLANE_NV12_BUF_CFG(pipe, plane)\
_MMIO_PLANE(plane, _PLANE_NV12_BUF_CFG_1(pipe), 
_PLANE_NV12_BUF_CFG_2(pipe))
 
+#define _PLANE_AUX_DIST_1_B0x711c0
+#define _PLANE_AUX_DIST_2_B0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, _PLANE_AUX_DIST_1_A, _PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, _PLANE_AUX_DIST_2_A, _PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define _PLANE_AUX_OFFSET_1_B  0x711c4
+#define _PLANE_AUX_OFFSET_2_B  0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, _PLANE_AUX_OFFSET_1_A, _PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, _PLANE_AUX_OFFSET_2_A, _PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
 #define _PLANE_COLOR_CTL_1_B   0x711CC
 #define _PLANE_COLOR_CTL_2_B   0x712CC
 #define _PLANE_COLOR_CTL_3_B   0x713CC
@@ -6695,6 +6717,7 @@ enum {
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
 
 #define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
 #define  DPA_MASK_VBLANK_SRD   (1 << 15)
 #define  FORCE_ARB_IDLE_PLANES (1 << 14)
 #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 80d09d6..18559c8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1999,11 +1999,19 @@ static unsigned int intel_tile_size(const struct 
drm_i915_private *dev_priv)
return 128;

[Intel-gfx] [PATCH 5/8] drm/i915: Upscale scaler max scale for NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch updates scaler max limit support for NV12

v2: Rebased (me)

Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 28 
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  3 ++-
 3 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 18559c8..9de836e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3438,6 +3438,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+   case DRM_FORMAT_NV12:
+   return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4801,7 +4803,8 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
  unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ uint32_t pixel_format)
 {
struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
@@ -4814,7 +4817,8 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 * the 90/270 degree plane rotation cases (to match the
 * GTT mapping), hence no need to account for rotation here.
 */
-   need_scaling = src_w != dst_w || src_h != dst_h;
+   need_scaling = src_w != dst_w || src_h != dst_h ||
+   (pixel_format == DRM_FORMAT_NV12);
 
/*
 * if plane is being disabled or scaler is no more required or force 
detach
@@ -4878,7 +4882,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
&state->scaler_state.scaler_id,
state->pipe_src_w, state->pipe_src_h,
-   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
+   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay, 0);
 }
 
 /**
@@ -4908,7 +4912,8 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
drm_rect_width(&plane_state->base.src) >> 16,
drm_rect_height(&plane_state->base.src) >> 16,
drm_rect_width(&plane_state->base.dst),
-   drm_rect_height(&plane_state->base.dst));
+   drm_rect_height(&plane_state->base.dst),
+   fb ? fb->format->format : 0);
 
if (ret || plane_state->scaler_id < 0)
return ret;
@@ -4934,6 +4939,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
@@ -13641,7 +13647,8 @@ static int intel_atomic_commit(struct drm_device *dev,
 }
 
 int
-skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+skl_max_scale(struct intel_crtc *intel_crtc,
+   struct intel_crtc_state *crtc_state, uint32_t pixel_format)
 {
struct drm_i915_private *dev_priv;
int max_scale;
@@ -13667,8 +13674,9 @@ static int intel_atomic_commit(struct drm_device *dev,
 *or
 *cdclk/crtc_clock
 */
-   max_scale = min((1 << 16) * 3 - 1,
-   (1 << 8) * ((max_dotclk << 8) / crtc_clock));
+   max_scale = min((1 << 16) *
+   (pixel_format == DRM_FORMAT_NV12 ? 2 : 3) - 1,
+   (1 << 8) * ((max_dotclk << 8) / crtc_clock));
 
return max_scale;
 }
@@ -13689,7 +13697,11 @@ static int intel_atomic_commit(struct drm_device *dev,
/* use scaler when colorkey is not required */
if (state->ckey.flags == I915_SET_COLORKEY_NONE) {
min_scale = 1;
-   max_scale = skl_max_scale(to_intel_crtc(crtc), 
crtc_state);
+   max_scale = skl_max_scale(to_intel_crtc(crtc),
+   crtc_state,
+   state->base.fb ?
+   state->base.fb->format->format :
+   0);
}
can_position = true;
}
diff --git a

[Intel-gfx] [PATCH 6/8] drm/i915: Add NV12 as supported format for primary plane

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for
primary plane

v2: Rebased (Chandra Konduru)

v3: Rebased (me)

v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats

Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 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 9de836e..83b20fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -85,6 +85,7 @@ static bool is_mmio_work(struct intel_flip_work *work)
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
 };
 
 /* Cursor formats */
@@ -13984,7 +13985,6 @@ void intel_plane_destroy(struct drm_plane *plane)
if (INTEL_GEN(dev_priv) >= 9) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
-
primary->update_plane = skylake_update_primary_plane;
primary->disable_plane = skylake_disable_primary_plane;
} else if (INTEL_GEN(dev_priv) >= 4) {
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/8] drm/i915: Implement .get_format_info() hook for CCS

[Vidya Srinivas]

From: Ville Syrjälä 

SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The location
of CCS is provided by userspace as just another plane with its own offset.

By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.

Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.

v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout
v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)

Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Reviewed-by: Ben Widawsky  (v3)
Signed-off-by: Ville Syrjä 
---
 drivers/gpu/drm/drm_fourcc.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c | 37 
 include/drm/drm_mode_config.h|  3 ++-
 include/uapi/drm/drm_fourcc.h|  3 +++
 4 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152d..50da618 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -222,7 +222,7 @@ const struct drm_format_info *drm_format_info(u32 format)
const struct drm_format_info *info = NULL;
 
if (dev->mode_config.funcs->get_format_info)
-   info = dev->mode_config.funcs->get_format_info(mode_cmd);
+   info = dev->mode_config.funcs->get_format_info(dev, mode_cmd);
 
if (!info)
info = drm_format_info(mode_cmd->pixel_format);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dec9e58..80d09d6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2433,6 +2433,42 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t 
fb_modifier)
}
 }
 
+static const struct drm_format_info ccs_formats[] = {
+   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+  int num_formats, u32 format)
+{
+   int i;
+
+   for (i = 0; i < num_formats; i++) {
+   if (formats[i].format == format)
+   return &formats[i];
+   }
+
+   return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *cmd)
+{
+   switch (cmd->modifier[0]) {
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+   default:
+   return NULL;
+   }
+}
+
 static int
 intel_fill_fb_info(struct drm_i915_private *dev_priv,
   struct drm_framebuffer *fb)
@@ -14607,6 +14643,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)
 
 static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+   .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4298171..f0d3d38 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -81,7 +81,8 @@ struct drm_mode_config_funcs {
 * The format information specific to the given fb metadata, or
 * NULL if none is found.
 */
-   const struct drm_format_info *(*get_format_info)(const struct 
drm_mode_fb_cmd2 *mode_cmd);
+   const struct drm_format_info *(*get_format_info)(struct drm_device *dev,
+   const struct drm_mode_fb_cmd2 *mode_cmd);
 
/**
 * @output_poll_changed:
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/dr

[Intel-gfx] [PATCH 0/8] Adding NV12 support for SKL display

[Vidya Srinivas]

This patch series is adding NV12 support for Skylake display after
rebasing on latest drm-intel-nightly. Initial series of the patches
can be found here:
https://lists.freedesktop.org/archives/intel-gfx/2015-May/066786.html

Feature has been currently tested with custom linux based test tool
IGT test development is under progress. Floating these patches for
initial review. These NV12 patches are dependent on Ville's patches
mentioned below.

Update from last rev:
Patches were initial reviewed last when floated but
currently there was a design change with respect to
- the way fb offset is handled
- the way rotation is handled
Rebase of the current NV12 patch series has been done as per the
current changes on drm-intel-nightly.
Review comments from Ville (12th June 2017) have been addressed

Chandra Konduru (6):
  drm/i915: Set scaler mode for NV12
  drm/i915: Update format_is_yuv() to include NV12
  drm/i915: Upscale scaler max scale for NV12
  drm/i915: Add NV12 as supported format for primary plane
  drm/i915: Add NV12 as supported format for sprite plane
  drm/i915: Add NV12 support to intel_framebuffer_init

Ville Syrjälä (2):
  drm/i915: Implement .get_format_info() hook for CCS
  drm/i915: Add render decompression support

 drivers/gpu/drm/drm_fourcc.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |  24 +++
 drivers/gpu/drm/i915/intel_atomic.c  |   8 +-
 drivers/gpu/drm/i915/intel_display.c | 312 ---
 drivers/gpu/drm/i915/intel_drv.h |   3 +-
 drivers/gpu/drm/i915/intel_pm.c  |  29 +++-
 drivers/gpu/drm/i915/intel_sprite.c  |  18 +-
 include/drm/drm_mode_config.h|   3 +-
 include/uapi/drm/drm_fourcc.h|   3 +
 9 files changed, 366 insertions(+), 36 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH I-G-T 1/2] igt/kms_pipe_crc_basic: Print pipe name when skipping

[Gabriel Krisman Bertazi]

Signed-off-by: Gabriel Krisman Bertazi 
---
 tests/kms_pipe_crc_basic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index f49b434857e6..177211249808 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -172,7 +172,8 @@ static void test_read_crc(data_t *data, int pipe, unsigned 
flags)
valid_connectors ++;
}
 
-   igt_require_f(valid_connectors, "No connector found for pipe %i\n", 
pipe);
+   igt_require_f(valid_connectors, "No connector found for pipe %s\n",
+ kmstest_pipe_name(pipe));
 }
 
 data_t data = {0, };
-- 
2.11.0

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

[Intel-gfx] [PATCH I-G-T 2/2] igt/kms_pipe_crc_basic: Skip test before system suspend

[Gabriel Krisman Bertazi]

Do a dummy crc read such that if there are no valid outputs for the
pipe, it skip the test before doing a system suspend.

Signed-off-by: Gabriel Krisman Bertazi 
---
 tests/kms_pipe_crc_basic.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
index 177211249808..35adddba648a 100644
--- a/tests/kms_pipe_crc_basic.c
+++ b/tests/kms_pipe_crc_basic.c
@@ -222,6 +222,9 @@ igt_main
 
igt_subtest_f("suspend-read-crc-pipe-%c", 'A'+i) {
igt_skip_on(i >= data.display.n_pipes);
+
+   test_read_crc(&data, i, 0);
+
igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
  SUSPEND_TEST_NONE);
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Wait for concurrent global resets to complete

[Michel Thierry]

On 19/06/17 08:37, Chris Wilson wrote:

If we enter i915_handle_error() a second time and a global reset is
already in progress, we can simply wait for completion of the first
reset. Currently we exit earlier prior to the actual reset being
performed -- the worst of both worlds!

v2: Plug into the existing reset_queue, and remember that kselftests is
playing games with I915_RESET_BACKOFF to prevent hangcheck from screwing
up.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_irq.c  | 23 +++
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c |  4 
 2 files changed, 15 insertions(+), 12 deletions(-)



Reviewed-by: Michel Thierry 

And thanks for renaming i915_reset_and_wakeup, it looks better when 
reset_engine is also there.

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

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Andrey Grodzovsky]

On 06/19/2017 03:24 PM, Sean Paul wrote:

On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote:

On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:

Problem:
While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immidietly follwoing an atomic_commit.

s/immidietly/immediately/g
s/follwoing/following/g


After dumping the atomic state I relized that in this case there was
not even one CRTC attached to the state and only disabled
planes. This probably due to a commit which hadn't changed any property
which would require attaching crtc state. This means drmHandleEvent
will never wake up from read since without CRTC in atomic state
the event fd will not be singnaled.

s/singnaled/signaled/g


This point to a bug in IGT but also DRM should gracefully
fail  such scenario so no hang on user side will happen.


Can we create an IGT fix for this to make sure this won't happen?


Fix:
Explicitly fail by failing atomic_commit early in
drm_mode_atomic_commit where such problem can be identified.


The change seems reasonable to me but I would like to see some input
from someone who's more familiar with the usermode side of things.

I wonder if there's ever a case where it might be desirable to generate an event
from a commit without a crtc. I don't know if anyone has explicitly said that an
event can only be generated from state with crtc.

For a generic event i agree, bit seems to me without active CRTC no way you
can  expect PAGE_FLIP_EVENT to fire.


I usually don't mind letting userspace shoot itself in the foot, so keep that in
mind :)

Sean


Seems to me you still would try to avoid a bad configuration, returning 
error
will help debugging for user who made a mistake. I also see something 
similar

in drm_mode_atomic_ioctl around line 2122 -

/* can't test and expect an event at the same time. */
if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
(arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
return -EINVAL;

Thanks,
Andrey

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_atomic.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..32eae1c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
  {
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
-   int i, ret;
+   int i, c = 0, ret;
  
  	if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)

return 0;
@@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device *dev,
  
  			crtc_state->event->base.fence = fence;

}
+
+   c++;

Not sure if intentional, but I like it.


}
  
+	/*

+* Having this flag means user mode pends on event which will never
+* reach due to lack of at least one CRTC for signaling
+*/
+   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+   return -EINVAL;
+
return 0;
  }
  
@@ -2179,6 +2188,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,

drm_mode_object_unreference(obj);
}
  
+

+

Remove these extraneous newlines.

Harry


ret = prepare_crtc_signaling(dev, state, arg, file_priv, &fence_state,
 &num_fences);
if (ret)



___
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/cfl: Fix Workarounds.

[Patchwork]

== Series Details ==

Series: drm/i915/cfl: Fix Workarounds.
URL   : https://patchwork.freedesktop.org/series/26010/
State : success

== Summary ==

Series 26010v1 drm/i915/cfl: Fix Workarounds.
https://patchwork.freedesktop.org/api/1.0/series/26010/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-r) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:459s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:490s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:547s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:491s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:583s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:429s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:419s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:463s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:505s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:514s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:576s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:572s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:475s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:432s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:515s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:499s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:503s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:619s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:0   skip:29  
time:404s

28880958b7cd59f14172c942d82182acf104d880 drm-tip: 2017y-06m-19d-21h-07m-06s UTC 
integration manifest
f241681 drm/i915/cfl: Fix Workarounds.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4990/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/cfl: Fix Workarounds.

[Rodrigo Vivi]

During the review of Coffee Lake workarounds Mika pointed out
that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC
should be removed from CFL and with that I should carry the rv-b.

However when doing the v2 I removed another Workaround that should
remain because although not mentioned by spec the history of hangs
around it advocates on its favor.

On some follow-up patches I continued operating on the wrong
workardound, but Ville noticed that, so here is the fix for the
current CFL code that is upstream already.

Fixes: 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake workarounds.")
Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Mika Kuoppala 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a4487c5..5b4de71 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -821,9 +821,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
   GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
 
-   /* WaDisableKillLogic:bxt,skl,kbl,cfl */
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
-  ECOCHK_DIS_TLB);
+   /* WaDisableKillLogic:bxt,skl,kbl */
+   if (!IS_COFFEELAKE(dev_priv))
+   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
+  ECOCHK_DIS_TLB);
 
/* WaClearFlowControlGpgpuContextSave:skl,bxt,kbl,glk,cfl */
/* WaDisablePartialInstShootdown:skl,bxt,kbl,glk,cfl */
@@ -894,10 +895,9 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT_MASKED(HDC_CHICKEN0,
  HDC_FORCE_NON_COHERENT);
 
-   /* WaDisableHDCInvalidation:skl,bxt,kbl */
-   if (!IS_COFFEELAKE(dev_priv))
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
-  BDW_DISABLE_HDC_INVALIDATION);
+   /* WaDisableHDCInvalidation:skl,bxt,kbl,cfl */
+   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
+  BDW_DISABLE_HDC_INVALIDATION);
 
/* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
if (IS_SKYLAKE(dev_priv) ||
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

[Rodrigo Vivi]

Patch merged to dinq, thanks for spotting this and also for reviews
and comments.

On Mon, Jun 19, 2017 at 11:39 AM, Rodrigo Vivi  wrote:
> Paulo noticed that we were missing few bits clear
> before writing values back to the register on
> these RMW MMIO operations.
>
> v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
> v3: Remove unnecessary braces. (Jani).
>
> Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
> Cc: Paulo Zanoni 
> Cc: Manasi Navare 
> Cc: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 9 +
>  drivers/gpu/drm/i915/intel_ddi.c | 7 +++
>  2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bd535f1..c8647cf 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1764,8 +1764,11 @@ enum skl_disp_power_wells {
> _CNL_PORT_TX_DW2_LN0_AE, \
> _CNL_PORT_TX_DW2_LN0_F)
>  #define   SWING_SEL_UPPER(x)   ((x >> 3) << 15)
> +#define   SWING_SEL_UPPER_MASK (1 << 15)
>  #define   SWING_SEL_LOWER(x)   ((x & 0x7) << 11)
> +#define   SWING_SEL_LOWER_MASK (0x7 << 11)
>  #define   RCOMP_SCALAR(x)  ((x) << 0)
> +#define   RCOMP_SCALAR_MASK(0xFF << 0)
>
>  #define _CNL_PORT_TX_DW4_GRP_AE0x162350
>  #define _CNL_PORT_TX_DW4_GRP_B 0x1623D0
> @@ -1795,8 +1798,11 @@ enum skl_disp_power_wells {
> _CNL_PORT_TX_DW4_LN0_F)
>  #define   LOADGEN_SELECT   (1 << 31)
>  #define   POST_CURSOR_1(x) ((x) << 12)
> +#define   POST_CURSOR_1_MASK   (0x3F << 12)
>  #define   POST_CURSOR_2(x) ((x) << 6)
> +#define   POST_CURSOR_2_MASK   (0x3F << 6)
>  #define   CURSOR_COEFF(x)  ((x) << 0)
> +#define   CURSOR_COEFF_MASK(0x3F << 6)
>
>  #define _CNL_PORT_TX_DW5_GRP_AE0x162354
>  #define _CNL_PORT_TX_DW5_GRP_B 0x1623D4
> @@ -1825,7 +1831,9 @@ enum skl_disp_power_wells {
>  #define   TX_TRAINING_EN   (1 << 31)
>  #define   TAP3_DISABLE (1 << 29)
>  #define   SCALING_MODE_SEL(x)  ((x) << 18)
> +#define   SCALING_MODE_SEL_MASK(0x7 << 18)
>  #define   RTERM_SELECT(x)  ((x) << 3)
> +#define   RTERM_SELECT_MASK(0x7 << 3)
>
>  #define _CNL_PORT_TX_DW7_GRP_AE0x16235C
>  #define _CNL_PORT_TX_DW7_GRP_B 0x1623DC
> @@ -1852,6 +1860,7 @@ enum skl_disp_power_wells {
> _CNL_PORT_TX_DW7_LN0_AE, \
> _CNL_PORT_TX_DW7_LN0_F)
>  #define   N_SCALAR(x)  ((x) << 24)
> +#define   N_SCALAR_MASK(0x7F << 24)
>
>  /* The spec defines this only for BXT PHY0, but lets assume that this
>   * would exist for PHY1 too if it had a second channel.
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index db80938..80e96f1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1813,11 +1813,14 @@ static void cnl_ddi_vswing_program(struct 
> drm_i915_private *dev_priv,
>
> /* Set PORT_TX_DW5 Scaling Mode Sel to 010b. */
> val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
> +   val &= ~SCALING_MODE_SEL_MASK;
> val |= SCALING_MODE_SEL(2);
> I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
>
> /* Program PORT_TX_DW2 */
> val = I915_READ(CNL_PORT_TX_DW2_LN0(port));
> +   val &= ~(SWING_SEL_LOWER_MASK | SWING_SEL_UPPER_MASK |
> +RCOMP_SCALAR_MASK);
> val |= SWING_SEL_UPPER(ddi_translations[level].dw2_swing_sel);
> val |= SWING_SEL_LOWER(ddi_translations[level].dw2_swing_sel);
> /* Rcomp scalar is fixed as 0x98 for every table entry */
> @@ -1828,6 +1831,8 @@ static void cnl_ddi_vswing_program(struct 
> drm_i915_private *dev_priv,
> /* We cannot write to GRP. It would overrite individual loadgen */
> for (ln = 0; ln < 4; ln++) {
> val = I915_READ(CNL_PORT_TX_DW4_LN(port, ln));
> +   val &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
> +CURSOR_COEFF_MASK);
> val |= 
> POST_CURSOR_1(ddi_translations[level].dw4_post_cursor_1);
> val |= 
> POST_CURSOR_2(ddi_translations[level].dw4_post_cursor_2);
> val |= CURSOR_COEFF(ddi_translations[level].dw4_cursor_coeff);
> @@ -1837,12 +1842,14 @@ static void cnl_ddi_vswing_program(struct 
> drm_i915_private *dev_priv,
>  /* Program PORT_TX_DW5 */
> /* All DW5 values are fixed for every table entry */
> val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
> +   val &= ~RTE

Re: [Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

[Jani Nikula]

On Mon, 19 Jun 2017, Dhinakaran Pandiyan  wrote:
> Maarten and Ville noticed that we are enabling backlight via DP aux very
> early in the modeset_init path via the intel_dp_aux_setup_backlight()
> function, since commit e7156c833903 ("drm/i915: Add Backlight Control using
> DPCD for eDP connectors (v9)"). Looks like all we need to do during
> _setup_backlight() is read the current brightness state instead of
> modifying it.
>
> v2: Rewrote commit message.
>
> Cc: Ville Syrjala 
> Cc: Maarten Lankhorst 
> Cc: Jani Nikula 
> Cc: Yetunde Adebisi 
> Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Maarten Lankhorst 
> Acked-by: Jani Nikula 
> Tested-by: Puthikorn Voravootivat 
> Fixes: e7156c833903 ("drm/i915: Add Backlight Control using DPCD for eDP 
> connectors (v9)")
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1497384239-2965-1-git-send-email-dhinakaran.pandi...@intel.com
> Signed-off-by: Ville Syrjälä 
> (cherry picked from commit f6262bda462e81e959b80a96dac799bd9df27f73)

Pushed to drm-intel-fixes, thanks for the backport.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 6532e22..40ba313 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -119,8 +119,6 @@ static int intel_dp_aux_setup_backlight(struct 
> intel_connector *connector,
>   struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
>   struct intel_panel *panel = &connector->panel;
>  
> - intel_dp_aux_enable_backlight(connector);
> -
>   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
>   panel->backlight.max = 0x;
>   else

-- 
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] drm/i915: Make intel_digital_port_connected() work for any port

[Ville Syrjälä]

On Mon, Jun 19, 2017 at 12:06:07PM -0700, Manasi Navare wrote:
> I have tested this for PORT A and works great to give HPD live status.
> Thanks for the patch. Looks good to me.
> 
> On Thu, Jun 15, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Add the missing port A handling to intel_digital_port_connected()
> > and also separate SPT from the CPT/LPT code a bit.
> > 
>  Reviewed-by: Manasi Navare 

Thanks. Pushed to dinq.

> > Cc: Manasi Navare 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 83 
> > ++---
> >  1 file changed, 70 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 64fa774c855b..bca4ac12f950 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4418,8 +4418,6 @@ static bool ibx_digital_port_connected(struct 
> > drm_i915_private *dev_priv,
> > u32 bit;
> >  
> > switch (port->port) {
> > -   case PORT_A:
> > -   return true;
> > case PORT_B:
> > bit = SDE_PORTB_HOTPLUG;
> > break;
> > @@ -4443,8 +4441,6 @@ static bool cpt_digital_port_connected(struct 
> > drm_i915_private *dev_priv,
> > u32 bit;
> >  
> > switch (port->port) {
> > -   case PORT_A:
> > -   return true;
> > case PORT_B:
> > bit = SDE_PORTB_HOTPLUG_CPT;
> > break;
> > @@ -4454,12 +4450,28 @@ static bool cpt_digital_port_connected(struct 
> > drm_i915_private *dev_priv,
> > case PORT_D:
> > bit = SDE_PORTD_HOTPLUG_CPT;
> > break;
> > +   default:
> > +   MISSING_CASE(port->port);
> > +   return false;
> > +   }
> > +
> > +   return I915_READ(SDEISR) & bit;
> > +}
> > +
> > +static bool spt_digital_port_connected(struct drm_i915_private *dev_priv,
> > +  struct intel_digital_port *port)
> > +{
> > +   u32 bit;
> > +
> > +   switch (port->port) {
> > +   case PORT_A:
> > +   bit = SDE_PORTA_HOTPLUG_SPT;
> > +   break;
> > case PORT_E:
> > bit = SDE_PORTE_HOTPLUG_SPT;
> > break;
> > default:
> > -   MISSING_CASE(port->port);
> > -   return false;
> > +   return cpt_digital_port_connected(dev_priv, port);
> > }
> >  
> > return I915_READ(SDEISR) & bit;
> > @@ -4511,6 +4523,42 @@ static bool gm45_digital_port_connected(struct 
> > drm_i915_private *dev_priv,
> > return I915_READ(PORT_HOTPLUG_STAT) & bit;
> >  }
> >  
> > +static bool ilk_digital_port_connected(struct drm_i915_private *dev_priv,
> > +  struct intel_digital_port *port)
> > +{
> > +   if (port->port == PORT_A)
> > +   return I915_READ(DEISR) & DE_DP_A_HOTPLUG;
> > +   else
> > +   return ibx_digital_port_connected(dev_priv, port);
> > +}
> > +
> > +static bool snb_digital_port_connected(struct drm_i915_private *dev_priv,
> > +  struct intel_digital_port *port)
> > +{
> > +   if (port->port == PORT_A)
> > +   return I915_READ(DEISR) & DE_DP_A_HOTPLUG;
> > +   else
> > +   return cpt_digital_port_connected(dev_priv, port);
> > +}
> > +
> > +static bool ivb_digital_port_connected(struct drm_i915_private *dev_priv,
> > +  struct intel_digital_port *port)
> > +{
> > +   if (port->port == PORT_A)
> > +   return I915_READ(DEISR) & DE_DP_A_HOTPLUG_IVB;
> > +   else
> > +   return cpt_digital_port_connected(dev_priv, port);
> > +}
> > +
> > +static bool bdw_digital_port_connected(struct drm_i915_private *dev_priv,
> > +  struct intel_digital_port *port)
> > +{
> > +   if (port->port == PORT_A)
> > +   return I915_READ(GEN8_DE_PORT_ISR) & GEN8_PORT_DP_A_HOTPLUG;
> > +   else
> > +   return cpt_digital_port_connected(dev_priv, port);
> > +}
> > +
> >  static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
> >struct intel_digital_port 
> > *intel_dig_port)
> >  {
> > @@ -4547,16 +4595,25 @@ static bool bxt_digital_port_connected(struct 
> > drm_i915_private *dev_priv,
> >  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> >   struct intel_digital_port *port)
> >  {
> > -   if (HAS_PCH_IBX(dev_priv))
> > -   return ibx_digital_port_connected(dev_priv, port);
> > -   else if (HAS_PCH_SPLIT(dev_priv))
> > -   return cpt_digital_port_connected(dev_priv, port);
> > +   if (HAS_GMCH_DISPLAY(dev_priv)) {
> > +   if (IS_GM45(dev_priv))
> > +   return gm45_digital_port_connected(dev_priv, port);
> > +   else
> > +   return g4x_digital_port_connected(dev_priv, port);
> > +   }
> > +
> > +   if (IS_GEN5(dev_priv))
> > +   return ilk_digital_po

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Sean Paul]

On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote:
> On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> > Problem:
> > While running IGT kms_atomic_transition test suite i encountered
> > a hang in drmHandleEvent immidietly follwoing an atomic_commit.
> 
> s/immidietly/immediately/g
> s/follwoing/following/g
> 
> > After dumping the atomic state I relized that in this case there was
> > not even one CRTC attached to the state and only disabled
> > planes. This probably due to a commit which hadn't changed any property
> > which would require attaching crtc state. This means drmHandleEvent
> > will never wake up from read since without CRTC in atomic state
> > the event fd will not be singnaled.
> 
> s/singnaled/signaled/g
> 
> > This point to a bug in IGT but also DRM should gracefully
> > fail  such scenario so no hang on user side will happen.
> > 
> 
> Can we create an IGT fix for this to make sure this won't happen?
> 
> > Fix:
> > Explicitly fail by failing atomic_commit early in
> > drm_mode_atomic_commit where such problem can be identified.
> > 
> 
> The change seems reasonable to me but I would like to see some input
> from someone who's more familiar with the usermode side of things.

I wonder if there's ever a case where it might be desirable to generate an event
from a commit without a crtc. I don't know if anyone has explicitly said that an
event can only be generated from state with crtc.

I usually don't mind letting userspace shoot itself in the foot, so keep that in
mind :)

Sean


> 
> > Signed-off-by: Andrey Grodzovsky 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index a567310..32eae1c 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> > *dev,
> >  {
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *crtc_state;
> > -   int i, ret;
> > +   int i, c = 0, ret;
> >  
> > if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
> > return 0;
> > @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
> > *dev,
> >  
> > crtc_state->event->base.fence = fence;
> > }
> > +
> > +   c++;
> 
> Not sure if intentional, but I like it.
> 
> > }
> >  
> > +   /*
> > +* Having this flag means user mode pends on event which will never
> > +* reach due to lack of at least one CRTC for signaling
> > +*/
> > +   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> > +   return -EINVAL;
> > +
> > return 0;
> >  }
> >  
> > @@ -2179,6 +2188,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > drm_mode_object_unreference(obj);
> > }
> >  
> > +
> > +
> 
> Remove these extraneous newlines.
> 
> Harry
> 
> > ret = prepare_crtc_signaling(dev, state, arg, file_priv, &fence_state,
> >  &num_fences);
> > if (ret)
> > 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
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/cnl: Fix RMW on ddi vswing sequence. (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev4)
URL   : https://patchwork.freedesktop.org/series/25935/
State : success

== Summary ==

Series 25935v4 drm/i915/cnl: Fix RMW on ddi vswing sequence.
https://patchwork.freedesktop.org/api/1.0/series/25935/revisions/4/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:464s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:483s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:589s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:548s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:490s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:582s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:430s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:416s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:469s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:511s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:566s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:573s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:476s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:433s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:516s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:503s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:503s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:620s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

8f66eff8aa12ae767fd53f6b0e3badc2258d3d5c drm-tip: 2017y-06m-19d-17h-57m-19s UTC 
integration manifest
45c9690 drm/i915/cnl: Fix RMW on ddi vswing sequence.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4989/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

[Ville Syrjälä]

On Mon, Jun 19, 2017 at 07:01:21PM +, Vivi, Rodrigo wrote:
> On Mon, 2017-06-19 at 21:22 +0300, Ville Syrjälä wrote:
> > On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote:
> > > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake 
> > > workarounds.")
> > > Mika pointed out that Spec tells those 2 workarounds were not needed.
> > > 
> > > So when double checking I confirmed that and also that by Spec
> > > they only apply to SKL and BXT.
> > > 
> > > v2: Instead of increase the if/else move the wa
> > > to individual platform functions. (Ville).
> > > Also remove from GLK since spec only mentions SKL and BXT.
> > 
> > The spec seems to be telling me that these shouldn't needed on any
> > platform. But there are scary comments in the code saying that they
> > have been kept to cure some hangs. Probably best to wair for Mika to be
> > back to review this one.
> 
> About WaDisableKillLogic:

The patch didn't seem to touch WaDisableKillLogic. Or maybe I read the
wrong patch.

> 
> Bspec: Gen 9 Workarounds: 
> #0684 3D  WaDisableKillLogic - SKL and BXT.
> 
> About the other one:
> 
> GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC...
> Fun, but it is not in the spec anymore indeed. If you search for e184
> gen9 workarounds page is listed, but it is not mentioned anymore.
> Mika and I indeed saw that there at some point for SKL at least, but not
> for others..
> 
> not sure!
> 
> > 
> > > 
> > > Cc: Ander Conselvan de Oliveira 
> > > Cc: Ville Syrjälä 
> > > Cc: Mika Kuoppala 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/intel_engine_cs.c | 26 --
> > >  1 file changed, 16 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > index a4487c5..33c3a9d 100644
> > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > @@ -831,11 +831,6 @@ static int gen9_init_workarounds(struct 
> > > intel_engine_cs *engine)
> > > FLOW_CONTROL_ENABLE |
> > > PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
> > >  
> > > - /* Syncing dependencies between camera and graphics:skl,bxt,kbl */
> > > - if (!IS_COFFEELAKE(dev_priv))
> > > - WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> > > -   GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> > > -
> > >   /* WaDisableDgMirrorFixInHalfSliceChicken5:bxt */
> > >   if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
> > >   WA_CLR_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN5,
> > > @@ -894,11 +889,6 @@ static int gen9_init_workarounds(struct 
> > > intel_engine_cs *engine)
> > >   WA_SET_BIT_MASKED(HDC_CHICKEN0,
> > > HDC_FORCE_NON_COHERENT);
> > >  
> > > - /* WaDisableHDCInvalidation:skl,bxt,kbl */
> > > - if (!IS_COFFEELAKE(dev_priv))
> > > - I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> > > -BDW_DISABLE_HDC_INVALIDATION);
> > > -
> > >   /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
> > >   if (IS_SKYLAKE(dev_priv) ||
> > >   IS_KABYLAKE(dev_priv) ||
> > > @@ -1007,6 +997,14 @@ static int skl_init_workarounds(struct 
> > > intel_engine_cs *engine)
> > >   if (ret)
> > >   return ret;
> > >  
> > > + /* Syncing dependencies between camera and graphics:skl */
> > > + WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> > > +   GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> > > +
> > > + /* WaDisableHDCInvalidation:skl */
> > > + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> > > +BDW_DISABLE_HDC_INVALIDATION);
> > > +
> > >   return skl_tune_iz_hashing(engine);
> > >  }
> > >  
> > > @@ -1076,6 +1074,14 @@ static int bxt_init_workarounds(struct 
> > > intel_engine_cs *engine)
> > >   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
> > >  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> > >  
> > > + /* Syncing dependencies between camera and graphics:bxt */
> > > + WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> > > +   GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> > > +
> > > + /* WaDisableHDCInvalidation:bxt */
> > > + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> > > +BDW_DISABLE_HDC_INVALIDATION);
> > > +
> > >   return 0;
> > >  }
> > >  
> > > -- 
> > > 1.9.1
> > 
> 

-- 
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] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

[Vivi, Rodrigo]

On Mon, 2017-06-19 at 21:22 +0300, Ville Syrjälä wrote:
> On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote:
> > When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake 
> > workarounds.")
> > Mika pointed out that Spec tells those 2 workarounds were not needed.
> > 
> > So when double checking I confirmed that and also that by Spec
> > they only apply to SKL and BXT.
> > 
> > v2: Instead of increase the if/else move the wa
> > to individual platform functions. (Ville).
> > Also remove from GLK since spec only mentions SKL and BXT.
> 
> The spec seems to be telling me that these shouldn't needed on any
> platform. But there are scary comments in the code saying that they
> have been kept to cure some hangs. Probably best to wair for Mika to be
> back to review this one.

About WaDisableKillLogic:

Bspec: Gen 9 Workarounds: 
#0684   3D  WaDisableKillLogic - SKL and BXT.

About the other one:

GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC...
Fun, but it is not in the spec anymore indeed. If you search for e184
gen9 workarounds page is listed, but it is not mentioned anymore.
Mika and I indeed saw that there at some point for SKL at least, but not
for others..

not sure!

> 
> > 
> > Cc: Ander Conselvan de Oliveira 
> > Cc: Ville Syrjälä 
> > Cc: Mika Kuoppala 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 26 --
> >  1 file changed, 16 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index a4487c5..33c3a9d 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -831,11 +831,6 @@ static int gen9_init_workarounds(struct 
> > intel_engine_cs *engine)
> >   FLOW_CONTROL_ENABLE |
> >   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
> >  
> > -   /* Syncing dependencies between camera and graphics:skl,bxt,kbl */
> > -   if (!IS_COFFEELAKE(dev_priv))
> > -   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> > - GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> > -
> > /* WaDisableDgMirrorFixInHalfSliceChicken5:bxt */
> > if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
> > WA_CLR_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN5,
> > @@ -894,11 +889,6 @@ static int gen9_init_workarounds(struct 
> > intel_engine_cs *engine)
> > WA_SET_BIT_MASKED(HDC_CHICKEN0,
> >   HDC_FORCE_NON_COHERENT);
> >  
> > -   /* WaDisableHDCInvalidation:skl,bxt,kbl */
> > -   if (!IS_COFFEELAKE(dev_priv))
> > -   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> > -  BDW_DISABLE_HDC_INVALIDATION);
> > -
> > /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
> > if (IS_SKYLAKE(dev_priv) ||
> > IS_KABYLAKE(dev_priv) ||
> > @@ -1007,6 +997,14 @@ static int skl_init_workarounds(struct 
> > intel_engine_cs *engine)
> > if (ret)
> > return ret;
> >  
> > +   /* Syncing dependencies between camera and graphics:skl */
> > +   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> > + GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> > +
> > +   /* WaDisableHDCInvalidation:skl */
> > +   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> > +  BDW_DISABLE_HDC_INVALIDATION);
> > +
> > return skl_tune_iz_hashing(engine);
> >  }
> >  
> > @@ -1076,6 +1074,14 @@ static int bxt_init_workarounds(struct 
> > intel_engine_cs *engine)
> > WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
> >GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> >  
> > +   /* Syncing dependencies between camera and graphics:bxt */
> > +   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> > + GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> > +
> > +   /* WaDisableHDCInvalidation:bxt */
> > +   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> > +  BDW_DISABLE_HDC_INVALIDATION);
> > +
> > return 0;
> >  }
> >  
> > -- 
> > 1.9.1
> 

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

Re: [Intel-gfx] [PATCH] drm/i915: Make intel_digital_port_connected() work for any port

[Manasi Navare]

I have tested this for PORT A and works great to give HPD live status.
Thanks for the patch. Looks good to me.

On Thu, Jun 15, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Add the missing port A handling to intel_digital_port_connected()
> and also separate SPT from the CPT/LPT code a bit.
> 
 Reviewed-by: Manasi Navare 
> Cc: Manasi Navare 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 83 
> ++---
>  1 file changed, 70 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 64fa774c855b..bca4ac12f950 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4418,8 +4418,6 @@ static bool ibx_digital_port_connected(struct 
> drm_i915_private *dev_priv,
>   u32 bit;
>  
>   switch (port->port) {
> - case PORT_A:
> - return true;
>   case PORT_B:
>   bit = SDE_PORTB_HOTPLUG;
>   break;
> @@ -4443,8 +4441,6 @@ static bool cpt_digital_port_connected(struct 
> drm_i915_private *dev_priv,
>   u32 bit;
>  
>   switch (port->port) {
> - case PORT_A:
> - return true;
>   case PORT_B:
>   bit = SDE_PORTB_HOTPLUG_CPT;
>   break;
> @@ -4454,12 +4450,28 @@ static bool cpt_digital_port_connected(struct 
> drm_i915_private *dev_priv,
>   case PORT_D:
>   bit = SDE_PORTD_HOTPLUG_CPT;
>   break;
> + default:
> + MISSING_CASE(port->port);
> + return false;
> + }
> +
> + return I915_READ(SDEISR) & bit;
> +}
> +
> +static bool spt_digital_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port)
> +{
> + u32 bit;
> +
> + switch (port->port) {
> + case PORT_A:
> + bit = SDE_PORTA_HOTPLUG_SPT;
> + break;
>   case PORT_E:
>   bit = SDE_PORTE_HOTPLUG_SPT;
>   break;
>   default:
> - MISSING_CASE(port->port);
> - return false;
> + return cpt_digital_port_connected(dev_priv, port);
>   }
>  
>   return I915_READ(SDEISR) & bit;
> @@ -4511,6 +4523,42 @@ static bool gm45_digital_port_connected(struct 
> drm_i915_private *dev_priv,
>   return I915_READ(PORT_HOTPLUG_STAT) & bit;
>  }
>  
> +static bool ilk_digital_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port)
> +{
> + if (port->port == PORT_A)
> + return I915_READ(DEISR) & DE_DP_A_HOTPLUG;
> + else
> + return ibx_digital_port_connected(dev_priv, port);
> +}
> +
> +static bool snb_digital_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port)
> +{
> + if (port->port == PORT_A)
> + return I915_READ(DEISR) & DE_DP_A_HOTPLUG;
> + else
> + return cpt_digital_port_connected(dev_priv, port);
> +}
> +
> +static bool ivb_digital_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port)
> +{
> + if (port->port == PORT_A)
> + return I915_READ(DEISR) & DE_DP_A_HOTPLUG_IVB;
> + else
> + return cpt_digital_port_connected(dev_priv, port);
> +}
> +
> +static bool bdw_digital_port_connected(struct drm_i915_private *dev_priv,
> +struct intel_digital_port *port)
> +{
> + if (port->port == PORT_A)
> + return I915_READ(GEN8_DE_PORT_ISR) & GEN8_PORT_DP_A_HOTPLUG;
> + else
> + return cpt_digital_port_connected(dev_priv, port);
> +}
> +
>  static bool bxt_digital_port_connected(struct drm_i915_private *dev_priv,
>  struct intel_digital_port 
> *intel_dig_port)
>  {
> @@ -4547,16 +4595,25 @@ static bool bxt_digital_port_connected(struct 
> drm_i915_private *dev_priv,
>  bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
> struct intel_digital_port *port)
>  {
> - if (HAS_PCH_IBX(dev_priv))
> - return ibx_digital_port_connected(dev_priv, port);
> - else if (HAS_PCH_SPLIT(dev_priv))
> - return cpt_digital_port_connected(dev_priv, port);
> + if (HAS_GMCH_DISPLAY(dev_priv)) {
> + if (IS_GM45(dev_priv))
> + return gm45_digital_port_connected(dev_priv, port);
> + else
> + return g4x_digital_port_connected(dev_priv, port);
> + }
> +
> + if (IS_GEN5(dev_priv))
> + return ilk_digital_port_connected(dev_priv, port);
> + else if (IS_GEN6(dev_priv))
> + return snb_digital_port_connected(dev_priv, port);
> + else if (IS_GEN7(dev_priv))
> + return ivb_digital_port_connected(dev

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Jani Nikula]

On Thu, 15 Jun 2017, Imre Deak  wrote:
> On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
>> I believe it is worth allowing RPM to work without requiring DMC, no?!
>
> Not if there is no good reason for not using DMC. It was decided early
> on that we won't support that configuration since if you care about the
> power saving provided by partially disabling things you probably also
> care about the bigger power saving provided by DMC. So that is the
> current state of the driver, enabling runtime PM without having DMC
> loaded is not supported. Proper support for that would need to be added
> after a justification why not to use the firmware.

Agreed. We already have too many configurations to support, and we
already struggle with our testing coverage as-is. Adding new
configurations to be tested is not to be taken lightly.

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

Re: [Intel-gfx] [PATCH v9 05/21] drm/i915: Add support for per engine reset recovery

[Michel Thierry]

On 19/06/17 05:46, Chris Wilson wrote:

Quoting Michel Thierry (2017-06-15 21:18:12)

@@ -2992,10 +3014,8 @@ void i915_gem_reset_finish(struct drm_i915_private 
*dev_priv)

lockdep_assert_held(&dev_priv->drm.struct_mutex);

-   for_each_engine(engine, dev_priv, id) {
-   tasklet_enable(&engine->irq_tasklet);
-   kthread_unpark(engine->breadcrumbs.signaler);
-   }
+   for_each_engine(engine, dev_priv, id)
+   i915_gem_reset_finish_engine(engine);


And we shouldn't forget to clear the active_request here!


The hangcheck.active_request?

And thanks for spotting the break/continue error.

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

[Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

[Rodrigo Vivi]

Paulo noticed that we were missing few bits clear
before writing values back to the register on
these RMW MMIO operations.

v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
v3: Remove unnecessary braces. (Jani).

Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo Zanoni 
Cc: Manasi Navare 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h  | 9 +
 drivers/gpu/drm/i915/intel_ddi.c | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bd535f1..c8647cf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1764,8 +1764,11 @@ enum skl_disp_power_wells {
_CNL_PORT_TX_DW2_LN0_AE, \
_CNL_PORT_TX_DW2_LN0_F)
 #define   SWING_SEL_UPPER(x)   ((x >> 3) << 15)
+#define   SWING_SEL_UPPER_MASK (1 << 15)
 #define   SWING_SEL_LOWER(x)   ((x & 0x7) << 11)
+#define   SWING_SEL_LOWER_MASK (0x7 << 11)
 #define   RCOMP_SCALAR(x)  ((x) << 0)
+#define   RCOMP_SCALAR_MASK(0xFF << 0)
 
 #define _CNL_PORT_TX_DW4_GRP_AE0x162350
 #define _CNL_PORT_TX_DW4_GRP_B 0x1623D0
@@ -1795,8 +1798,11 @@ enum skl_disp_power_wells {
_CNL_PORT_TX_DW4_LN0_F)
 #define   LOADGEN_SELECT   (1 << 31)
 #define   POST_CURSOR_1(x) ((x) << 12)
+#define   POST_CURSOR_1_MASK   (0x3F << 12)
 #define   POST_CURSOR_2(x) ((x) << 6)
+#define   POST_CURSOR_2_MASK   (0x3F << 6)
 #define   CURSOR_COEFF(x)  ((x) << 0)
+#define   CURSOR_COEFF_MASK(0x3F << 6)
 
 #define _CNL_PORT_TX_DW5_GRP_AE0x162354
 #define _CNL_PORT_TX_DW5_GRP_B 0x1623D4
@@ -1825,7 +1831,9 @@ enum skl_disp_power_wells {
 #define   TX_TRAINING_EN   (1 << 31)
 #define   TAP3_DISABLE (1 << 29)
 #define   SCALING_MODE_SEL(x)  ((x) << 18)
+#define   SCALING_MODE_SEL_MASK(0x7 << 18)
 #define   RTERM_SELECT(x)  ((x) << 3)
+#define   RTERM_SELECT_MASK(0x7 << 3)
 
 #define _CNL_PORT_TX_DW7_GRP_AE0x16235C
 #define _CNL_PORT_TX_DW7_GRP_B 0x1623DC
@@ -1852,6 +1860,7 @@ enum skl_disp_power_wells {
_CNL_PORT_TX_DW7_LN0_AE, \
_CNL_PORT_TX_DW7_LN0_F)
 #define   N_SCALAR(x)  ((x) << 24)
+#define   N_SCALAR_MASK(0x7F << 24)
 
 /* The spec defines this only for BXT PHY0, but lets assume that this
  * would exist for PHY1 too if it had a second channel.
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index db80938..80e96f1 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1813,11 +1813,14 @@ static void cnl_ddi_vswing_program(struct 
drm_i915_private *dev_priv,
 
/* Set PORT_TX_DW5 Scaling Mode Sel to 010b. */
val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
+   val &= ~SCALING_MODE_SEL_MASK;
val |= SCALING_MODE_SEL(2);
I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
 
/* Program PORT_TX_DW2 */
val = I915_READ(CNL_PORT_TX_DW2_LN0(port));
+   val &= ~(SWING_SEL_LOWER_MASK | SWING_SEL_UPPER_MASK |
+RCOMP_SCALAR_MASK);
val |= SWING_SEL_UPPER(ddi_translations[level].dw2_swing_sel);
val |= SWING_SEL_LOWER(ddi_translations[level].dw2_swing_sel);
/* Rcomp scalar is fixed as 0x98 for every table entry */
@@ -1828,6 +1831,8 @@ static void cnl_ddi_vswing_program(struct 
drm_i915_private *dev_priv,
/* We cannot write to GRP. It would overrite individual loadgen */
for (ln = 0; ln < 4; ln++) {
val = I915_READ(CNL_PORT_TX_DW4_LN(port, ln));
+   val &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
+CURSOR_COEFF_MASK);
val |= POST_CURSOR_1(ddi_translations[level].dw4_post_cursor_1);
val |= POST_CURSOR_2(ddi_translations[level].dw4_post_cursor_2);
val |= CURSOR_COEFF(ddi_translations[level].dw4_cursor_coeff);
@@ -1837,12 +1842,14 @@ static void cnl_ddi_vswing_program(struct 
drm_i915_private *dev_priv,
 /* Program PORT_TX_DW5 */
/* All DW5 values are fixed for every table entry */
val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
+   val &= ~RTERM_SELECT_MASK;
val |= RTERM_SELECT(6);
val |= TAP3_DISABLE;
I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
 
 /* Program PORT_TX_DW7 */
val = I915_READ(CNL_PORT_TX_DW7_LN0(port));
+   val &= ~N_SCALAR_MASK;
val |= N_SCALAR(ddi_translations[level].dw7_n_scalar);
I915_WRITE(C

Re: [Intel-gfx] [PATCH i-g-t v3] tests/chamelium: Add common suspend and hibernate tests for DP and HDMI

[Lyude Paul]

On Mon, 2017-06-19 at 12:39 +0300, Paul Kocialkowski wrote:
> This adds two new tests: common-hpd-after-suspend and
> common-hpd-after-hibernate that are aimed at testing HPD change
> during
> suspend/hibernate for both DP and HDMI, at the same time.
> 
> The interest in bringing this test up is to reduce the time spent in
> testing, with the downside of less precision regarding the test's
> outcome. The per-connector tests are still available to get a more
> precise idea of which connector causes a failure, when that happens.
> 
> VGA is explicitly excluded from this test as there is currently no
> way of doing delayed hpd pulses for it.
> 
> The generic hpd suspend/resume test code is split in a dedicated
> function, that allow testing one or all possible ports.
> 
> Signed-off-by: Paul Kocialkowski 
Reviewed-by: Lyude Paul 

Will push to git in just a little bit, thanks!

> ---
>  tests/chamelium.c | 118
> +-
>  1 file changed, 100 insertions(+), 18 deletions(-)
> 
> diff --git a/tests/chamelium.c b/tests/chamelium.c
> index 76b14e95..3cf9f3b5 100644
> --- a/tests/chamelium.c
> +++ b/tests/chamelium.c
> @@ -143,8 +143,18 @@ wait_for_connector(data_t *data, struct
> chamelium_port *port,
>  static void
>  reset_state(data_t *data, struct chamelium_port *port)
>  {
> + int p;
> +
>   chamelium_reset(data->chamelium);
> - wait_for_connector(data, port, DRM_MODE_DISCONNECTED);
> +
> + if (port) {
> + wait_for_connector(data, port,
> DRM_MODE_DISCONNECTED);
> + } else {
> + for (p = 0; p < data->port_count; p++) {
> + port = data->ports[p];
> + wait_for_connector(data, port,
> DRM_MODE_DISCONNECTED);
> + }
> + }
>  }
>  
>  static void
> @@ -206,36 +216,96 @@ test_edid_read(data_t *data, struct
> chamelium_port *port,
>  }
>  
>  static void
> -test_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
> - enum igt_suspend_state state,
> - enum igt_suspend_test test)
> +try_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
> +    enum igt_suspend_state state, enum
> igt_suspend_test test,
> +    struct udev_monitor *mon, bool connected)
>  {
> - struct udev_monitor *mon = igt_watch_hotplug();
> -
> - reset_state(data, port);
> + int p;
>  
>   igt_set_autoresume_delay(SUSPEND_RESUME_DELAY);
>   igt_flush_hotplugs(mon);
>  
> - /* Make sure we notice new connectors after resuming */
> - chamelium_async_hpd_pulse_start(data->chamelium, port,
> false,
> - SUSPEND_RESUME_DELAY / 2);
> + if (port) {
> + chamelium_async_hpd_pulse_start(data->chamelium,
> port,
> + connected,
> + SUSPEND_RESUME_DELAY
> / 2);
> + } else {
> + for (p = 0; p < data->port_count; p++) {
> + port = data->ports[p];
> + if (chamelium_port_get_type(port) ==
> DRM_MODE_CONNECTOR_VGA)
> + continue;
> +
> + chamelium_async_hpd_pulse_start(data-
> >chamelium, port,
> + connected,
> + SUSPEND_RESU
> ME_DELAY / 2);
> + }
> +
> + port = NULL;
> + }
> +
>   igt_system_suspend_autoresume(state, test);
>   chamelium_async_hpd_pulse_finish(data->chamelium);
>  
>   igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
> - igt_assert_eq(reprobe_connector(data, port),
> DRM_MODE_CONNECTED);
> + if (port) {
> + igt_assert_eq(reprobe_connector(data, port),
> connected ?
> +   DRM_MODE_DISCONNECTED :
> DRM_MODE_CONNECTED);
> + } else {
> + for (p = 0; p < data->port_count; p++) {
> + port = data->ports[p];
> + if (chamelium_port_get_type(port) ==
> DRM_MODE_CONNECTOR_VGA)
> + continue;
> +
> + igt_assert_eq(reprobe_connector(data, port),
> connected ?
> +   DRM_MODE_DISCONNECTED :
> +   DRM_MODE_CONNECTED);
> + }
>  
> - igt_flush_hotplugs(mon);
> + port = NULL;
> + }
> +}
> +
> +static void
> +test_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
> + enum igt_suspend_state state,
> + enum igt_suspend_test test)
> +{
> + struct udev_monitor *mon = igt_watch_hotplug();
> +
> + reset_state(data, port);
> +
> + /* Make sure we notice new connectors after resuming */
> + try_suspend_resume_hpd(data, port, state, test, mon, false);
>  
>   /* Now make sure we notice disconnected connectors after
> res

Re: [Intel-gfx] [PATCH] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

[Ville Syrjälä]

On Mon, Jun 19, 2017 at 10:23:41AM -0700, Rodrigo Vivi wrote:
> When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake 
> workarounds.")
> Mika pointed out that Spec tells those 2 workarounds were not needed.
> 
> So when double checking I confirmed that and also that by Spec
> they only apply to SKL and BXT.
> 
> v2: Instead of increase the if/else move the wa
> to individual platform functions. (Ville).
> Also remove from GLK since spec only mentions SKL and BXT.

The spec seems to be telling me that these shouldn't needed on any
platform. But there are scary comments in the code saying that they
have been kept to cure some hangs. Probably best to wair for Mika to be
back to review this one.

> 
> Cc: Ander Conselvan de Oliveira 
> Cc: Ville Syrjälä 
> Cc: Mika Kuoppala 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index a4487c5..33c3a9d 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -831,11 +831,6 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *engine)
> FLOW_CONTROL_ENABLE |
> PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
>  
> - /* Syncing dependencies between camera and graphics:skl,bxt,kbl */
> - if (!IS_COFFEELAKE(dev_priv))
> - WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> -   GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> -
>   /* WaDisableDgMirrorFixInHalfSliceChicken5:bxt */
>   if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
>   WA_CLR_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN5,
> @@ -894,11 +889,6 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *engine)
>   WA_SET_BIT_MASKED(HDC_CHICKEN0,
> HDC_FORCE_NON_COHERENT);
>  
> - /* WaDisableHDCInvalidation:skl,bxt,kbl */
> - if (!IS_COFFEELAKE(dev_priv))
> - I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> -BDW_DISABLE_HDC_INVALIDATION);
> -
>   /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
>   if (IS_SKYLAKE(dev_priv) ||
>   IS_KABYLAKE(dev_priv) ||
> @@ -1007,6 +997,14 @@ static int skl_init_workarounds(struct intel_engine_cs 
> *engine)
>   if (ret)
>   return ret;
>  
> + /* Syncing dependencies between camera and graphics:skl */
> + WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> +   GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> +
> + /* WaDisableHDCInvalidation:skl */
> + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> +BDW_DISABLE_HDC_INVALIDATION);
> +
>   return skl_tune_iz_hashing(engine);
>  }
>  
> @@ -1076,6 +1074,14 @@ static int bxt_init_workarounds(struct intel_engine_cs 
> *engine)
>   WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
>  GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
>  
> + /* Syncing dependencies between camera and graphics:bxt */
> + WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> +   GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
> +
> + /* WaDisableHDCInvalidation:bxt */
> + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> +BDW_DISABLE_HDC_INVALIDATION);
> +
>   return 0;
>  }
>  
> -- 
> 1.9.1

-- 
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] drm/i915: Don't enable backlight at setup time.

[Pandiyan, Dhinakaran]

On Mon, 2017-06-19 at 11:08 -0700, Dhinakaran Pandiyan wrote:
> Maarten and Ville noticed that we are enabling backlight via DP aux very
> early in the modeset_init path via the intel_dp_aux_setup_backlight()
> function, since commit e7156c833903 ("drm/i915: Add Backlight Control using
> DPCD for eDP connectors (v9)"). Looks like all we need to do during
> _setup_backlight() is read the current brightness state instead of
> modifying it.
> 
> v2: Rewrote commit message.
> 
> Cc: Ville Syrjala 
> Cc: Maarten Lankhorst 
> Cc: Jani Nikula 
> Cc: Yetunde Adebisi 
> Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Maarten Lankhorst 
> Acked-by: Jani Nikula 
> Tested-by: Puthikorn Voravootivat 
> Fixes: e7156c833903 ("drm/i915: Add Backlight Control using DPCD for eDP 
> connectors (v9)")
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1497384239-2965-1-git-send-email-dhinakaran.pandi...@intel.com
> Signed-off-by: Ville Syrjälä 
> (cherry picked from commit f6262bda462e81e959b80a96dac799bd9df27f73)


I am sending a backport for the first time, please let me know if I
messed up something. 



> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 6532e22..40ba313 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -119,8 +119,6 @@ static int intel_dp_aux_setup_backlight(struct 
> intel_connector *connector,
>   struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
>   struct intel_panel *panel = &connector->panel;
>  
> - intel_dp_aux_enable_backlight(connector);
> -
>   if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
>   panel->backlight.max = 0x;
>   else

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

[Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

[Dhinakaran Pandiyan]

Maarten and Ville noticed that we are enabling backlight via DP aux very
early in the modeset_init path via the intel_dp_aux_setup_backlight()
function, since commit e7156c833903 ("drm/i915: Add Backlight Control using
DPCD for eDP connectors (v9)"). Looks like all we need to do during
_setup_backlight() is read the current brightness state instead of
modifying it.

v2: Rewrote commit message.

Cc: Ville Syrjala 
Cc: Maarten Lankhorst 
Cc: Jani Nikula 
Cc: Yetunde Adebisi 
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Maarten Lankhorst 
Acked-by: Jani Nikula 
Tested-by: Puthikorn Voravootivat 
Fixes: e7156c833903 ("drm/i915: Add Backlight Control using DPCD for eDP 
connectors (v9)")
Link: 
http://patchwork.freedesktop.org/patch/msgid/1497384239-2965-1-git-send-email-dhinakaran.pandi...@intel.com
Signed-off-by: Ville Syrjälä 
(cherry picked from commit f6262bda462e81e959b80a96dac799bd9df27f73)
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 6532e22..40ba313 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -119,8 +119,6 @@ static int intel_dp_aux_setup_backlight(struct 
intel_connector *connector,
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
struct intel_panel *panel = &connector->panel;
 
-   intel_dp_aux_enable_backlight(connector);
-
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
panel->backlight.max = 0x;
else
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

[Patchwork]

== Series Details ==

Series: drm/i915: Remove WaDisableKillLogic and 
GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.
URL   : https://patchwork.freedesktop.org/series/26001/
State : success

== Summary ==

Series 26001v1 drm/i915: Remove WaDisableKillLogic and 
GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.
https://patchwork.freedesktop.org/api/1.0/series/26001/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
fail   -> PASS   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:462s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:480s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:585s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:557s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:486s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:580s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:432s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:465s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:520s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:581s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:474s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:433s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:513s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:508s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:509s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:620s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:1   skip:29  
time:408s

508325c380d12aaccd410adc935e24f70acf69a8 drm-tip: 2017y-06m-19d-09h-05m-32s UTC 
integration manifest
0fce103 drm/i915: Remove WaDisableKillLogic and 
GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4987/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Fix RMW on ddi vswing sequence. (rev3)
URL   : https://patchwork.freedesktop.org/series/25935/
State : failure

== Summary ==

Series 25935v3 drm/i915/cnl: Fix RMW on ddi vswing sequence.
https://patchwork.freedesktop.org/api/1.0/series/25935/revisions/3/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bsw-n3050)

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:463s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:486s
fi-bsw-n3050 total:237  pass:204  dwarn:0   dfail:0   fail:0   skip:32 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:549s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:485s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:584s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:435s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:463s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:515s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:566s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:576s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:480s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:434s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:517s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:502s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:503s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:612s
fi-snb-2600  total:278  pass:246  dwarn:0   dfail:0   fail:2   skip:29  
time:407s

508325c380d12aaccd410adc935e24f70acf69a8 drm-tip: 2017y-06m-19d-09h-05m-32s UTC 
integration manifest
7ebee82 drm/i915/cnl: Fix RMW on ddi vswing sequence.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4986/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC for KBL and GLK.

[Rodrigo Vivi]

When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake 
workarounds.")
Mika pointed out that Spec tells those 2 workarounds were not needed.

So when double checking I confirmed that and also that by Spec
they only apply to SKL and BXT.

v2: Instead of increase the if/else move the wa
to individual platform functions. (Ville).
Also remove from GLK since spec only mentions SKL and BXT.

Cc: Ander Conselvan de Oliveira 
Cc: Ville Syrjälä 
Cc: Mika Kuoppala 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a4487c5..33c3a9d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -831,11 +831,6 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
  FLOW_CONTROL_ENABLE |
  PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
 
-   /* Syncing dependencies between camera and graphics:skl,bxt,kbl */
-   if (!IS_COFFEELAKE(dev_priv))
-   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
- GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
-
/* WaDisableDgMirrorFixInHalfSliceChicken5:bxt */
if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
WA_CLR_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN5,
@@ -894,11 +889,6 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT_MASKED(HDC_CHICKEN0,
  HDC_FORCE_NON_COHERENT);
 
-   /* WaDisableHDCInvalidation:skl,bxt,kbl */
-   if (!IS_COFFEELAKE(dev_priv))
-   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
-  BDW_DISABLE_HDC_INVALIDATION);
-
/* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
if (IS_SKYLAKE(dev_priv) ||
IS_KABYLAKE(dev_priv) ||
@@ -1007,6 +997,14 @@ static int skl_init_workarounds(struct intel_engine_cs 
*engine)
if (ret)
return ret;
 
+   /* Syncing dependencies between camera and graphics:skl */
+   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
+ GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
+
+   /* WaDisableHDCInvalidation:skl */
+   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
+  BDW_DISABLE_HDC_INVALIDATION);
+
return skl_tune_iz_hashing(engine);
 }
 
@@ -1076,6 +1074,14 @@ static int bxt_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_BIT(GEN9_GAMT_ECO_REG_RW_IA,
   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
 
+   /* Syncing dependencies between camera and graphics:bxt */
+   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
+ GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
+
+   /* WaDisableHDCInvalidation:bxt */
+   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
+  BDW_DISABLE_HDC_INVALIDATION);
+
return 0;
 }
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add information to missing case.

[Navare, Manasi D]

On Sat, 2017-06-17 at 01:31 -0700, Dhinakaran Pandiyan wrote:
> On Friday, June 16, 2017 10:18:28 PM PDT Vivi, Rodrigo wrote:
> > On Fri, 2017-06-16 at 21:54 +, Navare, Manasi D wrote:
> > 
> > > On Fri, 2017-06-16 at 21:26 +, Vivi, Rodrigo wrote:
> > > 
> > > > On Fri, 2017-06-16 at 21:21 +, Pandiyan, Dhinakaran wrote:
> > > > 
> > > > > On Fri, 2017-06-16 at 14:12 -0700, Manasi Navare wrote:
> > > > > 
> > > > > > On Fri, Jun 16, 2017 at 08:58:25PM +, Pandiyan, 
> > > > > > Dhinakaran
> > > > > > wrote:
> > > > > > 
> > > > > > > On Fri, 2017-06-16 at 13:20 -0700, Rodrigo Vivi wrote:
> > > > > > > 
> > > > > > > > This missing case could be reached out on missing type 
> > > > > > > > or missing voltage.
> > > > > > > 
> > > > > > > 
> > > > > > > Should we even reach this far with a missing DDI type?
> > > > > > > 
> > > > > > > -DK
> > > > > > >
> > > > > > >
> > > > > > 
> > > > > > 
> > > > > > Yes it is possible that we get into this situation if 
> > > > > > reading of the vccio voltage from PORT_COMP_DW3 returns a 
> > > > > > garbage value due to some corruption
> > > > > 
> > > > > 
> > > > > MISSING_CASE already logs that.
> > > > > 
> > > > > 
> > > > > > or lets say the type is something that is not supported on 
> > > > > > this platform.
> > > > > > 
> > > > > 
> > > > > But my question is, should we even be trying to program vswing 
> > > > > without knowing the ddi type or for an invalid type?
> > > > 
> > > > 
> > > > we will reach the return; and avoid vswing programming.
> > > > And logs will give us some information of what failed during modeset.
> > > > 
> > > 
> > > 
> > > Correct me if I am wrong, the only callers I could see are
> > > intel_dp_set_signal_levels() and intel_ddi_pre_enable_hdmi(). In 
> > > both cases, the encoder type should have been set appropriately. 
> > > My concern is that if we are seeing some other type, we should be 
> > > handling that before calling cnl_ddi_vswing_program()
> > 
> > this is why I didn't get the missing case on the type if/else ;)
> > 
> > we should never reach that case, but in case there is the missing 
> > case an extra debug message doesn't hurt...
> > 
> 
> We should not be writing to registers in the caller for invalid encoder 
> types. 
> And also debug log a bit sooner. How about?

I liked it, with one bikeshed below:

> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/ 
> intel_ddi.c index db80938..81cdffb 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1858,14 +1858,18 @@ static void cnl_ddi_vswing_sequence(struct 
> intel_encoder *encoder, u32 level)
> u32 val;
> int ln = 0;
>  
> -   if ((intel_dp) && (type == INTEL_OUTPUT_EDP || type == 
> INTEL_OUTPUT_DP)) {
> +   if (intel_dp && (type == INTEL_OUTPUT_EDP || type == 
> + INTEL_OUTPUT_DP))
> {
> width = intel_dp->lane_count;
> rate = intel_dp->link_rate;
> -   } else {
> +   } else if (type == INTEL_OUTPUT_HDMI){
> width = 4;
> /* Rate is always < than 6GHz for HDMI */
> +   } else {
> +   DRM_DEBUG_KMS("vswing sequence undefined for encoder 
> + type %d
> \n", type);

this should be 

MISSING_CASE(type);

instead.

> +   return;
> }
>  
> +
> /*
>  * 1. If port type is eDP or DP,
>  * set PORT_PCS_DW1 cmnkeeper_enable to 1b,
> 
> -DK

I think it is your patch now ;)
But let me know if you want me to do anything here..

I still think that there is a chance of running into a situation where the 
combination of the type
And the read vccio voltage is invalid and where we would need the debug print.
Also because I hate to sprinkle debug prints after a bug is filed would rather 
have it there
Making the debug easier. That is just my 2 centsbut if some people are too 
opinionated about
The debug print then go ahead remove it.

Manasi


> 
> > 
> > > 
> > > 
> > > But this debug message catches the condition where the type is 
> > > correct but the type and corresponding vccio voltage Combination 
> > > is wrong and the ddi tables are not present for that combination. 
> > > I definitely think it is a good idea to have this Debug print here in the 
> > > missing case.
> > > Manasi
> > > 
> > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > >  So let's add a debug
> > > > > > > > 
> > > > > > > > message to make our lives easier whenever this might happen.
> > > > > > > > 
> > > > > > > > Cc: Paulo Zanoni 
> > > > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > > > ---
> > > > > > > > 
> > > > > > > >  drivers/gpu/drm/i915/intel_ddi.c | 1 +
> > > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > > 
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > index e66947a..c96c8d0 100644
> > > > > > > > --- a/drivers/gpu/drm/i

[Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

[Rodrigo Vivi]

Paulo noticed that we were missing few bits clear
before writing values back to the register on
these RMW MMIO operations.

v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
v3: Remove unnecessary braces. (Jani).

Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo Zanoni 
Cc: Manasi Navare 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h  | 9 +
 drivers/gpu/drm/i915/intel_ddi.c | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bd535f1..c8647cf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1764,8 +1764,11 @@ enum skl_disp_power_wells {
_CNL_PORT_TX_DW2_LN0_AE, \
_CNL_PORT_TX_DW2_LN0_F)
 #define   SWING_SEL_UPPER(x)   ((x >> 3) << 15)
+#define   SWING_SEL_UPPER_MASK (1 << 15)
 #define   SWING_SEL_LOWER(x)   ((x & 0x7) << 11)
+#define   SWING_SEL_LOWER_MASK (0x7 << 11)
 #define   RCOMP_SCALAR(x)  ((x) << 0)
+#define   RCOMP_SCALAR_MASK(0xFF << 0)
 
 #define _CNL_PORT_TX_DW4_GRP_AE0x162350
 #define _CNL_PORT_TX_DW4_GRP_B 0x1623D0
@@ -1795,8 +1798,11 @@ enum skl_disp_power_wells {
_CNL_PORT_TX_DW4_LN0_F)
 #define   LOADGEN_SELECT   (1 << 31)
 #define   POST_CURSOR_1(x) ((x) << 12)
+#define   POST_CURSOR_1_MASK   (0x3F << 12)
 #define   POST_CURSOR_2(x) ((x) << 6)
+#define   POST_CURSOR_2_MASK   (0x3F << 6)
 #define   CURSOR_COEFF(x)  ((x) << 0)
+#define   CURSOR_COEFF_MASK(0x3F << 6)
 
 #define _CNL_PORT_TX_DW5_GRP_AE0x162354
 #define _CNL_PORT_TX_DW5_GRP_B 0x1623D4
@@ -1825,7 +1831,9 @@ enum skl_disp_power_wells {
 #define   TX_TRAINING_EN   (1 << 31)
 #define   TAP3_DISABLE (1 << 29)
 #define   SCALING_MODE_SEL(x)  ((x) << 18)
+#define   SCALING_MODE_SEL_MASK(0x7 << 18)
 #define   RTERM_SELECT(x)  ((x) << 3)
+#define   RTERM_SELECT_MASK(0x7 << 3)
 
 #define _CNL_PORT_TX_DW7_GRP_AE0x16235C
 #define _CNL_PORT_TX_DW7_GRP_B 0x1623DC
@@ -1852,6 +1860,7 @@ enum skl_disp_power_wells {
_CNL_PORT_TX_DW7_LN0_AE, \
_CNL_PORT_TX_DW7_LN0_F)
 #define   N_SCALAR(x)  ((x) << 24)
+#define   N_SCALAR_MASK(0x7F << 24)
 
 /* The spec defines this only for BXT PHY0, but lets assume that this
  * would exist for PHY1 too if it had a second channel.
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index db80938..80e96f1 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1813,11 +1813,14 @@ static void cnl_ddi_vswing_program(struct 
drm_i915_private *dev_priv,
 
/* Set PORT_TX_DW5 Scaling Mode Sel to 010b. */
val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
+   val &= ~SCALING_MODE_SEL_MASK;
val |= SCALING_MODE_SEL(2);
I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
 
/* Program PORT_TX_DW2 */
val = I915_READ(CNL_PORT_TX_DW2_LN0(port));
+   val &= ~(SWING_SEL_LOWER_MASK | SWING_SEL_UPPER_MASK |
+RCOMP_SCALAR_MASK);
val |= SWING_SEL_UPPER(ddi_translations[level].dw2_swing_sel);
val |= SWING_SEL_LOWER(ddi_translations[level].dw2_swing_sel);
/* Rcomp scalar is fixed as 0x98 for every table entry */
@@ -1828,6 +1831,8 @@ static void cnl_ddi_vswing_program(struct 
drm_i915_private *dev_priv,
/* We cannot write to GRP. It would overrite individual loadgen */
for (ln = 0; ln < 4; ln++) {
val = I915_READ(CNL_PORT_TX_DW4_LN(port, ln));
+   val &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
+CURSOR_COEFF_MASK);
val |= POST_CURSOR_1(ddi_translations[level].dw4_post_cursor_1);
val |= POST_CURSOR_2(ddi_translations[level].dw4_post_cursor_2);
val |= CURSOR_COEFF(ddi_translations[level].dw4_cursor_coeff);
@@ -1837,12 +1842,14 @@ static void cnl_ddi_vswing_program(struct 
drm_i915_private *dev_priv,
 /* Program PORT_TX_DW5 */
/* All DW5 values are fixed for every table entry */
val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
+   val &= ~RTERM_SELECT_MASK;
val |= RTERM_SELECT(6);
val |= TAP3_DISABLE;
I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
 
 /* Program PORT_TX_DW7 */
val = I915_READ(CNL_PORT_TX_DW7_LN0(port));
+   val &= ~N_SCALAR_MASK;
val |= N_SCALAR(ddi_translations[level].dw7_n_scalar);
I915_WRITE(C

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add information to missing case.

[Vivi, Rodrigo]

On Sat, 2017-06-17 at 01:31 -0700, Dhinakaran Pandiyan wrote:
> On Friday, June 16, 2017 10:18:28 PM PDT Vivi, Rodrigo wrote:
> > On Fri, 2017-06-16 at 21:54 +, Navare, Manasi D wrote:
> > 
> > > On Fri, 2017-06-16 at 21:26 +, Vivi, Rodrigo wrote:
> > > 
> > > > On Fri, 2017-06-16 at 21:21 +, Pandiyan, Dhinakaran wrote:
> > > > 
> > > > > On Fri, 2017-06-16 at 14:12 -0700, Manasi Navare wrote:
> > > > > 
> > > > > > On Fri, Jun 16, 2017 at 08:58:25PM +, Pandiyan, Dhinakaran
> > > > > > wrote:
> > > > > > 
> > > > > > > On Fri, 2017-06-16 at 13:20 -0700, Rodrigo Vivi wrote:
> > > > > > > 
> > > > > > > > This missing case could be reached out on missing type or 
> > > > > > > > missing voltage.
> > > > > > > 
> > > > > > > 
> > > > > > > Should we even reach this far with a missing DDI type?
> > > > > > > 
> > > > > > > -DK
> > > > > > >
> > > > > > >
> > > > > > 
> > > > > > 
> > > > > > Yes it is possible that we get into this situation if reading of 
> > > > > > the vccio voltage from PORT_COMP_DW3 returns a garbage value due 
> > > > > > to some corruption
> > > > > 
> > > > > 
> > > > > MISSING_CASE already logs that.
> > > > > 
> > > > > 
> > > > > > or lets say the type is something that is not supported on this 
> > > > > > platform.
> > > > > > 
> > > > > 
> > > > > But my question is, should we even be trying to program vswing 
> > > > > without knowing the ddi type or for an invalid type?
> > > > 
> > > > 
> > > > we will reach the return; and avoid vswing programming.
> > > > And logs will give us some information of what failed during modeset.
> > > > 
> > > 
> > > 
> > > Correct me if I am wrong, the only callers I could see are
> > > intel_dp_set_signal_levels() and intel_ddi_pre_enable_hdmi(). In both
> > > cases, the encoder type should have been set appropriately. My concern is
> > > that if we are seeing some other type, we should be handling that before
> > > calling cnl_ddi_vswing_program()
> > 
> > this is why I didn't get the missing case on the type if/else ;)
> > 
> > we should never reach that case, but in case there is the missing case
> > an extra debug message doesn't hurt...
> > 
> 
> We should not be writing to registers in the caller for invalid encoder 
> types. 
> And also debug log a bit sooner. How about?

I liked it, with one bikeshed below:

> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/
> intel_ddi.c
> index db80938..81cdffb 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1858,14 +1858,18 @@ static void cnl_ddi_vswing_sequence(struct 
> intel_encoder *encoder, u32 level)
> u32 val;
> int ln = 0;
>  
> -   if ((intel_dp) && (type == INTEL_OUTPUT_EDP || type == 
> INTEL_OUTPUT_DP)) {
> +   if (intel_dp && (type == INTEL_OUTPUT_EDP || type == 
> INTEL_OUTPUT_DP)) 
> {
> width = intel_dp->lane_count;
> rate = intel_dp->link_rate;
> -   } else {
> +   } else if (type == INTEL_OUTPUT_HDMI){
> width = 4;
> /* Rate is always < than 6GHz for HDMI */
> +   } else {
> +   DRM_DEBUG_KMS("vswing sequence undefined for encoder type %d
> \n", type);

this should be 

MISSING_CASE(type);

instead.

> +   return;
> }
>  
> +
> /*
>  * 1. If port type is eDP or DP,
>  * set PORT_PCS_DW1 cmnkeeper_enable to 1b,
> 
> -DK

I think it is your patch now ;)
But let me know if you want me to do anything here..

> 
> > 
> > > 
> > > 
> > > But this debug message catches the condition where the type is correct but
> > > the type and corresponding vccio voltage Combination is wrong and the
> > > ddi tables are not present for that combination. I definitely think it is
> > > a good idea to have this Debug print here in the missing case. 
> > > Manasi
> > > 
> > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > >  So let's add a debug
> > > > > > > > 
> > > > > > > > message to make our lives easier whenever this might happen.
> > > > > > > > 
> > > > > > > > Cc: Paulo Zanoni 
> > > > > > > > Signed-off-by: Rodrigo Vivi 
> > > > > > > > ---
> > > > > > > > 
> > > > > > > >  drivers/gpu/drm/i915/intel_ddi.c | 1 +
> > > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > > 
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > index e66947a..c96c8d0 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > @@ -1802,6 +1802,7 @@ static void cnl_ddi_vswing_program(struct
> > > > > > > > drm_i915_private *dev_priv,
> > > > > > > 
> > > > > > > > }
> > > > > > > >  
> > > > > > > >  
> > > > > > > >  
> > > > > > > > if (ddi_translations == NULL) {
> > > > > > > > 
> > > > > > > > +   DRM_DEBUG_KMS("Missing DDI translation table 
> > > > > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI YCBCR output handling in DRM layer (rev4)

[Patchwork]

== Series Details ==

Series: HDMI YCBCR output handling in DRM layer (rev4)
URL   : https://patchwork.freedesktop.org/series/22684/
State : failure

== Summary ==

Series 22684v4 HDMI YCBCR output handling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/22684/revisions/4/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-6260u)
dmesg-warn -> SKIP   (fi-skl-6700hq) fdo#101144 +2
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
pass   -> SKIP   (fi-kbl-r)
pass   -> SKIP   (fi-glk-2a)
Subgroup basic-flip-default-b:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
pass   -> SKIP   (fi-kbl-r)
pass   -> SKIP   (fi-glk-2a)
Subgroup basic-flip-default-c:
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
pass   -> SKIP   (fi-kbl-r)
pass   -> SKIP   (fi-glk-2a)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m) fdo#100215 +15
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-6260u)
fail   -> SKIP   (fi-skl-6700hq) fdo#101154 +28
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-bxt-j4205)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-kbl-7560u)
pass   -> SKIP   (fi-kbl-r)
p

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Don't try detecting sinks on ports already in use

[Gabriel Krisman Bertazi]

Ville Syrjälä  writes:


>>  mutex_lock(&dev->mode_config.mutex);
>>  DRM_DEBUG_KMS("running encoder hotplug functions\n");
>> @@ -339,13 +340,18 @@ static void i915_hotplug_work_func(struct work_struct 
>> *work)
>>  if (!intel_connector->encoder)
>>  continue;
>>  intel_encoder = intel_connector->encoder;
>> -if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) {
>> +enc_hpd_pin_mask = (1 << intel_encoder->hpd_pin);
>> +if (hpd_event_bits & enc_hpd_pin_mask) {
>>  DRM_DEBUG_KMS("Connector %s (pin %i) received hotplug 
>> event.\n",
>>connector->name, intel_encoder->hpd_pin);
>>  if (intel_encoder->hot_plug)
>>  intel_encoder->hot_plug(intel_encoder);
>> -if (intel_hpd_irq_event(dev, connector))
>> +if (intel_hpd_irq_event(dev, connector)) {
>>  changed = true;
>> +if (connector->status ==
>> +connector_status_connected)
>> +hpd_event_bits &= ~(enc_hpd_pin_mask);
>
> This won't work correctly because now it will fail to update
> connector->status for the other connector. I admit that being fast
> enough to switch between DP<->HDMI directly while the HPD interrupt
> is enabled is perhaps a little unlikely, but it can certainly happen
> very easily if the interrupt has been disabled.

Hi Ville,

I see.  So, still racy when dealing with multiple connectors events on
the same HPD line.  Nice catch. I didn't see that.

> We alrady have other bugs in that area. Eg. if you manage to switch to a
> totally different display without noticing the disconnected state in
> between we'll skip sending the uevent. We should really be checking if
> the sink changed somehow (eg. EDID changed) and in that case send the
> uevent anyway.
>
> I also don't think this can have anything to do with vblank tests
> failing, unless there's some other problem involved that somehow
> triggers HPDs while the test is doing its measurements.

I thought about (blindly) reducing the overhead of
i915_hotplug_work_func, as mentioned by Chris in his second comment in
the report for bug 100215.  But I understand that the latest
reproduction of 100215 triggered a lot of timeouts directly from
userspace, and I didn't find any HPD occurrences there.

Anyway, correct me if I'm wrong, but I still understand that the amount
of time the DP detection takes is a little too much, and the fact that
it triggers whenever we connect anything to a shared port is very odd
behavior.  There are a few bugs reported where the DP detection timeouts
was pointed as the probable root cause.

I came up with two patches to workaround the issue but they both had
issues of their own.  I understand the first version I submitted is a
better approach than the second, and I think we could explore something
in that direction, once we address the race condition first pointed out
by Chris.  He suggested on an earlier email that we leverage the
knowledge about digital ports to improve the overall detection, but I'm
not sure how to start that.  I've been checking the specs and I don't
see how we could decide whether we have a DP device without doing the
dpcp dance.  Do you have any suggestions on that?  I'm new to i915, so
I'm not sure if I'm missing something, if that is the case, please point
it out. :)

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

[Intel-gfx] [PATCH v4 14/15] drm/i915: set colorspace for ycbcr outputs

[Shashank Sharma]

When HDMI output is other than RGB, we have to load the
corresponding colorspace of output mode. This patch fills
the colorspace of AVI infoframe as per the HDMI output mode.

V2: Rebase
V3: Rebase
V4: Rebase

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 8d5aa1e..3bd9af3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -472,6 +472,14 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
return;
}
 
+   ret = drm_hdmi_avi_infoframe_set_colorspace(&frame.avi,
+   adjusted_mode,
+   crtc_state->hdmi_output);
+   if (ret < 0) {
+   DRM_ERROR("couldn't fill AVI colorspace\n");
+   return;
+   }
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
-- 
2.7.4

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

[Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs

[Shashank Sharma]

This patch checks encoder level support for HDMI YCBCR outputs.
HDMI output mode is a connector property, this patch checks if
source and sink can support the HDMI output type selected by user.
And if they both can, it commits the hdmi output type into crtc state,
for further staging in driver.

V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.
V4: Rebase

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_display.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 93 ++--
 3 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f9bf0d5..da29536 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+   PIPE_CONF_CHECK_I(hdmi_output);
 
PIPE_CONF_CHECK_I(has_audio);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1727350..38fe56c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -780,6 +780,9 @@ struct intel_crtc_state {
 
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+   /* HDMI output type */
+   enum drm_hdmi_output_type hdmi_output;
 };
 
 struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 170abc4..22da5cd 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1317,7 +1317,8 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
return status;
 }
 
-static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
+static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
+   enum drm_hdmi_output_type hdmi_out)
 {
struct drm_i915_private *dev_priv =
to_i915(crtc_state->base.crtc->dev);
@@ -1329,6 +1330,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (HAS_GMCH_DISPLAY(dev_priv))
return false;
 
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
+   /*
+* HDMI spec says YCBCR422 is 12bpc, but its not a deep
+* color format. So respect the spec, and not allow this
+* to be deep color
+*/
+   DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
+   return false;
+   }
+
/*
 * HDMI 12bpc affects the clocks, so it's only possible
 * when not cloning with other encoder types.
@@ -1342,6 +1353,12 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
 
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+   if (!(info->hdmi.y420_dc_modes &
+   DRM_EDID_YCBCR420_DC_36))
+   return false;
+   }
+
if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
return false;
}
@@ -1354,6 +1371,65 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state 
*crtc_state)
return true;
 }
 
+static u8
+intel_hdmi_get_src_output_support(struct drm_connector *connector)
+{
+   struct drm_i915_private *dev_priv = connector->dev->dev_private;
+   u8 supported_outputs = DRM_COLOR_FORMAT_RGB444;
+
+   if (dev_priv->info.gen < 7)
+   return supported_outputs;
+
+   /* Gen 7 and above support HDMI 1.4b outputs */
+   supported_outputs |= (DRM_COLOR_FORMAT_YCRCB444 |
+   DRM_COLOR_FORMAT_YCRCB422);
+
+   if (IS_GEMINILAKE(dev_priv))
+   supported_outputs |= DRM_COLOR_FORMAT_YCRCB420;
+
+   return supported_outputs;
+}
+
+static enum drm_hdmi_output_type
+intel_hdmi_compute_ycbcr_config(struct drm_connector_state *conn_state,
+  struct intel_crtc_state *config,
+  int *clock_12bpc, int *clock_8bpc)
+{
+   struct drm_connector *connector = conn_state->connector;
+   struct drm_display_mode *mode = &config->base.adjusted_mode;
+   enum drm_hdmi_output_type type = conn_state->hdmi_output;
+   u8 src_output_cap = intel_hdmi_get_src_output_support(connector);
+
+   /*
+* Can we support any YCBCR output based on these parameters ?
+* current source capabilities +
+* current sink capabilities +
+* give

[Intel-gfx] [PATCH v4 15/15] drm/i915/glk: set HDMI 2.0 identifier

[Shashank Sharma]

This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.

V3: Added this patch
V4: Rebase

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3bd9af3..0d9d088 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1979,6 +1979,9 @@ 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))
+   connector->ycbcr_420_allowed = true;
+
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
 
switch (port) {
-- 
2.7.4

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

[Intel-gfx] [PATCH v4 13/15] drm/i915: prepare csc unit for YCBCR HDMI output

[Shashank Sharma]

To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.

Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.

This function adds a csc handler, to perform RGB->YCBCR conversion
as per recommended spec values.

V2: Rebase
V3: Rebase
V4: Rebase

Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_color.c   | 47 +++-
 drivers/gpu/drm/i915/intel_display.c | 32 
 2 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 306c6b0..12d5f21 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,19 @@
 
 #define LEGACY_LUT_LENGTH  (sizeof(struct drm_color_lut) * 256)
 
+/* Post offset values for RGB->YCBCR conversion */
+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/* Direct spec values for RGB->YUV conversion matrix */
+#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
+#define CSC_RGB_TO_YUV_BU 0x37e8
+#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
+#define CSC_RGB_TO_YUV_BY 0xb528
+#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
+#define CSC_RGB_TO_YUV_BV 0x1e08
+
 /*
  * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
  * format). This macro takes the coefficient we want transformed and the
@@ -91,6 +104,35 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t 
*input)
}
 }
 
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+{
+   int pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+   /* We don't use high values for conversion */
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   /* Program direct spec values for RGB to YCBCR conversion matrix */
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+   /* Spec postoffset values */
+   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+   I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+   I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+
+   /* CSC mode before gamma */
+   I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
 /* Set up the pipe CSC unit. */
 static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
 {
@@ -101,7 +143,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
 
-   if (crtc_state->ctm) {
+   if (intel_crtc_state->hdmi_output > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+   i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+   return;
+   } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->data;
uint64_t input[9] = { 0, };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 71fd19e..96ff2a0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6261,6 +6261,29 @@ static void intel_crtc_compute_pixel_rate(struct 
intel_crtc_state *crtc_state)
ilk_pipe_pixel_rate(crtc_state);
 }
 
+static int intel_crtc_ycbcr_config(struct intel_crtc_state *state)
+{
+   struct drm_crtc_state *drm_state = &state->base;
+   struct drm_i915_private *dev_priv = to_i915(drm_state->crtc->dev);
+
+   /* YCBCR420 is supported only in HDMI 2.0 controllers */
+   if ((state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420) &&
+   !IS_GEMINILAKE(dev_priv)) {
+   DRM_ERROR("YCBCR420 output is not supported\n");
+   return -EINVAL;
+   }
+
+   /* We need CSC for output conversion from RGB->YCBCR */
+   if (drm_state->ctm) {
+   DRM_ERROR("YCBCR output and CTM is not possible together\n");
+   return -EINVAL;
+   }
+
+   DRM_DEBUG_DRIVER("Output %s can be supported\n",
+drm_get_hdmi_output_name(state->hdmi_output));
+   return 0;
+}
+
 static int intel_crtc_compute_config(struct intel_crtc *crtc,
 struct intel_crtc_state *pipe_con

[Intel-gfx] [PATCH v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

[Shashank Sharma]

To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.

This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
  scaler framework. This output type is identified using bit
  30 of the scaler users bitmap.

V2: rebase
V3: rebase
V4: rebase

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
 drivers/gpu/drm/i915/intel_display.c | 26 ++
 drivers/gpu/drm/i915/intel_drv.h | 10 +-
 drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
 drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
 5 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..a8c9ac5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
 
/* panel fitter case: assign as a crtc scaler */
scaler_id = &scaler_state->scaler_id;
+   } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+   name = "HDMI-OUTPUT";
+   idx = intel_crtc->base.base.id;
+
+   /* hdmi output case: needs a pipe scaler */
+   scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index da29536..983f581 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
 
+   if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+   && scaler_user == SKL_HDMI_OUTPUT_INDEX)
+   /* YCBCR 444 -> 420 conversion needs a scaler */
+   need_scaling = true;
+
/*
 * if plane is being disabled or scaler is no more required or force 
detach
 *  - free scaler binded to this plane/crtc
@@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 }
 
 /**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+   const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+   return skl_update_scaler(state, !state->base.active,
+   SKL_HDMI_OUTPUT_INDEX, &state->scaler_state.scaler_id,
+   state->pipe_src_w, state->pipe_src_h,
+   mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
  * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
  *
  * @state: crtc's scaler state
@@ -8058,6 +8083,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
 
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 38fe56c..2206aa8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
 *
 * If a bit is set, a user is using a scaler.
 * Here user can be a plane or crtc as defined below:
-*   bits 0-30 - plane (bit position is index from drm_plane_index)
+*   bits 0-29 - plane (bit position is index from drm_plane_index)
+*   bit 30- hdmi output
 *   bit 31- crtc
 *
 * Instead of creating a new index to cover planes and crtc, using
@@ -484,6 +485,12 @@ struct intel_crtc_scaler_state {
 * avilability.
 */
 #define SKL_CRTC_INDEX 31
+
+   /*
+* HDMI YCBCR 420 output consume a scaler. So adding a user
+* for HDMI output 420 requirement.
+*/
+#define SKL_HDMI_OUTPUT_INDEX 30
unsigned scaler_users;
 
/* scaler used by crtc for panel fitting purpose */
@@ -1481,6 +1488,7 @@ void intel_mode_from_pipe_config(struct drm_display_mode 
*mode,
 struct intel_crtc_state *pipe_config);
 
 int skl_update_scaler_crtc(struct intel_crtc_state *crtc

[Intel-gfx] [PATCH v4 12/15] drm/i915: prepare pipe for YCBCR output

[Shashank Sharma]

To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
  blend mode to use the scaler in 5x3 ratio (bits 26 and 27)

This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR outputs.

V2: rebase
V3: rebase
V4: rebase

Cc: Ville Syrjala 
Cc: Ander Conselvan De Oliveira 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  | 3 +++
 drivers/gpu/drm/i915/intel_display.c | 9 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 88e4707..77921ec 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5196,6 +5196,9 @@ enum {
 
 #define _PIPE_MISC_A   0x70030
 #define _PIPE_MISC_B   0x71030
+#define   PIPEMISC_YCBCR420_ENABLE (1<<27)
+#define   PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
+#define   PIPEMISC_OUTPUT_YCBCR(1<<11)
 #define   PIPEMISC_DITHER_BPC_MASK (7<<5)
 #define   PIPEMISC_DITHER_8_BPC(0<<5)
 #define   PIPEMISC_DITHER_10_BPC   (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 983f581..71fd19e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8109,6 +8109,15 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
 
+   if (hdmi_out > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+   val |= PIPEMISC_OUTPUT_YCBCR;
+
+   if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR420) {
+   val |= PIPEMISC_YCBCR420_ENABLE |
+  PIPEMISC_YCBCR420_MODE_BLEND;
+   }
+   }
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH v4 08/15] drm: set output colorspace in AVI infoframe

[Shashank Sharma]

HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.

As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI infoframes.

V2: Rebase
V3: Rebase

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 40 
 include/drm/drm_edid.h |  5 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 42934b2..edba190 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4782,6 +4782,46 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
 
 /**
+ * drm_hdmi_avi_infoframe_set_colorspace - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output)
+{
+   switch (hdmi_output) {
+   case DRM_HDMI_OUTPUT_YCBCR444:
+   frame->colorspace = HDMI_COLORSPACE_YUV444;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR422:
+   frame->colorspace = HDMI_COLORSPACE_YUV422;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR420:
+   frame->colorspace = HDMI_COLORSPACE_YUV420;
+   frame->pixel_repeat = 0;
+   break;
+   case DRM_HDMI_OUTPUT_DEFAULT_RGB:
+   frame->colorspace = HDMI_COLORSPACE_RGB;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR_HQ:
+   case DRM_HDMI_OUTPUT_YCBCR_LQ:
+   case DRM_HDMI_OUTPUT_INVALID:
+   DRM_ERROR("Invalid HDMI output type\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
  * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
  *quantization range information
  * @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index d4ff17c..3ea833f 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,6 +329,7 @@ struct cea_sad {
 struct drm_encoder;
 struct drm_connector;
 struct drm_display_mode;
+enum drm_hdmi_output_type;
 
 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -351,6 +352,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink);
 int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output);
+int
 drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);
 void
-- 
2.7.4

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

[Intel-gfx] [PATCH v4 09/15] drm: add helper functions for YCBCR output handling

[Shashank Sharma]

This patch adds set of helper functions for YCBCR HDMI output
handling. These functions provide functionality like:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 mode.
- get the highest subsamled ycbcr output.
- get the lowest subsamled ycbcr output.
- check if a given source and sink combination can support any
  YCBCR HDMI output.
- check if a given source and sink combination can support a particular
  YCBCR HDMI output.

Currently all these helpers are kept static, and only one wrapper function
is exposed to callers, which is "drm_find_hdmi_output_type". This function
takes inputs as current mode, user preference and src + sink capabilities,
and provides the most suitable HDMI output format to match all of these
inputs.

This wrapper function will be used in next few patches in this
series from I915 driver.

V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  |   2 +-
 drivers/gpu/drm/drm_modes.c | 307 
 include/drm/drm_edid.h  |   1 +
 include/drm/drm_modes.h |   5 +
 4 files changed, 314 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index edba190..2f8810a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2949,7 +2949,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);
 
-static bool drm_valid_cea_vic(u8 vic)
+bool drm_valid_cea_vic(u8 vic)
 {
return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
 }
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f2493b9..09e6b10 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1576,3 +1576,310 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
 out:
return ret;
 }
+
+/**
+ * drm_mode_is_420_only - if a given videomode can be only supported in 
YCBCR420
+ * output format
+ *
+ * @connector: drm connector under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can support YCBCR420 output
+ * false if not.
+ */
+static bool drm_mode_is_420_only(struct drm_display_info *display,
+   struct drm_display_mode *mode)
+{
+   u8 vic = drm_match_cea_mode(mode);
+
+   /*
+* Requirements of a 420_only mode:
+* must be a valid cea mode
+* entry in 420_only bitmap
+*/
+   if (!drm_valid_cea_vic(vic))
+   return false;
+
+   return test_bit(vic, display->hdmi.y420_vdb_modes);
+}
+
+/**
+ * drm_mode_is_420_also - if a given videomode can be supported in YCBCR420
+ * output format also (along with RGB/YCBCR444/422)
+ *
+ * @display: display under action.
+ * @mode: video mode to be tested.
+ *
+ * Returns:
+ * true if the mode can support YCBCR420 output
+ * false if not.
+ */
+static bool drm_mode_is_420_also(struct drm_display_info *display,
+   struct drm_display_mode *mode)
+{
+   u8 vic = drm_match_cea_mode(mode);
+
+   /*
+* Requirements of a 420_also mode:
+* must be a valid cea mode
+* entry in 420_also bitmap
+*/
+   if (!drm_valid_cea_vic(vic))
+   return false;
+
+   return test_bit(vic, display->hdmi.y420_cmdb_modes);
+}
+
+
+static bool drm_mode_is_420(struct drm_display_info *display,
+   struct drm_display_mode *mode)
+{
+   return drm_mode_is_420_only(display, mode) ||
+   drm_mode_is_420_also(display, mode);
+}
+
+/**
+ * drm_can_support_this_ycbcr_output - can a given source and sink combination
+ * support a particular YCBCR output type.
+ *
+ * @display: sink information.
+ * @mode: video mode from modeset
+ * @type: enum indicating YCBCR output type
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+ */
+static bool drm_can_support_this_ycbcr_output(struct drm_display_info *display,
+   struct drm_display_mode *mode,
+   enum drm_hdmi_output_type type,
+   u32 source_outputs)
+{
+   /* YCBCR420 output support can be per mode basis */
+   if (type == DRM_HDMI_OUTPUT_YCBCR420 &&
+   !drm_mode_is_420(display, mode))
+   return false;
+
+   return display->color_formats & source_outputs & type;
+}
+
+/**
+ * drm_can_support_ycbcr_output - can a given source and sink combination
+ * support any YCBCR outputs ?
+ *
+ * @display: sink information.
+ * @source_outputs: bitmap of source supported HDMI output formats.
+ *
+ * Returns:
+ * true on success.
+ * false on failure.
+

[Intel-gfx] [PATCH v4 07/15] drm: create hdmi output property

[Shashank Sharma]

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
 - RGB
 - YCBCR 444
 - YCBCR 422
 - YCBCR 420

This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference, for the HDMI output type. The
output type enums are similar to the mentioned outputs above. To
handle various subsampling of YCBCR output types, this property
allows two special cases:
 - DRM_HDMI_OUTPUT_YCBCR_HQ
   This indicates preferred output should be YCBCR output, with highest
   subsampling rate by the source/sink, which can be typically:
- ycbcr444
- ycbcr422
- ycbcr420
 - DRM_HDMI_OUTPUT_YCBCR_LQ
   This indicates preferred output should be YCBCR output, with lowest
   subsampling rate supported by source/sink, which can be:
- ycbcr420
- ycbcr422
- ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

PS: While doing modeset for YCBCR 420 only modes, this property is
ignored, as those timings can be supported only in YCBCR 420
output mode.

V2: Added description for the new variable to address build warning
V3: Rebase

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic.c|  2 ++
 drivers/gpu/drm/drm_atomic_helper.c |  4 
 drivers/gpu/drm/drm_connector.c | 32 
 include/drm/drm_connector.h | 18 ++
 include/drm/drm_mode_config.h   |  5 +
 5 files changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 77dcef0..9f1d46d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 86d3093..1356b3f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -637,6 +637,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->hdmi_output !=
+   new_connector_state->hdmi_output)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..f3c5928 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
  config->edid_property,
  0);
 
+   if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
+   drm_object_attach_property(&connector->base,
+  config->hdmi_output_property,
+  0);
+
drm_object_attach_property(&connector->base,
  config->dpms_property, 0);
 
@@ -617,6 +622,26 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
 
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {
+   { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+   { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
+   { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+   { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr420" },
+   { DRM_HDMI_OUTPUT_YCBCR_HQ, "output_ycbcr_high_subsampling" },
+   { DRM_HDMI_OUTPUT_YCBCR_LQ, "output_ycbcr_low_subsampling" },
+   { DRM_HDMI_OUTPUT_INVALID, "invalid_output" },
+};
+
+/**
+ * drm_get_hdmi_output_name - return a string for a given hdmi output enum
+ * @type: enum of output type
+ */
+const char *drm_get_hdmi_output_name(enum drm_hdmi_output_type type)
+{
+   return drm_hdmi_output_enum_list[type].name;
+}
+EXPORT_SYMBOL(drm_get_hdmi_output_name);
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -789,6 +814,13 @@ int drm_connector_create_standard_properties(struc

[Intel-gfx] [PATCH v4 06/15] drm/edid: parse sink information before CEA blocks

[Shashank Sharma]

CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
This block contains a map of indexes of CEA modes, which can
support YCBCR 420 output also. To avoid multiple parsing of same
CEA block, let's parse the sink information and get this map, before
parsing CEA modes.

This patch moves the call to drm_add_display_info function, before the
mode parsing block.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b4583f6..42934b2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4605,6 +4605,13 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
quirks = edid_get_quirks(edid);
 
/*
+* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
+* To avoid multiple parsing of same block, lets parse that map
+* from sink info, before parsing CEA modes.
+*/
+   drm_add_display_info(connector, edid);
+
+   /*
 * EDID spec says modes should be preferred in this order:
 * - preferred detailed mode
 * - other detailed modes from base block
@@ -4632,8 +4639,6 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
edid_fixup_preferred(connector, quirks);
 
-   drm_add_display_info(connector, edid);
-
if (quirks & EDID_QUIRK_FORCE_6BPC)
connector->display_info.bpc = 6;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v4 05/15] drm/edid: parse ycbcr 420 deep color information

[Shashank Sharma]

CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.

V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc_modes into this patch, where its used
(Ville)

Cc: Ville Syrjälä 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 15 +++
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_edid.h  |  5 +
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8c7e73b..b4583f6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4196,6 +4196,19 @@ drm_default_rgb_quant_range(const struct 
drm_display_mode *mode)
 }
 EXPORT_SYMBOL(drm_default_rgb_quant_range);
 
+static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
+const u8 *db)
+{
+   struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+   if (db[7] & DRM_EDID_YCBCR420_DC_48)
+   info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
+   if (db[7] & DRM_EDID_YCBCR420_DC_36)
+   info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
+   if (db[7] & DRM_EDID_YCBCR420_DC_30)
+   info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_30;
+}
+
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
 {
@@ -4236,6 +4249,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
drm_connector *connector,
scdc->scrambling.low_rates = true;
}
}
+
+   drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
 }
 
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ce2212d..1305fe9 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -156,6 +156,9 @@ struct drm_hdmi_info {
 
/** @y420_cmdb_map: bitmap of SVD index, to extraxt vcb modes */
unsigned long y420_cmdb_map;
+
+   /** @y420_dc_modes: bitmap of deep color support index */
+   u8 y420_dc_modes;
 };
 
 /**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 89c0062..d4ff17c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -213,6 +213,11 @@ struct detailed_timing {
 #define DRM_EDID_HDMI_DC_30   (1 << 4)
 #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
 
+/* YCBCR 420 deep color modes */
+#define DRM_EDID_YCBCR420_DC_48  (1 << 6)
+#define DRM_EDID_YCBCR420_DC_36  (1 << 5)
+#define DRM_EDID_YCBCR420_DC_30  (1 << 4)
+
 /* ELD Header Block */
 #define DRM_ELD_HEADER_BLOCK_SIZE  4
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID

[Shashank Sharma]

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.

These blocks are:

- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.

- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.

This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
  an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Emil Velikov 

V2: Addressed
Review comments from Emil:
- Use 1ULL< 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
  to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
  blocks.

V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
  choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
  bit positions manually.

V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
  only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c  | 157 +++-
 include/drm/drm_connector.h |  20 ++
 2 files changed, 174 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2d1b30..8c7e73b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
 #define VIDEO_BLOCK 0x02
 #define VENDOR_BLOCK0x03
 #define SPEAKER_BLOCK  0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420   0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
 #define EDID_BASIC_AUDIO   (1 << 6)
 #define EDID_CEA_YCRCB444  (1 << 5)
 #define EDID_CEA_YCRCB422  (1 << 4)
@@ -3153,15 +3155,79 @@ drm_display_mode_from_vic_index(struct drm_connector 
*connector,
return newmode;
 }
 
+/*
+ * do_y420vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * Parse the CEA-861-F YCBCR 420 Video Data Block (Y420VDB)
+ * which contains modes which can be supported in YCBCR 420
+ * output format only.
+ */
+static int do_y420vdb_modes(struct drm_connector *connector,
+  const u8 *svds, u8 svds_len)
+{
+   int modes = 0, i;
+   struct drm_device *dev = connector->dev;
+   struct drm_display_info *info = &connector->display_info;
+   struct drm_hdmi_info *hdmi = &info->hdmi;
+
+   for (i = 0; i < svds_len; i++) {
+   u8 vic = svd_to_vic(svds[i]);
+   struct drm_display_mode *newmode;
+
+   newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
+   if (!newmode)
+   break;
+   bitmap_set(hdmi->y420_vdb_modes, vic, 1);
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+
+   if (modes > 0)
+   info->color_formats |= DRM_COLOR_FORMAT_YCRCB420;
+   return modes;
+}
+
+/*
+ * drm_add_cmdb_modes - Add a YCBCR 420 mode into bitmap
+ * @connector: connector correspo

[Intel-gfx] [PATCH v4 02/15] drm: add YCBCR 420 capability identifier

[Shashank Sharma]

This patch adds a bool variable (ycbcr_420_allowed) in the drm connector
structure. While handling the EDID from HDMI 2.0 sinks, its important to
know if the source is capable of handling YCBCR 420 outputs or not, so that
a lot of work can be done/bypassed based on this information. One such
example is adding YCBCR420 only modes.

If the driver knows that this source is not HDMI 2.0 capable, it will
not add YCBCR420-only modes while adding EDID modes, and will prevent
any runtime modeset failures.

This variable will be initialized from I915 driver in the next patch
and will be used in the EDID handling for HDMI 2.0 specific features,
in this same series.

V3: introduced the new variable
V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville)

Signed-off-by: Shashank Sharma 
---
 include/drm/drm_connector.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index d8bb25f..7493fd3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -728,6 +728,15 @@ struct drm_connector {
bool interlace_allowed;
bool doublescan_allowed;
bool stereo_allowed;
+
+   /**
+* @ycbcr_420_allowed : This bool indicates if this connector is
+* capable of handling YCBCR 420 output. While parsing the EDID
+* blocks, its very helpful to know, if the source is capable of
+* handling YCBCR 420 outputs.
+*/
+   bool ycbcr_420_allowed;
+
/**
 * @registered: Is this connector exposed (registered) with userspace?
 * Protected by @mutex.
-- 
2.7.4

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

[Intel-gfx] [PATCH v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)

[Shashank Sharma]

CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Harry Wentland 

V2: Rebase
V3: Rebase
V4: Added native bit handling as per CEA-861-F spec (Ville)

Reviewed-by: Jose Abreu 
Reviewed-by: Alex Deucher 
Acked-by: Harry Wentland 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 227 -
 1 file changed, 226 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d312fe1..e2d1b30 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
{
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  

[Intel-gfx] [PATCH v4 01/15] drm: add HDMI 2.0 VIC support for AVI info-frames

[Shashank Sharma]

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
  As CEA-861-F has already defined VICs for 4K videomodes, this
  patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
  until the mode is 3D.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
  send only one of it.

Reviewed-by: Andrzej Hajda 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
 drivers/gpu/drm/bridge/sii902x.c  |  2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
 drivers/gpu/drm/drm_edid.c| 12 +++-
 drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c | 17 -
 drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
 drivers/gpu/drm/tegra/hdmi.c  |  2 +-
 drivers/gpu/drm/tegra/sor.c   |  2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
 include/drm/drm_edid.h|  3 ++-
 21 files changed, 50 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 3c62c45..4923ddc 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index c8ed0fa..4101684 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 3e90c19..a7f6b32 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v8_0_audio_write_sad_regs(encoder);
dce_v8_0_audio_write_latency_fields(encoder, mode);
 
-   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 9006578..a083211 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1097,7 +1097,8 @@ static void anx78xx_bridge_mode_set(struct drm_bridge 
*bridg

[Intel-gfx] [PATCH v4 00/15] HDMI YCBCR output handling in DRM layer

[Shashank Sharma]

This patch series adds support for YCBCR HDMI output handling in DRM layer.
The main aim of this patch series was to handle YCBCR 4:2:0 output for
HDMI 2.0 displays. But while providing a framework to handle non-RGB
outputs, support for YCBCR 4:4:4 and 4:2:2 was also added.

First 2 patches, complete the CEA mode-db in drm driver, by adding
new 4k modes. Current CEA mode-db contains 64 modes only (VIC 1-64),
whereas CEA-861-F defined VICs up to 107, including 4k modes, from VIC range
93-107. First patch makes sure that inclusion of these modes doesn't break
existing HDMI 1.4 monitors, across various drivers.

Next 3 patches focus on parsing new YCBCR 4:2:0 EDID blocks, and adding
YCBCR 4:2:0 modes in connector (only for connectors who declare themselves
as HDMI 2.0 compliant during init)

Next 6 patch create a property (hdmi_output_format) and add the framework
to handle the HDMI output type defined in the property. There are also some
helper functions provided, to help with the YCBCR HDMI output, like adding
deep color information, set color space and get the appropriate YCBCR output
based on source + sink capabilities.

A User can set the HDMI output property, and select the desired output
from YCBCR 4:4:4, 4:2:2 or 4:2:0. A driver can use framework's helper
functions to check if this source + sink + mode combination can drive
the desired output, or what would be the best suitable output.

By default the value of the property is default RGB, so if you don't
set the property, there is no change in the regular functionality of
an existing source.

More details are available with respective patches.

Last 6 patches add the I915 core implementation of the HDMI output handling.
This patch series was tested with a GLK device, ACER S277HK monitor and
ASTRO VA-1844A HDMI analyzer.

V3: Added a new patch to introduce YCBCR_420_allowed identifier.
V4: Added a new patch to re-sequence sink info parsing befor CEA modes.

Shashank Sharma (15):
  drm: add HDMI 2.0 VIC support for AVI info-frames
  drm: add YCBCR 420 capability identifier
  drm/edid: Complete CEA modedb(VIC 1-107)
  drm/edid: parse YCBCR 420 videomodes from EDID
  drm/edid: parse ycbcr 420 deep color information
  drm/edid: parse sink information before CEA blocks
  drm: create hdmi output property
  drm: set output colorspace in AVI infoframe
  drm: add helper functions for YCBCR output handling
  drm/i915: add compute-config for YCBCR outputs
  drm/i915: prepare scaler for YCBCR420 modeset
  drm/i915: prepare pipe for YCBCR output
  drm/i915: prepare csc unit for YCBCR HDMI output
  drm/i915: set colorspace for ycbcr outputs
  drm/i915/glk: set HDMI 2.0 identifier

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |   2 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c |   3 +-
 drivers/gpu/drm/bridge/sii902x.c  |   2 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   2 +
 drivers/gpu/drm/drm_atomic_helper.c   |   4 +
 drivers/gpu/drm/drm_connector.c   |  32 +++
 drivers/gpu/drm/drm_edid.c| 462 +-
 drivers/gpu/drm/drm_modes.c   | 307 
 drivers/gpu/drm/exynos/exynos_hdmi.c  |   2 +-
 drivers/gpu/drm/i2c/tda998x_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h   |   3 +
 drivers/gpu/drm/i915/intel_atomic.c   |   6 +
 drivers/gpu/drm/i915/intel_color.c|  47 ++-
 drivers/gpu/drm/i915/intel_display.c  |  68 +
 drivers/gpu/drm/i915/intel_drv.h  |  13 +-
 drivers/gpu/drm/i915/intel_hdmi.c | 131 -
 drivers/gpu/drm/i915/intel_panel.c|   3 +-
 drivers/gpu/drm/i915/intel_sdvo.c |   3 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c   |   2 +-
 drivers/gpu/drm/omapdrm/omap_encoder.c|   3 +-
 drivers/gpu/drm/radeon/radeon_audio.c |   2 +-
 drivers/gpu/drm/rockchip/inno_hdmi.c  |   2 +-
 drivers/gpu/drm/sti/sti_hdmi.c|   2 +-
 drivers/gpu/drm/tegra/hdmi.c  |   2 +-
 drivers/gpu/drm/tegra/sor.c   |   2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|   2 +-
 drivers/gpu/drm/zte/zx_hdmi.c |   2 +-
 include/drm/drm_connector.h   |  50 
 include/drm/drm_edid.h|  14 +-
 include/drm/drm_mode_config.h |   5 +
 include/drm/drm_modes.h   |   5 +
 34 files changed, 1157 insertions(+), 34 deletions(-)

-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for concurrent global resets to complete (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Wait for concurrent global resets to complete (rev2)
URL   : https://patchwork.freedesktop.org/series/25994/
State : success

== Summary ==

Series 25994v2 drm/i915: Wait for concurrent global resets to complete
https://patchwork.freedesktop.org/api/1.0/series/25994/revisions/2/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:464s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:481s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:569s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:546s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:497s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:581s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:433s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:464s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:490s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:511s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:570s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:573s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:479s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:435s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:513s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:506s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:617s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:1   skip:29  
time:403s

508325c380d12aaccd410adc935e24f70acf69a8 drm-tip: 2017y-06m-19d-09h-05m-32s UTC 
integration manifest
1f1187f drm/i915: Wait for concurrent global resets to complete

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4984/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Wait for concurrent global resets to complete

[Chris Wilson]

If we enter i915_handle_error() a second time and a global reset is
already in progress, we can simply wait for completion of the first
reset. Currently we exit earlier prior to the actual reset being
performed -- the worst of both worlds!

v2: Plug into the existing reset_queue, and remember that kselftests is
playing games with I915_RESET_BACKOFF to prevent hangcheck from screwing
up.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_irq.c  | 23 +++
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c |  4 
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4cd9ee1ba332..db21f4e1fb85 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2600,13 +2600,13 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
 }
 
 /**
- * i915_reset_and_wakeup - do process context error handling work
+ * i915_global_reset - do process context error handling work
  * @dev_priv: i915 device private
  *
  * Fire an error uevent so userspace can see that a hang or error
  * was detected.
  */
-static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv)
+static void i915_global_reset(struct drm_i915_private *dev_priv)
 {
struct kobject *kobj = &dev_priv->drm.primary->kdev->kobj;
char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
@@ -2646,13 +2646,6 @@ static void i915_reset_and_wakeup(struct 
drm_i915_private *dev_priv)
if (!test_bit(I915_WEDGED, &dev_priv->gpu_error.flags))
kobject_uevent_env(kobj,
   KOBJ_CHANGE, reset_done_event);
-
-   /*
-* Note: The wake_up also serves as a memory barrier so that
-* waiters see the updated value of the dev_priv->gpu_error.
-*/
-   clear_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags);
-   wake_up_all(&dev_priv->gpu_error.reset_queue);
 }
 
 static inline void
@@ -2744,11 +2737,17 @@ void i915_handle_error(struct drm_i915_private 
*dev_priv,
if (!engine_mask)
goto out;
 
-   if (test_and_set_bit(I915_RESET_BACKOFF,
-&dev_priv->gpu_error.flags))
+   if (test_and_set_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags)) {
+   wait_event(dev_priv->gpu_error.reset_queue,
+  !test_bit(I915_RESET_BACKOFF,
+&dev_priv->gpu_error.flags));
goto out;
+   }
+
+   i915_global_reset(dev_priv);
 
-   i915_reset_and_wakeup(dev_priv);
+   clear_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags);
+   wake_up_all(&dev_priv->gpu_error.reset_queue);
 
 out:
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c 
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index aa31d6c0cdfb..cc00a361f0fa 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -316,6 +316,8 @@ static int igt_global_reset(void *arg)
 
GEM_BUG_ON(test_bit(I915_RESET_HANDOFF, &i915->gpu_error.flags));
clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+   wake_up_all(&i915->gpu_error.reset_queue);
+
if (i915_terminally_wedged(&i915->gpu_error))
err = -EIO;
 
@@ -404,6 +406,7 @@ static int igt_wait_reset(void *arg)
 unlock:
mutex_unlock(&i915->drm.struct_mutex);
clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+   wake_up_all(&i915->gpu_error.reset_queue);
 
if (i915_terminally_wedged(&i915->gpu_error))
return -EIO;
@@ -519,6 +522,7 @@ static int igt_reset_queue(void *arg)
 unlock:
mutex_unlock(&i915->drm.struct_mutex);
clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+   wake_up_all(&i915->gpu_error.reset_queue);
 
if (i915_terminally_wedged(&i915->gpu_error))
return -EIO;
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Harry Wentland]

On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> Problem:
> While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immidietly follwoing an atomic_commit.

s/immidietly/immediately/g
s/follwoing/following/g

> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the state and only disabled
> planes. This probably due to a commit which hadn't changed any property
> which would require attaching crtc state. This means drmHandleEvent
> will never wake up from read since without CRTC in atomic state
> the event fd will not be singnaled.

s/singnaled/signaled/g

> This point to a bug in IGT but also DRM should gracefully
> fail  such scenario so no hang on user side will happen.
> 

Can we create an IGT fix for this to make sure this won't happen?

> Fix:
> Explicitly fail by failing atomic_commit early in
> drm_mode_atomic_commit where such problem can be identified.
> 

The change seems reasonable to me but I would like to see some input
from someone who's more familiar with the usermode side of things.

> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/drm_atomic.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..32eae1c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
> - int i, ret;
> + int i, c = 0, ret;
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>   return 0;
> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  
>   crtc_state->event->base.fence = fence;
>   }
> +
> + c++;

Not sure if intentional, but I like it.

>   }
>  
> + /*
> +  * Having this flag means user mode pends on event which will never
> +  * reach due to lack of at least one CRTC for signaling
> +  */
> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> + return -EINVAL;
> +
>   return 0;
>  }
>  
> @@ -2179,6 +2188,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   drm_mode_object_unreference(obj);
>   }
>  
> +
> +

Remove these extraneous newlines.

Harry

>   ret = prepare_crtc_signaling(dev, state, arg, file_priv, &fence_state,
>&num_fences);
>   if (ret)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Alex Williamson]

On Mon, 19 Jun 2017 08:38:32 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > My suggestion was to use vfio device fd for this ioctl and have
> > dmabuf
> > mgr fd as member in above query_plane structure, for region type it
> > would be set to 0.  
> 
> Region type should be DRM_PLANE_TYPE_PRIMARY
> 
> > Can't mmap that page to get surface information. There is no way to
> > synchronize between QEMU reading this mmapped region and vendor
> > driver
> > writing it. There could be race condition in these two operations.
> > Read
> > on this page should be trapped and blocking, so that surface in that
> > region is only updated when its asked for.  
> 
> Does it make sense to have a "generation" field in the plane_info
> struct (which gets increased each time the struct changes) ?

It seems less cumbersome than checking each field to see if it has
changed.  Thanks,

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

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Alex Williamson]

On Mon, 19 Jun 2017 08:34:13 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > So perhaps this becomes:
> > 
> > struct vfio_device_gfx_plane_info {
> > __u64 start;
> > __u64 drm_format_mod;
> > __u32 drm_format;
> > __u32 width;
> > __u32 height;
> > __u32 stride;
> > __u32 size;
> > __u32 x_pos;
> > __u32 y_pos;
> > };  
> 
> Looks good.
> 
> > struct vfio_device_query_gfx_plane {
> > __u32 argsz;
> > __u32 flags;
> > #define VFIO_GFX_PLANE_FLAGS_REGION_ID  (1 << 0)
> > #define VFIO_GFX_PLANE_FLAGS_PLANE_ID   (1 << 1)
> > struct vfio_device_gfx_plane_info plane_info;
> > __u32 id; 
> > };  
> 
> Hmm, plane isn't really an ID, it is a type, with type being either
> DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think the
> flage above make sense.

The intention was that ..._REGION_ID and ...PLANE_ID are describing
what the vfio_device_query_gfx_plane.id field represents, either a
region index or a plane identifier.  The type of plane would be
represented within the vfio_device_gfx_plane_info struct.

> What are the nvidia plane for cursor support btw?
> 
> > The flag defines the data in the id field as either referring to a
> > region (perhaps there could be multiple regions with only one active)  
> 
> Well, we have a "start" field in vfio_device_gfx_plane_info (maybe we
> should rename that to "offset"), which can be used to place multiple
> planes into a single, fixed region.

That seems reasonable.
 
> Also I think it would be useful to have some way to figure the device
> capabilities as the userspace workflow will look quite different for
> the two cases.

In the region case, VFIO_DEVICE_GET_REGION_INFO would include a device
specific region with a hopefully common identifier to identify it as a
graphics framebuffer.  VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
plane as a region index.

In the dmabuf case, VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
plane as a "plane ID" and some sort of
VFIO_DEVICE_GET_GFX_PLANE(VFIO_GFX_TYPE_DMABUF) ioctl would be
necessary to get a file descriptor to that plane.

What else are you thinking we need?  Thanks,

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

[Intel-gfx] [Regression report] Weekly regression report WW42

[elizabethx . de . la . torre . mena]

Link to FDO regression list: 
https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&component=DRM%2FIntel&f0=OP&f1=OP&f2=short_desc&f3=keywords&f4=CP&f5=CP&j1=OR&known_name=i915%20regressions&list_id=600614&o2=anywordssubstr&o3=anywordssubstr&op_sys=All&op_sys=Linux%20%28All%29&op_sys=other&order=bug_id%20DESC&product=DRI&query_based_on=i915%20regressions&query_format=advanced&rep_platform=All&rep_platform=x86%20%28IA32%29&rep_platform=x86-64%20%28AMD64%29&rep_platform=IA64%20%28Itanium%29&rep_platform=Other&v2=regression%20bisect&v3=regression%20bisected%20pending_bisect
Total regressions: 19

This week regressions:0
+---+-+++
| BugId | Summary | Created on | Bisect |
+---+-+++

Previous regressions:19
++--+++
| BugId  | Summary  
| Created on | Bisect |
++--+++
| 99575  | [ilk bisected] "drm/i915: Type safe register read/write" -> 
poor/nonexistent IPS | 2017-01-28 | Yes|
| 99362  | no resolutions >=1080p with Acer P7500 and Thinkpad X1   
| 2017-01-11 | No |
| 99093  | [PNV][BLK][ELK][BXT/SKL/KBL/BDW/BSW/GLK][regression] N450 and D510 
machines get  | 2016-12-15 | Yes|
| 98517  | Skylake gen6 suspend/resume video regression 4.9 
| 2016-10-31 | No |
| 96428  | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR* dp aux hw did not 
signal timeout (h | 2016-06-07 | Yes|
| 95736  | [SNB bisected] *ERROR* uncleared fifo underrun on pipe A 
| 2016-05-24 | Yes|
| 94590  | [KBL] igt/kms_fbcon_fbt/psr-suspend regression   
| 2016-03-17 | No |
| 93782  | [i9xx TV][BISECT] vblank wait timeout on crtc
| 2016-01-19 | Yes|
| 92050  | [regression]/bug introduced by commit 
[0e572fe7383a376992364914694c39aa7fe44c1d] | 2015-09-19 | Yes|
| 91974  | [bisected] unrecoverable black screen after killing X
| 2015-09-11 | Yes|
| 88124  | i915: regression: after DP connected (via docking station) monitor 
is turned off | 2015-01-06 | Yes|
| 101245 | Haswell ULT max. resolution regression in KMS [HSW] [i915]   
| 2017-05-31 | No |
| 10 | [Regression BDW] backlight flickering/display artifacting on 
Broadwell integrate | 2017-05-20 | No |
| 101049 | [IVB] [bisected] Freeze when booting with kernel 4.9 and later   
| 2017-05-15 | Yes|
| 100973 | [SKL][Regression] Dell monitor stays black until GDM restart 
| 2017-05-08 | No |
| 100907 | [i965 bisected] boot hang on Dell D830 with kernel > 4.7 
| 2017-05-02 | Yes|
| 100617 | [Regression bisected] Gnome Shell slow animations
| 2017-04-08 | Yes|
| 100610 | WARNING: CPU: 1 PID: 16615 at drivers/gpu/drm/drm_debugfs_crc.c:185 
crtc_crc_ope | 2017-04-07 | Yes|
| 100221 | [SKL] Resume from suspend to disk fails - bisected   
| 2017-03-15 | Yes|
++--+++___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [Bug Report] Weekly progress report WW24

[De La Torre Mena, ElizabethX]

Highlights:

-  22 bugs open during the week

-  20 bugs closed during the week

-  359 total bugs remain open

-  16 bugs labeled ReadyForDev during the week

-  88 total bugs labeled ReadyForDev remain open

Details:

-  Bugs open during the week (by priority)

highest

1

high

1

medium

20

Total

22



https://bugs.freedesktop.org/report.cgi?x_axis_field=&y_axis_field=priority&z_axis_field=&no_redirect=1&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=DRI&component=DRM%2FIntel&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=PLEASETEST&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=creation_ts&o1=greaterthaneq&v1=2017-06-11&f2=noop&o2=noop&v2=&format=table&action=wrap

-  Bugs closed during the week (by priority)

highest

4

high

4

medium

12

Total

20


https://bugs.freedesktop.org/report.cgi?x_axis_field=&y_axis_field=priority&z_axis_field=&no_redirect=1&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=DRI&component=DRM%2FIntel&bug_status=CLOSED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=delta_ts&o1=greaterthaneq&v1=2017-06-11&f2=delta_ts&o2=lessthan&v2=2017-06-19&f3=noop&o3=noop&v3=&format=table&action=wrap

-  Total Bugs(by priority)
highest

15

high

43

medium

288

low

11

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for concurrent global resets to complete

[Patchwork]

== Series Details ==

Series: drm/i915: Wait for concurrent global resets to complete
URL   : https://patchwork.freedesktop.org/series/25994/
State : success

== Summary ==

Series 25994v1 drm/i915: Wait for concurrent global resets to complete
https://patchwork.freedesktop.org/api/1.0/series/25994/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:461s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:488s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:582s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:545s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:492s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:583s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:430s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:462s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:526s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:572s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:577s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:478s
fi-skl-6700hqtotal:278  pass:228  dwarn:1   dfail:0   fail:27  skip:22  
time:428s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:512s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:504s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:620s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:1   skip:29  
time:414s

508325c380d12aaccd410adc935e24f70acf69a8 drm-tip: 2017y-06m-19d-09h-05m-32s UTC 
integration manifest
34c74ea drm/i915: Wait for concurrent global resets to complete

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4983/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Wait for concurrent global resets to complete

[Chris Wilson]

If we enter i915_handle_error() a second time and a global reset is
already in progress, we can simply wait for completion of the first
reset. Currently we exit earlier prior to the actual reset being
performed -- the worst of both worlds!

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_irq.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4cd9ee1ba332..906128e8c350 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2600,13 +2600,13 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
 }
 
 /**
- * i915_reset_and_wakeup - do process context error handling work
+ * i915_global_reset - do process context error handling work
  * @dev_priv: i915 device private
  *
  * Fire an error uevent so userspace can see that a hang or error
  * was detected.
  */
-static void i915_reset_and_wakeup(struct drm_i915_private *dev_priv)
+static void i915_global_reset(struct drm_i915_private *dev_priv)
 {
struct kobject *kobj = &dev_priv->drm.primary->kdev->kobj;
char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
@@ -2646,13 +2646,6 @@ static void i915_reset_and_wakeup(struct 
drm_i915_private *dev_priv)
if (!test_bit(I915_WEDGED, &dev_priv->gpu_error.flags))
kobject_uevent_env(kobj,
   KOBJ_CHANGE, reset_done_event);
-
-   /*
-* Note: The wake_up also serves as a memory barrier so that
-* waiters see the updated value of the dev_priv->gpu_error.
-*/
-   clear_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags);
-   wake_up_all(&dev_priv->gpu_error.reset_queue);
 }
 
 static inline void
@@ -2745,11 +2738,19 @@ void i915_handle_error(struct drm_i915_private 
*dev_priv,
goto out;
 
if (test_and_set_bit(I915_RESET_BACKOFF,
-&dev_priv->gpu_error.flags))
+&dev_priv->gpu_error.flags)) {
+   wait_on_bit(&dev_priv->gpu_error.flags,
+   I915_RESET_BACKOFF,
+   TASK_UNINTERRUPTIBLE);
goto out;
+   }
+
+   i915_global_reset(dev_priv);
 
-   i915_reset_and_wakeup(dev_priv);
+   clear_bit(I915_RESET_BACKOFF, &dev_priv->gpu_error.flags);
+   wake_up_bit(&dev_priv->gpu_error.flags, I915_RESET_BACKOFF);
 
+   wake_up_all(&dev_priv->gpu_error.reset_queue);
 out:
intel_runtime_pm_put(dev_priv);
 }
-- 
2.11.0

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Setting pch_id for HSW/BDW in virtual environment

[Martin Peres]

On 14/06/17 16:18, Joonas Lahtinen wrote:

On ke, 2017-06-14 at 11:27 +, Patchwork wrote:

== Series Details ==

Series: drm/i915: Setting pch_id for HSW/BDW in virtual environment
URL   : https://patchwork.freedesktop.org/series/25772/
State : success


Janie & Daniel,

This patch could be considered for the CI topic branch, because it'll
do the detection right for the machines in the CI, but might worsen
situation for others.

Regards, Joonas


I agree. I could merge that now to fix our CI while they are reworking 
the world not to have this problem.


Daniel, what's your take on this?

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

Re: [Intel-gfx] [PATCH] [RFC] drm/i915/skl+: enable PF_ID interlace mode in SKL

[Ville Syrjälä]

On Mon, Jun 19, 2017 at 05:50:28PM +0530, Mahesh Kumar wrote:
> Hi Ville,
> 
> Thanks for review
> 
> 
> On Friday 16 June 2017 07:47 PM, Ville Syrjälä wrote:
> > On Wed, Jun 07, 2017 at 03:19:05PM +0530, Mahesh Kumar wrote:
> >> In previous GEN default Interlace mode enabled is IF-ID mode, but IF-ID
> >> mode has many limitations in SKL. This mode doesn't support y-tiling,
> >> 90-270 rotation is not supported & YUV-420 planar source pixel formats
> >> are not supported with above mode.
> > I think we'll want something much more simple for stable. And that
> > should probably be just -EINVAL if we try to do any of those
> > forbidden things with an interlaced mode.
> Agree.
> >
> >> This patch make changes to use PF-ID Interlace mode in SKL+ platforms.
> >> PF-ID mode require one scaler to be attached in pipe-scaling mode.
> >>During WM calculation adjusted pixel rate need to be doubled.
> >>During max_supported_pixel_format calculation vertical downscale is 2.0.
> >>
> >> Signed-off-by: Mahesh Kumar 
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90238
> >> ---
> >>   drivers/gpu/drm/i915/intel_atomic.c  | 13 ++
> >>   drivers/gpu/drm/i915/intel_display.c | 47 
> >> +++-
> >>   drivers/gpu/drm/i915/intel_drv.h | 10 
> >>   drivers/gpu/drm/i915/intel_panel.c   |  9 +--
> >>   drivers/gpu/drm/i915/intel_pm.c  | 17 -
> >>   5 files changed, 87 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index d791b3ef89b5..06ed2fc449d7 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -248,6 +248,13 @@ int intel_atomic_setup_scalers(struct 
> >> drm_i915_private *dev_priv,
> >>return -EINVAL;
> >>}
> >>   
> >> +  if (num_scalers_need > 1 &&
> >> +  scaler_state->scaler_users & (1 << SKL_CRTC_INDEX) &&
> >> +  scaler_state->scaler_users & (1 << SKL_PF_ID_INDEX)) {
> >> +  DRM_ERROR("Can't attach scaler to CRTC in Interlace Mode\n");
> >> +  return -EINVAL;
> >> +  }
> > I thought the whole point of PF-ID here was that we can then do pipe
> > scaling (and other things). So this check looks wrong to me.
> With PF-ID we can have Y-tiled buffers, & 90/270 rotation enabled, It 
> doesn't explicitly talk about scaling.

PF-ID itself is scaling. Presumably you don't have to have exactly
2:1 scaling factor with PF-ID.

> BSpec doesn't limit us from using 2 scalers as a pipe scaler, still I 
> sent a query to HW team regarding same.

We don't want to use multiple scalers. I dubt that would even work. And
before SKL the panel fitter was a dedicated piece of hw anyway so there
was no way to even try to assign multiple scalers to the pipe.

>
> Current S/W framework doesn't allows us to attach multiple pipe-scalers 
> in a pipe (multiple scaler_id associated with one crtc_state). that's 
> the reason for above check.
> >
> > And I'm thinking we shouldn't be adding yet another scaler user for
> > this, and instead it should just be part of the normal pfit setup.
> To use existing scaler framework, we need one scaler-user to be 
> associated with it.
> If we use existing CRTC_INDEX user then there will be many corner cases 
> to handle.

I'm not 100% whether we need any adjustment in the pfit code itself.
The spec doesn't seem to tell us that we need to adjust the panel
fitter window in any way. That's a little inconsistent with the
resulting scaling factor, but I guess the hw will automagically reduce
the destination size by two when the pipe is in the PF-ID mode.

So I think it should mostly be a simple matter of calling the pfit
code to set up the pos/size, and then you should just adjust
ilk_pipe_pixel_rate() to double the resulting pixel rate.

That said, I'm not really sure we want to flip PF-ID on automagically.
It would result in scaling when the user doesn't necessarily want it.
So we might want to think about some kind if property to control this
stuff.

> To make it simple I added new scaler-user.
> This code uses pfit setup only  to attach/enable Pipe-scaler.
> Please let me know if I didn't understood your concern correctly.
> Any other suggestions/queries are welcome.
> 
> -Mahesh
> 
> >
> >> +
> >>/* walkthrough scaler_users bits and start assigning scalers */
> >>for (i = 0; i < sizeof(scaler_state->scaler_users) * 8; i++) {
> >>int *scaler_id;
> >> @@ -264,6 +271,12 @@ int intel_atomic_setup_scalers(struct 
> >> drm_i915_private *dev_priv,
> >>   
> >>/* panel fitter case: assign as a crtc scaler */
> >>scaler_id = &scaler_state->scaler_id;
> >> +  } else if (i == SKL_PF_ID_INDEX) {
> >> +  name = "PF-ID INTERLACE MODE";
> >> +  idx = intel_crtc->base.base.id;
> >> +
> >> +  /* PF-ID interlaced mode cas

Re: [Intel-gfx] [PATCH v9 05/21] drm/i915: Add support for per engine reset recovery

[Chris Wilson]

Quoting Michel Thierry (2017-06-15 21:18:12)
> @@ -2992,10 +3014,8 @@ void i915_gem_reset_finish(struct drm_i915_private 
> *dev_priv)
>  
> lockdep_assert_held(&dev_priv->drm.struct_mutex);
>  
> -   for_each_engine(engine, dev_priv, id) {
> -   tasklet_enable(&engine->irq_tasklet);
> -   kthread_unpark(engine->breadcrumbs.signaler);
> -   }
> +   for_each_engine(engine, dev_priv, id)
> +   i915_gem_reset_finish_engine(engine);

And we shouldn't forget to clear the active_request here!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_rmfb: Fix cursor fb size

[Lofstedt, Marta]

Tested OK, also NOTE that this fixes bug 97975

/Marta

> -Original Message-
> From: ville.syrj...@linux.intel.com [mailto:ville.syrj...@linux.intel.com]
> Sent: Monday, June 19, 2017 3:29 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Lofstedt, Marta 
> Subject: [PATCH i-g-t] tests/kms_rmfb: Fix cursor fb size
> 
> From: Ville Syrjälä 
> 
> Don't use the display mode size to determine the cursor fb size. That will 
> lead
> to a framebuffer with a stride that the cursor plane won't support. Just use
> the max cursor size as the fb size instead.
> 
> This started to trip up after i915 started to actually use the cursor fb 
> stride in
> commit 1e1bb8710e60 ("drm/i915: Use fb->pitches[0] in cursor code")
> 
> Cc: Marta Löfstedt 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97975
> Signed-off-by: Ville Syrjälä 
> ---
>  tests/kms_rmfb.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/tests/kms_rmfb.c b/tests/kms_rmfb.c index
> 5753d74c9411..9f1f564e54aa 100644
> --- a/tests/kms_rmfb.c
> +++ b/tests/kms_rmfb.c
> @@ -66,16 +66,11 @@ test_rmfb(struct rmfb_data *data, igt_output_t
> *output, enum pipe pipe, bool reo
>   igt_create_fb(data->drm_fd, mode->hdisplay, mode-
> >vdisplay,
> DRM_FORMAT_XRGB,
> LOCAL_DRM_FORMAT_MOD_NONE, &fb);
> 
> - igt_create_fb(data->drm_fd, mode->hdisplay, mode-
> >vdisplay,
> -   DRM_FORMAT_ARGB,
> LOCAL_DRM_FORMAT_MOD_NONE, &argb_fb);
> -
>   do_or_die(drmGetCap(data->drm_fd,
> DRM_CAP_CURSOR_WIDTH, &cursor_width));
> - if (cursor_width > mode->hdisplay)
> - cursor_width = mode->hdisplay;
> -
>   do_or_die(drmGetCap(data->drm_fd,
> DRM_CAP_CURSOR_HEIGHT, &cursor_height));
> - if (cursor_height > mode->vdisplay)
> - cursor_height = mode->vdisplay;
> +
> + igt_create_fb(data->drm_fd, cursor_width, cursor_height,
> +   DRM_FORMAT_ARGB,
> LOCAL_DRM_FORMAT_MOD_NONE, &argb_fb);
> 
>   /*
>* Make sure these buffers are suited for display use
> --
> 2.13.0

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

Re: [Intel-gfx] [PATCH v9 05/21] drm/i915: Add support for per engine reset recovery

[Chris Wilson]

Quoting Michel Thierry (2017-06-15 21:18:12)
>  int i915_gem_reset_prepare(struct drm_i915_private *dev_priv)
>  {
> struct intel_engine_cs *engine;
> +   struct drm_i915_gem_request *request;
> enum intel_engine_id id;
> int err = 0;
>  
> -   /* Ensure irq handler finishes, and not run again. */
> for_each_engine(engine, dev_priv, id) {
> -   struct drm_i915_gem_request *request = NULL;
> -
> -   /* Prevent the signaler thread from updating the request
> -* state (by calling dma_fence_signal) as we are processing
> -* the reset. The write from the GPU of the seqno is
> -* asynchronous and the signaler thread may see a different
> -* value to us and declare the request complete, even though
> -* the reset routine have picked that request as the active
> -* (incomplete) request. This conflict is not handled
> -* gracefully!
> -*/
> -   kthread_park(engine->breadcrumbs.signaler);
> -
> -   /* 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
> -* calling engine->init_hw() and also writing the ELSP.
> -* Turning off the engine->irq_tasklet until the reset is over
> -* prevents the race.
> -*/
> -   tasklet_kill(&engine->irq_tasklet);
> -   tasklet_disable(&engine->irq_tasklet);
> -
> -   if (engine->irq_seqno_barrier)
> -   engine->irq_seqno_barrier(engine);
> -
> -   if (engine_stalled(engine)) {
> -   request = i915_gem_find_active_request(engine);
> -   if (request && request->fence.error == -EIO)
> -   err = -EIO; /* Previous reset failed! */
> +   request = i915_gem_reset_prepare_engine(engine);
> +   if (IS_ERR(request)) {
> +   err = PTR_ERR(request);
> +   break;

s/break/continue/

Otherwise, prepare/finish are unbalanced leading to tasklets being very
confused.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/kms_rmfb: Fix cursor fb size

[ville . syrjala]

From: Ville Syrjälä 

Don't use the display mode size to determine the cursor fb size. That
will lead to a framebuffer with a stride that the cursor plane won't
support. Just use the max cursor size as the fb size instead.

This started to trip up after i915 started to actually use the cursor fb
stride in commit 1e1bb8710e60 ("drm/i915: Use fb->pitches[0] in cursor code")

Cc: Marta Löfstedt 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97975
Signed-off-by: Ville Syrjälä 
---
 tests/kms_rmfb.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/tests/kms_rmfb.c b/tests/kms_rmfb.c
index 5753d74c9411..9f1f564e54aa 100644
--- a/tests/kms_rmfb.c
+++ b/tests/kms_rmfb.c
@@ -66,16 +66,11 @@ test_rmfb(struct rmfb_data *data, igt_output_t *output, 
enum pipe pipe, bool reo
igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
  DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE, &fb);
 
-   igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
- DRM_FORMAT_ARGB, LOCAL_DRM_FORMAT_MOD_NONE, &argb_fb);
-
do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_WIDTH, &cursor_width));
-   if (cursor_width > mode->hdisplay)
-   cursor_width = mode->hdisplay;
-
do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_HEIGHT, 
&cursor_height));
-   if (cursor_height > mode->vdisplay)
-   cursor_height = mode->vdisplay;
+
+   igt_create_fb(data->drm_fd, cursor_width, cursor_height,
+ DRM_FORMAT_ARGB, LOCAL_DRM_FORMAT_MOD_NONE, &argb_fb);
 
/*
 * Make sure these buffers are suited for display use
-- 
2.13.0

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert execbuf to use struct-of-array packing for critical fields

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-06-19 13:06:18)
> 
> On 16/06/2017 17:02, Chris Wilson wrote:
> > @@ -520,7 +511,8 @@ static inline int use_cpu_reloc(const struct 
> > reloc_cache *cache,
> >   static int eb_reserve_vma(const struct i915_execbuffer *eb,
> > struct i915_vma *vma)
> >   {
> > - struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
> > + struct drm_i915_gem_exec_object2 *entry =
> > + &eb->exec[vma->exec_flags - eb->flags];
> 
> There are three instances of this so maybe "entry = exec_entry(eb, 
> vma)"? Added benefit that exec_entry implementation could site a comment 
> explaining the magic.

You were meant to jump in and suggest some way I would store the index.
:)

> > @@ -870,23 +864,20 @@ static void eb_release_vmas(const struct 
> > i915_execbuffer *eb)
> >   unsigned int i;
> >   
> >   for (i = 0; i < count; i++) {
> > - struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
> > - struct i915_vma *vma = exec_to_vma(entry);
> > + struct i915_vma *vma = eb->vma[i];
> > + unsigned int flags = eb->flags[i];
> >   
> >   if (!vma)
> >   continue;
> >   
> > - GEM_BUG_ON(vma->exec_entry != entry);
> > - vma->exec_entry = NULL;
> > + GEM_BUG_ON(vma->exec_flags != &eb->flags[i]);
> > + vma->exec_flags = NULL;
> >   
> > - if (entry->flags & __EXEC_OBJECT_HAS_PIN)
> > - __eb_unreserve_vma(vma, entry);
> > + if (flags & __EXEC_OBJECT_HAS_PIN)
> > + __eb_unreserve_vma(vma, flags);
> >   
> > - if (entry->flags & __EXEC_OBJECT_HAS_REF)
> > + if (flags & __EXEC_OBJECT_HAS_REF)
> >   i915_vma_put(vma);
> > -
> > - entry->flags &=
> > - ~(__EXEC_OBJECT_RESERVED | __EXEC_OBJECT_HAS_REF);
> 
> No need to clear these from eb->flags[i] to ensure no double free?

No, the other path that may drop the vma prevents the double-free by
setting count to 0. Along the error path we don't have the vma set for
incomplete loads.

> > @@ -1830,33 +1824,34 @@ static int eb_move_to_gpu(struct i915_execbuffer 
> > *eb)
> >   return -ENOMEM;
> >   
> >   capture->next = eb->request->capture_list;
> > - capture->vma = vma;
> > + capture->vma = eb->vma[i];
> >   eb->request->capture_list = capture;
> >   }
> >   
> > - if (entry->flags & EXEC_OBJECT_ASYNC)
> > - goto skip_flushes;
> > + if (flags & EXEC_OBJECT_ASYNC)
> > + continue;
> >   
> > + obj = eb->vma[i]->obj;
> >   if (unlikely(obj->cache_dirty && !obj->cache_coherent))
> >   i915_gem_clflush_object(obj, 0);
> >   
> >   err = i915_gem_request_await_object
> > - (eb->request, obj, entry->flags & EXEC_OBJECT_WRITE);
> > + (eb->request, obj, flags & EXEC_OBJECT_WRITE);
> >   if (err)
> >   return err;
> > -
> > -skip_flushes:
> > - i915_vma_move_to_active(vma, eb->request, entry->flags);
> > - __eb_unreserve_vma(vma, entry);
> > - vma->exec_entry = NULL;
> 
> Grumble, it would have been better if this change was in a separate patch.

Grumble. It was more meaningful at some earlier version of the patch
where there was a dance here with flags.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [RFC] drm/i915/skl+: enable PF_ID interlace mode in SKL

[Mahesh Kumar]

Hi Ville,

Thanks for review


On Friday 16 June 2017 07:47 PM, Ville Syrjälä wrote:

On Wed, Jun 07, 2017 at 03:19:05PM +0530, Mahesh Kumar wrote:

In previous GEN default Interlace mode enabled is IF-ID mode, but IF-ID
mode has many limitations in SKL. This mode doesn't support y-tiling,
90-270 rotation is not supported & YUV-420 planar source pixel formats
are not supported with above mode.

I think we'll want something much more simple for stable. And that
should probably be just -EINVAL if we try to do any of those
forbidden things with an interlaced mode.

Agree.



This patch make changes to use PF-ID Interlace mode in SKL+ platforms.
PF-ID mode require one scaler to be attached in pipe-scaling mode.
   During WM calculation adjusted pixel rate need to be doubled.
   During max_supported_pixel_format calculation vertical downscale is 2.0.

Signed-off-by: Mahesh Kumar 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90238
---
  drivers/gpu/drm/i915/intel_atomic.c  | 13 ++
  drivers/gpu/drm/i915/intel_display.c | 47 +++-
  drivers/gpu/drm/i915/intel_drv.h | 10 
  drivers/gpu/drm/i915/intel_panel.c   |  9 +--
  drivers/gpu/drm/i915/intel_pm.c  | 17 -
  5 files changed, 87 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index d791b3ef89b5..06ed2fc449d7 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -248,6 +248,13 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
return -EINVAL;
}
  
+	if (num_scalers_need > 1 &&

+   scaler_state->scaler_users & (1 << SKL_CRTC_INDEX) &&
+   scaler_state->scaler_users & (1 << SKL_PF_ID_INDEX)) {
+   DRM_ERROR("Can't attach scaler to CRTC in Interlace Mode\n");
+   return -EINVAL;
+   }

I thought the whole point of PF-ID here was that we can then do pipe
scaling (and other things). So this check looks wrong to me.
With PF-ID we can have Y-tiled buffers, & 90/270 rotation enabled, It 
doesn't explicitly talk about scaling.
BSpec doesn't limit us from using 2 scalers as a pipe scaler, still I 
sent a query to HW team regarding same.
Current S/W framework doesn't allows us to attach multiple pipe-scalers 
in a pipe (multiple scaler_id associated with one crtc_state). that's 
the reason for above check.


And I'm thinking we shouldn't be adding yet another scaler user for
this, and instead it should just be part of the normal pfit setup.
To use existing scaler framework, we need one scaler-user to be 
associated with it.
If we use existing CRTC_INDEX user then there will be many corner cases 
to handle. To make it simple I added new scaler-user.

This code uses pfit setup only  to attach/enable Pipe-scaler.
Please let me know if I didn't understood your concern correctly.
Any other suggestions/queries are welcome.

-Mahesh




+
/* walkthrough scaler_users bits and start assigning scalers */
for (i = 0; i < sizeof(scaler_state->scaler_users) * 8; i++) {
int *scaler_id;
@@ -264,6 +271,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
*dev_priv,
  
  			/* panel fitter case: assign as a crtc scaler */

scaler_id = &scaler_state->scaler_id;
+   } else if (i == SKL_PF_ID_INDEX) {
+   name = "PF-ID INTERLACE MODE";
+   idx = intel_crtc->base.base.id;
+
+   /* PF-ID interlaced mode case: needs a pipe scaler */
+   scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
  
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 85ac32549e85..15c79b46d645 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
  
+	if ((crtc_state->base.adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)

+   && scaler_user == SKL_PF_ID_INDEX)
+   /* PF-ID Interlace mode needs a scaler */
+   need_scaling = true;
+
/*
 * if plane is being disabled or scaler is no more required or force 
detach
 *  - free scaler binded to this plane/crtc
@@ -4635,16 +4640,24 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 * scaler can be assigned to other user. Actual register
 * update to free the scaler is done in plane/panel-fit programming.
 * For this purpose crtc/plane_state->scaler_id isn't reset here.
+* Now Interlace mode is a new user of pipe-scaler, so free the 
scaler-id
+* only if call is for respective user. If no user for scaler fre

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert execbuf to use struct-of-array packing for critical fields

[Tvrtko Ursulin]

On 16/06/2017 17:02, Chris Wilson wrote:

When userspace is doing most of the work, avoiding relocs (using
NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we
still spend a lot of time processing the arrays in execbuf, even though
we now should have nothing to do most of the time. One issue that
becomes readily apparent in profiling anv is that iterating over the
large execobj[] is unfriendly to the loop prefetchers of the CPU and it
much prefers iterating over a pair of arrays rather than one big array.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_evict.c  |   4 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 187 +++--
  drivers/gpu/drm/i915/i915_vma.h|   2 +-
  3 files changed, 97 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index a193f1b36c67..4df039ef2ce3 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -318,8 +318,8 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
/* Overlap of objects in the same batch? */
if (i915_vma_is_pinned(vma)) {
ret = -ENOSPC;
-   if (vma->exec_entry &&
-   vma->exec_entry->flags & EXEC_OBJECT_PINNED)
+   if (vma->exec_flags &&
+   *vma->exec_flags & EXEC_OBJECT_PINNED)
ret = -EINVAL;
break;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index eb46dfa374a7..9da0d209dd38 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -191,6 +191,8 @@ struct i915_execbuffer {
struct drm_file *file; /** per-file lookup tables and limits */
struct drm_i915_gem_execbuffer2 *args; /** ioctl parameters */
struct drm_i915_gem_exec_object2 *exec; /** ioctl execobj[] */
+   struct i915_vma **vma;
+   unsigned int *flags;
  
  	struct intel_engine_cs *engine; /** engine to queue the request to */

struct i915_gem_context *ctx; /** context for building the request */
@@ -245,14 +247,6 @@ struct i915_execbuffer {
  };
  
  /*

- * As an alternative to creating a hashtable of handle-to-vma for a batch,
- * we used the last available reserved field in the execobject[] and stash
- * a link from the execobj to its vma.
- */
-#define __exec_to_vma(ee) (ee)->rsvd2
-#define exec_to_vma(ee) u64_to_ptr(struct i915_vma, __exec_to_vma(ee))
-
-/*
   * Used to convert any address to canonical form.
   * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
   * MI_LOAD_REGISTER_MEM and others, see Broadwell PRM Vol2a) require the
@@ -315,7 +309,7 @@ static bool
  eb_vma_misplaced(const struct drm_i915_gem_exec_object2 *entry,
 const struct i915_vma *vma)
  {
-   if (!(entry->flags & __EXEC_OBJECT_HAS_PIN))
+   if (!(*vma->exec_flags & __EXEC_OBJECT_HAS_PIN))
return true;
  
  	if (vma->node.size < entry->pad_to_size)

@@ -341,7 +335,7 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2 
*entry,
  
  static inline void

  eb_pin_vma(struct i915_execbuffer *eb,
-  struct drm_i915_gem_exec_object2 *entry,
+  const struct drm_i915_gem_exec_object2 *entry,
   struct i915_vma *vma)
  {
u64 flags;
@@ -365,33 +359,30 @@ eb_pin_vma(struct i915_execbuffer *eb,
}
  
  		if (i915_vma_pin_fence(vma))

-   entry->flags |= __EXEC_OBJECT_HAS_FENCE;
+   *vma->exec_flags |= __EXEC_OBJECT_HAS_FENCE;
}
  
-	entry->flags |= __EXEC_OBJECT_HAS_PIN;

+   *vma->exec_flags |= __EXEC_OBJECT_HAS_PIN;
  }
  
-static inline void

-__eb_unreserve_vma(struct i915_vma *vma,
-  const struct drm_i915_gem_exec_object2 *entry)
+static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
  {
-   GEM_BUG_ON(!(entry->flags & __EXEC_OBJECT_HAS_PIN));
+   GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
  
-	if (unlikely(entry->flags & __EXEC_OBJECT_HAS_FENCE))

+   if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
i915_vma_unpin_fence(vma);
  
  	__i915_vma_unpin(vma);

  }
  
  static inline void

-eb_unreserve_vma(struct i915_vma *vma,
-struct drm_i915_gem_exec_object2 *entry)
+eb_unreserve_vma(struct i915_vma *vma, unsigned int *flags)
  {
-   if (!(entry->flags & __EXEC_OBJECT_HAS_PIN))
+   if (!(*flags & __EXEC_OBJECT_HAS_PIN))
return;
  
-	__eb_unreserve_vma(vma, entry);

-   entry->flags &= ~__EXEC_OBJECT_RESERVED;
+   __eb_unreserve_vma(vma, *flags);
+   *flags &= ~__EXEC_OBJECT_RESERVED;
  }
  
  static int

@@ -421,7 +412,7 @@ eb_validate_vma(struct i915_execbuffer *eb,
entry->pad_to_siz

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Remove WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC

[Ville Syrjälä]

On Fri, Jun 16, 2017 at 04:43:41PM -0700, Rodrigo Vivi wrote:
> When reviewing commit 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake 
> workarounds.")
> Mika pointed out that Spec tells those 2 workarounds were not needed.
> 
> So when double checking I confirmed that and also that by Spec they don't 
> apply
> to Kabylake as well.
> 
> Cc: Mika Kuoppala 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index a4487c5..2c29bab 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -831,8 +831,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *engine)
> FLOW_CONTROL_ENABLE |
> PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
>  
> - /* Syncing dependencies between camera and graphics:skl,bxt,kbl */
> - if (!IS_COFFEELAKE(dev_priv))
> + /* Syncing dependencies between camera and graphics:skl,bxt */
> + if (!IS_COFFEELAKE(dev_priv) && !IS_KABYLAKE(dev_priv))
>   WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
> GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
>  
> @@ -894,8 +894,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *engine)
>   WA_SET_BIT_MASKED(HDC_CHICKEN0,
> HDC_FORCE_NON_COHERENT);
>  
> - /* WaDisableHDCInvalidation:skl,bxt,kbl */
> - if (!IS_COFFEELAKE(dev_priv))
> + /* WaDisableHDCInvalidation:skl,bxt */
> + if (!IS_COFFEELAKE(dev_priv) && !IS_KABYLAKE(dev_priv))
>   I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
>  BDW_DISABLE_HDC_INVALIDATION);

IMO you should just move these to the skl/bxt/glk code.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Simplify intel_engines_init (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Simplify intel_engines_init (rev2)
URL   : https://patchwork.freedesktop.org/series/25907/
State : success

== Summary ==

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

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-snb-2600) fdo#100215
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101154 +19

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:470s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:487s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:571s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:548s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-glk-2atotal:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:587s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:430s
fi-hsw-4770r total:278  pass:261  dwarn:0   dfail:0   fail:0   skip:16  
time:421s
fi-ilk-650   total:278  pass:227  dwarn:0   dfail:0   fail:0   skip:50  
time:458s
fi-ivb-3520m total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:490s
fi-ivb-3770  total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:18  
time:521s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:571s
fi-kbl-r total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18  
time:575s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:483s
fi-skl-6700hqtotal:278  pass:224  dwarn:5   dfail:16  fail:11  skip:22  
time:470s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:514s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:499s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:509s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:28  
time:621s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:1   skip:29  
time:400s

508325c380d12aaccd410adc935e24f70acf69a8 drm-tip: 2017y-06m-19d-09h-05m-32s UTC 
integration manifest
b655f01 drm/i915: Do not re-calculate num_rings locally
4bbc96e drm/i915: Simplify intel_engines_init

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4981/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/2] drm/i915: Do not re-calculate num_rings locally

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Since bb8f0f5abdd7 ("drm/i915: Split intel_engine allocation
and initialisation") intel_info->num_rings is set early in the
load sequence and so available to be used direclty in the 2nd
load phase.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index acd1da9b62a3..5224b7abb8a3 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2140,7 +2140,7 @@ static void intel_ring_default_vfuncs(struct 
drm_i915_private *dev_priv,
 
engine->emit_breadcrumb = gen6_sema_emit_breadcrumb;
 
-   num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1;
+   num_rings = INTEL_INFO(dev_priv)->num_rings - 1;
if (INTEL_GEN(dev_priv) >= 8) {
engine->emit_breadcrumb_sz += num_rings * 6;
} else {
@@ -2184,8 +2184,7 @@ int intel_init_render_ring_buffer(struct intel_engine_cs 
*engine)
 
engine->semaphore.signal = gen8_rcs_signal;
 
-   num_rings =
-   hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1;
+   num_rings = INTEL_INFO(dev_priv)->num_rings - 1;
engine->emit_breadcrumb_sz += num_rings * 8;
}
} else if (INTEL_GEN(dev_priv) >= 6) {
-- 
2.9.4

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

Re: [Intel-gfx] [PATCH 5/7] drm/i915: add _PICK macro for the "a + index * (b - a)" macros

[Chauhan, Madhav]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani Nikula
> Sent: Friday, June 16, 2017 1:56 AM
> To: Zanoni, Paulo R ; intel-
> g...@lists.freedesktop.org
> Cc: Zanoni, Paulo R 
> Subject: Re: [Intel-gfx] [PATCH 5/7] drm/i915: add _PICK macro for the "a +
> index * (b - a)" macros
> 
> On Tue, 13 Jun 2017, Paulo Zanoni  wrote:
> > Instead of duplicating the macro everywhere, add a single definition
> > for it and call it just like we do with the _PICK3 macros.
> >
> > Signed-off-by: Paulo Zanoni 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index d271098..3e46ba1 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -48,25 +48,26 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
> reg)
> > return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG);  }
> >
> > +#define _PICK(__index, a, b) ((a) + (__index) * ((b) - (a)))
> 
> The change overall is good but I'd name this in a way that emphasizes the
> registers are evenly spaced. _LINEAR?

Also as we discussed, will publish the changes for handling scenario
when a>b. Currently it will work only when b>a.

Regards,
Madhav

> 
> BR,
> Jani.
> 
> >  #define _PICK3(__index, ...) (((const u32 []){ __VA_ARGS__
> > })[__index])
> >
> > -#define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
> > +#define _PIPE(pipe, a, b) _PICK(pipe, a, b)
> >  #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b))  #define
> > _MMIO_PIPE3(pipe, ...) _MMIO(_PICK3(pipe, __VA_ARGS__))
> >
> > -#define _PLANE(plane, a, b) _PIPE(plane, a, b) -#define
> > _MMIO_PLANE(plane, a, b) _MMIO_PIPE(plane, a, b)
> > +#define _PLANE(plane, a, b) _PICK(plane, a, b) #define
> > +_MMIO_PLANE(plane, a, b) _MMIO(_PLANE(plane, a, b))
> >
> > -#define _TRANS(tran, a, b) ((a) + (tran)*((b)-(a)))
> > +#define _TRANS(tran, a, b) _PICK(tran, a, b)
> >  #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b))
> >
> > -#define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
> > +#define _PORT(port, a, b) _PICK(port, a, b)
> >  #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b))  #define
> > _MMIO_PORT3(port, ...) _MMIO(_PICK3(port, __VA_ARGS__))
> >  #define _MMIO_PORT3_LN(port, ln, a0, a1, b, c, d, e, f)
>   \
> > _MMIO(_PICK3(port, a0, b, c, d, e, f) + (ln * (a1 - a0)))
> >
> > -#define _PLL(pll, a, b) ((a) + (pll)*((b)-(a)))
> > +#define _PLL(pll, a, b) _PICK(pll, a, b)
> >  #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b))
> >
> >  #define _PHY3(phy, ...) _PICK3(phy, __VA_ARGS__) @@ -6415,7 +6416,7
> > @@ enum {
> >  #define _PS_ECC_STAT_2B 0x68AD0
> >  #define _PS_ECC_STAT_1C 0x691D0
> >
> > -#define _ID(id, a, b) ((a) + (id)*((b)-(a)))
> > +#define _ID(id, a, b) _PICK(id, a, b)
> >  #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
> > _ID(id, _PS_1A_CTRL, _PS_2A_CTRL),   \
> > _ID(id, _PS_1B_CTRL, _PS_2B_CTRL))
> 
> --
> 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

[Intel-gfx] [PATCH i-g-t v3] tests/chamelium: Add common suspend and hibernate tests for DP and HDMI

[Paul Kocialkowski]

This adds two new tests: common-hpd-after-suspend and
common-hpd-after-hibernate that are aimed at testing HPD change during
suspend/hibernate for both DP and HDMI, at the same time.

The interest in bringing this test up is to reduce the time spent in
testing, with the downside of less precision regarding the test's
outcome. The per-connector tests are still available to get a more
precise idea of which connector causes a failure, when that happens.

VGA is explicitly excluded from this test as there is currently no
way of doing delayed hpd pulses for it.

The generic hpd suspend/resume test code is split in a dedicated
function, that allow testing one or all possible ports.

Signed-off-by: Paul Kocialkowski 
---
 tests/chamelium.c | 118 +-
 1 file changed, 100 insertions(+), 18 deletions(-)

diff --git a/tests/chamelium.c b/tests/chamelium.c
index 76b14e95..3cf9f3b5 100644
--- a/tests/chamelium.c
+++ b/tests/chamelium.c
@@ -143,8 +143,18 @@ wait_for_connector(data_t *data, struct chamelium_port 
*port,
 static void
 reset_state(data_t *data, struct chamelium_port *port)
 {
+   int p;
+
chamelium_reset(data->chamelium);
-   wait_for_connector(data, port, DRM_MODE_DISCONNECTED);
+
+   if (port) {
+   wait_for_connector(data, port, DRM_MODE_DISCONNECTED);
+   } else {
+   for (p = 0; p < data->port_count; p++) {
+   port = data->ports[p];
+   wait_for_connector(data, port, DRM_MODE_DISCONNECTED);
+   }
+   }
 }
 
 static void
@@ -206,36 +216,96 @@ test_edid_read(data_t *data, struct chamelium_port *port,
 }
 
 static void
-test_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
-   enum igt_suspend_state state,
-   enum igt_suspend_test test)
+try_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
+  enum igt_suspend_state state, enum igt_suspend_test test,
+  struct udev_monitor *mon, bool connected)
 {
-   struct udev_monitor *mon = igt_watch_hotplug();
-
-   reset_state(data, port);
+   int p;
 
igt_set_autoresume_delay(SUSPEND_RESUME_DELAY);
igt_flush_hotplugs(mon);
 
-   /* Make sure we notice new connectors after resuming */
-   chamelium_async_hpd_pulse_start(data->chamelium, port, false,
-   SUSPEND_RESUME_DELAY / 2);
+   if (port) {
+   chamelium_async_hpd_pulse_start(data->chamelium, port,
+   connected,
+   SUSPEND_RESUME_DELAY / 2);
+   } else {
+   for (p = 0; p < data->port_count; p++) {
+   port = data->ports[p];
+   if (chamelium_port_get_type(port) == 
DRM_MODE_CONNECTOR_VGA)
+   continue;
+
+   chamelium_async_hpd_pulse_start(data->chamelium, port,
+   connected,
+   SUSPEND_RESUME_DELAY / 
2);
+   }
+
+   port = NULL;
+   }
+
igt_system_suspend_autoresume(state, test);
chamelium_async_hpd_pulse_finish(data->chamelium);
 
igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
-   igt_assert_eq(reprobe_connector(data, port), DRM_MODE_CONNECTED);
+   if (port) {
+   igt_assert_eq(reprobe_connector(data, port), connected ?
+ DRM_MODE_DISCONNECTED : DRM_MODE_CONNECTED);
+   } else {
+   for (p = 0; p < data->port_count; p++) {
+   port = data->ports[p];
+   if (chamelium_port_get_type(port) == 
DRM_MODE_CONNECTOR_VGA)
+   continue;
+
+   igt_assert_eq(reprobe_connector(data, port), connected ?
+ DRM_MODE_DISCONNECTED :
+ DRM_MODE_CONNECTED);
+   }
 
-   igt_flush_hotplugs(mon);
+   port = NULL;
+   }
+}
+
+static void
+test_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
+   enum igt_suspend_state state,
+   enum igt_suspend_test test)
+{
+   struct udev_monitor *mon = igt_watch_hotplug();
+
+   reset_state(data, port);
+
+   /* Make sure we notice new connectors after resuming */
+   try_suspend_resume_hpd(data, port, state, test, mon, false);
 
/* Now make sure we notice disconnected connectors after resuming */
-   chamelium_async_hpd_pulse_start(data->chamelium, port, true,
-   SUSPEND_RESUME_DELAY / 2);
-   igt_system_suspend_autoresume(state, test);
-   chamelium_async_hpd_pulse_finish(data->chamelium);
+   try_suspend_resume_h

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix RMW on ddi vswing sequence.

[Jani Nikula]

On Fri, 16 Jun 2017, Rodrigo Vivi  wrote:
> Paulo noticed that we were missing few bits clear
> before writing values back to the register on
> these RMW MMIO operations.
>
> v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
>
> Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
> Cc: Paulo Zanoni 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 9 +
>  drivers/gpu/drm/i915/intel_ddi.c | 7 +++
>  2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index bd535f1..c8647cf 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1764,8 +1764,11 @@ enum skl_disp_power_wells {
>   _CNL_PORT_TX_DW2_LN0_AE, \
>   _CNL_PORT_TX_DW2_LN0_F)
>  #define   SWING_SEL_UPPER(x) ((x >> 3) << 15)
> +#define   SWING_SEL_UPPER_MASK   (1 << 15)
>  #define   SWING_SEL_LOWER(x) ((x & 0x7) << 11)
> +#define   SWING_SEL_LOWER_MASK   (0x7 << 11)
>  #define   RCOMP_SCALAR(x)((x) << 0)
> +#define   RCOMP_SCALAR_MASK  (0xFF << 0)
>  
>  #define _CNL_PORT_TX_DW4_GRP_AE  0x162350
>  #define _CNL_PORT_TX_DW4_GRP_B   0x1623D0
> @@ -1795,8 +1798,11 @@ enum skl_disp_power_wells {
>   _CNL_PORT_TX_DW4_LN0_F)
>  #define   LOADGEN_SELECT (1 << 31)
>  #define   POST_CURSOR_1(x)   ((x) << 12)
> +#define   POST_CURSOR_1_MASK (0x3F << 12)
>  #define   POST_CURSOR_2(x)   ((x) << 6)
> +#define   POST_CURSOR_2_MASK (0x3F << 6)
>  #define   CURSOR_COEFF(x)((x) << 0)
> +#define   CURSOR_COEFF_MASK  (0x3F << 6)
>  
>  #define _CNL_PORT_TX_DW5_GRP_AE  0x162354
>  #define _CNL_PORT_TX_DW5_GRP_B   0x1623D4
> @@ -1825,7 +1831,9 @@ enum skl_disp_power_wells {
>  #define   TX_TRAINING_EN (1 << 31)
>  #define   TAP3_DISABLE   (1 << 29)
>  #define   SCALING_MODE_SEL(x)((x) << 18)
> +#define   SCALING_MODE_SEL_MASK  (0x7 << 18)
>  #define   RTERM_SELECT(x)((x) << 3)
> +#define   RTERM_SELECT_MASK  (0x7 << 3)
>  
>  #define _CNL_PORT_TX_DW7_GRP_AE  0x16235C
>  #define _CNL_PORT_TX_DW7_GRP_B   0x1623DC
> @@ -1852,6 +1860,7 @@ enum skl_disp_power_wells {
>   _CNL_PORT_TX_DW7_LN0_AE, \
>   _CNL_PORT_TX_DW7_LN0_F)
>  #define   N_SCALAR(x)((x) << 24)
> +#define   N_SCALAR_MASK  (0x7F << 24)
>  
>  /* The spec defines this only for BXT PHY0, but lets assume that this
>   * would exist for PHY1 too if it had a second channel.
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index db80938..b4371e6 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1813,11 +1813,14 @@ static void cnl_ddi_vswing_program(struct 
> drm_i915_private *dev_priv,
>  
>   /* Set PORT_TX_DW5 Scaling Mode Sel to 010b. */
>   val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
> + val &= ~(SCALING_MODE_SEL_MASK);

Unnecessary braces.

>   val |= SCALING_MODE_SEL(2);
>   I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
>  
>   /* Program PORT_TX_DW2 */
>   val = I915_READ(CNL_PORT_TX_DW2_LN0(port));
> + val &= ~(SWING_SEL_LOWER_MASK | SWING_SEL_UPPER_MASK |
> +  RCOMP_SCALAR_MASK);
>   val |= SWING_SEL_UPPER(ddi_translations[level].dw2_swing_sel);
>   val |= SWING_SEL_LOWER(ddi_translations[level].dw2_swing_sel);
>   /* Rcomp scalar is fixed as 0x98 for every table entry */
> @@ -1828,6 +1831,8 @@ static void cnl_ddi_vswing_program(struct 
> drm_i915_private *dev_priv,
>   /* We cannot write to GRP. It would overrite individual loadgen */
>   for (ln = 0; ln < 4; ln++) {
>   val = I915_READ(CNL_PORT_TX_DW4_LN(port, ln));
> + val &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
> +  CURSOR_COEFF_MASK);
>   val |= POST_CURSOR_1(ddi_translations[level].dw4_post_cursor_1);
>   val |= POST_CURSOR_2(ddi_translations[level].dw4_post_cursor_2);
>   val |= CURSOR_COEFF(ddi_translations[level].dw4_cursor_coeff);
> @@ -1837,12 +1842,14 @@ static void cnl_ddi_vswing_program(struct 
> drm_i915_private *dev_priv,
>  /* Program PORT_TX_DW5 */
>   /* All DW5 values are fixed for every table entry */
>   val = I915_READ(CNL_PORT_TX_DW5_LN0(port));
> + val &= ~(RTERM_SELECT_MASK);

Unnecessary braces.

>   val |= RTERM_SELECT(6);
>   val |= TAP3_DISABLE;
>   I915_WRITE(CNL_PORT_TX_DW5_GRP(p

Re: [Intel-gfx] [PATCH i-g-t v2] tests/chamelium: Add common suspend and hibernate tests for DP and HDMI

[Paul Kocialkowski]

Hi,

On Fri, 2017-06-16 at 19:28 -0400, Lyude Paul wrote:
> On Fri, 2017-06-16 at 17:17 +0300, Paul Kocialkowski wrote:
> > This adds two new tests: common-hpd-after-suspend and
> > common-hpd-after-hibernate that are aimed at testing HPD change during
> > suspend/hibernate for both DP and HDMI, at the same time.
> > 
> > The interest in bringing this test up is to reduce the time spent in
> > testing, with the downside of less precision regarding the test's
> > outcome. The per-connector tests are still available to get a more
> > precise idea of which connector causes a failure, when that happens.
> > 
> > VGA is explicitly excluded from this test as there is currently no
> > way of doing delayed hpd pulses for it.
> > 
> > > Signed-off-by: Paul Kocialkowski 
> > 
> > ---
> >  tests/chamelium.c | 86
> > +++
> >  1 file changed, 86 insertions(+)
> > 
> > diff --git a/tests/chamelium.c b/tests/chamelium.c
> > index 76b14e95..d569c8ee 100644
> > --- a/tests/chamelium.c
> > +++ b/tests/chamelium.c
> > @@ -241,6 +241,80 @@ test_suspend_resume_hpd(data_t *data, struct
> > chamelium_port *port,
> >  }
> >  
> >  static void
> > +test_suspend_resume_hpd_common(data_t *data, enum igt_suspend_state state,
> > +  enum igt_suspend_test test)
> > +{
> > +   struct udev_monitor *mon = igt_watch_hotplug();
> > +   struct chamelium_port *port;
> > +   int p;
> > +
> > +   for (p = 0; p < data->port_count; p++) {
> > +   port = data->ports[p];
> > +   if (chamelium_port_get_type(port) ==
> > DRM_MODE_CONNECTOR_VGA)
> > +   continue;
> > +
> > +   reset_state(data, port);
> > +
> > +   igt_debug("Testing port %s\n",
> > chamelium_port_get_name(port));
> > +   }
> > +
> > +   igt_set_autoresume_delay(SUSPEND_RESUME_DELAY);
> > +   igt_flush_hotplugs(mon);
> > +
> > +   /* Make sure we notice new connectors after resuming */
> > +   for (p = 0; p < data->port_count; p++) {
> > +   port = data->ports[p];
> > +   if (chamelium_port_get_type(port) ==
> > DRM_MODE_CONNECTOR_VGA)
> > +   continue;
> > +
> > +   chamelium_async_hpd_pulse_start(data->chamelium, port,
> > false,
> > +   SUSPEND_RESUME_DELAY / 2);
> > +   }
> > +
> > +   igt_system_suspend_autoresume(state, test);
> > +   chamelium_async_hpd_pulse_finish(data->chamelium);
> > +
> > +   igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
> > +
> > +   for (p = 0; p < data->port_count; p++) {
> > +   port = data->ports[p];
> > +   if (chamelium_port_get_type(port) ==
> > DRM_MODE_CONNECTOR_VGA)
> > +   continue;
> > +
> > +   igt_assert_eq(reprobe_connector(data, port),
> > + DRM_MODE_CONNECTED);
> > +   }
> > +
> > +   igt_flush_hotplugs(mon);
> > +
> > +   /* Now make sure we notice disconnected connectors after resuming
> > */
> > +   for (p = 0; p < data->port_count; p++) {
> > +   port = data->ports[p];
> > +   if (chamelium_port_get_type(port) ==
> > DRM_MODE_CONNECTOR_VGA)
> > +   continue;
> > +
> > +   chamelium_async_hpd_pulse_start(data->chamelium, port,
> > true,
> > +   SUSPEND_RESUME_DELAY / 2);
> > +   }
> > +
> > +   igt_system_suspend_autoresume(state, test);
> > +   chamelium_async_hpd_pulse_finish(data->chamelium);
> > +
> > +   igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
> > +
> > +   for (p = 0; p < data->port_count; p++) {
> > +   port = data->ports[p];
> > +   if (chamelium_port_get_type(port) ==
> > DRM_MODE_CONNECTOR_VGA)
> > +   continue;
> > +
> > +   igt_assert_eq(reprobe_connector(data, port),
> > + DRM_MODE_DISCONNECTED);
> > +   }
> > +
> > +   igt_cleanup_hotplug(mon);
> > +}
> > +
> > +static void
> 
> For smaller bits of code this isn't a big deal since we're talking
> about tests here, but this is a lot of code to have for a single
> function like this. Mind splitting this into something like (feel free
> to take some liberty with the function naming)

That is quite right, this is indeed starting to look too big. Thanks for
pointing it out. I'll send v2 with a dedicated function as suggested.

> test_suspend_resume_hpd(data_t *data, enum igt_suspend_state state, enum
> igt_suspend_test test)
>   → try_suspend_resume_hpd(data_t *data, enum igt_suspend_state state, enum
> igt_suspend_test test, bool connected)
> 
> Other then that, looks good. With the changes mentioned:
> 
> Reviewed-by: Lyude Paul 
> 
> >  test_suspend_resume_edid_change(data_t *data, struct chamelium_port *port,
> > enum igt_suspend_state state,
> > enum igt_suspend_test test,
> > @@ -750,6 +824,18 @@ igt_main
> > test_hpd_without_ddc(&data, port);
> > }
> >  
> > +  

Re: [Intel-gfx] Fixes that failed to backport to v4.12-rc1

[Jani Nikula]

On Mon, 15 May 2017, Jani Nikula  wrote:
> Continuing [1] for v4.12-rc1
>
> The following commits have been marked as Cc: stable or fixing something
> in v4.12-rc1 or earlier, but failed to cherry-pick to
> drm-intel-fixes. Please see if they are worth backporting, and please do
> so if they are.

Update:

f6262bda462e ("drm/i915: Don't enable backlight at setup time.")
e27ab73d17ef ("drm/i915: Mark CPU cache as dirty on every transition for CPU 
writes")
071750e550af ("drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations")

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

Re: [Intel-gfx] [PATCH] drm/i915: Differentiate between sw write location into ring and last hw read

[Jani Nikula]

On Thu, 15 Jun 2017, Chris Wilson  wrote:
> We need to keep track of the last location we ask the hw to read up to
> (RING_TAIL) separately from our last write location into the ring, so
> that in the event of a GPU reset we do not tell the HW to proceed into
> a partially written request (which can happen if that request is waiting
> for an external signal before being executed).
>
> v2: Refactor intel_ring_reset() (Mika)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100144
> Testcase: igt/gem_exec_fence/await-hang
> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
> Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to 
> actual hw submission")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/20170425130049.26147-1-ch...@chris-wilson.co.uk
> Reviewed-by: Mika Kuoppala 
> (cherry picked from commit e6ba9992de6c63fe86c028b4876338e1cb7dac34)

Thanks, picked up to drm-intel-fixes.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/i915_gem_request.c|  2 +-
>  drivers/gpu/drm/i915/i915_guc_submission.c |  4 +--
>  drivers/gpu/drm/i915/intel_lrc.c   |  6 ++---
>  drivers/gpu/drm/i915/intel_ringbuffer.c| 41 
> --
>  drivers/gpu/drm/i915/intel_ringbuffer.h| 19 --
>  5 files changed, 48 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 5ddbc9499775..a74d0ac737cb 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -623,7 +623,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
>* GPU processing the request, we never over-estimate the
>* position of the head.
>*/
> - req->head = req->ring->tail;
> + req->head = req->ring->emit;
>  
>   /* Check that we didn't interrupt ourselves with a new request */
>   GEM_BUG_ON(req->timeline->seqno != req->fence.seqno);
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 1642fff9cf13..ab5140ba108d 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -480,9 +480,7 @@ static void guc_wq_item_append(struct i915_guc_client 
> *client,
>   GEM_BUG_ON(freespace < wqi_size);
>  
>   /* The GuC firmware wants the tail index in QWords, not bytes */
> - tail = rq->tail;
> - assert_ring_tail_valid(rq->ring, rq->tail);
> - tail >>= 3;
> + tail = intel_ring_set_tail(rq->ring, rq->tail) >> 3;
>   GEM_BUG_ON(tail > WQ_RING_TAIL_MAX);
>  
>   /* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index c8f7c631fc1f..10c63dbd617c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -326,8 +326,7 @@ static u64 execlists_update_context(struct 
> drm_i915_gem_request *rq)
>   rq->ctx->ppgtt ?: rq->i915->mm.aliasing_ppgtt;
>   u32 *reg_state = ce->lrc_reg_state;
>  
> - assert_ring_tail_valid(rq->ring, rq->tail);
> - reg_state[CTX_RING_TAIL+1] = rq->tail;
> + reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring, rq->tail);
>  
>   /* True 32b PPGTT with dynamic page allocation: update PDP
>* registers and point the unallocated PDPs to scratch page.
> @@ -2036,8 +2035,7 @@ void intel_lr_context_resume(struct drm_i915_private 
> *dev_priv)
>   ce->state->obj->mm.dirty = true;
>   i915_gem_object_unpin_map(ce->state->obj);
>  
> - ce->ring->head = ce->ring->tail = 0;
> - intel_ring_update_space(ce->ring);
> + intel_ring_reset(ce->ring, 0);
>   }
>   }
>  }
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 66a2b8b83972..513a0f4b469b 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -49,7 +49,7 @@ static int __intel_ring_space(int head, int tail, int size)
>  
>  void intel_ring_update_space(struct intel_ring *ring)
>  {
> - ring->space = __intel_ring_space(ring->head, ring->tail, ring->size);
> + ring->space = __intel_ring_space(ring->head, ring->emit, ring->size);
>  }
>  
>  static int
> @@ -774,8 +774,8 @@ static void i9xx_submit_request(struct 
> drm_i915_gem_request *request)
>  
>   i915_gem_request_submit(request);
>  
> - assert_ring_tail_valid(request->ring, request->tail);
> - I915_WRITE_TAIL(request->engine, request->tail);
> + I915_WRITE_TAIL(request->engine,
> + intel_ring_set_tail(request->ring, request->tail));
>  }
>  
>  static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req, u32 *cs

[Intel-gfx] Updated drm-intel-testing

[Daniel Vetter]

Hi all,

Final pile of features for 4.13

New uabi:
- batch bo in first slot, for faster execbuf assembly in userspace
  (Chris Wilson)
- (sub)slice getparam, needed for mesa perf support (Robert Bragg)

First pile of patches for cnl/cfl support, maintained by Rodrigo but
with lots of contributions from others. Still incomplete since public
review still ongoing.

Features/refactoring:
- Make execbuf faster (Chris Wilson), a pile of series to make execbuf
  buffer handling have fewer passes, use less list walking, postpone
  more work to async workers and shuffle buffers less, all to make the
  common case much faster (in some cases at least).
- cold boot support for glk dsi (Madhav Chauhan)
- Clean up pipe A quirk and related old platform hacks (Ville)
- perf sampling support for kbl/glk (Lionel)
- perf cleanups (Robert Bragg)
- wire atomic state to backlight code, to avoid pipe lookup hacks
  (Maarten)
- reduce request waiting latency/overhead to remove the spinning and
  associated cpu cycle wasting (Chris)
- fix 90/270 rotation wm computation (Ville)
- new ddb allocation algo for skl (Kumar Mahesh)
- fix regression due to system suspend optimiazatino (Imre)
- the usual pile of small cleanups and refactors all over

GVT updates contained in this tag:
- optimization for per-VM mmio save/restore (Changbin)
- optimization for mmio hash table (Changbin)
- scheduler optimization with event (Ping)
- vGPU reset refinement (Fred)
- other misc refactor and cleanups, etc.

Happy testing!

Cheers, Daniel

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

Re: [Intel-gfx] [PATCH] drm/i915: Actually attach the tv_format property to the SDVO connector

[Maarten Lankhorst]

Op 15-06-17 om 19:23 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> Attach the tv_format property to the SDVO connector instead of passing
> a '0' in place of the pointer to the property. This got broken when
> the SDVO connector properties were converted to atomic.
>
> We can thank sparse for catching this:
> drivers/gpu/drm/i915/intel_sdvo.c:2742:75: warning: Using plain integer as 
> NULL pointer
>
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Fixes: 630d30a4ee27 ("drm/i915: Convert intel_sdvo connector properties to 
> atomic.")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index f4329d20b6f6..3f8f30b412cd 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -2739,7 +2739,8 @@ static bool intel_sdvo_tv_create_property(struct 
> intel_sdvo *intel_sdvo,
>   i, 
> tv_format_names[intel_sdvo_connector->tv_format_supported[i]]);
>  
>   intel_sdvo_connector->base.base.state->tv.mode = 
> intel_sdvo_connector->tv_format_supported[0];
> - drm_object_attach_property(&intel_sdvo_connector->base.base.base, 0, 0);
> + drm_object_attach_property(&intel_sdvo_connector->base.base.base,
> +intel_sdvo_connector->tv_format, 0);
>   return true;
>  
>  }

Reviewed-by: Maarten Lankhorst 

Thanks for catching!

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