[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/dmc: Make no_stepping_info an array

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

Series: series starting with [1/2] drm/i915/dmc: Make no_stepping_info an array
URL   : https://patchwork.freedesktop.org/series/13818/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-skl-6700k)
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2731/

38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
2016y-10m-14d-16h-23m-48s UTC integration manifest
6c7e89b drm/i915/DMC/KBL: Load DMC on KBL using he no_stepping_info array
a43c6e5 drm/i915/dmc: Make no_stepping_info an array

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/1] drm/i915/guc: Sanitory checks for platform that dont have GuC

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

Series: series starting with [1/1] drm/i915/guc: Sanitory checks for platform 
that dont have GuC
URL   : https://patchwork.freedesktop.org/series/13815/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700k)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2730/

38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
2016y-10m-14d-16h-23m-48s UTC integration manifest
1392686 drm/i915/guc: Sanitory checks for platform that dont have GuC

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


[Intel-gfx] [PATCH 2/2] drm/i915/DMC/KBL: Load DMC on KBL using he no_stepping_info array

2016-10-14 Thread Anusha Srivatsa
Currently, for display there is only one DMC image for KBL.
Remove the stepping_info table for KBL and use the no_stepping_info
for loading the firmware image.

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_csr.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index cf57167..e0e348b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -168,12 +168,6 @@ struct stepping_info {
char substepping;
 };
 
-static const struct stepping_info kbl_stepping_info[] = {
-   {'A', '0'}, {'B', '0'}, {'C', '0'},
-   {'D', '0'}, {'E', '0'}, {'F', '0'},
-   {'G', '0'}, {'H', '0'}, {'I', '0'},
-};
-
 static const struct stepping_info skl_stepping_info[] = {
{'A', '0'}, {'B', '0'}, {'C', '0'},
{'D', '0'}, {'E', '0'}, {'F', '0'},
@@ -197,8 +191,8 @@ intel_get_stepping_info(struct drm_i915_private *dev_priv)
unsigned int size;
 
if (IS_KABYLAKE(dev_priv)) {
-   size = ARRAY_SIZE(kbl_stepping_info);
-   si = kbl_stepping_info;
+   size = ARRAY_SIZE(no_stepping_info);
+   si = no_stepping_info;
} else if (IS_SKYLAKE(dev_priv)) {
size = ARRAY_SIZE(skl_stepping_info);
si = skl_stepping_info;
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/2] drm/i915/dmc: Make no_stepping_info an array

2016-10-14 Thread Anusha Srivatsa
Make no_stepping_info an array of structs so that
on plaforms that have only one binary of DMC, we can
iterate through this array by having the same logic
for firmware loads

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_csr.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 1ea0e1f..cf57167 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -186,7 +186,9 @@ static const struct stepping_info bxt_stepping_info[] = {
{'B', '0'}, {'B', '1'}, {'B', '2'}
 };
 
-static const struct stepping_info no_stepping_info = { '*', '*' };
+static const struct stepping_info no_stepping_info[] = {
+   { '*', '*' }
+};
 
 static const struct stepping_info *
 intel_get_stepping_info(struct drm_i915_private *dev_priv)
@@ -210,7 +212,7 @@ intel_get_stepping_info(struct drm_i915_private *dev_priv)
if (INTEL_REVID(dev_priv) < size)
return si + INTEL_REVID(dev_priv);
 
-   return _stepping_info;
+   return no_stepping_info;
 }
 
 static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/1] drm/i915/guc: Sanitory checks for platform that dont have GuC

2016-10-14 Thread Anusha Srivatsa
i915.enable_guc_loading/submission=2 forces the usage of GuC.
For platforms that do not have a GuC, asking the kernel to use a GuC
should not result in an error state. Do extra checks to see if the
platform even has a GuC or not, regardless of the kernel parameter.

v2: Based on Rodrigo's patch and Paulo's suggestion(Paulo, Rodrigo)
v3: Correct the Indentation(Jani, Paulo)
v4: Added the blank line(Jani, Paulo)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573
Cc: Rodrigo Vivi 
Cc: Zanoni Paulo 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 678b51a..94c3ad9 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -719,11 +719,17 @@ void intel_guc_init(struct drm_device *dev)
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
const char *fw_path;
 
-   /* A negative value means "use platform default" */
-   if (i915.enable_guc_loading < 0)
-   i915.enable_guc_loading = HAS_GUC_UCODE(dev);
-   if (i915.enable_guc_submission < 0)
-   i915.enable_guc_submission = HAS_GUC_SCHED(dev);
+   if (!HAS_GUC(dev)) {
+   i915.enable_guc_loading = 0;
+   i915.enable_guc_submission = 0;
+   } else {
+   /* A negative value means "use platform default" */
+   if (i915.enable_guc_loading < 0)
+   i915.enable_guc_loading = HAS_GUC_UCODE(dev);
+   if (i915.enable_guc_submission < 0)
+   i915.enable_guc_submission = HAS_GUC_SCHED(dev);
+   }
+
 
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
-- 
2.7.4

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for Start of skl watermark cleanup (rev3)

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

Series: Start of skl watermark cleanup (rev3)
URL   : https://patchwork.freedesktop.org/series/1/
State : warning

== Summary ==

Series 1v3 Start of skl watermark cleanup
https://patchwork.freedesktop.org/api/1.0/series/1/revisions/3/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-skl-6700k)
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-5557u)
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-byt-j1900 failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2729/

38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
2016y-10m-14d-16h-23m-48s UTC integration manifest
e6ec3db drm/i915/gen9: Don't wrap strings in verify_wm_state()
be9c54e drm/i915/gen9: Actually verify WM levels in verify_wm_state()
158bb87 drm/i915/gen9: Add skl_wm_level_equals()
95570fd drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable
1f4ad42 drm/i915/gen9: Add ddb changes to atomic debug output
9fd875d drm/i915/gen9: Get rid of redundant watermark values
aaf254a drm/i915/gen9: Cleanup skl_pipe_wm_active_state
6e1087f drm/i915/gen9: Make skl_wm_level per-plane
b1399ab drm/i915/skl: Remove linetime from skl_wm_values
599c303 drm/i915/skl: Move per-pipe ddb allocations into crtc states

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: unconditionally apply the memory bandwidth WA

2016-10-14 Thread Lyude
Reviewed-by: Lyude 

On Tue, 2016-10-11 at 15:25 -0300, Paulo Zanoni wrote:
> Mahesh Kumar is already working on a proper implementation for the
> workaround, but while we still don't have it, let's just
> unconditionally apply the workaround for everybody and we hope we can
> close all those numerous bugzilla tickets. Also, I'm not sure how
> easy
> it will be to backport the final implementation to the stable
> Kernels,
> and this patch here is probably easier to backport.
> 
> At the present moment I still don't have confirmation that this patch
> fixes any of the bugs listed below, but we should definitely try
> testing all of them again.
> 
> v2: s/intel_needs_memory_bw_wa/skl_needs_memory_bw_wa/ (Lyude).
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94337
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94884
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95010
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97830
> Cc: sta...@vger.kernel.org
> Cc: Mahesh Kumar 
> Cc: Lyude 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 49
> ++---
>  1 file changed, 41 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index fe6c1c6..13bd974 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2879,6 +2879,21 @@ skl_wm_plane_id(const struct intel_plane
> *plane)
>   }
>  }
>  
> +/*
> + * FIXME: We still don't have the proper code detect if we need to
> apply the WA,
> + * so assume we'll always need it in order to avoid underruns.
> + */
> +static bool skl_needs_memory_bw_wa(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state-
> >base.dev);
> +
> + if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv) ||
> + IS_KABYLAKE(dev_priv))
> + return true;
> +
> + return false;
> +}
> +
>  static bool
>  intel_has_sagv(struct drm_i915_private *dev_priv)
>  {
> @@ -2999,9 +3014,10 @@ bool intel_can_enable_sagv(struct
> drm_atomic_state *state)
>   struct drm_device *dev = state->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_atomic_state *intel_state =
> to_intel_atomic_state(state);
> - struct drm_crtc *crtc;
> + struct intel_crtc *crtc;
> + struct intel_plane *plane;
>   enum pipe pipe;
> - int level, plane;
> + int level, id, latency;
>  
>   if (!intel_has_sagv(dev_priv))
>   return false;
> @@ -3019,27 +3035,36 @@ bool intel_can_enable_sagv(struct
> drm_atomic_state *state)
>  
>   /* Since we're now guaranteed to only have one active
> CRTC... */
>   pipe = ffs(intel_state->active_crtcs) - 1;
> - crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> + crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
>  
> - if (crtc->state->mode.flags & DRM_MODE_FLAG_INTERLACE)
> + if (crtc->base.state->mode.flags & DRM_MODE_FLAG_INTERLACE)
>   return false;
>  
> - for_each_plane(dev_priv, pipe, plane) {
> + for_each_intel_plane_on_crtc(dev, crtc, plane) {
> + id = skl_wm_plane_id(plane);
> +
>   /* Skip this plane if it's not enabled */
> - if (intel_state->wm_results.plane[pipe][plane][0] ==
> 0)
> + if (intel_state->wm_results.plane[pipe][id][0] == 0)
>   continue;
>  
>   /* Find the highest enabled wm level for this plane
> */
>   for (level = ilk_wm_max_level(dev);
> -  intel_state-
> >wm_results.plane[pipe][plane][level] == 0; --level)
> +  intel_state->wm_results.plane[pipe][id][level]
> == 0; --level)
>    { }
>  
> + latency = dev_priv->wm.skl_latency[level];
> +
> + if (skl_needs_memory_bw_wa(intel_state) &&
> + plane->base.state->fb->modifier[0] ==
> + I915_FORMAT_MOD_X_TILED)
> + latency += 15;
> +
>   /*
>    * If any of the planes on this pipe don't enable wm
> levels
>    * that incur memory latencies higher then 30µs we
> can't enable
>    * the SAGV
>    */
> - if (dev_priv->wm.skl_latency[level] <
> SKL_SAGV_BLOCK_TIME)
> + if (latency < SKL_SAGV_BLOCK_TIME)
>   return false;
>   }
>  
> @@ -3555,12 +3580,18 @@ static int skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
>   uint32_t 

[Intel-gfx] [PATCH v2 07/10] drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable

2016-10-14 Thread Lyude
There's not much of a reason this should have the locations to read out
the hardware state hardcoded, so allow the caller to specify the
location and add this function to intel_drv.h. As well, we're going to
need this function to be reusable for the next patch.

Changes since v1:
- Fix accidental behavior change in the code that Paulo pointed out

Signed-off-by: Lyude 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 28 ++--
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a85ce2c..7036310 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1756,6 +1756,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
+void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
+ struct skl_pipe_wm *out);
 bool intel_can_enable_sagv(struct drm_atomic_state *state);
 int intel_enable_sagv(struct drm_i915_private *dev_priv);
 int intel_disable_sagv(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2fe851e..6eaeb87 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4288,15 +4288,13 @@ static inline void skl_wm_level_from_reg_val(uint32_t 
val,
PLANE_WM_LINES_MASK;
 }
 
-static void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc)
+void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
+ struct skl_pipe_wm *out)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct skl_wm_values *hw = _priv->wm.skl_hw;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct intel_plane *intel_plane;
-   struct skl_pipe_wm *active = >wm.skl.optimal;
struct skl_plane_wm *wm;
enum pipe pipe = intel_crtc->pipe;
int level, id, max_level;
@@ -4306,7 +4304,7 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
 
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
id = skl_wm_plane_id(intel_plane);
-   wm = >wm.skl.optimal.planes[id];
+   wm = >planes[id];
 
for (level = 0; level <= max_level; level++) {
if (id != PLANE_CURSOR)
@@ -4328,20 +4326,30 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
if (!intel_crtc->active)
return;
 
-   hw->dirty_pipes |= drm_crtc_mask(crtc);
-   active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
-   intel_crtc->wm.active.skl = *active;
+   out->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
 }
 
 void skl_wm_get_hw_state(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct skl_wm_values *hw = _priv->wm.skl_hw;
struct skl_ddb_allocation *ddb = _priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
+   struct intel_crtc *intel_crtc;
+   struct intel_crtc_state *cstate;
 
skl_ddb_get_hw_state(dev_priv, ddb);
-   list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   skl_pipe_wm_get_hw_state(crtc);
+   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
+   intel_crtc = to_intel_crtc(crtc);
+   cstate = to_intel_crtc_state(crtc->state);
+
+   skl_pipe_wm_get_hw_state(crtc, >wm.skl.optimal);
+
+   if (intel_crtc->active) {
+   hw->dirty_pipes |= drm_crtc_mask(crtc);
+   intel_crtc->wm.active.skl = cstate->wm.skl.optimal;
+   }
+   }
 
if (dev_priv->active_crtcs) {
/* Fully recompute DDB on first atomic commit */
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 03/10] drm/i915/gen9: Make skl_wm_level per-plane

2016-10-14 Thread Lyude
Having skl_wm_level contain all of the watermarks for each plane is
annoying since it prevents us from having any sort of object to
represent a single watermark level, something we take advantage of in
the next commit to cut down on all of the copy paste code in here.

Changes since v1:
- Style nitpicks
- Fix accidental usage of i vs. PLANE_CURSOR
- Split out skl_pipe_wm_active_state simplification into seperate patch

Signed-off-by: Lyude 
Reviewed-by: Paulo Zanoni 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |   6 +-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 207 +++
 3 files changed, 111 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e56d4a4..4d1133f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1653,9 +1653,9 @@ struct skl_wm_values {
 };
 
 struct skl_wm_level {
-   bool plane_en[I915_MAX_PLANES];
-   uint16_t plane_res_b[I915_MAX_PLANES];
-   uint8_t plane_res_l[I915_MAX_PLANES];
+   bool plane_en;
+   uint16_t plane_res_b;
+   uint8_t plane_res_l;
 };
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 10a0cf2..84301d3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -468,9 +468,13 @@ struct intel_pipe_wm {
bool sprites_scaled;
 };
 
-struct skl_pipe_wm {
+struct skl_plane_wm {
struct skl_wm_level wm[8];
struct skl_wm_level trans_wm;
+};
+
+struct skl_pipe_wm {
+   struct skl_plane_wm planes[I915_MAX_PLANES];
uint32_t linetime;
 };
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a7d5721..1bdccc9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3674,67 +3674,52 @@ static int
 skl_compute_wm_level(const struct drm_i915_private *dev_priv,
 struct skl_ddb_allocation *ddb,
 struct intel_crtc_state *cstate,
+struct intel_plane *intel_plane,
 int level,
 struct skl_wm_level *result)
 {
struct drm_atomic_state *state = cstate->base.state;
struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
-   struct drm_plane *plane;
-   struct intel_plane *intel_plane;
-   struct intel_plane_state *intel_pstate;
+   struct drm_plane *plane = _plane->base;
+   struct intel_plane_state *intel_pstate = NULL;
uint16_t ddb_blocks;
enum pipe pipe = intel_crtc->pipe;
int ret;
+   int i = skl_wm_plane_id(intel_plane);
+
+   if (state)
+   intel_pstate =
+   intel_atomic_get_existing_plane_state(state,
+ intel_plane);
 
/*
-* We'll only calculate watermarks for planes that are actually
-* enabled, so make sure all other planes are set as disabled.
+* Note: If we start supporting multiple pending atomic commits against
+* the same planes/CRTC's in the future, plane->state will no longer be
+* the correct pre-state to use for the calculations here and we'll
+* need to change where we get the 'unchanged' plane data from.
+*
+* For now this is fine because we only allow one queued commit against
+* a CRTC.  Even if the plane isn't modified by this transaction and we
+* don't have a plane lock, we still have the CRTC's lock, so we know
+* that no other transactions are racing with us to update it.
 */
-   memset(result, 0, sizeof(*result));
+   if (!intel_pstate)
+   intel_pstate = to_intel_plane_state(plane->state);
 
-   for_each_intel_plane_mask(_priv->drm,
- intel_plane,
- cstate->base.plane_mask) {
-   int i = skl_wm_plane_id(intel_plane);
-
-   plane = _plane->base;
-   intel_pstate = NULL;
-   if (state)
-   intel_pstate =
-   intel_atomic_get_existing_plane_state(state,
- 
intel_plane);
+   WARN_ON(!intel_pstate->base.fb);
 
-   /*
-* Note: If we start supporting multiple pending atomic commits
-* against the same planes/CRTC's in the future, plane->state
-* will no longer be the correct pre-state to use for the
-* calculations here and we'll need to change where we get the
-* 

[Intel-gfx] [PATCH v2 04/10] drm/i915/gen9: Cleanup skl_pipe_wm_active_state

2016-10-14 Thread Lyude
This function is a wreck, let's help it get its life back together and
cleanup all of the copy pasta here.

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Paulo Zanoni 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 52 +++--
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1bdccc9..2d63a37 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4271,46 +4271,22 @@ static void ilk_optimize_watermarks(struct 
intel_crtc_state *cstate)
 static void skl_pipe_wm_active_state(uint32_t val,
 struct skl_pipe_wm *active,
 bool is_transwm,
-bool is_cursor,
 int i,
 int level)
 {
+   struct skl_plane_wm *plane_wm = >planes[i];
bool is_enabled = (val & PLANE_WM_EN) != 0;
 
if (!is_transwm) {
-   if (!is_cursor) {
-   active->planes[i].wm[level].plane_en = is_enabled;
-   active->planes[i].wm[level].plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[i].wm[level].plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   } else {
-   active->planes[PLANE_CURSOR].wm[level].plane_en =
-   is_enabled;
-   active->planes[PLANE_CURSOR].wm[level].plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[PLANE_CURSOR].wm[level].plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   }
+   plane_wm->wm[level].plane_en = is_enabled;
+   plane_wm->wm[level].plane_res_b = val & PLANE_WM_BLOCKS_MASK;
+   plane_wm->wm[level].plane_res_l =
+   (val >> PLANE_WM_LINES_SHIFT) & PLANE_WM_LINES_MASK;
} else {
-   if (!is_cursor) {
-   active->planes[i].trans_wm.plane_en = is_enabled;
-   active->planes[i].trans_wm.plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[i].trans_wm.plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   } else {
-   active->planes[PLANE_CURSOR].trans_wm.plane_en =
-   is_enabled;
-   active->planes[PLANE_CURSOR].trans_wm.plane_res_b =
-   val & PLANE_WM_BLOCKS_MASK;
-   active->planes[PLANE_CURSOR].trans_wm.plane_res_l =
-   (val >> PLANE_WM_LINES_SHIFT) &
-   PLANE_WM_LINES_MASK;
-   }
+   plane_wm->trans_wm.plane_en = is_enabled;
+   plane_wm->trans_wm.plane_res_b = val & PLANE_WM_BLOCKS_MASK;
+   plane_wm->trans_wm.plane_res_l =
+   (val >> PLANE_WM_LINES_SHIFT) & PLANE_WM_LINES_MASK;
}
 }
 
@@ -4349,20 +4325,20 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++) {
temp = hw->plane[pipe][i][level];
-   skl_pipe_wm_active_state(temp, active, false,
-   false, i, level);
+   skl_pipe_wm_active_state(temp, active, false, i, level);
}
temp = hw->plane[pipe][PLANE_CURSOR][level];
-   skl_pipe_wm_active_state(temp, active, false, true, i, level);
+   skl_pipe_wm_active_state(temp, active, false, PLANE_CURSOR,
+level);
}
 
for (i = 0; i < intel_num_planes(intel_crtc); i++) {
temp = hw->plane_trans[pipe][i];
-   skl_pipe_wm_active_state(temp, active, true, false, i, 0);
+   skl_pipe_wm_active_state(temp, active, true, i, 0);
}
 
temp = hw->plane_trans[pipe][PLANE_CURSOR];
-   skl_pipe_wm_active_state(temp, active, true, true, i, 0);
+   skl_pipe_wm_active_state(temp, active, true, PLANE_CURSOR, 0);
 
intel_crtc->wm.active.skl = *active;
 }
-- 
2.7.4

___
Intel-gfx 

[Intel-gfx] [PATCH v3 02/10] drm/i915/skl: Remove linetime from skl_wm_values

2016-10-14 Thread Lyude
Next part of cleaning up the watermark code for skl. This is easy, since
it seems that we never actually needed to keep track of the linetime in
the skl_wm_values struct anyway.

Signed-off-by: Lyude 
Reviewed-by: Paulo Zanoni 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 -
 drivers/gpu/drm/i915/intel_display.c | 6 --
 drivers/gpu/drm/i915/intel_pm.c  | 7 +--
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ac4287f99..e56d4a4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1648,7 +1648,6 @@ struct skl_ddb_allocation {
 struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
-   uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
 };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7a68cc3..ced70ad 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14844,6 +14844,8 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *intel_cstate =
+   to_intel_crtc_state(crtc->state);
struct intel_crtc_state *old_intel_state =
to_intel_crtc_state(old_crtc_state);
bool modeset = needs_modeset(crtc->state);
@@ -14860,13 +14862,13 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
intel_color_load_luts(crtc->state);
}
 
-   if (to_intel_crtc_state(crtc->state)->update_pipe)
+   if (intel_cstate->update_pipe)
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_GEN(dev_priv) >= 9) {
skl_detach_scalers(intel_crtc);
 
I915_WRITE(PIPE_WM_LINETIME(pipe),
-  dev_priv->wm.skl_hw.wm_linetime[pipe]);
+  intel_cstate->wm.skl.optimal.linetime);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 66586af..a7d5721 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3845,8 +3845,6 @@ static void skl_compute_wm_results(struct drm_device *dev,
temp |= PLANE_WM_EN;
 
r->plane_trans[pipe][PLANE_CURSOR] = temp;
-
-   r->wm_linetime[pipe] = p_wm->linetime;
 }
 
 static void skl_ddb_entry_write(struct drm_i915_private *dev_priv,
@@ -4081,7 +4079,6 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
 struct skl_wm_values *src,
 enum pipe pipe)
 {
-   dst->wm_linetime[pipe] = src->wm_linetime[pipe];
memcpy(dst->plane[pipe], src->plane[pipe],
   sizeof(dst->plane[pipe]));
memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
@@ -4332,8 +4329,6 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
 
max_level = ilk_wm_max_level(dev_priv);
 
-   hw->wm_linetime[pipe] = I915_READ(PIPE_WM_LINETIME(pipe));
-
for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++)
hw->plane[pipe][i][level] =
@@ -4350,7 +4345,7 @@ static void skl_pipe_wm_get_hw_state(struct drm_crtc 
*crtc)
 
hw->dirty_pipes |= drm_crtc_mask(crtc);
 
-   active->linetime = hw->wm_linetime[pipe];
+   active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
 
for (level = 0; level <= max_level; level++) {
for (i = 0; i < intel_num_planes(intel_crtc); i++) {
-- 
2.7.4

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


[Intel-gfx] [PATCH v2 08/10] drm/i915/gen9: Add skl_wm_level_equals()

2016-10-14 Thread Lyude
Helper we're going to be using for implementing verification of the wm
levels in skl_verify_wm_level().

Signed-off-by: Lyude 
Reviewed-by: Paulo Zanoni 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7036310..96963ea 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1761,6 +1761,8 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
 bool intel_can_enable_sagv(struct drm_atomic_state *state);
 int intel_enable_sagv(struct drm_i915_private *dev_priv);
 int intel_disable_sagv(struct drm_i915_private *dev_priv);
+bool skl_wm_level_equals(const struct skl_wm_level *l1,
+const struct skl_wm_level *l2);
 bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old,
   const struct skl_ddb_allocation *new,
   enum pipe pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6eaeb87..fae3ce4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3857,6 +3857,20 @@ void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
>plane[pipe][PLANE_CURSOR]);
 }
 
+bool skl_wm_level_equals(const struct skl_wm_level *l1,
+const struct skl_wm_level *l2)
+{
+   if (l1->plane_en != l2->plane_en)
+   return false;
+
+   /* If both planes aren't enabled, the rest shouldn't matter */
+   if (!l1->plane_en)
+   return true;
+
+   return (l1->plane_res_l == l2->plane_res_l &&
+   l1->plane_res_b == l2->plane_res_b);
+}
+
 static inline bool skl_ddb_entries_overlap(const struct skl_ddb_entry *a,
   const struct skl_ddb_entry *b)
 {
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 01/10] drm/i915/skl: Move per-pipe ddb allocations into crtc states

2016-10-14 Thread Lyude
First part of cleaning up all of the skl watermark code. This moves the
structures for storing the ddb allocations of each pipe into
intel_crtc_state, along with moving the structures for storing the
current ddb allocations active on hardware into intel_crtc.

Changes since v1:
- Don't replace alloc->start = alloc->end = 0;

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Paulo Zanoni 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_display.c | 16 ---
 drivers/gpu/drm/i915/intel_drv.h |  8 +---
 drivers/gpu/drm/i915/intel_pm.c  | 40 +++-
 4 files changed, 30 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b2..ac4287f99 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1641,7 +1641,6 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 }
 
 struct skl_ddb_allocation {
-   struct skl_ddb_entry pipe[I915_MAX_PIPES];
struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
 };
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 60c699e..7a68cc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14246,12 +14246,11 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 unsigned int *crtc_vblank_mask)
 {
struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_crtc *crtc;
+   struct intel_crtc *intel_crtc;
struct drm_crtc_state *old_crtc_state;
-   struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
-   struct skl_ddb_allocation *cur_ddb = _priv->wm.skl_hw.ddb;
+   struct intel_crtc_state *cstate;
unsigned int updated = 0;
bool progress;
enum pipe pipe;
@@ -14269,12 +14268,14 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
bool vbl_wait = false;
unsigned int cmask = drm_crtc_mask(crtc);
-   pipe = to_intel_crtc(crtc)->pipe;
+
+   intel_crtc = to_intel_crtc(crtc);
+   cstate = to_intel_crtc_state(crtc->state);
+   pipe = intel_crtc->pipe;
 
if (updated & cmask || !crtc->state->active)
continue;
-   if (skl_ddb_allocation_overlaps(state, cur_ddb, new_ddb,
-   pipe))
+   if (skl_ddb_allocation_overlaps(state, intel_crtc))
continue;
 
updated |= cmask;
@@ -14285,7 +14286,8 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 * then we need to wait for a vblank to pass for the
 * new ddb allocation to take effect.
 */
-   if (!skl_ddb_allocation_equals(cur_ddb, new_ddb, pipe) 
&&
+   if (!skl_ddb_entry_equal(>wm.skl.ddb,
+_crtc->hw_ddb) &&
!crtc->state->active_changed &&
intel_state->wm_results.dirty_pipes != updated)
vbl_wait = true;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5bc1154..10a0cf2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -496,6 +496,7 @@ struct intel_crtc_wm_state {
struct {
/* gen9+ only needs 1-step wm programming */
struct skl_pipe_wm optimal;
+   struct skl_ddb_entry ddb;
 
/* cached plane data rate */
unsigned plane_data_rate[I915_MAX_PLANES];
@@ -733,6 +734,9 @@ struct intel_crtc {
bool cxsr_allowed;
} wm;
 
+   /* gen9+: ddb allocation currently being used */
+   struct skl_ddb_entry hw_ddb;
+
int scanline_offset;
 
struct {
@@ -1755,9 +1759,7 @@ bool skl_ddb_allocation_equals(const struct 
skl_ddb_allocation *old,
   const struct skl_ddb_allocation *new,
   enum pipe pipe);
 bool skl_ddb_allocation_overlaps(struct drm_atomic_state 

[Intel-gfx] [PATCH v2 10/10] drm/i915/gen9: Don't wrap strings in verify_wm_state()

2016-10-14 Thread Lyude
Wrapping strings is against the guidelines in Documentation/CodingStyle,
chapter 2.

Signed-off-by: Lyude 
Reviewed-by: Paulo Zanoni 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ca12f0e..eaec9f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13509,8 +13509,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
sw_ddb_entry = _ddb->plane[pipe][plane];
 
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c plane %d "
- "(expected (%u,%u), found (%u,%u))\n",
+   DRM_ERROR("mismatch in DDB state pipe %c plane %d 
(expected (%u,%u), found (%u,%u))\n",
  pipe_name(pipe), plane + 1,
  sw_ddb_entry->start, sw_ddb_entry->end,
  hw_ddb_entry->start, hw_ddb_entry->end);
@@ -13560,8 +13559,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
sw_ddb_entry = _ddb->plane[pipe][PLANE_CURSOR];
 
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
+   DRM_ERROR("mismatch in DDB state pipe %c cursor 
(expected (%u,%u), found (%u,%u))\n",
  pipe_name(pipe),
  sw_ddb_entry->start, sw_ddb_entry->end,
  hw_ddb_entry->start, hw_ddb_entry->end);
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 05/10] drm/i915/gen9: Get rid of redundant watermark values

2016-10-14 Thread Lyude
Now that we've make skl_wm_levels make a little more sense, we can
remove all of the redundant wm information. Up until now we'd been
storing two copies of all of the skl watermarks: one being the
skl_pipe_wm structs, the other being the global wm struct in
drm_i915_private containing the raw register values. This is confusing
and problematic, since it means we're prone to accidentally letting the
two copies go out of sync. So, get rid of all of the functions
responsible for computing the register values and just use a single
helper, skl_write_wm_level(), to convert and write the new watermarks on
the fly.

Changes since v1:
- Fixup skl_write_wm_level()
- Fixup skl_wm_level_from_reg_val()
- Don't forget to copy *active to intel_crtc->wm.active.skl
Changes since v2:
- Fix usage of wrong cstate

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Paulo Zanoni 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 -
 drivers/gpu/drm/i915/intel_display.c |  14 ++-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 204 ---
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
 5 files changed, 91 insertions(+), 143 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4d1133f..929b643 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1648,8 +1648,6 @@ struct skl_ddb_allocation {
 struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
-   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
-   uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
 struct skl_wm_level {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ced70ad..18e82b4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3378,6 +3378,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
const struct skl_wm_values *wm = _priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   _state->wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
@@ -3414,7 +3416,7 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_y = src_y;
 
if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
-   skl_write_plane_wm(intel_crtc, wm, 0);
+   skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
@@ -3448,6 +3450,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+   const struct skl_plane_wm *p_wm = >wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
 
/*
@@ -3455,7 +3459,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
 * plane's visiblity isn't actually changing neither is its watermarks.
 */
if (!crtc->primary->state->visible)
-   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
+   skl_write_plane_wm(intel_crtc, p_wm,
+  _priv->wm.skl_results.ddb, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
@@ -10826,12 +10831,15 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
const struct skl_wm_values *wm = _priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   >wm.skl.optimal.planes[PLANE_CURSOR];
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
 
if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & drm_crtc_mask(crtc))
-   skl_write_cursor_wm(intel_crtc, wm);
+   skl_write_cursor_wm(intel_crtc, p_wm, >ddb);
 
if (plane_state && plane_state->base.visible) {
cntl = MCURSOR_GAMMA_ENABLE;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 84301d3..a85ce2c 100644
--- 

[Intel-gfx] [PATCH v2 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()

2016-10-14 Thread Lyude
Thanks to Paulo Zanoni for indirectly pointing this out.

Looks like we never actually added any code for checking whether or not
we actually wrote watermark levels properly. Let's fix that.

Changes since v1:
- Use %u instead of %d when printing WM state mismatches

Signed-off-by: Lyude 
Reviewed-by: Paulo Zanoni 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 100 +--
 1 file changed, 84 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 18e82b4..ca12f0e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13455,30 +13455,66 @@ static void verify_wm_state(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_ddb_allocation hw_ddb, *sw_ddb;
-   struct skl_ddb_entry *hw_entry, *sw_entry;
+   struct skl_pipe_wm hw_wm, *sw_wm;
+   struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+   struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
const enum pipe pipe = intel_crtc->pipe;
-   int plane;
+   int plane, level, max_level = ilk_wm_max_level(dev_priv);
 
if (INTEL_INFO(dev)->gen < 9 || !new_state->active)
return;
 
+   skl_pipe_wm_get_hw_state(crtc, _wm);
+   sw_wm = _crtc->wm.active.skl;
+
skl_ddb_get_hw_state(dev_priv, _ddb);
sw_ddb = _priv->wm.skl_hw.ddb;
 
/* planes */
for_each_plane(dev_priv, pipe, plane) {
-   hw_entry = _ddb.plane[pipe][plane];
-   sw_entry = _ddb->plane[pipe][plane];
+   hw_plane_wm = _wm.planes[plane];
+   sw_plane_wm = _wm->planes[plane];
 
-   if (skl_ddb_entry_equal(hw_entry, sw_entry))
-   continue;
+   /* Watermarks */
+   for (level = 0; level <= max_level; level++) {
+   if (skl_wm_level_equals(_plane_wm->wm[level],
+   _plane_wm->wm[level]))
+   continue;
+
+   DRM_ERROR("mismatch in WM pipe %c plane %d level %d 
(expected e=%d b=%u l=%u, got e=%d b=%u l=%u)\n",
+ pipe_name(pipe), plane + 1, level,
+ sw_plane_wm->wm[level].plane_en,
+ sw_plane_wm->wm[level].plane_res_b,
+ sw_plane_wm->wm[level].plane_res_l,
+ hw_plane_wm->wm[level].plane_en,
+ hw_plane_wm->wm[level].plane_res_b,
+ hw_plane_wm->wm[level].plane_res_l);
+   }
 
-   DRM_ERROR("mismatch in DDB state pipe %c plane %d "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe), plane + 1,
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   if (!skl_wm_level_equals(_plane_wm->trans_wm,
+_plane_wm->trans_wm)) {
+   DRM_ERROR("mismatch in trans WM pipe %c plane %d 
(expected e=%d b=%u l=%u, got e=%d b=%u l=%u)\n",
+ pipe_name(pipe), plane + 1,
+ sw_plane_wm->trans_wm.plane_en,
+ sw_plane_wm->trans_wm.plane_res_b,
+ sw_plane_wm->trans_wm.plane_res_l,
+ hw_plane_wm->trans_wm.plane_en,
+ hw_plane_wm->trans_wm.plane_res_b,
+ hw_plane_wm->trans_wm.plane_res_l);
+   }
+
+   /* DDB */
+   hw_ddb_entry = _ddb.plane[pipe][plane];
+   sw_ddb_entry = _ddb->plane[pipe][plane];
+
+   if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c plane %d "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe), plane + 1,
+ sw_ddb_entry->start, sw_ddb_entry->end,
+ hw_ddb_entry->start, hw_ddb_entry->end);
+   }
}
 
/*
@@ -13488,15 +13524,47 @@ static void verify_wm_state(struct drm_crtc *crtc,
 * once the plane becomes visible, we can skip this check
 */
if (intel_crtc->cursor_addr) {
-   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
- 

[Intel-gfx] [PATCH v3 06/10] drm/i915/gen9: Add ddb changes to atomic debug output

2016-10-14 Thread Lyude
Finally, add some debugging output for ddb changes in the atomic debug
output. This makes it a lot easier to spot bugs from incorrect ddb
allocations.

Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Paulo Zanoni 
Cc: Ville Syrjälä 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 54 +
 1 file changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5df5cea..2fe851e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4044,6 +4044,58 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
   sizeof(dst->ddb.plane[pipe]));
 }
 
+static void
+skl_print_wm_changes(const struct drm_atomic_state *state)
+{
+   const struct drm_device *dev = state->dev;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct intel_atomic_state *intel_state =
+   to_intel_atomic_state(state);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   const struct drm_plane *plane;
+   const struct intel_plane *intel_plane;
+   const struct drm_plane_state *pstate;
+   const struct skl_ddb_allocation *old_ddb = _priv->wm.skl_hw.ddb;
+   const struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
+   enum pipe pipe;
+   int id;
+   int i, j;
+
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   for_each_plane_in_state(state, plane, pstate, j) {
+   const struct skl_ddb_entry *old, *new;
+
+   intel_plane = to_intel_plane(plane);
+   id = skl_wm_plane_id(intel_plane);
+   old = _ddb->plane[pipe][id];
+   new = _ddb->plane[pipe][id];
+
+   if (intel_plane->pipe != pipe)
+   continue;
+
+   if (skl_ddb_entry_equal(old, new))
+   continue;
+
+   if (id != PLANE_CURSOR) {
+   DRM_DEBUG_ATOMIC("[PLANE:%d:plane %d%c] ddb (%d 
- %d) -> (%d - %d)\n",
+plane->base.id, id + 1,
+pipe_name(pipe),
+old->start, old->end,
+new->start, new->end);
+   } else {
+   DRM_DEBUG_ATOMIC("[PLANE:%d:cursor %c] ddb (%d 
- %d) -> (%d - %d)\n",
+plane->base.id,
+pipe_name(pipe),
+old->start, old->end,
+new->start, new->end);
+   }
+   }
+   }
+}
+
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
@@ -4105,6 +4157,8 @@ skl_compute_wm(struct drm_atomic_state *state)
intel_cstate->update_wm_pre = true;
}
 
+   skl_print_wm_changes(state);
+
return 0;
 }
 
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 00/10] Start of skl watermark cleanup

2016-10-14 Thread Lyude
While it (mostly) works, the code for handling watermarks on Skylake has been
kind of ugly for a while. As well a lot of it isn't that friendly to atomic
transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
full cleanup, it's a good start. As well, we add a couple of features for
making debugging watermarks a little easier.

Rebased for latest nightly, new r-bs added + some changes

Lyude (10):
  drm/i915/skl: Move per-pipe ddb allocations into crtc states
  drm/i915/skl: Remove linetime from skl_wm_values
  drm/i915/gen9: Make skl_wm_level per-plane
  drm/i915/gen9: Cleanup skl_pipe_wm_active_state
  drm/i915/gen9: Get rid of redundant watermark values
  drm/i915/gen9: Add ddb changes to atomic debug output
  drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable
  drm/i915/gen9: Add skl_wm_level_equals()
  drm/i915/gen9: Actually verify WM levels in verify_wm_state()
  drm/i915/gen9: Don't wrap strings in verify_wm_state()

 drivers/gpu/drm/i915/i915_drv.h  |  10 +-
 drivers/gpu/drm/i915/intel_display.c | 138 ---
 drivers/gpu/drm/i915/intel_drv.h |  24 +-
 drivers/gpu/drm/i915/intel_pm.c  | 466 +--
 drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
 5 files changed, 355 insertions(+), 291 deletions(-)

-- 
2.7.4

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


Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

2016-10-14 Thread Pandiyan, Dhinakaran
On Fri, 2016-10-14 at 03:09 +, Yang, Libin wrote:
> Tested-by: Libin Yang 
> 
> Regards,
> Libin
> 
> 

Thanks Libin. Can you confirm the max. BCLK frequency we set for the
audio controller?


-DK
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> > Of
> > Dhinakaran Pandiyan
> > Sent: Friday, October 14, 2016 2:04 AM
> > To: intel-...@freedesktop.org
> > Cc: Nikula, Jani ; Kp, Jeeja ;
> > Libin Yang ; Pandiyan, Dhinakaran
> > 
> > Subject: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is
> > enabled with 4 lanes and HBR2
> > 
> > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > 
> > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > continuously cycling off and on. This is essential for DP MST audio as the 
> > link
> > is trained at HBR2 and 4 lanes by default.
> > 
> > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 47
> > +---
> >  1 file changed, 43 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index cfcb03f..6a05183 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct
> > drm_atomic_state *state)
> > return 0;
> >  }
> > 
> > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state) {
> > +
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc *crtc;
> > +   int i;
> > +
> > +   /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> > +* audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> > +* there may be audio corruption or screen corruption."
> > +*/
> > +
> > +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   struct intel_crtc_state *pipe_config =
> > +   to_intel_crtc_state(crtc_state);
> > +
> > +   return (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->has_audio &&
> > +   pipe_config->port_clock == 54 &&
> > +   pipe_config->lane_count == 4);
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)  {
> > int max_pixclk = ilk_max_pixel_rate(state);
> > +   int cdclk, min_cdclk = 0;
> > struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> > 
> > -   intel_state->cdclk = intel_state->dev_cdclk =
> > -   bxt_calc_cdclk(max_pixclk);
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = bxt_calc_cdclk(432000);
> > +
> > +   cdclk = bxt_calc_cdclk(max_pixclk);
> > +   intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
> > 
> > if (!intel_state->active_crtcs)
> > intel_state->dev_cdclk = bxt_calc_cdclk(0); @@ -10374,7
> > +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct
> > drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> > int max_pixclk = ilk_max_pixel_rate(state);
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = broadwell_calc_cdclk(432000);
> > 
> > /*
> >  * FIXME should also account for plane ratio @@ -10382,6 +10414,8
> > @@ static int broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
> >  */
> > cdclk = broadwell_calc_cdclk(max_pixclk);
> > 
> > +   cdclk = max(min_cdclk, cdclk);
> > +
> > if (cdclk > dev_priv->max_cdclk_freq) {
> > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max
> > (%d kHz)\n",
> >   cdclk, dev_priv->max_cdclk_freq); @@ -10411,7
> > +10445,10 @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state
> > *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > const int max_pixclk = ilk_max_pixel_rate(state);
> > int vco = intel_state->cdclk_pll_vco;
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = skl_calc_cdclk(432000, vco);
> > 
> > /*
> >  * FIXME should also account for plane ratio @@ -10419,6 +10456,8
> > @@ static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
> >  */
> > cdclk = skl_calc_cdclk(max_pixclk, vco);
> > 
> > +   cdclk = max(min_cdclk, cdclk);
> > +
> > /*
> >  * FIXME move the 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

2016-10-14 Thread Pandiyan, Dhinakaran
On Thu, 2016-10-13 at 21:44 +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > 
> > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > continuously cycling off and on. This is essential for DP MST audio as the
> > link is trained at HBR2 and 4 lanes by default.
> > 
> > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 47 
> > +---
> >  1 file changed, 43 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index cfcb03f..6a05183 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > return 0;
> >  }
> >  
> > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> > +{
> > +
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc *crtc;
> > +   int i;
> > +
> > +   /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> > +* audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> > +* there may be audio corruption or screen corruption."
> > +*/
> > +
> > +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   struct intel_crtc_state *pipe_config =
> > +   to_intel_crtc_state(crtc_state);
> > +
> > +   return (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->has_audio &&
> > +   pipe_config->port_clock == 54 &&
> > +   pipe_config->lane_count == 4);
> > +   }
> 
> That's not good enough on account of crtcs not part of the state
> potentially needing the workaround as well. However, since we only do
> this when there's a modeset, I think we'll be covered by the
> connection_mutex, and so we should be able to peek at the current state
> of all crtcs without grabbing the corresponding crtc locks.
> 

Please correct me if I am wrong. Won't the first modeset that has all
the conditions met (DP + HBR2 + 4 lanes + audio) include the crtc
driving the display which triggered the modeset?

Since, the new cdclk freq that will be set is common for all the crtcs,
we don't need the workaround for crtcs that are not in state. 

> So I think we'd be OK with something like:
> 
> WARN_ON(!locked(connection_mutex));
> 
> for_each_intel_crtc() {
>   /*
>* Peeking at the current state is safe since
>* we can only get here while holding the
>* connection_mutex.
>*/
>   crtc_state = intel_get_existing_crtc_state();
>   if (!crtc_state)
>   crtc_state = to_intel_crtc_state(crtc->base.state);
> 
>   ...
> }
> 
> The other option would be to track the min cdclk for each pipe in the
> top level state I suppose. We already do that for the pixel rate
> actually so that we can calculate the cdclk to begin with. Hmm. Maybe
> we should just switch to tracking the min cdclk per pipe instead of the
> pixel rate. Or did we need to the pixel rate itself for something else,
> Maarten?
> 
> Or we could perhaps replace the pixel rate/pixclk tracking with the peek
> approach entirely. Not quite sure. Would have to read the entire thing
> through.
> 

I thought of this, but the work around applies for only three platforms
(potentially just two) as of now. Does it warrant a driver wide change?
I have to check if mincdclk is useful elsewhere.

> > +
> > +   return false;
> > +}
> > +
> >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> >  {
> > int max_pixclk = ilk_max_pixel_rate(state);
> > +   int cdclk, min_cdclk = 0;
> > struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> >  
> > -   intel_state->cdclk = intel_state->dev_cdclk =
> > -   bxt_calc_cdclk(max_pixclk);
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = bxt_calc_cdclk(432000);
> > +
> > +   cdclk = bxt_calc_cdclk(max_pixclk);
> > +   intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
> >  
> > if (!intel_state->active_crtcs)
> > intel_state->dev_cdclk = bxt_calc_cdclk(0);
> > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> > int max_pixclk = ilk_max_pixel_rate(state);
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

2016-10-14 Thread Pandiyan, Dhinakaran
On Fri, 2016-10-14 at 11:40 +0300, Jani Nikula wrote:
> On Thu, 13 Oct 2016, Dhinakaran Pandiyan  
> wrote:
> > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> >
> > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > continuously cycling off and on. This is essential for DP MST audio as the
> > link is trained at HBR2 and 4 lanes by default.
> >
> > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> >
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 47 
> > +---
> >  1 file changed, 43 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index cfcb03f..6a05183 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > return 0;
> >  }
> >  
> > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> 
> One drive-by comment, this name for the function would suggest it
> returns the minimum cdclk for dp audio. As-is, the function name is
> confusing.
> 

Agreed, I was running out of ideas and spent way too much time thinking
about the function name :) Any suggestions?

> BR,
> Jani.
> 
> > +{
> > +
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc *crtc;
> > +   int i;
> > +
> > +   /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> > +* audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> > +* there may be audio corruption or screen corruption."
> > +*/
> > +
> > +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   struct intel_crtc_state *pipe_config =
> > +   to_intel_crtc_state(crtc_state);
> > +
> > +   return (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->has_audio &&
> > +   pipe_config->port_clock == 54 &&
> > +   pipe_config->lane_count == 4);
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> >  {
> > int max_pixclk = ilk_max_pixel_rate(state);
> > +   int cdclk, min_cdclk = 0;
> > struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> >  
> > -   intel_state->cdclk = intel_state->dev_cdclk =
> > -   bxt_calc_cdclk(max_pixclk);
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = bxt_calc_cdclk(432000);
> > +
> > +   cdclk = bxt_calc_cdclk(max_pixclk);
> > +   intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
> >  
> > if (!intel_state->active_crtcs)
> > intel_state->dev_cdclk = bxt_calc_cdclk(0);
> > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> > int max_pixclk = ilk_max_pixel_rate(state);
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = broadwell_calc_cdclk(432000);
> >  
> > /*
> >  * FIXME should also account for plane ratio
> > @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> >  */
> > cdclk = broadwell_calc_cdclk(max_pixclk);
> >  
> > +   cdclk = max(min_cdclk, cdclk);
> > +
> > if (cdclk > dev_priv->max_cdclk_freq) {
> > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> >   cdclk, dev_priv->max_cdclk_freq);
> > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > const int max_pixclk = ilk_max_pixel_rate(state);
> > int vco = intel_state->cdclk_pll_vco;
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = skl_calc_cdclk(432000, vco);
> >  
> > /*
> >  * FIXME should also account for plane ratio
> > @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> >  */
> > cdclk = skl_calc_cdclk(max_pixclk, vco);
> >  
> > +   cdclk = max(min_cdclk, cdclk);
> > +
> > /*
> >  * FIXME move the cdclk caclulation to
> >  * compute_config() so we can fail gracegully.
> 

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


Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

2016-10-14 Thread Pandiyan, Dhinakaran
On Thu, 2016-10-13 at 11:30 -0700, Jim Bride wrote:
> On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > 
> > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > continuously cycling off and on. This is essential for DP MST audio as the
> > link is trained at HBR2 and 4 lanes by default.
> > 
> > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 47 
> > +---
> >  1 file changed, 43 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index cfcb03f..6a05183 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > return 0;
> >  }
> >  
> > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> > +{
> > +
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc *crtc;
> > +   int i;
> > +
> > +   /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> > +* audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> > +* there may be audio corruption or screen corruption."
> > +*/
> 
> It's probably worth mentioning that this limitation really only applies for
> SKL (at least that I can see) and BXT A (which I don't think we even care
> about anymore since it's not a production part.)  Were we seeing underruns
> on non-SKL platforms that increasing CDCLK fixed?   In any event, I'd rather
> see this only implemented for SKL (see BDW code below) unless we've 
> empirically
> noticed a similar problem on BDW (or the B-Spec says something about this and 
> I
> missed it.)
> 
> Jim
> 
> 
Yes, Libin saw the problem when testing a BDW NUC. And, the patch is
applicable to BDW according to the BSpec. I will try to get a
confirmation on whether this is needed BXT production parts.

> > +
> > +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   struct intel_crtc_state *pipe_config =
> > +   to_intel_crtc_state(crtc_state);
> > +
> > +   return (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->has_audio &&
> > +   pipe_config->port_clock == 54 &&
> > +   pipe_config->lane_count == 4);
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> >  {
> > int max_pixclk = ilk_max_pixel_rate(state);
> > +   int cdclk, min_cdclk = 0;
> > struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> >  
> > -   intel_state->cdclk = intel_state->dev_cdclk =
> > -   bxt_calc_cdclk(max_pixclk);
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = bxt_calc_cdclk(432000);
> > +
> > +   cdclk = bxt_calc_cdclk(max_pixclk);
> > +   intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
> >  
> > if (!intel_state->active_crtcs)
> > intel_state->dev_cdclk = bxt_calc_cdclk(0);
> > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> > int max_pixclk = ilk_max_pixel_rate(state);
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = broadwell_calc_cdclk(432000);
> >  
> > /*
> >  * FIXME should also account for plane ratio
> > @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> >  */
> > cdclk = broadwell_calc_cdclk(max_pixclk);
> >  
> > +   cdclk = max(min_cdclk, cdclk);
> > +
> > if (cdclk > dev_priv->max_cdclk_freq) {
> > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> >   cdclk, dev_priv->max_cdclk_freq);
> > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > const int max_pixclk = ilk_max_pixel_rate(state);
> > int vco = intel_state->cdclk_pll_vco;
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = skl_calc_cdclk(432000, vco);
> >  
> > /*
> >  * FIXME should also account for plane ratio
> > @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> >  */
> > cdclk = 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: WA to address the Ringbuffer coherency issue

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

Series: drm/i915/guc: WA to address the Ringbuffer coherency issue
URL   : https://patchwork.freedesktop.org/series/13807/
State : warning

== Summary ==

Series 13807v1 drm/i915/guc: WA to address the Ringbuffer coherency issue
https://patchwork.freedesktop.org/api/1.0/series/13807/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-bdw-5557u)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-skl-6700k)
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6770hq)
pass   -> SKIP   (fi-hsw-4770)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-byt-j1900 failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2728/

38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
2016y-10m-14d-16h-23m-48s UTC integration manifest
86dd25f drm/i915/guc: WA to address the Ringbuffer coherency issue

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


Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

2016-10-14 Thread Pandiyan, Dhinakaran
On Thu, 2016-10-13 at 15:28 -0300, Paulo Zanoni wrote:
> Em Qui, 2016-10-13 às 11:04 -0700, Dhinakaran Pandiyan escreveu:
> > According to BSpec, cdclk has to be not less than 432 MHz with DP
> > audio
> > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> 
> This is just for pre-production hardware, and we don't implement
> workarounds for pre-prod.
> 
> 

I try to get a confirmation that is applicable to production HW too.

> A quick research seems to indicate that our CDCLK must be at least
> twice the frequency of the audio BCLK. Maybe this is what we need to
> investigate/check?
> 

From what I see in the description for AUD_FREQ_CNTRL, BCLK is either
48MHz or 96MHz. But we see this issue even with cdclk set to 337.5 MHz.

> Anyway, it looks like we're getting closer to the final bug fix.
> 
> > 
> > Having a lower cdclk triggers pipe underruns, which then lead to
> > displays
> > continuously cycling off and on. This is essential for DP MST audio
> > as the
> > link is trained at HBR2 and 4 lanes by default.
> > 
> > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> 
> Please use the "Bugzilla:" tag since there are some scripts and robots
> that parse it and do stuff with it.
> 
> 

Will do. 

> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 47
> > +---
> >  1 file changed, 43 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index cfcb03f..6a05183 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6603,14 +6603,43 @@ static int
> > valleyview_modeset_calc_cdclk(struct drm_atomic_state *state)
> > return 0;
> >  }
> >  
> > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> > +{
> > +
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc *crtc;
> > +   int i;
> > +
> > +   /* BSpec says "Do not use DisplayPort with CDCLK less than
> > 432 MHz,
> > +* audio enabled, port width x4, and link rate HBR2 (5.4
> > GHz), or else
> > +* there may be audio corruption or screen corruption."
> > +*/
> > +
> > +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   struct intel_crtc_state *pipe_config =
> > +   to_intel_crtc_state(crtc_state);
> > +
> > +   return (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->has_audio &&
> > +   pipe_config->port_clock == 54 &&
> > +   pipe_config->lane_count == 4);
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> >  {
> > int max_pixclk = ilk_max_pixel_rate(state);
> > +   int cdclk, min_cdclk = 0;
> > struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> >  
> > -   intel_state->cdclk = intel_state->dev_cdclk =
> > -   bxt_calc_cdclk(max_pixclk);
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = bxt_calc_cdclk(432000);
> > +
> > +   cdclk = bxt_calc_cdclk(max_pixclk);
> > +   intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk,
> > cdclk);
> >  
> > if (!intel_state->active_crtcs)
> > intel_state->dev_cdclk = bxt_calc_cdclk(0);
> > @@ -10374,7 +10403,10 @@ static int
> > broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> > int max_pixclk = ilk_max_pixel_rate(state);
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = broadwell_calc_cdclk(432000);
> >  
> > /*
> >  * FIXME should also account for plane ratio
> > @@ -10382,6 +10414,8 @@ static int
> > broadwell_modeset_calc_cdclk(struct drm_atomic_state *state)
> >  */
> > cdclk = broadwell_calc_cdclk(max_pixclk);
> >  
> > +   cdclk = max(min_cdclk, cdclk);
> > +
> > if (cdclk > dev_priv->max_cdclk_freq) {
> > DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max
> > (%d kHz)\n",
> >   cdclk, dev_priv->max_cdclk_freq);
> > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct
> > drm_atomic_state *state)
> > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > const int max_pixclk = ilk_max_pixel_rate(state);
> > int vco = intel_state->cdclk_pll_vco;
> > -   int cdclk;
> > +   int cdclk, min_cdclk = 0;
> > +
> > +   if (cdclk_min_for_dp_audio(state))
> > +   min_cdclk = skl_calc_cdclk(432000, vco);
> >  
> > /*
> >  * FIXME should also account for plane ratio
> > @@ -10419,6 +10456,8 @@ static int skl_modeset_calc_cdclk(struct
> > drm_atomic_state *state)
> >  */
> > cdclk = 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

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

Series: drm/i915: Suppress underrun reporting around DP link retraining
URL   : https://patchwork.freedesktop.org/series/13805/
State : warning

== Summary ==

Series 13805v1 drm/i915: Suppress underrun reporting around DP link retraining
https://patchwork.freedesktop.org/api/1.0/series/13805/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700k)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-hsw-4770)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2727/

38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
2016y-10m-14d-16h-23m-48s UTC integration manifest
171418c drm/i915: Suppress underruns during DP link retraining
2a576f6 drm/i915: Extract intel_crtc_pch_transcoder()

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


Re: [Intel-gfx] [PATCH] drm/i915/guc: WA to address the Ringbuffer coherency issue

2016-10-14 Thread Goel, Akash



On 10/14/2016 11:45 PM, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 11:53:44PM +0530, akash.g...@intel.com wrote:

From: Akash Goel 

Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
pinned in mappable aperture portion of GGTT and for ringbuffer pages
allocated from Stolen memory, access can only be done through GMADR BAR.
In case of GuC based submission, updates done in ringbuffer via GMADR
may not get commited to memory by the time the Command streamer starts
reading them, resulting in fetching of stale data.


Please leave a blank line between paragraphs, or try to not leave so
much whitespace at the end of a sentence.


I am sorry. Will be mindful of this from now.


For Host based submission, such problem is not there as the write to Ring
Tail or ELSP register happens from the Host side prior to submission.
Access to any GFX register from CPU side goes to GTTMMADR BAR and Hw already
enforces the ordering between outstanding GMADR writes & new GTTMADR access.
MMIO writes from GuC side do not go to GTTMMADR BAR as GuC communication to
registers within GT is contained within GT, so ordering is not enforced
resulting in a race, which can manifest in form of a hang.
To ensure the flush of in flight GMADR writes, a POSTING READ is done to
GuC register prior to doorbell ring.
There is already a similar WA in i915_gem_object_flush_gtt_write_domain(),
which takes care of GMADR writes from User space to GEM buffers, but not the
ringbuffer writes from KMD.
This WA is needed on all recent HW.

Cc: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a1f76c8..43c8a72 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -601,6 +601,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
  */
 static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
+   struct drm_i915_private *dev_priv = rq->i915;
unsigned int engine_id = rq->engine->id;
struct intel_guc *guc = >i915->guc;
struct i915_guc_client *client = guc->execbuf_client;
@@ -608,6 +609,11 @@ static void i915_guc_submit(struct drm_i915_gem_request 
*rq)

spin_lock(>wq_lock);
guc_wq_item_append(client, rq);
+
+   /* WA to flush out the pending GMADR writes to ring buffer. */
+   if (i915_vma_is_map_and_fenceable(rq->ring->vma))
+   POSTING_READ(GUC_STATUS);


Did you test POSTING_READ_FW() ?
Sorry though we haven't explicitly tried POSTING_READ_FW() but it should 
work since, as per the __gen9_fw_ranges[] table, GuC registers 
(C000-Cxxx) do not lie in any Forcewake domain range.




Otherwise it makes an unfortunate amount of sense, and I feel justified
in what I had to do in flush_gtt_write_domwin! :)

Yes your hunch, expectedly, was spot on :).

Best regards
Akash

-Chris


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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Simplify DP port limited color range bit platform checks

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

Series: drm/i915: Simplify DP port limited color range bit platform checks
URL   : https://patchwork.freedesktop.org/series/13803/
State : warning

== Summary ==

Series 13803v1 drm/i915: Simplify DP port limited color range bit platform 
checks
https://patchwork.freedesktop.org/api/1.0/series/13803/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-skl-6700k)
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6770hq)
pass   -> SKIP   (fi-hsw-4770)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2726/

38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
2016y-10m-14d-16h-23m-48s UTC integration manifest
49d98ac drm/i915: Simplify DP port limited color range bit platform checks

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


Re: [Intel-gfx] [PATCH] drm/i915/guc: WA to address the Ringbuffer coherency issue

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 11:53:44PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel 
> 
> Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
> pinned in mappable aperture portion of GGTT and for ringbuffer pages
> allocated from Stolen memory, access can only be done through GMADR BAR.
> In case of GuC based submission, updates done in ringbuffer via GMADR
> may not get commited to memory by the time the Command streamer starts
> reading them, resulting in fetching of stale data.

Please leave a blank line between paragraphs, or try to not leave so
much whitespace at the end of a sentence.

> For Host based submission, such problem is not there as the write to Ring
> Tail or ELSP register happens from the Host side prior to submission.
> Access to any GFX register from CPU side goes to GTTMMADR BAR and Hw already
> enforces the ordering between outstanding GMADR writes & new GTTMADR access.
> MMIO writes from GuC side do not go to GTTMMADR BAR as GuC communication to
> registers within GT is contained within GT, so ordering is not enforced
> resulting in a race, which can manifest in form of a hang.
> To ensure the flush of in flight GMADR writes, a POSTING READ is done to
> GuC register prior to doorbell ring.
> There is already a similar WA in i915_gem_object_flush_gtt_write_domain(),
> which takes care of GMADR writes from User space to GEM buffers, but not the
> ringbuffer writes from KMD.
> This WA is needed on all recent HW.
> 
> Cc: Chris Wilson 
> Signed-off-by: Sagar Arun Kamble 
> Signed-off-by: Akash Goel 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index a1f76c8..43c8a72 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -601,6 +601,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
>   */
>  static void i915_guc_submit(struct drm_i915_gem_request *rq)
>  {
> + struct drm_i915_private *dev_priv = rq->i915;
>   unsigned int engine_id = rq->engine->id;
>   struct intel_guc *guc = >i915->guc;
>   struct i915_guc_client *client = guc->execbuf_client;
> @@ -608,6 +609,11 @@ static void i915_guc_submit(struct drm_i915_gem_request 
> *rq)
>  
>   spin_lock(>wq_lock);
>   guc_wq_item_append(client, rq);
> +
> + /* WA to flush out the pending GMADR writes to ring buffer. */
> + if (i915_vma_is_map_and_fenceable(rq->ring->vma))
> + POSTING_READ(GUC_STATUS);

Did you test POSTING_READ_FW() ?

Otherwise it makes an unfortunate amount of sense, and I feel justified
in what I had to do in flush_gtt_write_domwin! :)
-Chris

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


[Intel-gfx] [PATCH] drm/i915/guc: WA to address the Ringbuffer coherency issue

2016-10-14 Thread akash . goel
From: Akash Goel 

Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are
pinned in mappable aperture portion of GGTT and for ringbuffer pages
allocated from Stolen memory, access can only be done through GMADR BAR.
In case of GuC based submission, updates done in ringbuffer via GMADR
may not get commited to memory by the time the Command streamer starts
reading them, resulting in fetching of stale data.
For Host based submission, such problem is not there as the write to Ring
Tail or ELSP register happens from the Host side prior to submission.
Access to any GFX register from CPU side goes to GTTMMADR BAR and Hw already
enforces the ordering between outstanding GMADR writes & new GTTMADR access.
MMIO writes from GuC side do not go to GTTMMADR BAR as GuC communication to
registers within GT is contained within GT, so ordering is not enforced
resulting in a race, which can manifest in form of a hang.
To ensure the flush of in flight GMADR writes, a POSTING READ is done to
GuC register prior to doorbell ring.
There is already a similar WA in i915_gem_object_flush_gtt_write_domain(),
which takes care of GMADR writes from User space to GEM buffers, but not the
ringbuffer writes from KMD.
This WA is needed on all recent HW.

Cc: Chris Wilson 
Signed-off-by: Sagar Arun Kamble 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a1f76c8..43c8a72 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -601,6 +601,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
  */
 static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
+   struct drm_i915_private *dev_priv = rq->i915;
unsigned int engine_id = rq->engine->id;
struct intel_guc *guc = >i915->guc;
struct i915_guc_client *client = guc->execbuf_client;
@@ -608,6 +609,11 @@ static void i915_guc_submit(struct drm_i915_gem_request 
*rq)
 
spin_lock(>wq_lock);
guc_wq_item_append(client, rq);
+
+   /* WA to flush out the pending GMADR writes to ring buffer. */
+   if (i915_vma_is_map_and_fenceable(rq->ring->vma))
+   POSTING_READ(GUC_STATUS);
+
b_ret = guc_ring_doorbell(client);
 
client->submissions[engine_id] += 1;
-- 
1.9.2

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Document our internal limit on object size

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

Series: series starting with [1/2] drm/i915: Document our internal limit on 
object size
URL   : https://patchwork.freedesktop.org/series/13797/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (fi-skl-6770hq)
dmesg-warn -> PASS   (fi-skl-6700k)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS   (fi-ilk-650)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2725/

38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
2016y-10m-14d-16h-23m-48s UTC integration manifest
edfea81 drm/i915: Limit the scattergather coalescing to 32bits
fee9f2e drm/i915: Document our internal limit on object size

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Suppress underruns during DP link retraining

2016-10-14 Thread Ville Syrjälä
On Fri, Oct 14, 2016 at 06:27:49PM +0100, Chris Wilson wrote:
> On Fri, Oct 14, 2016 at 08:02:54PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > DP link retraining causes (spurious?) underruns. We can't really avoid
> > them, except perhaps by doing a full modeset (which has its own underrun
> > suppression anyway). So let's just hide them.
> > 
> > MST still has its own logic for retrainin, but a bigger hpd handling
> > cleanup/unification is needed there anyway, so let's leave that be for now.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=98251
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 29 +++--
> >  1 file changed, 27 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index bc03f61d94f1..780691a34133 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3988,6 +3988,31 @@ go_again:
> >  }
> >  
> >  static void
> > +intel_dp_retrain_link(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> > +
> > +   /* Suppress underruns caused by re-training */
> > +   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, false);
> > +   if (crtc->config->has_pch_encoder)
> > +   intel_set_pch_fifo_underrun_reporting(dev_priv,
> > + 
> > intel_crtc_pch_transcoder(crtc), false);
> > +
> > +   intel_dp_start_link_train(intel_dp);
> > +   intel_dp_stop_link_train(intel_dp);
> > +
> > +   /* Keep underrun reporting disabled until things are stable */
> > +   intel_wait_for_vblank(_priv->drm, crtc->pipe);
> 
> I panicked over the irqreturn for hpd_pulse. That's a scary way of
> saying the return type is boolean.

It's been known to cause bugs too when people don't remember what it
means.

> 
> > +   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, true);
> > +   if (crtc->config->has_pch_encoder)
> > +   intel_set_pch_fifo_underrun_reporting(dev_priv,
> > + 
> > intel_crtc_pch_transcoder(crtc), true);
> 
> These are becoming quite popular. Is has_pch_encoder generic enough for
> all crtc?
> 
> intel_crtc_suppress_underruns(struct intel_crtc *crtc, bool state)
> {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> 
>   if (!state)
>   intel_wait_for_vblank(_priv->drm, crtc->pipe);
> 
>   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, state);
>   if (crtc->config->has_pch_encoder)
>   intel_set_pch_fifo_underrun_reporting(dev_priv,
> 
> intel_crtc_pch_transcoder(crtc),
> state);
> }

Hmm. I suppose we could replace a the ones in dp/hdmi/sdvo code
with something like that. Would need to use
intel_wait_for_vblank_if_active() though.

The ones directly in the crtc enable/disable paths paths aren't quite
that straightforward though. Making them simpler might ease the
maintenance burden though, with the cost of a slight loss in coverage.

> 
> If this was igt, we would be writing all kinds of silly
> 
> #define intel_crtc_suppress_underruns(crtc, state) \
>   for (state = true; __intel_crtc_suppress_underruns(crtc, state); state 
> = false)
> 
> 
> intel_crtc_suppress_underruns(crtc, state) {
>   intel_dp_start_link_train(intel_dp);
>   intel_dp_stop_link_train(intel_dp);
> }
> 
> Other than bikeshedding to see if we can trim down the profileration,
> this looks inline with the suppression everywhere else, so
> Reviewed-by: Chris Wilson 
> 
> Main concern was over the vblank wait making short/long pulse handling
> slower, but the code looks like it will survive - and the only
> noticeable artifacts would be if link training failed anyway with the
> small delay before recovery.

The pipe should be running still so at least it shouldn't have to wait
for a timeout.

In general the retraining doesn't feel entirely robust. If I try force a
retraining on my ILK or IVB when the link is actually good, it generally
doesn't succeed. If I toggle the port state at the start of the
retraining it starts to work. The spec even says we should do that, so
might be we should go for it. I think I'll need to digest this idea a
bit more thogh, as I haven't pondered the ramifications thorougly.

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/41] drm/i915: Move user fault tracking to a separate list

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 05:20:14PM +, Saarinen, Jani wrote:
> dmesg 
> [  215.647898] BUG: unable to handle kernel paging request at fff0
> [  215.647960] IP: [] drm_debugfs_crtc_add+0x10/0x90

0 haswell:/usr/src/linux (eb-fence)$ git grep drm_debugfs_crtc_add
=1 haswell:/usr/src/linux (eb-fence)$ 

Doesn't exist in -nightly and I don't see any reference to it in history.

> [  215.648002] PGD 1e07067 PUD 1e09067 PMD 0 
> [  215.648039] Oops:  [#1] PREEMPT SMP
> [  215.648064] Modules linked in: vgem(+) snd_hda_intel i915 
> x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi 
> snd_hda_codec_generic mei_me crct10dif_pclmul snd_hda_codec crc32_pclmul 
> snd_hwdep snd_hda_core ghash_clmulni_intel mei snd_pcm lpc_ich sdhci_pci 
> sdhci mmc_core e1000e ptp pps_core [last unloaded: i915]
> [  215.648306] CPU: 3 PID: 8939 Comm: modprobe Tainted: G U  
> 4.8.0-rc8-CI-CI_DRM_1671+ #1

That kernel id is out of date, we haven't been at 4.8.0-rc8 for a week
or two.
-Chris

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for RFC drm/i915: Add a sunset clause to GPU hang logging

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 05:09:08PM +, Saarinen, Jani wrote:
> > == Series Details ==
> > 
> > Series: RFC drm/i915: Add a sunset clause to GPU hang logging
> > URL   : https://patchwork.freedesktop.org/series/13788/
> > State : warning
> > 
> > == Summary ==
> > 
> > Series 13788v1 RFC drm/i915: Add a sunset clause to GPU hang logging
> > https://patchwork.freedesktop.org/api/1.0/series/13788/revisions/1/mbox/
> > 
> > Test kms_force_connector_basic:
> > Subgroup prune-stale-modes:
> > pass   -> SKIP   (fi-snb-2600)
> Have been stable before:
> IGT-Version: 1.16-g171b21d (x86_64) (Linux: 4.8.0-CI-Patchwork_2722+ x86_64)
> Test requirement not met in function main, file 
> kms_force_connector_basic.c:111:
> Test requirement: !(vga_connector->connection == DRM_MODE_CONNECTED)
> Last errno: 2, No such file or directory
> Subtest prune-stale-modes: SKIP

This is an indication that it is not as stable as you think it is ;)
-Chris

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Suppress underruns during DP link retraining

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 08:02:54PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> DP link retraining causes (spurious?) underruns. We can't really avoid
> them, except perhaps by doing a full modeset (which has its own underrun
> suppression anyway). So let's just hide them.
> 
> MST still has its own logic for retrainin, but a bigger hpd handling
> cleanup/unification is needed there anyway, so let's leave that be for now.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98251
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index bc03f61d94f1..780691a34133 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3988,6 +3988,31 @@ go_again:
>  }
>  
>  static void
> +intel_dp_retrain_link(struct intel_dp *intel_dp)
> +{
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> +
> + /* Suppress underruns caused by re-training */
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, false);
> + if (crtc->config->has_pch_encoder)
> + intel_set_pch_fifo_underrun_reporting(dev_priv,
> +   
> intel_crtc_pch_transcoder(crtc), false);
> +
> + intel_dp_start_link_train(intel_dp);
> + intel_dp_stop_link_train(intel_dp);
> +
> + /* Keep underrun reporting disabled until things are stable */
> + intel_wait_for_vblank(_priv->drm, crtc->pipe);

I panicked over the irqreturn for hpd_pulse. That's a scary way of
saying the return type is boolean.

> + intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, true);
> + if (crtc->config->has_pch_encoder)
> + intel_set_pch_fifo_underrun_reporting(dev_priv,
> +   
> intel_crtc_pch_transcoder(crtc), true);

These are becoming quite popular. Is has_pch_encoder generic enough for
all crtc?

intel_crtc_suppress_underruns(struct intel_crtc *crtc, bool state)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);

if (!state)
intel_wait_for_vblank(_priv->drm, crtc->pipe);

intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, state);
if (crtc->config->has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev_priv,
  
intel_crtc_pch_transcoder(crtc),
  state);
}

If this was igt, we would be writing all kinds of silly

#define intel_crtc_suppress_underruns(crtc, state) \
for (state = true; __intel_crtc_suppress_underruns(crtc, state); state 
= false)


intel_crtc_suppress_underruns(crtc, state) {
intel_dp_start_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
}

Other than bikeshedding to see if we can trim down the profileration,
this looks inline with the suppression everywhere else, so
Reviewed-by: Chris Wilson 

Main concern was over the vblank wait making short/long pulse handling
slower, but the code looks like it will survive - and the only
noticeable artifacts would be if link training failed anyway with the
small delay before recovery.
-Chris

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Emit telltales for extra levels of debug upon initialisation

2016-10-14 Thread Saarinen, Jani
> == Series Details ==
> 
> Series: drm/i915: Emit telltales for extra levels of debug upon initialisation
> URL   : https://patchwork.freedesktop.org/series/13785/
> State : warning
> 
> == Summary ==
> 
> Series 13785v1 drm/i915: Emit telltales for extra levels of debug upon
> initialisation
> https://patchwork.freedesktop.org/api/1.0/series/13785/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-a:
> pass   -> DMESG-WARN (fi-ilk-650)
https://bugs.freedesktop.org/show_bug.cgi?id=98251
Vile's patch (just sent) should help here. 

> Subgroup read-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-byt-j1900)
https://bugs.freedesktop.org/show_bug.cgi?id=98040

> Test vgem_basic:
> Subgroup unload:
> skip   -> PASS   (fi-skl-6700k)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2720/
> 
> e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 2016y-10m-
> 14d-11h-43m-09s UTC integration manifest
> 64736d0 drm/i915: Emit telltales for extra levels of debug upon initialisation
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/41] drm/i915: Move user fault tracking to a separate list

2016-10-14 Thread Saarinen, Jani
> == Series Details ==
> 
> Series: series starting with [01/41] drm/i915: Move user fault tracking to a
> separate list
> URL   : https://patchwork.freedesktop.org/series/13780/
> State : failure
> 
> == Summary ==
> 
> Series 13780v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/13780/revisions/1/mbox/
> 
> Test kms_force_connector_basic:
> Subgroup force-load-detect:
> pass   -> INCOMPLETE (fi-snb-2520m)
[031/244] skip: 5, pass: 26 -
running: igt/vgem_reload_basic

[031/244] skip: 5, pass: 26 \ 
dmesg-fail: igt/vgem_reload_basic

[032/244] skip: 5, pass: 26, dmesg-fail: 1 \
running: igt/drv_getparams_basic/basic-subslice-total

[032/244] skip: 5, pass: 26, dmesg-fail: 1 | 
Build timed out (after 18 minutes). Marking the build as aborted.
--
Stderr  
/opt/igt/tests/vgem_reload_basic: line 26:  8939 Killed  
/sbin/modprobe vgem $*

Environment 
PIGLIT_PLATFORM="mixed_glx_egl" PIGLIT_SOURCE_DIR="/opt/igt/piglit"

Command /opt/igt/tests/vgem_reload_basic

dmesg   
[  215.647898] BUG: unable to handle kernel paging request at fff0
[  215.647960] IP: [] drm_debugfs_crtc_add+0x10/0x90
[  215.648002] PGD 1e07067 PUD 1e09067 PMD 0 
[  215.648039] Oops:  [#1] PREEMPT SMP
[  215.648064] Modules linked in: vgem(+) snd_hda_intel i915 
x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi 
snd_hda_codec_generic mei_me crct10dif_pclmul snd_hda_codec crc32_pclmul 
snd_hwdep snd_hda_core ghash_clmulni_intel mei snd_pcm lpc_ich sdhci_pci sdhci 
mmc_core e1000e ptp pps_core [last unloaded: i915]
[  215.648306] CPU: 3 PID: 8939 Comm: modprobe Tainted: G U  
4.8.0-rc8-CI-CI_DRM_1671+ #1
[  215.648354] Hardware name: LENOVO 42962WU/42962WU, BIOS 8DET56WW (1.26 ) 
12/01/2011
[  215.648395] task: 880111bca740 task.stack: 8801150cc000
[  215.648427] RIP: 0010:[]  [] 
drm_debugfs_crtc_add+0x10/0x90
[  215.648479] RSP: 0018:8801150cfc38  EFLAGS: 00010282
[  215.648508] RAX:  RBX: fff0 RCX: 0006

> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-byt-j1900)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-byt-j1900)
> Test vgem_basic:
> Subgroup unload:
> skip   -> PASS   (fi-skl-6700k)
> pass   -> SKIP   (fi-hsw-4770)
> skip   -> PASS   (fi-kbl-7200u)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:186  pass:158  dwarn:0   dfail:0   fail:0   skip:27
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2719/
> 
> e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 2016y-10m-
> 14d-11h-43m-09s UTC integration manifest
> 0f86ecc drm/i915: Support explicit fencing for execbuf
> 7f5162e drm/i915: Enable userspace to opt-out of implicit fencing
> f55af4a drm/i915: Enable multiple timelines
> cb6ef98 drm/i915: Defer setting of global seqno on request to submission
> 30dbfdb drm/i915: Reserve space in the global seqno during request
> allocation
> 087e6731 drm/i915: Create a unique name for the context
> 4e04f5b drm/i915: Move the global sync optimisation to the timeline
> 2f0449e drm/i915: Defer breadcrumb emission
> 520767f drm/i915: Record space required for breadcrumb emission
> cc1329d drm/i915: Rename ->emit_request to ->emit_breadcrumb
> baa6f9e drm/i915: Introduce a global_seqno for each request
> 8d1698c drm/i915: Wait first for submission, before waiting for request
> completion
> 2446a25 drm/i915: Queue the idling context switch after all other timelines
> 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix cxsr_latency_table reorg

2016-10-14 Thread Saarinen, Jani
> == Series Details ==
> 
> Series: drm/i915: Fix cxsr_latency_table reorg
> URL   : https://patchwork.freedesktop.org/series/13789/
> State : warning
> 
> == Summary ==
> 
> Series 13789v1 drm/i915: Fix cxsr_latency_table reorg
> https://patchwork.freedesktop.org/api/1.0/series/13789/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-byt-j1900)
https://bugs.freedesktop.org/show_bug.cgi?id=98040

> Test vgem_basic:
> Subgroup unload:
> skip   -> PASS   (fi-skl-6700k)
> pass   -> SKIP   (fi-hsw-4770)
> skip   -> PASS   (fi-kbl-7200u)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2723/
> 
> e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 2016y-10m-
> 14d-11h-43m-09s UTC integration manifest
> a854fc9 drm/i915: Fix cxsr_latency_table reorg
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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


Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for RFC drm/i915: Add a sunset clause to GPU hang logging

2016-10-14 Thread Saarinen, Jani
> == Series Details ==
> 
> Series: RFC drm/i915: Add a sunset clause to GPU hang logging
> URL   : https://patchwork.freedesktop.org/series/13788/
> State : warning
> 
> == Summary ==
> 
> Series 13788v1 RFC drm/i915: Add a sunset clause to GPU hang logging
> https://patchwork.freedesktop.org/api/1.0/series/13788/revisions/1/mbox/
> 
> Test kms_force_connector_basic:
> Subgroup prune-stale-modes:
> pass   -> SKIP   (fi-snb-2600)
Have been stable before:
IGT-Version: 1.16-g171b21d (x86_64) (Linux: 4.8.0-CI-Patchwork_2722+ x86_64)
Test requirement not met in function main, file kms_force_connector_basic.c:111:
Test requirement: !(vga_connector->connection == DRM_MODE_CONNECTED)
Last errno: 2, No such file or directory
Subtest prune-stale-modes: SKIP

> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (fi-skl-6770hq)

> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-byt-j1900)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-byt-j1900)
For a/b still: https://bugs.freedesktop.org/show_bug.cgi?id=98040

> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-hsw-4770)
> skip   -> PASS   (fi-kbl-7200u)
> skip   -> PASS   (fi-skl-6700k)
Still unstable test on HSW, SKL's and KBL.

> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2722/
> 
> e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 2016y-10m-
> 14d-11h-43m-09s UTC integration manifest
> 5a74e57 RFC drm/i915: Add a sunset clause to GPU hang logging
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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


Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Parse VBT data for lspcon

2016-10-14 Thread Saarinen, Jani
> == Series Details ==
> 
> Series: drm/i915: Parse VBT data for lspcon
> URL   : https://patchwork.freedesktop.org/series/13786/
> State : warning
> 
> == Summary ==
> 
> Series 13786v1 drm/i915: Parse VBT data for lspcon
> https://patchwork.freedesktop.org/api/1.0/series/13786/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-byt-j1900)
Still same: https://bugs.freedesktop.org/show_bug.cgi?id=98040


> Test vgem_basic:
> Subgroup unload:
> skip   -> PASS   (fi-kbl-7200u)
> skip   -> PASS   (fi-skl-6700k)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2721/
> 
> e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 2016y-10m-
> 14d-11h-43m-09s UTC integration manifest 1edb07a drm/i915: Parse VBT
> data for lspcon
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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


[Intel-gfx] [PATCH 1/2] drm/i915: Extract intel_crtc_pch_transcoder()

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

Extract the code to determine which PCH transcoder we're using to a
small helper.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 21 ++---
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 60c699e2c2af..2bd2b1f1d7b5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1926,6 +1926,18 @@ void lpt_disable_pch_transcoder(struct drm_i915_private 
*dev_priv)
I915_WRITE(TRANS_CHICKEN2(PIPE_A), val);
 }
 
+enum transcoder intel_crtc_pch_transcoder(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+   WARN_ON(!crtc->config->has_pch_encoder);
+
+   if (HAS_PCH_LPT(dev_priv))
+   return TRANSCODER_A;
+   else
+   return (enum transcoder) crtc->pipe;
+}
+
 /**
  * intel_enable_pipe - enable a pipe, asserting requirements
  * @crtc: crtc responsible for the pipe
@@ -1939,7 +1951,6 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = to_i915(dev);
enum pipe pipe = crtc->pipe;
enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
-   enum pipe pch_transcoder;
i915_reg_t reg;
u32 val;
 
@@ -1949,11 +1960,6 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
assert_cursor_disabled(dev_priv, pipe);
assert_sprites_disabled(dev_priv, pipe);
 
-   if (HAS_PCH_LPT(dev_priv))
-   pch_transcoder = TRANSCODER_A;
-   else
-   pch_transcoder = pipe;
-
/*
 * A pipe without a PLL won't actually be able to drive bits from
 * a plane.  On ILK+ the pipe PLLs are integrated, so we don't
@@ -1967,7 +1973,8 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
} else {
if (crtc->config->has_pch_encoder) {
/* if driving the PCH, we need FDI enabled */
-   assert_fdi_rx_pll_enabled(dev_priv, pch_transcoder);
+   assert_fdi_rx_pll_enabled(dev_priv,
+ (enum pipe) 
intel_crtc_pch_transcoder(crtc));
assert_fdi_tx_pll_enabled(dev_priv,
  (enum pipe) cpu_transcoder);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a885b2ac9618..7bc1491a8cde 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1183,6 +1183,7 @@ void i915_audio_component_init(struct drm_i915_private 
*dev_priv);
 void i915_audio_component_cleanup(struct drm_i915_private *dev_priv);
 
 /* intel_display.c */
+enum transcoder intel_crtc_pch_transcoder(struct intel_crtc *crtc);
 void skl_set_preferred_cdclk_vco(struct drm_i915_private *dev_priv, int vco);
 void intel_update_rawclk(struct drm_i915_private *dev_priv);
 int vlv_get_cck_clock(struct drm_i915_private *dev_priv,
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/2] drm/i915: Suppress underruns during DP link retraining

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

DP link retraining causes (spurious?) underruns. We can't really avoid
them, except perhaps by doing a full modeset (which has its own underrun
suppression anyway). So let's just hide them.

MST still has its own logic for retrainin, but a bigger hpd handling
cleanup/unification is needed there anyway, so let's leave that be for now.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98251
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc03f61d94f1..780691a34133 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3988,6 +3988,31 @@ go_again:
 }
 
 static void
+intel_dp_retrain_link(struct intel_dp *intel_dp)
+{
+   struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
+
+   /* Suppress underruns caused by re-training */
+   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, false);
+   if (crtc->config->has_pch_encoder)
+   intel_set_pch_fifo_underrun_reporting(dev_priv,
+ 
intel_crtc_pch_transcoder(crtc), false);
+
+   intel_dp_start_link_train(intel_dp);
+   intel_dp_stop_link_train(intel_dp);
+
+   /* Keep underrun reporting disabled until things are stable */
+   intel_wait_for_vblank(_priv->drm, crtc->pipe);
+
+   intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, true);
+   if (crtc->config->has_pch_encoder)
+   intel_set_pch_fifo_underrun_reporting(dev_priv,
+ 
intel_crtc_pch_transcoder(crtc), true);
+}
+
+static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
@@ -4012,8 +4037,8 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
(!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
  intel_encoder->base.name);
-   intel_dp_start_link_train(intel_dp);
-   intel_dp_stop_link_train(intel_dp);
+
+   intel_dp_retrain_link(intel_dp);
}
 }
 
-- 
2.7.4

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


[Intel-gfx] [PATCH 0/2] drm/i915: Suppress underrun reporting around DP link retraining

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

This series should reduce the underrn spam in CI. I expect it won't eliminate 
it entirely
as we seem to have two classes of dmesg warns: from link retraining, and from 
normal
modesets. The second category will need more investigation, but one suspect 
might be
the audio enable sequence.

Ville Syrjälä (2):
  drm/i915: Extract intel_crtc_pch_transcoder()
  drm/i915: Suppress underruns during DP link retraining

 drivers/gpu/drm/i915/intel_display.c | 21 ++---
 drivers/gpu/drm/i915/intel_dp.c  | 29 +++--
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 42 insertions(+), 9 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: warning for Enable lspcon support for GEN9 devices (rev6)

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

Series: Enable lspcon support for GEN9 devices (rev6)
URL   : https://patchwork.freedesktop.org/series/8024/
State : warning

== Summary ==

Series 8024v6 Enable lspcon support for GEN9 devices
https://patchwork.freedesktop.org/api/1.0/series/8024/revisions/6/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test kms_busy:
Subgroup basic-flip-default-a:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-default-b:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-default-c:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> DMESG-WARN (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup hang-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-rte:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-skl-6770hq)
pass   -> SKIP   (fi-hsw-4770)
skip   -> PASS   (fi-skl-6700k)
skip   -> PASS   (fi-kbl-7200u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   

Re: [Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

2016-10-14 Thread Sharma, Shashank

Regards

Shashank


On 10/14/2016 8:02 PM, Jani Nikula wrote:

On Fri, 14 Oct 2016, Shashank Sharma  wrote:

Many GEN9 boards come with on-board lspcon cards.
Fot these boards, VBT configuration should properly point out
if a particular port contains lspcon device, so that driver can
initialize it properly.

This patch adds a utility function, which checks the VBT flag
for lspcon bit, and tells us if a port is configured to have a
lspcon device or not.

V2: Fixed review comments from Ville
- Do not forget PORT_D while checking lspcon for GEN9

V3: Addressed review comments from Rodrigo
- Create a HAS_LSPCON() macro for better use case handling.
- Do not dump warnings for non-gen-9 platforms, it will be noise.

V4: Rebase
V5: Rebase
V6: Pass dev_priv to HAS_LSPCON() macro

Signed-off-by: Shashank Sharma 
Reviewed-by: Rodrigo Vivi 

I was hoping you'd use the version I rebased and sent, put it first in
the series, and rebase the rest on that. The point is, this series has
taken so long that lspcon devices have proliferated all over the place,
and we'll be getting more and more bugs about them. If this patch was
first, with the debug logging, we could at least get that to 4.9, maybe
stable kernels, and we'd immediately know the reason. I think it'll be a
hard sell to get the whole series to 4.9 kernel.

BR,
Jani.

Jani,
The patch got its first r-b since a long time.
After that, it was waiting to be merged, for long time.

Recently, when Imre was asked to test the patches, and he found one 
issue specific to APL.
We were trying to fix a suspend-resume issue, which was fixed with the 
last patch.

Now this patch is ready to be merged, just waiting for Imre's r-b.

Third patch just gives information about if LSPCON is available or not, 
which is not a big help for anything as such.
So instead of changing the sequence, and confusing the reviewers, I 
thought it would be better to send the whole series and

get this merged as-it-is.

Regards
Shashank



---
  drivers/gpu/drm/i915/i915_drv.h   |  5 
  drivers/gpu/drm/i915/intel_bios.c | 49 +++
  2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b2..7bab2f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2864,6 +2864,8 @@ struct drm_i915_cmd_table {
  
  #define HAS_GMCH_DISPLAY(dev_priv) ((dev_priv)->info.has_gmch_display)
  
+#define HAS_LSPCON(dev_priv) (IS_GEN9(dev_priv))

+
  /* DPF == dynamic parity feature */
  #define HAS_L3_DPF(dev_priv) ((dev_priv)->info.has_l3_dpf)
  #define NUM_L3_SLICES(dev_priv) (IS_HSW_GT3(dev_priv) ? \
@@ -3631,6 +3633,9 @@ bool intel_bios_is_port_dp_dual_mode(struct 
drm_i915_private *dev_priv, enum por
  bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
  bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
+bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+   enum port port);
+
  
  /* intel_opregion.c */

  #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 83667e8..32e1def 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1763,3 +1763,52 @@ intel_bios_is_port_hpd_inverted(struct drm_i915_private 
*dev_priv,
  
  	return false;

  }
+
+/**
+ * intel_bios_is_lspcon_present - if LSPCON is attached on %port
+ * @dev_priv:  i915 device instance
+ * @port:  port to check
+ *
+ * Return true if LSPCON is present on this port
+ */
+bool
+intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+   enum port port)
+{
+   int i;
+
+   if (!HAS_LSPCON(dev_priv))
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   if (!dev_priv->vbt.child_dev[i].common.lspcon)
+   continue;
+
+   switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+   case DVO_PORT_DPA:
+   case DVO_PORT_HDMIA:
+   if (port == PORT_A)
+   return true;
+   break;
+   case DVO_PORT_DPB:
+   case DVO_PORT_HDMIB:
+   if (port == PORT_B)
+   return true;
+   break;
+   case DVO_PORT_DPC:
+   case DVO_PORT_HDMIC:
+   if (port == PORT_C)
+   return true;
+   break;
+   case DVO_PORT_DPD:
+   case DVO_PORT_HDMID:
+   if (port == PORT_D)
+   return true;
+   break;
+   default:
+  

[Intel-gfx] [PATCH] drm/i915: Simplify DP port limited color range bit platform checks

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

Instead of checking for everything not supporting the limited color
range bit in the DP port register, let's check for the one thing
that does have it (g4x).

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

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc03f61d94f1..2c73515d212b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1790,9 +1790,7 @@ static void intel_dp_prepare(struct intel_encoder 
*encoder,
trans_dp &= ~TRANS_DP_ENH_FRAMING;
I915_WRITE(TRANS_DP_CTL(crtc->pipe), trans_dp);
} else {
-   if (!HAS_PCH_SPLIT(dev_priv) && !IS_VALLEYVIEW(dev_priv) &&
-   !IS_CHERRYVIEW(dev_priv) &&
-   pipe_config->limited_color_range)
+   if (IS_G4X(dev_priv) && pipe_config->limited_color_range)
intel_dp->DP |= DP_COLOR_RANGE_16_235;
 
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
@@ -2514,8 +2512,7 @@ static void intel_dp_get_config(struct intel_encoder 
*encoder,
 
pipe_config->base.adjusted_mode.flags |= flags;
 
-   if (!HAS_PCH_SPLIT(dev_priv) && !IS_VALLEYVIEW(dev_priv) &&
-   !IS_CHERRYVIEW(dev_priv) && tmp & DP_COLOR_RANGE_16_235)
+   if (IS_G4X(dev_priv) && tmp & DP_COLOR_RANGE_16_235)
pipe_config->limited_color_range = true;
 
pipe_config->lane_count =
-- 
2.7.4

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix cxsr_latency_table reorg

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

Series: drm/i915: Fix cxsr_latency_table reorg
URL   : https://patchwork.freedesktop.org/series/13789/
State : warning

== Summary ==

Series 13789v1 drm/i915: Fix cxsr_latency_table reorg
https://patchwork.freedesktop.org/api/1.0/series/13789/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6700k)
pass   -> SKIP   (fi-hsw-4770)
skip   -> PASS   (fi-kbl-7200u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2723/

e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 
2016y-10m-14d-11h-43m-09s UTC integration manifest
a854fc9 drm/i915: Fix cxsr_latency_table reorg

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 05:03:39PM +0100, Chris Wilson wrote:
> > We could try to future proof more maybe like
> > sizeof(typeof(obj->base.size)), is typeof can be used like that?
> > Something similar for sg API if possible. But then again, it could
> > be better future proofing to be hardcoded like you wrote it. Yes I
> > think so.
> 
> I was just about to write it as obj->base.size, Let's compare!
> 
> #define overflows_type(x, T) \
>   (sizeof(x) < sizeof(T) && (x) > 1 << (sizeof(T) * BITS_PER_BYTE))

(sizeof(x) > sizeof(T) && ((x) >= 1 << (sizeof(T) * BITS_PER_BYTE)))
> 
>   if (overflows_type(size, obj->base.size)
> 
> or
> 
>   if (overflows_type(size, size_t))
> 
> I think obj->base.size looks better from the self-documentation standpoint.
> -Chris

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 04:49:33PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 16:18, Chris Wilson wrote:
> >In many places, we try to count pages using a 32 bit integer. That
> >implies if we are asked to create an object larger than 43bits, we will
> >subtly crash much later. Catch this on the boundary, and add a warning
> >to remind ourselves later on our exabyte systems.
> >
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_drv.h |  2 +-
> >  drivers/gpu/drm/i915/i915_gem.c | 14 --
> >  2 files changed, 13 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index fe875b27a6bf..43eb1a72f19e 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -3107,7 +3107,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
> >*obj);
> >  void i915_gem_object_init(struct drm_i915_gem_object *obj,
> >  const struct drm_i915_gem_object_ops *ops);
> >  struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> >-  size_t size);
> >+   u64 size);
> >  struct drm_i915_gem_object *i915_gem_object_create_from_data(
> > struct drm_device *dev, const void *data, size_t size);
> >  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
> > *file);
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index fe92e28ea0a8..0d1dc04302ec 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -4131,14 +4131,24 @@ static const struct drm_i915_gem_object_ops 
> >i915_gem_object_ops = {
> > .put_pages = i915_gem_object_put_pages_gtt,
> >  };
> >-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> >-  size_t size)
> >+struct drm_i915_gem_object *
> >+i915_gem_object_create(struct drm_device *dev, u64 size)
> >  {
> > struct drm_i915_gem_object *obj;
> > struct address_space *mapping;
> > gfp_t mask;
> > int ret;
> >+/* There is a prevalence of the assumption that we fit the object's
> >+ * page count inside a 32bit variable. Let's document this and catch
> >+ * if we ever need to fix it.
> >+ */
> >+if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
> >+return ERR_PTR(-E2BIG);
> >+
> >+if (sizeof(size_t) < sizeof(u64) && size > INT_MAX)
> >+return ERR_PTR(-E2BIG);
> >+
> 
> Shouldn't it be UINT_MAX in both cases?

I've spotted a few "int page_count = obj->size / PAGE_SIZE;" so we can't
trust ourselves at all!

> We could try to future proof more maybe like
> sizeof(typeof(obj->base.size)), is typeof can be used like that?
> Something similar for sg API if possible. But then again, it could
> be better future proofing to be hardcoded like you wrote it. Yes I
> think so.

I was just about to write it as obj->base.size, Let's compare!

#define overflows_type(x, T) \
(sizeof(x) < sizeof(T) && (x) > 1 << (sizeof(T) * BITS_PER_BYTE))

  if (overflows_type(size, obj->base.size)

or

  if (overflows_type(size, size_t))

I think obj->base.size looks better from the self-documentation standpoint.
-Chris

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 16:18, Chris Wilson wrote:

In many places, we try to count pages using a 32 bit integer. That
implies if we are asked to create an object larger than 43bits, we will
subtly crash much later. Catch this on the boundary, and add a warning
to remind ourselves later on our exabyte systems.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  2 +-
  drivers/gpu/drm/i915/i915_gem.c | 14 --
  2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b27a6bf..43eb1a72f19e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3107,7 +3107,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
*obj);
  void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
  struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size);
+  u64 size);
  struct drm_i915_gem_object *i915_gem_object_create_from_data(
struct drm_device *dev, const void *data, size_t size);
  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fe92e28ea0a8..0d1dc04302ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4131,14 +4131,24 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
  };
  
-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,

- size_t size)
+struct drm_i915_gem_object *
+i915_gem_object_create(struct drm_device *dev, u64 size)
  {
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
int ret;
  
+	/* There is a prevalence of the assumption that we fit the object's

+* page count inside a 32bit variable. Let's document this and catch
+* if we ever need to fix it.
+*/
+   if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
+   return ERR_PTR(-E2BIG);
+
+   if (sizeof(size_t) < sizeof(u64) && size > INT_MAX)
+   return ERR_PTR(-E2BIG);
+


Shouldn't it be UINT_MAX in both cases?

We could try to future proof more maybe like 
sizeof(typeof(obj->base.size)), is typeof can be used like that? 
Something similar for sg API if possible. But then again, it could be 
better future proofing to be hardcoded like you wrote it. Yes I think so.


Regards,

Tvrtko



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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 16:43, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 04:38:35PM +0100, Tvrtko Ursulin wrote:

On 14/10/2016 16:18, Chris Wilson wrote:

The scattergather list uses a 32bit size counter, we should avoid
exceeding it.

Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size")
Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0d1dc04302ec..858569419134 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
max_segment = swiotlb_max_size();
if (!max_segment)
-   max_segment = obj->base.size;
+   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (st == NULL)

I suppose it could be possible to get more that 4GiB of of contiguous pages.

sg_alloc_table_from_pages seems broken as well, for this, and more
so, for using longs and stuffing them into ints.

Noticed I was using unsigned long max_segment. Any complaints if I
change that to unsigned int as well?


Not from me, should be changed!

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 04:38:35PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 16:18, Chris Wilson wrote:
> >The scattergather list uses a 32bit size counter, we should avoid
> >exceeding it.
> >
> >Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment 
> >size")
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 0d1dc04302ec..858569419134 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct 
> >drm_i915_gem_object *obj)
> > max_segment = swiotlb_max_size();
> > if (!max_segment)
> >-max_segment = obj->base.size;
> >+max_segment = rounddown(UINT_MAX, PAGE_SIZE);
> > st = kmalloc(sizeof(*st), GFP_KERNEL);
> > if (st == NULL)
> 
> I suppose it could be possible to get more that 4GiB of of contiguous pages.
> 
> sg_alloc_table_from_pages seems broken as well, for this, and more
> so, for using longs and stuffing them into ints.

Noticed I was using unsigned long max_segment. Any complaints if I
change that to unsigned int as well?
-Chris

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 16:24, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 04:18:10PM +0100, Chris Wilson wrote:

In many places, we try to count pages using a 32 bit integer. That
implies if we are asked to create an object larger than 43bits, we will
subtly crash much later. Catch this on the boundary, and add a warning
to remind ourselves later on our exabyte systems.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  2 +-
  drivers/gpu/drm/i915/i915_gem.c | 14 --
  2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b27a6bf..43eb1a72f19e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3107,7 +3107,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
*obj);
  void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
  struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size);
+  u64 size);
  struct drm_i915_gem_object *i915_gem_object_create_from_data(
struct drm_device *dev, const void *data, size_t size);
  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fe92e28ea0a8..0d1dc04302ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4131,14 +4131,24 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
  };
  
-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,

- size_t size)
+struct drm_i915_gem_object *
+i915_gem_object_create(struct drm_device *dev, u64 size)
  {
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
int ret;
  
+	/* There is a prevalence of the assumption that we fit the object's

+* page count inside a 32bit variable. Let's document this and catch
+* if we ever need to fix it.
+*/
+   if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
+   return ERR_PTR(-E2BIG);
+
+   if (sizeof(size_t) < sizeof(u64) && size > INT_MAX)

What I was looking for here was SIZE_T_MAX. Any ideas?


Would (1ULL << (sizeof(size_t) * BITS_PER_BYTE)) - 1 work?

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 16:18, Chris Wilson wrote:

The scattergather list uses a 32bit size counter, we should avoid
exceeding it.

Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size")
Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0d1dc04302ec..858569419134 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
  
  	max_segment = swiotlb_max_size();

if (!max_segment)
-   max_segment = obj->base.size;
+   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
  
  	st = kmalloc(sizeof(*st), GFP_KERNEL);

if (st == NULL)


I suppose it could be possible to get more that 4GiB of of contiguous pages.

sg_alloc_table_from_pages seems broken as well, for this, and more so, 
for using longs and stuffing them into ints.


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 04:18:10PM +0100, Chris Wilson wrote:
> In many places, we try to count pages using a 32 bit integer. That
> implies if we are asked to create an object larger than 43bits, we will
> subtly crash much later. Catch this on the boundary, and add a warning
> to remind ourselves later on our exabyte systems.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/i915_gem.c | 14 --
>  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fe875b27a6bf..43eb1a72f19e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3107,7 +3107,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
> *obj);
>  void i915_gem_object_init(struct drm_i915_gem_object *obj,
>const struct drm_i915_gem_object_ops *ops);
>  struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> -   size_t size);
> +u64 size);
>  struct drm_i915_gem_object *i915_gem_object_create_from_data(
>   struct drm_device *dev, const void *data, size_t size);
>  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
> *file);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index fe92e28ea0a8..0d1dc04302ec 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4131,14 +4131,24 @@ static const struct drm_i915_gem_object_ops 
> i915_gem_object_ops = {
>   .put_pages = i915_gem_object_put_pages_gtt,
>  };
>  
> -struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> -   size_t size)
> +struct drm_i915_gem_object *
> +i915_gem_object_create(struct drm_device *dev, u64 size)
>  {
>   struct drm_i915_gem_object *obj;
>   struct address_space *mapping;
>   gfp_t mask;
>   int ret;
>  
> + /* There is a prevalence of the assumption that we fit the object's
> +  * page count inside a 32bit variable. Let's document this and catch
> +  * if we ever need to fix it.
> +  */
> + if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
> + return ERR_PTR(-E2BIG);
> +
> + if (sizeof(size_t) < sizeof(u64) && size > INT_MAX)

What I was looking for here was SIZE_T_MAX. Any ideas?
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for RFC drm/i915: Add a sunset clause to GPU hang logging

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

Series: RFC drm/i915: Add a sunset clause to GPU hang logging
URL   : https://patchwork.freedesktop.org/series/13788/
State : warning

== Summary ==

Series 13788v1 RFC drm/i915: Add a sunset clause to GPU hang logging
https://patchwork.freedesktop.org/api/1.0/series/13788/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-snb-2600)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-hsw-4770)
skip   -> PASS   (fi-kbl-7200u)
skip   -> PASS   (fi-skl-6700k)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

Results at /archive/results/CI_IGT_test/Patchwork_2722/

e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 
2016y-10m-14d-11h-43m-09s UTC integration manifest
5a74e57 RFC drm/i915: Add a sunset clause to GPU hang logging

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


[Intel-gfx] [PATCH 2/2] drm/i915: Limit the scattergather coalescing to 32bits

2016-10-14 Thread Chris Wilson
The scattergather list uses a 32bit size counter, we should avoid
exceeding it.

Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size")
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0d1dc04302ec..858569419134 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 
max_segment = swiotlb_max_size();
if (!max_segment)
-   max_segment = obj->base.size;
+   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (st == NULL)
-- 
2.9.3

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


[Intel-gfx] [PATCH 1/2] drm/i915: Document our internal limit on object size

2016-10-14 Thread Chris Wilson
In many places, we try to count pages using a 32 bit integer. That
implies if we are asked to create an object larger than 43bits, we will
subtly crash much later. Catch this on the boundary, and add a warning
to remind ourselves later on our exabyte systems.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 14 --
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b27a6bf..43eb1a72f19e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3107,7 +3107,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
*obj);
 void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
 struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size);
+  u64 size);
 struct drm_i915_gem_object *i915_gem_object_create_from_data(
struct drm_device *dev, const void *data, size_t size);
 void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fe92e28ea0a8..0d1dc04302ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4131,14 +4131,24 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
 };
 
-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size)
+struct drm_i915_gem_object *
+i915_gem_object_create(struct drm_device *dev, u64 size)
 {
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
int ret;
 
+   /* There is a prevalence of the assumption that we fit the object's
+* page count inside a 32bit variable. Let's document this and catch
+* if we ever need to fix it.
+*/
+   if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
+   return ERR_PTR(-E2BIG);
+
+   if (sizeof(size_t) < sizeof(u64) && size > INT_MAX)
+   return ERR_PTR(-E2BIG);
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
return ERR_PTR(-ENOMEM);
-- 
2.9.3

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Parse VBT data for lspcon

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

Series: drm/i915: Parse VBT data for lspcon
URL   : https://patchwork.freedesktop.org/series/13786/
State : warning

== Summary ==

Series 13786v1 drm/i915: Parse VBT data for lspcon
https://patchwork.freedesktop.org/api/1.0/series/13786/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-kbl-7200u)
skip   -> PASS   (fi-skl-6700k)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2721/

e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 
2016y-10m-14d-11h-43m-09s UTC integration manifest
1edb07a drm/i915: Parse VBT data for lspcon

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


[Intel-gfx] [PATCH igt] lib/igt_aux: Improve documentation for igt_system_suspend_autoresume()

2016-10-14 Thread Imre Deak
While at it fix the order of states for consistency.

Suggested by Daniel.

Cc: Daniel Vetter 
Signed-off-by: Imre Deak 
---
 lib/igt_aux.c | 21 -
 lib/igt_aux.h | 36 +++-
 2 files changed, 51 insertions(+), 6 deletions(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index f225c2f..421f6d4 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -628,8 +628,8 @@ void igt_cleanup_aperture_trashers(void)
 
 static const char *suspend_state_name[] = {
[SUSPEND_STATE_FREEZE] = "freeze",
-   [SUSPEND_STATE_MEM] = "mem",
[SUSPEND_STATE_STANDBY] = "standby",
+   [SUSPEND_STATE_MEM] = "mem",
[SUSPEND_STATE_DISK] = "disk",
 };
 
@@ -744,11 +744,22 @@ static uint32_t get_supported_suspend_states(int 
power_dir)
 
 /**
  * igt_system_suspend_autoresume:
+ * @state: an #igt_suspend_state, the target suspend state
+ * @test: an #igt_suspend_test, test point at which to complete the suspend
+ *   cycle
  *
- * Execute a system suspend (to idle, memory, disk) cycle optionally
- * completing the cycle at a given test point and automaically wake up again.
- * Waking up is either achieved using the RTC wake-up alarm for a full suspend
- * cycle or a kernel timer for a suspend test cycle.
+ * Execute a system suspend cycle targeting the given @state optionally
+ * completing the cycle at the given @test point and automaically wake up
+ * again. Waking up is either achieved using the RTC wake-up alarm for a full
+ * suspend cycle or a kernel timer for a suspend test cycle. The kernel timer
+ * delay for a test cycle can be configured by the suspend.pm_test_delay
+ * kernel parameter (5 sec by default).
+ *
+ * #SUSPEND_TEST_NONE specifies a full suspend cycle.
+ * The #SUSPEND_TEST_FREEZER..#SUSPEND_TEST_CORE test points can make it
+ * possible to collect error logs in case a full suspend cycle would prevent
+ * this by hanging the machine, or they can provide an idea of the faulty
+ * component by comparing fail/no-fail results at different test points.
  *
  * This is very handy for implementing any kind of suspend/resume test.
  */
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 39fd8ea..d30196b 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -116,15 +116,48 @@ void igt_cleanup_aperture_trashers(void);
 
 /* suspend/hibernate and auto-resume system */
 
+/**
+ *  igt_suspend_state:
+ *  @SUSPEND_STATE_FREEZE: suspend-to-idle target state, aka S0ix or freeze,
+ *first non-hibernation state
+ *  @SUSPEND_STATE_STANDBY: standby target state, aka S1, second
+ * non-hibernation state
+ *  @SUSPEND_STATE_MEM: suspend-to-mem target state aka S3, third
+ * non-hibernation state
+ *  @SUSPEND_STATE_DISK: suspend-to-disk target state, aka S4 or hibernation
+ *
+ *  Target suspend states used with igt_system_suspend_autoresume().
+ *  See /sys/power/state for the available states on a given machine.
+ */
 enum igt_suspend_state {
SUSPEND_STATE_FREEZE,
-   SUSPEND_STATE_MEM,
SUSPEND_STATE_STANDBY,
+   SUSPEND_STATE_MEM,
SUSPEND_STATE_DISK,
 
+   /*< private >*/
SUSPEND_STATE_NUM,
 };
 
+/**
+ * igt_suspend_test:
+ * @SUSPEND_TEST_NONE: no testing, perform a full suspend/resume cycle
+ * @SUSPEND_TEST_FREEZER: complete cycle after freezing all freezable threads
+ * @SUSPEND_TEST_DEVICES: complete cycle after the above step and suspending
+ *   devices (before calling the drivers' suspend late and
+ *   no_irq hooks). Platform and system devices are not
+ *   suspended here, see #SUSPEND_TEST_CORE.
+ * @SUSPEND_TEST_PLATFORM: complete cycle after all the above steps and calling
+ *the ACPI platform global control methods (applies
+ *only with /sys/power/disk set to platform)
+ * @SUSPEND_TEST_PROCESSORS: complete cycle after all the above steps and
+ *  disabling non-boot CPUs
+ * @SUSPEND_TEST_CORE: complete cycle after all the above steps and suspending
+ *platform and system devices
+ *
+ * Test points used with igt_system_suspend_autoresume(). Specifies if and 
where
+ * the suspend sequence is to be terminated.
+ */
 enum igt_suspend_test {
SUSPEND_TEST_NONE,
SUSPEND_TEST_FREEZER,
@@ -133,6 +166,7 @@ enum igt_suspend_test {
SUSPEND_TEST_PROCESSORS,
SUSPEND_TEST_CORE,
 
+   /*< private >*/
SUSPEND_TEST_NUM,
 };
 
-- 
2.5.0

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


Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 14:53, Chris Wilson wrote:
> >>>We do pass NORETRY | NOWARN for the higher order allocations, so it
> >>>shouldn't be as bad it seems?
> >>I don't know for sure without looking into the implementation
> >>details. But I assumed even with NORETRY it does some extra work to
> >>try and free up the space. And if it fails, and we ask for it again,
> >>it is just doing that extra work for nothing. Because within a
> >>single allocation it sounds unlikely that something would change so
> >>dramatically that it would start working.
> >iirc, NORETRY means abort after failure. In effect, it does
> >2 attempts from the freelist, a direct reclaim, and may then repeat
> >if the task's allowed set of nodes were concurrently changed.
> 
> Do you think it makes sense doing all that after it started failing,
> within our single get_pages allocation?

I was thinking about skipping the DIRECT_RECLAIM for high order, but it
seems like that is beneficial for THP, so I'm presuming it should also
be for ourselves. Trimming back max_order seems sensible, but I still
like the idea of taking advantage of contiguous pages where possible
(primarily these will be used for ringbuffers and shadow batches).
-Chris

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


Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 14:53, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 02:44:00PM +0100, Tvrtko Ursulin wrote:

On 14/10/2016 13:54, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote:

On 14/10/2016 13:18, Chris Wilson wrote:

+   gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
+   if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) {
+   /* 965gm cannot relocate objects above 4GiB. */
+   gfp &= ~__GFP_HIGHMEM;
+   gfp |= __GFP_DMA32;
+   }
+
+   do {
+   int order = min(fls(npages) - 1, max_order);

I still have reservations on going back to max_order when previous
chunks required an order decrease. Size of the object is unbound
since it is indirectly controlled by userspace, correct? How about
decreasing the max_order on every repeated order decrease, following
failed order allocation?

+   struct page *page;
+
+   do {
+   page = alloc_pages(gfp | (order ? QUIET : 0), order);
+   if (page)
+   break;
+   if (!order--)
+   goto err;

Like:
/* Limit future allocations as well */
max_order = order;


+   } while (1);

We do pass NORETRY | NOWARN for the higher order allocations, so it
shouldn't be as bad it seems?

I don't know for sure without looking into the implementation
details. But I assumed even with NORETRY it does some extra work to
try and free up the space. And if it fails, and we ask for it again,
it is just doing that extra work for nothing. Because within a
single allocation it sounds unlikely that something would change so
dramatically that it would start working.

iirc, NORETRY means abort after failure. In effect, it does
2 attempts from the freelist, a direct reclaim, and may then repeat
if the task's allowed set of nodes were concurrently changed.


Do you think it makes sense doing all that after it started failing, 
within our single get_pages allocation?


Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

2016-10-14 Thread Jani Nikula
On Fri, 14 Oct 2016, Shashank Sharma  wrote:
> Many GEN9 boards come with on-board lspcon cards.
> Fot these boards, VBT configuration should properly point out
> if a particular port contains lspcon device, so that driver can
> initialize it properly.
>
> This patch adds a utility function, which checks the VBT flag
> for lspcon bit, and tells us if a port is configured to have a
> lspcon device or not.
>
> V2: Fixed review comments from Ville
> - Do not forget PORT_D while checking lspcon for GEN9
>
> V3: Addressed review comments from Rodrigo
> - Create a HAS_LSPCON() macro for better use case handling.
> - Do not dump warnings for non-gen-9 platforms, it will be noise.
>
> V4: Rebase
> V5: Rebase
> V6: Pass dev_priv to HAS_LSPCON() macro
>
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Rodrigo Vivi 

I was hoping you'd use the version I rebased and sent, put it first in
the series, and rebase the rest on that. The point is, this series has
taken so long that lspcon devices have proliferated all over the place,
and we'll be getting more and more bugs about them. If this patch was
first, with the debug logging, we could at least get that to 4.9, maybe
stable kernels, and we'd immediately know the reason. I think it'll be a
hard sell to get the whole series to 4.9 kernel.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  5 
>  drivers/gpu/drm/i915/intel_bios.c | 49 
> +++
>  2 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fe875b2..7bab2f1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2864,6 +2864,8 @@ struct drm_i915_cmd_table {
>  
>  #define HAS_GMCH_DISPLAY(dev_priv) ((dev_priv)->info.has_gmch_display)
>  
> +#define HAS_LSPCON(dev_priv) (IS_GEN9(dev_priv))
> +
>  /* DPF == dynamic parity feature */
>  #define HAS_L3_DPF(dev_priv) ((dev_priv)->info.has_l3_dpf)
>  #define NUM_L3_SLICES(dev_priv) (IS_HSW_GT3(dev_priv) ? \
> @@ -3631,6 +3633,9 @@ bool intel_bios_is_port_dp_dual_mode(struct 
> drm_i915_private *dev_priv, enum por
>  bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
> *port);
>  bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
>enum port port);
> +bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
> + enum port port);
> +
>  
>  /* intel_opregion.c */
>  #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 83667e8..32e1def 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1763,3 +1763,52 @@ intel_bios_is_port_hpd_inverted(struct 
> drm_i915_private *dev_priv,
>  
>   return false;
>  }
> +
> +/**
> + * intel_bios_is_lspcon_present - if LSPCON is attached on %port
> + * @dev_priv:i915 device instance
> + * @port:port to check
> + *
> + * Return true if LSPCON is present on this port
> + */
> +bool
> +intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
> + enum port port)
> +{
> + int i;
> +
> + if (!HAS_LSPCON(dev_priv))
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + if (!dev_priv->vbt.child_dev[i].common.lspcon)
> + continue;
> +
> + switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
> + case DVO_PORT_DPA:
> + case DVO_PORT_HDMIA:
> + if (port == PORT_A)
> + return true;
> + break;
> + case DVO_PORT_DPB:
> + case DVO_PORT_HDMIB:
> + if (port == PORT_B)
> + return true;
> + break;
> + case DVO_PORT_DPC:
> + case DVO_PORT_HDMIC:
> + if (port == PORT_C)
> + return true;
> + break;
> + case DVO_PORT_DPD:
> + case DVO_PORT_HDMID:
> + if (port == PORT_D)
> + return true;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + return false;
> +}

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


[Intel-gfx] [PATCH v6 5/5] drm/i915: Add lspcon resume function

2016-10-14 Thread Shashank Sharma
As per the software design, we are driving lspcon in
PCON mode. But while resuming from suspend, lspcon can go
in LS mode (which is its default operating mode on power on)

This patch adds a resume function for lspcon, which makes sure
its operating in PCON mode, post resume.

V2: Address review comments from Imre
- move lspcon_resume call to encoder->reset()
- use early returns

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ++-
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_lspcon.c | 8 
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc03f61..25f4060 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4755,11 +4755,16 @@ static void intel_edp_panel_vdd_sanitize(struct 
intel_dp *intel_dp)
 void intel_dp_encoder_reset(struct drm_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+   struct intel_lspcon *lspcon = _dig_port->lspcon;
+   struct intel_dp *intel_dp = _dig_port->dp;
 
if (!HAS_DDI(dev_priv))
intel_dp->DP = I915_READ(intel_dp->output_reg);
 
+   if (IS_GEN9(dev_priv) && lspcon->active)
+   lspcon_resume(lspcon);
+
if (to_intel_encoder(encoder)->type != INTEL_OUTPUT_EDP)
return;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index abff78f..0d0de3a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1850,4 +1850,5 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
+void lspcon_resume(struct intel_lspcon *lspcon);
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 628ae6fb..d606f1a 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -89,6 +89,14 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
return true;
 }
 
+void lspcon_resume(struct intel_lspcon *lspcon)
+{
+   if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
+   DRM_ERROR("LSPCON resume failed\n");
+   else
+   DRM_DEBUG_KMS("LSPCON resume success\n");
+}
+
 bool lspcon_init(struct intel_digital_port *intel_dig_port)
 {
struct intel_dp *dp = _dig_port->dp;
-- 
1.9.1

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


[Intel-gfx] [PATCH v6 0/5] Enable lspcon support for GEN9 devices

2016-10-14 Thread Shashank Sharma
LSPCON is essentially a dp++->hdmi adapter with dual mode of operation.

These modes are:
- Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi
passive dongle, which steps up DP++ output to appropriate HDMI 1.4 signal.
This mode doesn't do any conversion at the protocol level.

- Protocol Converter mode: In PCON mode, this device acts as an
active DP++->HDMI 2.0 dongle, which converts the DP++ output to
compatible HDMI 2.0 output. In PCON mode, lspcon can support 4k@60
outputs, using DP HBR2 mode.

Many of Intel GEN9 devices come with in-built lspcon card
in motherboartd down mode. This patch series adds support for
lspcon devices in I915 driver.

While unit-testing this code, I was able to see a 4k@60 modeset with:
- BXT-T board
- Single HDMI 4k@60 display (ACER S)
- Ubuntu 14.04 desktop

V2: Worked on review comments from Ville
- In general, Ville suggested not to use the dual personality of
  DDI to drive lspcon, so this patch set drives it just as DP++ display.
  There is no separate detection for lspcon (hpd_pulse is good enough), and
  its being driven as a DP display with special initialization and EDID
  read sequence. To be able to do this, we driving lspcon in PCON mode only,
  where it can serve both HDMI1.3/HDMI1.4 sinks as well as 4k@60 capable
  HDMI 2.0 sinks. So compared to previous series, there is one patch less,
  as we have dropped lspcon detection patch.


V3: Addressed review comments from Rodrigo
Details available with respective patch.

V4: Addressed review comments from Ville
Details available with respective patch.

V5: Rebase, added a new patch for suspend/resume
V6: Rebase, addressed review comments from Imre

Shashank Sharma (5):
  drm: Helper for lspcon in drm_dp_dual_mode
  drm/i915: Add lspcon support for I915 driver
  drm/i915: Parse VBT data for lspcon
  drm/i915: Enable lspcon initialization
  drm/i915: Add lspcon resume function

 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 ++
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |   5 ++
 drivers/gpu/drm/i915/intel_bios.c |  49 +++
 drivers/gpu/drm/i915/intel_ddi.c  |  29 ++-
 drivers/gpu/drm/i915/intel_dp.c   |   7 +-
 drivers/gpu/drm/i915/intel_drv.h  |  10 +++
 drivers/gpu/drm/i915/intel_lspcon.c   | 136 ++
 include/drm/drm_dp_dual_mode_helper.h |  26 ++
 9 files changed, 364 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c

-- 
1.9.1

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


[Intel-gfx] [PATCH v6 1/5] drm: Helper for lspcon in drm_dp_dual_mode

2016-10-14 Thread Shashank Sharma
This patch adds lspcon support in dp_dual_mode helper.
lspcon is essentially a dp->hdmi dongle with dual personality.

LS mode: It works as a passive dongle, by level shifting DP++
signals to HDMI signals, in LS mode.
PCON mode: It works as a protocol converter active dongle
in pcon mode, by converting DP++ outputs to HDMI 2.0 outputs.

This patch adds support for lspcon detection and mode set
switch operations, as a dp dual mode dongle.

v2: Addressed review comments from Ville
- add adaptor id for lspcon devices (0x08), use it to identify lspcon
- change function names
  old: drm_lspcon_get_current_mode/drm_lspcon_change_mode
  new: drm_lspcon_get_mode/drm_lspcon_set_mode
- change drm_lspcon_get_mode type to int, to match
  drm_dp_dual_mode_get_tmds_output
- change 'err' to 'ret' to match the rest of the functions
- remove pointless typecasting during call to dual_mode_read
- fix the but while setting value of data, while writing lspcon mode
- fix indentation
- change mdelay(10) -> msleep(10)
- return ETIMEDOUT instead of EFAULT, when lspcon mode change times out
- Add an empty line to separate std regs macros and lspcon regs macros
  Indent bit definition

v3: Addressed review comments from Rodrigo
- change macro name from DP_DUAL_MODE_TYPE_LSPCON to
  DP_DUAL_MODE_TYPE_HAS_DPCD for better readability
- change macro name from DP_DUAL_MODE_LSPCON_MODE_PCON to
  DP_DUAL_MODE_LSPCON_MODE_PCON for better readability
- add comment for MCA specific offsets like 0x40 and 0x41
- remove DP_DUAL_MODE_REV_TYPE2 check while checking lspcon adapter id

v4: Addressed review comments from Ville
- Fixed indentation at few places
- s/current_mode/mode
- s/reqd_mode/mode
- remove unnecessary void* cast
- remove drm_edid.h from includes
- Add a comment for _HAS_DPCD
- Fix enum description, for lspcon_mode.

v5: Rebase
v6: Rebase

Signed-off-by: Shashank Sharma 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 ++
 include/drm/drm_dp_dual_mode_helper.h |  26 
 2 files changed, 129 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a7b2a75..a7aeb1e 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -148,6 +148,14 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
  DP_DUAL_MODE_REV_TYPE2);
 }
 
+bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
+   const uint8_t adaptor_id)
+{
+   return is_hdmi_adaptor(hdmi_id) &&
+   (adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
+DP_DUAL_MODE_TYPE_HAS_DPCD));
+}
+
 /**
  * drm_dp_dual_mode_detect - Identify the DP dual mode adaptor
  * @adapter: I2C adapter for the DDC bus
@@ -203,6 +211,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
_id, sizeof(adaptor_id));
if (ret == 0) {
+   if (is_lspcon_adaptor(hdmi_id, adaptor_id))
+   return DRM_DP_DUAL_MODE_LSPCON;
if (is_type2_adaptor(adaptor_id)) {
if (is_hdmi_adaptor(hdmi_id))
return DRM_DP_DUAL_MODE_TYPE2_HDMI;
@@ -364,3 +374,96 @@ const char *drm_dp_get_dual_mode_type_name(enum 
drm_dp_dual_mode_type type)
}
 }
 EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
+
+/**
+ * drm_lspcon_get_mode: Get LSPCON's current mode of operation by
+ * by reading offset (0x80, 0x41)
+ * @i2c_adapter: I2C-over-aux adapter
+ * @current_mode: out vaiable, current lspcon mode of operation
+ *
+ * Returns:
+ * 0 on success, sets the current_mode value to appropriate mode
+ * -error on failure
+ */
+int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+   enum drm_lspcon_mode *mode)
+{
+   u8 data;
+   int ret = 0;
+
+   if (!mode) {
+   DRM_ERROR("NULL input\n");
+   return -EINVAL;
+   }
+
+   /* Read Status: i2c over aux */
+   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
+   , sizeof(data));
+   if (ret < 0) {
+   DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+   return -EFAULT;
+   }
+
+   if (data & DP_DUAL_MODE_LSPCON_MODE_PCON)
+   *mode = DRM_LSPCON_MODE_PCON;
+   else
+   *mode = DRM_LSPCON_MODE_LS;
+   return 0;
+}
+EXPORT_SYMBOL(drm_lspcon_get_mode);
+
+/**
+ * drm_lspcon_change_mode: Change LSPCON's mode of operation by
+ * by writing offset (0x80, 0x40)
+ * @i2c_adapter: I2C-over-aux adapter
+ * @reqd_mode: required mode of operation
+ *
+ * Returns:
+ * 0 on success, -error on failure/timeout
+ */
+int drm_lspcon_set_mode(struct i2c_adapter *adapter,
+   enum 

[Intel-gfx] [PATCH v6 2/5] drm/i915: Add lspcon support for I915 driver

2016-10-14 Thread Shashank Sharma
This patch adds a new file, to accommodate lspcon support
for I915 driver. These functions probe, detect, initialize
and configure an on-board lspcon device during the driver
init time.

Also, this patch adds a small structure for lspcon device,
which will provide the runtime status of the device.

V2: addressed ville's review comments
- Clean the leftover macros from previous patch set

V3: Rebase
V4: addressed ville's review comments
- make internal functions static
- remove lspcon_detect_identifier, make it inline with lspcon_probe
- remove is_lspcon_active function
- remove force check while setting a lspcon mode

V5: Rebase
V6: Pass dev_priv to IS_GEN9 check

Signed-off-by: Shashank Sharma 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/intel_drv.h|   9 +++
 drivers/gpu/drm/i915/intel_lspcon.c | 128 
 3 files changed, 138 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8790ae4..6123400 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -101,6 +101,7 @@ i915-y += dvo_ch7017.o \
  intel_dvo.o \
  intel_hdmi.o \
  intel_i2c.o \
+ intel_lspcon.o \
  intel_lvds.o \
  intel_panel.o \
  intel_sdvo.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a885b2a..abff78f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -953,12 +953,19 @@ struct intel_dp {
bool compliance_test_active;
 };
 
+struct intel_lspcon {
+   bool active;
+   enum drm_lspcon_mode mode;
+   struct drm_dp_aux *aux;
+};
+
 struct intel_digital_port {
struct intel_encoder base;
enum port port;
u32 saved_port_bits;
struct intel_dp dp;
struct intel_hdmi hdmi;
+   struct intel_lspcon lspcon;
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
uint8_t max_lanes;
@@ -1841,4 +1848,6 @@ int intel_color_check(struct drm_crtc *crtc, struct 
drm_crtc_state *state);
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
 
+/* intel_lspcon.c */
+bool lspcon_init(struct intel_digital_port *intel_dig_port);
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
new file mode 100644
index 000..628ae6fb
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ *
+ */
+#include 
+#include 
+#include 
+#include "intel_drv.h"
+
+enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
+{
+   enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
+   struct i2c_adapter *adapter = >aux->ddc;
+
+   if (drm_lspcon_get_mode(adapter, _mode))
+   DRM_ERROR("Error reading LSPCON mode\n");
+   else
+   DRM_DEBUG_KMS("Current LSPCON mode %s\n",
+   current_mode == DRM_LSPCON_MODE_PCON ? "PCON" : "LS");
+   return current_mode;
+}
+
+static int lspcon_change_mode(struct intel_lspcon *lspcon,
+   enum drm_lspcon_mode mode, bool force)
+{
+   int err;
+   enum drm_lspcon_mode current_mode;
+   struct i2c_adapter *adapter = >aux->ddc;
+
+   err = drm_lspcon_get_mode(adapter, _mode);
+   if (err) {
+   DRM_ERROR("Error reading LSPCON mode\n");
+   return err;
+   }
+
+   if (current_mode == mode) {
+   DRM_DEBUG_KMS("Current mode = 

[Intel-gfx] [PATCH v6 4/5] drm/i915: Enable lspcon initialization

2016-10-14 Thread Shashank Sharma
This patch adds initialization code for lspcon.
What we are doing here is:
- Check if lspcon is configured in VBT for this port
- If lspcon is configured, initialize it and configure it
  as DP port.

V2: Addressed Ville's review comments:
- Not adding AVI IF functions for LSPCON display now.
  This part will be added once the dig_port level AVI-IF series
  gets merged.

V3: Rebase
V4: Rebase
V5: Rebase
V6: Rebase

Signed-off-by: Shashank Sharma 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a76afd7..7f7741c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2438,7 +2438,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
struct intel_digital_port *intel_dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
-   bool init_hdmi, init_dp;
+   bool init_hdmi, init_dp, init_lspcon = false;
int max_lanes;
 
if (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES) {
@@ -2470,6 +2470,19 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
init_hdmi = (dev_priv->vbt.ddi_port_info[port].supports_dvi ||
 dev_priv->vbt.ddi_port_info[port].supports_hdmi);
init_dp = dev_priv->vbt.ddi_port_info[port].supports_dp;
+
+   if (intel_bios_is_lspcon_present(dev_priv, port)) {
+   /*
+* Lspcon device needs to be driven with DP connector
+* with special detection sequence. So make sure DP
+* is initialized before lspcon.
+*/
+   init_dp = true;
+   init_lspcon = true;
+   init_hdmi = false;
+   DRM_DEBUG_KMS("VBT says port %c has lspcon\n", port_name(port));
+   }
+
if (!init_dp && !init_hdmi) {
DRM_DEBUG_KMS("VBT says port %c is not DVI/HDMI/DP compatible, 
respect it\n",
  port_name(port));
@@ -2546,6 +2559,20 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;
}
 
+   if (init_lspcon) {
+   if (lspcon_init(intel_dig_port))
+   /* TODO: handle hdmi info frame part */
+   DRM_DEBUG_KMS("LSPCON init success on port %c\n",
+   port_name(port));
+   else
+   /*
+* LSPCON init faied, but DP init was success, so
+* lets try to drive as DP++ port.
+*/
+   DRM_ERROR("LSPCON init failed on port %c\n",
+   port_name(port));
+   }
+
return;
 
 err:
-- 
1.9.1

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Emit telltales for extra levels of debug upon initialisation

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

Series: drm/i915: Emit telltales for extra levels of debug upon initialisation
URL   : https://patchwork.freedesktop.org/series/13785/
State : warning

== Summary ==

Series 13785v1 drm/i915: Emit telltales for extra levels of debug upon 
initialisation
https://patchwork.freedesktop.org/api/1.0/series/13785/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6700k)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2720/

e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 
2016y-10m-14d-11h-43m-09s UTC integration manifest
64736d0 drm/i915: Emit telltales for extra levels of debug upon initialisation

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


Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

2016-10-14 Thread Jani Nikula
On Fri, 14 Oct 2016, Tvrtko Ursulin  wrote:
> On 14/10/2016 14:31, Jani Nikula wrote:
>> On Thu, 13 Oct 2016, Tvrtko Ursulin  wrote:
>>> From: Tvrtko Ursulin 
>>>
>>> unsigned long is too wide - use smaller types in
>>> struct cxsr_latency to save 800-something bytes of .rodata.
>>>
>>> v2: All data even fits in u16 for even more saving. (Ville Syrjala)
>>> v3: Move bitfields to the end of the struct. (Joonas Lahtinen)
>>>
>>> Signed-off-by: Tvrtko Ursulin 
>>> Reviewed-by: Joonas Lahtinen 
>> Please learn how to run sparse, make it a habit to run it on your local
>> branches before submitting patches, and make it a rule to run it before
>> pushing patches. dim has helpers for this.
>
> Yeah I saw that you added dim sparse this week, however it only runs if 
> the dim tree is used for building it seems.
>
> I will try to figure out how to run in a separate build tree.

There was 'dim checker' before, and now also 'dim sparse'. Both do the
builds in the current directory, and do not cd to drm-intel directories,
so they can be used independent of other dim stuff.

In any case, running sparse is just a matter of having sparse in PATH,
and building using make C=1 or C=2. The former will run sparse on just
the files that need to be recompiled, the latter on everything. See also
'make help'. The helpers in dim first touch the the sources or rm the
object files, and run C=1.

>> The following is caused by this patch, fix or revert ASAP.
>
> Fix sent, you are on cc.

Thanks.

BR,
Jani.


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


[Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

2016-10-14 Thread Shashank Sharma
Many GEN9 boards come with on-board lspcon cards.
Fot these boards, VBT configuration should properly point out
if a particular port contains lspcon device, so that driver can
initialize it properly.

This patch adds a utility function, which checks the VBT flag
for lspcon bit, and tells us if a port is configured to have a
lspcon device or not.

V2: Fixed review comments from Ville
- Do not forget PORT_D while checking lspcon for GEN9

V3: Addressed review comments from Rodrigo
- Create a HAS_LSPCON() macro for better use case handling.
- Do not dump warnings for non-gen-9 platforms, it will be noise.

V4: Rebase
V5: Rebase
V6: Pass dev_priv to HAS_LSPCON() macro

Signed-off-by: Shashank Sharma 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h   |  5 
 drivers/gpu/drm/i915/intel_bios.c | 49 +++
 2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b2..7bab2f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2864,6 +2864,8 @@ struct drm_i915_cmd_table {
 
 #define HAS_GMCH_DISPLAY(dev_priv) ((dev_priv)->info.has_gmch_display)
 
+#define HAS_LSPCON(dev_priv) (IS_GEN9(dev_priv))
+
 /* DPF == dynamic parity feature */
 #define HAS_L3_DPF(dev_priv) ((dev_priv)->info.has_l3_dpf)
 #define NUM_L3_SLICES(dev_priv) (IS_HSW_GT3(dev_priv) ? \
@@ -3631,6 +3633,9 @@ bool intel_bios_is_port_dp_dual_mode(struct 
drm_i915_private *dev_priv, enum por
 bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
 bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
+bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+   enum port port);
+
 
 /* intel_opregion.c */
 #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 83667e8..32e1def 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1763,3 +1763,52 @@ intel_bios_is_port_hpd_inverted(struct drm_i915_private 
*dev_priv,
 
return false;
 }
+
+/**
+ * intel_bios_is_lspcon_present - if LSPCON is attached on %port
+ * @dev_priv:  i915 device instance
+ * @port:  port to check
+ *
+ * Return true if LSPCON is present on this port
+ */
+bool
+intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+   enum port port)
+{
+   int i;
+
+   if (!HAS_LSPCON(dev_priv))
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   if (!dev_priv->vbt.child_dev[i].common.lspcon)
+   continue;
+
+   switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+   case DVO_PORT_DPA:
+   case DVO_PORT_HDMIA:
+   if (port == PORT_A)
+   return true;
+   break;
+   case DVO_PORT_DPB:
+   case DVO_PORT_HDMIB:
+   if (port == PORT_B)
+   return true;
+   break;
+   case DVO_PORT_DPC:
+   case DVO_PORT_HDMIC:
+   if (port == PORT_C)
+   return true;
+   break;
+   case DVO_PORT_DPD:
+   case DVO_PORT_HDMID:
+   if (port == PORT_D)
+   return true;
+   break;
+   default:
+   break;
+   }
+   }
+
+   return false;
+}
-- 
1.9.1

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


Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 03:08:29PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 14:31, Jani Nikula wrote:
> >On Thu, 13 Oct 2016, Tvrtko Ursulin  wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>unsigned long is too wide - use smaller types in
> >>struct cxsr_latency to save 800-something bytes of .rodata.
> >>
> >>v2: All data even fits in u16 for even more saving. (Ville Syrjala)
> >>v3: Move bitfields to the end of the struct. (Joonas Lahtinen)
> >>
> >>Signed-off-by: Tvrtko Ursulin 
> >>Reviewed-by: Joonas Lahtinen 
> >Please learn how to run sparse, make it a habit to run it on your local
> >branches before submitting patches, and make it a rule to run it before
> >pushing patches. dim has helpers for this.
> 
> Yeah I saw that you added dim sparse this week, however it only runs
> if the dim tree is used for building it seems.
> 
> I will try to figure out how to run in a separate build tree.

apt-get install sparse
make C=1

Start fuming.
-Chris

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


Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 14:31, Jani Nikula wrote:

On Thu, 13 Oct 2016, Tvrtko Ursulin  wrote:

From: Tvrtko Ursulin 

unsigned long is too wide - use smaller types in
struct cxsr_latency to save 800-something bytes of .rodata.

v2: All data even fits in u16 for even more saving. (Ville Syrjala)
v3: Move bitfields to the end of the struct. (Joonas Lahtinen)

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen 

Please learn how to run sparse, make it a habit to run it on your local
branches before submitting patches, and make it a rule to run it before
pushing patches. dim has helpers for this.


Yeah I saw that you added dim sparse this week, however it only runs if 
the dim tree is used for building it seems.


I will try to figure out how to run in a separate build tree.


The following is caused by this patch, fix or revert ASAP.


Fix sent, you are on cc.

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH 14/41] drm/i915: Use a radixtree for random access to the object's backing storage

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 02:32:03PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 13:18, Chris Wilson wrote:
> >A while ago we switched from a contiguous array of pages into an sglist,
> >for that was both more convenient for mapping to hardware and avoided
> >the requirement for a vmalloc array of pages on every object. However,
> >certain GEM API calls (like pwrite, pread as well as performing
> >relocations) do desire access to individual struct pages. A quick hack
> >was to introduce a cache of the last access such that finding the
> >following page was quick - this works so long as the caller desired
> >sequential access. Walking backwards, or multiple callers, still hits a
> >slow linear search for each page. One solution is to store each
> >successful lookup in a radix tree.
> >
> >v2: Rewrite building the radixtree for clarity, hopefully.
> >
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_drv.h |  69 +---
> >  drivers/gpu/drm/i915/i915_gem.c | 179 
> > +---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c  |   4 +-
> >  drivers/gpu/drm/i915/i915_gem_userptr.c |   4 +-
> >  4 files changed, 193 insertions(+), 63 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index 38467dde1efe..53cf4b0e5359 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -2273,9 +2273,12 @@ struct drm_i915_gem_object {
> > struct sg_table *pages;
> > int pages_pin_count;
> >-struct get_page {
> >-struct scatterlist *sg;
> >-int last;
> >+struct i915_gem_object_page_iter {
> >+struct scatterlist *sg_pos;
> >+unsigned long sg_idx;
> 
> We are not consistent in the code with type used for number of pages
> in an object. sg_alloc_table even takes an unsigned int for it, so
> for as long as we build them as we do, unsigned long is a waste.

I know. It's worrying, today there is a possibility that we overflow a
32bit size. If this was counting in pages, we would have a few more
years of grace. All I can say is that we are fortunate that memory
remains expensive in the exabyte range.

> >@@ -4338,6 +4349,8 @@ void i915_gem_object_init(struct drm_i915_gem_object 
> >*obj,
> > obj->frontbuffer_ggtt_origin = ORIGIN_GTT;
> > obj->madv = I915_MADV_WILLNEED;
> >+INIT_RADIX_TREE(>get_page.radix, GFP_ATOMIC | __GFP_NOWARN);
> 
> Pros & cons of GFP_ATOMIC here? Versus perhaps going with the mutex?
> I don't know how much data radix tree allocates with this, per node,
> but we can have a lot of pages. Would this create extra pressure on
> slab shrinking, and in turn out objects?

The problem is that we require sg lookup on a !pagefault path, hence
mutexes and GFP_KERNEL turn out to be illegal. :|

> >+/* If we cannot allocate and insert this entry, or the
> >+ * individual pages from this range, cancel updating the
> >+ * sg_idx so that on this lookup we are forced to linearly
> >+ * scan onwards, but on future lookups we will try the
> >+ * insertion again (in which case we need to be careful of
> >+ * the error return reporting that we have already inserted
> >+ * this index).
> >+ */
> >+ret = radix_tree_insert(>radix, idx, sg);
> >+if (ret && ret != -EEXIST)
> >+goto scan;
> 
> What other error can we get here? Internal allocation failure?

Yes. ENOMEM is the only other error.
> 
> >+
> >+exception =
> >+RADIX_TREE_EXCEPTIONAL_ENTRY |
> >+idx << RADIX_TREE_EXCEPTIONAL_SHIFT;
> >+for (i = 1; i < count; i++) {
> >+ret = radix_tree_insert(>radix, idx + i,
> >+(void *)exception);
> >+if (ret && ret != -EEXIST)
> >+goto scan;
> >+}
> >+
> >+idx += count;
> >+sg = sg_next(sg);
> >+count = __sg_page_count(sg);
> >+}
> >+
> >+scan:
> >+iter->sg_pos = sg;
> >+iter->sg_idx = idx;
> >+
> >+spin_unlock(>lock);
> >+
> >+if (unlikely(n < idx)) /* insertion completed by another thread */
> >+goto lookup;
> >+
> >+/* In case we failed to insert the entry into the radixtree, we need
> >+ * to look beyond the current sg.
> >+ */
> >+while (idx + count <= n) {
> >+idx += count;
> >+sg = sg_next(sg);
> >+count = __sg_page_count(sg);
> >+}
> >+
> 
> Hmm... I assume failures happen then since you added this fallback.
> Due GFP_ATOMIC?

No, this was always in the code, because malloc failures happen. Quite
often if you run igt ;)
 
> >+*offset = n - idx;
> >+return sg;
> >+
> >+lookup:
> >+rcu_read_lock();
> >+
> 
> Property of 

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 02:44:00PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 13:54, Chris Wilson wrote:
> >On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote:
> >>On 14/10/2016 13:18, Chris Wilson wrote:
> >>>+  gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >>>+  if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) {
> >>>+  /* 965gm cannot relocate objects above 4GiB. */
> >>>+  gfp &= ~__GFP_HIGHMEM;
> >>>+  gfp |= __GFP_DMA32;
> >>>+  }
> >>>+
> >>>+  do {
> >>>+  int order = min(fls(npages) - 1, max_order);
> >>I still have reservations on going back to max_order when previous
> >>chunks required an order decrease. Size of the object is unbound
> >>since it is indirectly controlled by userspace, correct? How about
> >>decreasing the max_order on every repeated order decrease, following
> >>failed order allocation?
> >>>+  struct page *page;
> >>>+
> >>>+  do {
> >>>+  page = alloc_pages(gfp | (order ? QUIET : 0), order);
> >>>+  if (page)
> >>>+  break;
> >>>+  if (!order--)
> >>>+  goto err;
> >Like:
> > /* Limit future allocations as well */
> > max_order = order;
> >
> >>>+  } while (1);
> >We do pass NORETRY | NOWARN for the higher order allocations, so it
> >shouldn't be as bad it seems?
> 
> I don't know for sure without looking into the implementation
> details. But I assumed even with NORETRY it does some extra work to
> try and free up the space. And if it fails, and we ask for it again,
> it is just doing that extra work for nothing. Because within a
> single allocation it sounds unlikely that something would change so
> dramatically that it would start working.

iirc, NORETRY means abort after failure. In effect, it does
2 attempts from the freelist, a direct reclaim, and may then repeat
if the task's allowed set of nodes were concurrently changed.
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/41] drm/i915: Move user fault tracking to a separate list

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

Series: series starting with [01/41] drm/i915: Move user fault tracking to a 
separate list
URL   : https://patchwork.freedesktop.org/series/13780/
State : failure

== Summary ==

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

Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> INCOMPLETE (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6770hq)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-j1900)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6700k)
pass   -> SKIP   (fi-hsw-4770)
skip   -> PASS   (fi-kbl-7200u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:186  pass:158  dwarn:0   dfail:0   fail:0   skip:27 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2719/

e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 
2016y-10m-14d-11h-43m-09s UTC integration manifest
0f86ecc drm/i915: Support explicit fencing for execbuf
7f5162e drm/i915: Enable userspace to opt-out of implicit fencing
f55af4a drm/i915: Enable multiple timelines
cb6ef98 drm/i915: Defer setting of global seqno on request to submission
30dbfdb drm/i915: Reserve space in the global seqno during request allocation
087e6731 drm/i915: Create a unique name for the context
4e04f5b drm/i915: Move the global sync optimisation to the timeline
2f0449e drm/i915: Defer breadcrumb emission
520767f drm/i915: Record space required for breadcrumb emission
cc1329d drm/i915: Rename ->emit_request to ->emit_breadcrumb
baa6f9e drm/i915: Introduce a global_seqno for each request
8d1698c drm/i915: Wait first for submission, before waiting for request 
completion
2446a25 drm/i915: Queue the idling context switch after all other timelines
858b3b8 drm/i915: Combine seqno + tracking into a global timeline struct
1d25713 drm/i915: Restore nonblocking awaits for modesetting
ab14158 drm: Add reference counting to drm_atomic_state
3239c00 drm/i915: Move GEM activity tracking into a common struct 
reservation_object
8524932 drm/i915: Use lockless object free
6853309 drm/i915: Move object release to a freelist + worker
ee63ca2 drm/i915: Acquire the backing storage outside of struct_mutex in 
set-domain
278f458 drm/i915: Implement pwrite without struct-mutex
ea49a04 drm/i915: Implement pread without struct-mutex
b66f1a0 drm/i915/dmabuf: Acquire the backing storage outside of struct_mutex
40ea368 drm/i915: Move object backing storage manipulation to its own locking
bc1d4c4 drm/i915: Pass around sg_table to get_pages/put_pages backend
24732ba drm/i915: Refactor object page API
e0ba181 drm/i915: Use radixtree to jump start intel_partial_pages()
e4adaee drm/i915: Use a radixtree for random access to the object's backing 
storage
8521049 drm/i915: Markup GEM API with lockdep asserts
9463e56 drm/i915: Reuse the active golden render state batch
6733749 drm/i915: Introduce an internal allocator for disposable private objects
06562ad drm/i915: Defer active reference until required
aec8510 drm/i915: Remove unused i915_gem_active_wait() in favour of _unlocked()
e38de01 drm/i915: Rearrange i915_wait_request() accounting with callers
e6f3506 drm/i915: Allow i915_sw_fence_await_sw_fence() to allocate
70410d0 drm/i915: Support asynchronous waits on struct fence from 
i915_gem_request
e97c909 drm/i915: Move fence cancellation to runtime suspend
a2d18df drm/i915: Remove RPM sequence checking
2a155ae drm/i915: Remove superfluous locking around userfault_list

[Intel-gfx] [PATCH] drm/i915: Fix cxsr_latency_table reorg

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

I have re-ordered some struct members in patch:

  commit 44a655cae3043453f9dd8076538712d52e2e0ce4
  Author: Tvrtko Ursulin 
  Date:   Thu Oct 13 11:09:23 2016 +0100

  drm/i915: Shrink cxsr_latency_table

but that particular one is not initialized with named
initializers which broke it.

Move the bitfields back at the beginning. Space saving
is still there.

Signed-off-by: Tvrtko Ursulin 
Fixes: 44a655cae304 ("drm/i915: Shrink cxsr_latency_table")
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a885b2ac9618..5bc115496355 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -807,14 +807,14 @@ struct intel_watermark_params {
 };
 
 struct cxsr_latency {
+   bool is_desktop : 1;
+   bool is_ddr3 : 1;
u16 fsb_freq;
u16 mem_freq;
u16 display_sr;
u16 display_hpll_disable;
u16 cursor_sr;
u16 cursor_hpll_disable;
-   bool is_desktop : 1;
-   bool is_ddr3 : 1;
 };
 
 #define to_intel_atomic_state(x) container_of(x, struct intel_atomic_state, 
base)
-- 
2.7.4

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


Re: [Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver

2016-10-14 Thread Jani Nikula
On Fri, 14 Oct 2016, Ville Syrjälä  wrote:
> On Thu, Oct 13, 2016 at 02:38:30PM -0500, Pierre-Louis Bossart wrote:
>> Thanks Ville for the review. A lot of the comments are related to the 
>> initial VED code we took pretty much as is, no issues to clean-up further.
>> 
>> BTW, it looks like Jerome's patches were stuck for 10+ days on the 
>> intel-gfx server for some reason so not everyone saw the initial post?
>
> Did they make it to the list? Jani told me they didn't, nor were they in
> the moderation queue apparently. So no idea where they went. I tried
> bouncing them to the list, but I'm not sure they came through that time
> either.

The patches as bounced by Ville made it to the list, but the original
ones were lost and I have no idea what happened. They were not in
moderation and there was no trace of them.

BR,
Jani.



>
>> 
>> >> @@ -1141,7 +1141,13 @@ static void i915_driver_register(struct 
>> >> drm_i915_private *dev_priv)
>> >>   if (IS_GEN5(dev_priv))
>> >>   intel_gpu_ips_init(dev_priv);
>> >>
>> >> - i915_audio_component_init(dev_priv);
>> >> + if (intel_lpe_audio_detect(dev_priv)) {
>> >> + if (intel_lpe_audio_setup(dev_priv) < 0)
>> >> + DRM_ERROR("failed to setup LPE Audio bridge\n");
>> >> + }
>> >
>> > I'd move all that into the lpe audio code. No need to have anything here
>> > but a single function call IMO.
>> 
>> something like intel_lpe_audio_init() for symmetry with the hda 
>> component stuff, with both detection and setup handled internally?
>> >
>> >> +
>> >> + if (!IS_LPE_AUDIO_ENABLED(dev_priv))
>> >
>> > I don't like that too much. I think I would just make
>> > that HAS_LPE_AUDIO(). The current IS_VLV||IS_CHV check can just be
>> > inlined into the init function.
>> 
>> ok
>> 
>> 
>> >>
>> >>  #define HAS_POOLED_EU(dev)   (INTEL_INFO(dev)->has_pooled_eu)
>> >>
>> >> +#define HAS_LPE_AUDIO(dev)   (IS_VALLEYVIEW(dev) || 
>> >> IS_CHERRYVIEW(dev))
>> >> +#define IS_LPE_AUDIO_ENABLED(dev_priv) \
>> >> + (__I915__(dev_priv)->lpe_audio.platdev != NULL)
>> >> +#define IS_LPE_AUDIO_IRQ_VALID(dev_priv) \
>> >> + (__I915__(dev_priv)->lpe_audio.irq >= 0)
>> >
>> > Seems useless. We should just not register the lpe audio thing if we
>> > have no irq.
>> 
>> ok
>> 
>> >> --- a/drivers/gpu/drm/i915/i915_irq.c
>> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> >> @@ -1827,6 +1827,13 @@ static irqreturn_t valleyview_irq_handler(int irq, 
>> >> void *arg)
>> >>* signalled in iir */
>> >>   valleyview_pipestat_irq_ack(dev_priv, iir, pipe_stats);
>> >>
>> >> + if (IS_LPE_AUDIO_ENABLED(dev_priv))
>> >> + if (IS_LPE_AUDIO_IRQ_VALID(dev_priv))
>> >
>> > I think both of these checks can be removed. We won't unmask the
>> > interrupts unless lpe is enabled, so the IIR bits will never be set in
>> > that case.
>> >
>> >> + if (iir & (I915_LPE_PIPE_A_INTERRUPT |
>> >> + I915_LPE_PIPE_B_INTERRUPT |
>> >> + I915_LPE_PIPE_C_INTERRUPT))
>> >> + intel_lpe_audio_irq_handler(dev_priv);
>> >> +
>> 
>> ok.
>> 
>> >>   /*
>> >>* VLV_IIR is single buffered, and reflects the level
>> >>* from PIPESTAT/PORT_HOTPLUG_STAT, hence clear it last.
>> >> @@ -1907,6 +1914,13 @@ static irqreturn_t cherryview_irq_handler(int irq, 
>> >> void *arg)
>> >>* signalled in iir */
>> >>   valleyview_pipestat_irq_ack(dev_priv, iir, pipe_stats);
>> >>
>> >> + if (IS_LPE_AUDIO_ENABLED(dev_priv))
>> >> + if (IS_LPE_AUDIO_IRQ_VALID(dev_priv))
>> >> + if (iir & (I915_LPE_PIPE_A_INTERRUPT |
>> >> + I915_LPE_PIPE_B_INTERRUPT |
>> >> + I915_LPE_PIPE_C_INTERRUPT))
>> >> + intel_lpe_audio_irq_handler(dev_priv);
>> >> +
>> >
>> > ditto
>> 
>> ok
>> 
>> 
>> >> + platdev = platform_device_alloc("hdmi-lpe-audio", -1);
>> >> + if (!platdev) {
>> >> + ret = -ENOMEM;
>> >> + DRM_ERROR("Failed to allocate LPE audio platform device\n");
>> >> + goto err;
>> >> + }
>> >> +
>> >> + /* to work-around check_addr in nommu_map_sg() */
>> >
>> > What's this about?
>> 
>> Dunno, this was in the original VED series that we used as a baseline. 
>> Unless someone has memories from that time, i'll just remove this comment.
>> 
>> 
>> >> + DRM_DEBUG("%s: HDMI_AUDIO rsc.start[0] = 0x%x\n",
>> >> + __func__, (int)(rsc[0].start));
>> >
>> > __func__ pointless since DRM_DEBUG alreay adds it. Also saying
>> > "rsc.start[0]" in the message doesn't tell anyone anything useful.
>> > And I think irq numbers are usually printed in decimal.
>> 
>> Same, this was taken from the VED series, no issue to clean-up.
>> 
>> >
>> >> +
>> >> + rsc[1].start= 

[Intel-gfx] [PATCH] RFC drm/i915: Add a sunset clause to GPU hang logging

2016-10-14 Thread Chris Wilson
If the kernel is old, more than a few releases old, chances are that the
user is using an old kernel for a good reason, despite there being GPU
hangs. After 180days since driver release stop suggesting that they
should send those reports upstream.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0e82f04ac3d6..0719104ebdd5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -73,6 +73,7 @@
 #define DRIVER_NAME"i915"
 #define DRIVER_DESC"Intel Graphics"
 #define DRIVER_DATE"20161010"
+#define DRIVER_TIMESTAMP   1476452087
 
 #undef WARN_ON
 /* Many gcc seem to no see through this and fall over :( */
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2275a8d91539..e757783f935b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1551,6 +1551,8 @@ static int capture(void *data)
return 0;
 }
 
+#define DAY_AS_SECONDS(x) (24 * 60 * 60 * (x))
+
 /**
  * i915_capture_error_state - capture an error record for later analysis
  * @dev: drm device
@@ -1603,7 +1605,8 @@ void i915_capture_error_state(struct drm_i915_private 
*dev_priv,
return;
}
 
-   if (!warned) {
+   if (!warned &&
+   ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180)) {
DRM_INFO("GPU hangs can indicate a bug anywhere in the entire 
gfx stack, including userspace.\n");
DRM_INFO("Please file a _new_ bug report on 
bugs.freedesktop.org against DRI -> DRM/Intel\n");
DRM_INFO("drm/i915 developers can then reassign to the right 
component if it's not a kernel issue.\n");
-- 
2.9.3

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


Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 13:54, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote:

On 14/10/2016 13:18, Chris Wilson wrote:

+   gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
+   if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) {
+   /* 965gm cannot relocate objects above 4GiB. */
+   gfp &= ~__GFP_HIGHMEM;
+   gfp |= __GFP_DMA32;
+   }
+
+   do {
+   int order = min(fls(npages) - 1, max_order);

I still have reservations on going back to max_order when previous
chunks required an order decrease. Size of the object is unbound
since it is indirectly controlled by userspace, correct? How about
decreasing the max_order on every repeated order decrease, following
failed order allocation?

+   struct page *page;
+
+   do {
+   page = alloc_pages(gfp | (order ? QUIET : 0), order);
+   if (page)
+   break;
+   if (!order--)
+   goto err;

Like:
/* Limit future allocations as well */
max_order = order;


+   } while (1);

We do pass NORETRY | NOWARN for the higher order allocations, so it
shouldn't be as bad it seems?


I don't know for sure without looking into the implementation details. 
But I assumed even with NORETRY it does some extra work to try and free 
up the space. And if it fails, and we ask for it again, it is just doing 
that extra work for nothing. Because within a single allocation it 
sounds unlikely that something would change so dramatically that it 
would start working.


So yes, permanently limiting would sound safer to me.

Regards,

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

2016-10-14 Thread Sharma, Shashank
I was about to send another series to address Imre's patches. 
There I have addressed this problems. 

Please wait for some time, I will re-sync and send V6 for all patches. 

Even though I am not sure why it dint apply on nightly, as I did a git-pull few 
hours ago.  

Regards
Shashank 

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
Sent: Friday, October 14, 2016 7:10 PM
To: Patchwork ; Sharma, Shashank 

Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for 
GEN9 devices (rev5)

On Fri, 14 Oct 2016, Patchwork  wrote:
> == Series Details ==
>
> Series: Enable lspcon support for GEN9 devices (rev5)
> URL   : https://patchwork.freedesktop.org/series/8024/
> State : failure
>
> == Summary ==
>
>   LD  drivers/thermal/built-in.o
>   LD  drivers/iommu/built-in.o
>   LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
> In file included from drivers/gpu/drm/i915/intel_drv.h:32:0,
>  from drivers/gpu/drm/i915/intel_lspcon.c:28:
> drivers/gpu/drm/i915/intel_lspcon.c: In function ‘lspcon_resume’:
> drivers/gpu/drm/i915/i915_drv.h:2748:41: error: ‘struct drm_device’ has no 
> member named ‘info’
>  #define IS_GEN9(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(8)))
>  ^
> drivers/gpu/drm/i915/intel_lspcon.c:117:6: note: in expansion of macro 
> ‘IS_GEN9’
>   if (IS_GEN9(dev)) {
>   ^
> drivers/gpu/drm/i915/intel_lspcon.c: In function ‘lspcon_init’:
> drivers/gpu/drm/i915/i915_drv.h:2748:41: error: ‘struct drm_device’ has no 
> member named ‘info’
>  #define IS_GEN9(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(8)))
>  ^
> drivers/gpu/drm/i915/intel_lspcon.c:136:7: note: in expansion of macro 
> ‘IS_GEN9’
>   if (!IS_GEN9(dev)) {
>^

This conflicts with Tvrtko's recent changes to only accept dev_priv pointers in 
various macros.

I hope we can apply patch 3/5 first to add debug logging. I posted the rebased 
version of that [1].

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1476452135-31763-1-git-send-email-jani.nik...@intel.com


> scripts/Makefile.build:289: recipe for target 
> 'drivers/gpu/drm/i915/intel_lspcon.o' failed
> make[4]: *** [drivers/gpu/drm/i915/intel_lspcon.o] Error 1
> make[4]: *** Waiting for unfinished jobs
>   LD [M]  drivers/net/ethernet/intel/igb/igb.o
>   LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
>   LD  fs/btrfs/built-in.o
>   LD  drivers/tty/serial/8250/built-in.o
>   LD  drivers/tty/serial/built-in.o
>   LD  drivers/scsi/built-in.o
>   LD  drivers/tty/vt/built-in.o
>   LD  drivers/video/fbdev/core/fb.o
>   LD  drivers/tty/built-in.o
>   LD  drivers/video/fbdev/core/built-in.o
>   LD  drivers/video/fbdev/built-in.o
>   LD  drivers/video/built-in.o
>   LD  fs/ext4/ext4.o
>   LD  drivers/usb/core/usbcore.o
>   LD  drivers/usb/core/built-in.o
>   LD  net/core/built-in.o
>   LD  fs/ext4/built-in.o
>   LD  fs/built-in.o
>   AR  lib/lib.a
>   CC  arch/x86/kernel/cpu/capflags.o
>   LD  arch/x86/kernel/cpu/built-in.o
>   LD  arch/x86/kernel/built-in.o
>   LD  arch/x86/built-in.o
>   LD  drivers/usb/host/xhci-hcd.o
>   LD  drivers/usb/host/built-in.o
>   LD  drivers/usb/built-in.o
>   LD  net/ipv4/built-in.o
>   LD  net/built-in.o
>   LD  drivers/net/ethernet/built-in.o
>   LD  drivers/net/built-in.o
> scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' 
> failed
> make[3]: *** [drivers/gpu/drm/i915] Error 2
> scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:968: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>
> Full logs at /archive/deploy/logs/Patchwork_2717
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

2016-10-14 Thread Jani Nikula
On Fri, 14 Oct 2016, Patchwork  wrote:
> == Series Details ==
>
> Series: Enable lspcon support for GEN9 devices (rev5)
> URL   : https://patchwork.freedesktop.org/series/8024/
> State : failure
>
> == Summary ==
>
>   LD  drivers/thermal/built-in.o
>   LD  drivers/iommu/built-in.o
>   LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
> In file included from drivers/gpu/drm/i915/intel_drv.h:32:0,
>  from drivers/gpu/drm/i915/intel_lspcon.c:28:
> drivers/gpu/drm/i915/intel_lspcon.c: In function ‘lspcon_resume’:
> drivers/gpu/drm/i915/i915_drv.h:2748:41: error: ‘struct drm_device’ has no 
> member named ‘info’
>  #define IS_GEN9(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(8)))
>  ^
> drivers/gpu/drm/i915/intel_lspcon.c:117:6: note: in expansion of macro 
> ‘IS_GEN9’
>   if (IS_GEN9(dev)) {
>   ^
> drivers/gpu/drm/i915/intel_lspcon.c: In function ‘lspcon_init’:
> drivers/gpu/drm/i915/i915_drv.h:2748:41: error: ‘struct drm_device’ has no 
> member named ‘info’
>  #define IS_GEN9(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(8)))
>  ^
> drivers/gpu/drm/i915/intel_lspcon.c:136:7: note: in expansion of macro 
> ‘IS_GEN9’
>   if (!IS_GEN9(dev)) {
>^

This conflicts with Tvrtko's recent changes to only accept dev_priv
pointers in various macros.

I hope we can apply patch 3/5 first to add debug logging. I posted the
rebased version of that [1].

BR,
Jani.

[1] 
http://patchwork.freedesktop.org/patch/msgid/1476452135-31763-1-git-send-email-jani.nik...@intel.com


> scripts/Makefile.build:289: recipe for target 
> 'drivers/gpu/drm/i915/intel_lspcon.o' failed
> make[4]: *** [drivers/gpu/drm/i915/intel_lspcon.o] Error 1
> make[4]: *** Waiting for unfinished jobs
>   LD [M]  drivers/net/ethernet/intel/igb/igb.o
>   LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
>   LD  fs/btrfs/built-in.o
>   LD  drivers/tty/serial/8250/built-in.o
>   LD  drivers/tty/serial/built-in.o
>   LD  drivers/scsi/built-in.o
>   LD  drivers/tty/vt/built-in.o
>   LD  drivers/video/fbdev/core/fb.o
>   LD  drivers/tty/built-in.o
>   LD  drivers/video/fbdev/core/built-in.o
>   LD  drivers/video/fbdev/built-in.o
>   LD  drivers/video/built-in.o
>   LD  fs/ext4/ext4.o
>   LD  drivers/usb/core/usbcore.o
>   LD  drivers/usb/core/built-in.o
>   LD  net/core/built-in.o
>   LD  fs/ext4/built-in.o
>   LD  fs/built-in.o
>   AR  lib/lib.a
>   CC  arch/x86/kernel/cpu/capflags.o
>   LD  arch/x86/kernel/cpu/built-in.o
>   LD  arch/x86/kernel/built-in.o
>   LD  arch/x86/built-in.o
>   LD  drivers/usb/host/xhci-hcd.o
>   LD  drivers/usb/host/built-in.o
>   LD  drivers/usb/built-in.o
>   LD  net/ipv4/built-in.o
>   LD  net/built-in.o
>   LD  drivers/net/ethernet/built-in.o
>   LD  drivers/net/built-in.o
> scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed
> make[3]: *** [drivers/gpu/drm/i915] Error 2
> scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:968: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>
> Full logs at /archive/deploy/logs/Patchwork_2717
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 15/41] drm/i915: Use radixtree to jump start intel_partial_pages()

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 13:18, Chris Wilson wrote:

We can use the radixtree index of the obj->pages to find the start
position of the desired partial range.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 40 -
  1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2bbbda191e93..b3f341fe77bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3584,35 +3584,47 @@ intel_partial_pages(const struct i915_ggtt_view *view,
struct drm_i915_gem_object *obj)
  {
struct sg_table *st;
-   struct scatterlist *sg;
-   struct sg_page_iter obj_sg_iter;
+   struct scatterlist *sg, *iter;
+   unsigned int count = view->params.partial.size;
+   unsigned int offset;
int ret = -ENOMEM;
  
  	st = kmalloc(sizeof(*st), GFP_KERNEL);

if (!st)
goto err_st_alloc;
  
-	ret = sg_alloc_table(st, view->params.partial.size, GFP_KERNEL);

+   ret = sg_alloc_table(st, count, GFP_KERNEL);
if (ret)
goto err_sg_alloc;
  
+	iter = i915_gem_object_get_sg(obj,

+ view->params.partial.offset,
+ );
+   GEM_BUG_ON(!iter);
+
sg = st->sgl;
st->nents = 0;
-   for_each_sg_page(obj->pages->sgl, _sg_iter, obj->pages->nents,
-   view->params.partial.offset)
-   {
-   if (st->nents >= view->params.partial.size)
-   break;
+   do {
+   unsigned int len;
  
-		sg_set_page(sg, NULL, PAGE_SIZE, 0);

-   sg_dma_address(sg) = sg_page_iter_dma_address(_sg_iter);
-   sg_dma_len(sg) = PAGE_SIZE;
+   len = min(iter->length - (offset << PAGE_SHIFT),
+ count << PAGE_SHIFT);
+   sg_set_page(sg, NULL, len, 0);
+   sg_dma_address(sg) =
+   sg_dma_address(iter) + (offset << PAGE_SHIFT);
+   sg_dma_len(sg) = len;
  
-		sg = sg_next(sg);

st->nents++;
-   }
+   count -= len >> PAGE_SHIFT;
+   if (count == 0) {
+   sg_mark_end(sg);
+   return st;
+   }
  
-	return st;

+   sg = __sg_next(sg);
+   iter = __sg_next(iter);
+   offset = 0;
+   } while (1);
  
  err_sg_alloc:

kfree(st);


Looks OK and I trust you when you say it is faster.

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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


Re: [Intel-gfx] [PATCH] drm/i915: Parse VBT data for lspcon

2016-10-14 Thread Jani Nikula
On Fri, 14 Oct 2016, Jani Nikula  wrote:
> From: Shashank Sharma 
>
> Many GEN9 boards come with on-board lspcon cards.
> Fot these boards, VBT configuration should properly point out
> if a particular port contains lspcon device, so that driver can
> initialize it properly.
>
> This patch adds a utility function, which checks the VBT flag
> for lspcon bit, and tells us if a port is configured to have a
> lspcon device or not.
>
> While we do not enable any lspcon handling yet, debug log about ports
> with lspcon.
>
> V2: Fixed review comments from Ville
> - Do not forget PORT_D while checking lspcon for GEN9
>
> V3: Addressed review comments from Rodrigo
> - Create a HAS_LSPCON() macro for better use case handling.
> - Do not dump warnings for non-gen-9 platforms, it will be noise.
>
> V4: Rebase
> V5: Rebase
>
> v6 by Jani: rebase, debug log
>
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Rodrigo Vivi 
> Signed-off-by: Jani Nikula 
>
> ---
>
> Shashank, your series [1] didn't apply on nightly, so you'll need to
> rebase and post again anyway. However, please let's merge this patch
> from your series first, and we can even backport this so that we have
> debug logging about LSPCON devices.

[1] https://patchwork.freedesktop.org/series/8024/


>
> BR,
> Jani.
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  4 
>  drivers/gpu/drm/i915/intel_bios.c | 49 
> +++
>  drivers/gpu/drm/i915/intel_ddi.c  |  4 
>  3 files changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fe875b27a6bf..7c706a1ab7fe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2814,6 +2814,8 @@ struct drm_i915_cmd_table {
>  
>  #define HAS_DP_MST(dev)  (INTEL_INFO(dev)->has_dp_mst)
>  
> +#define HAS_LSPCON(dev_priv) (IS_GEN9(dev_priv))
> +
>  #define HAS_DDI(dev_priv)((dev_priv)->info.has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)  (INTEL_INFO(dev)->has_fpga_dbg)
>  #define HAS_PSR(dev) (INTEL_INFO(dev)->has_psr)
> @@ -3631,6 +3633,8 @@ bool intel_bios_is_port_dp_dual_mode(struct 
> drm_i915_private *dev_priv, enum por
>  bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
> *port);
>  bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
>enum port port);
> +bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
> +   enum port port);
>  
>  /* intel_opregion.c */
>  #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 83667e8cdd6b..6f49b2364b70 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1763,3 +1763,52 @@ intel_bios_is_port_hpd_inverted(struct 
> drm_i915_private *dev_priv,
>  
>   return false;
>  }
> +
> +/**
> + * intel_bios_is_lspcon_present - if LSPCON is attached on %port
> + * @dev_priv:i915 device instance
> + * @port:port to check
> + *
> + * Return true if LSPCON is present on this port
> + */
> +bool
> +intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
> +  enum port port)
> +{
> + int i;
> +
> + if (!HAS_LSPCON(dev_priv))
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + if (!dev_priv->vbt.child_dev[i].common.lspcon)
> + continue;
> +
> + switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
> + case DVO_PORT_DPA:
> + case DVO_PORT_HDMIA:
> + if (port == PORT_A)
> + return true;
> + break;
> + case DVO_PORT_DPB:
> + case DVO_PORT_HDMIB:
> + if (port == PORT_B)
> + return true;
> + break;
> + case DVO_PORT_DPC:
> + case DVO_PORT_HDMIC:
> + if (port == PORT_C)
> + return true;
> + break;
> + case DVO_PORT_DPD:
> + case DVO_PORT_HDMID:
> + if (port == PORT_D)
> + return true;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a76afd7a6616..adf731ac189b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2470,6 +2470,10 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> port)
>   init_hdmi = (dev_priv->vbt.ddi_port_info[port].supports_dvi ||
>

[Intel-gfx] [PATCH] drm/i915: Parse VBT data for lspcon

2016-10-14 Thread Jani Nikula
From: Shashank Sharma 

Many GEN9 boards come with on-board lspcon cards.
Fot these boards, VBT configuration should properly point out
if a particular port contains lspcon device, so that driver can
initialize it properly.

This patch adds a utility function, which checks the VBT flag
for lspcon bit, and tells us if a port is configured to have a
lspcon device or not.

While we do not enable any lspcon handling yet, debug log about ports
with lspcon.

V2: Fixed review comments from Ville
- Do not forget PORT_D while checking lspcon for GEN9

V3: Addressed review comments from Rodrigo
- Create a HAS_LSPCON() macro for better use case handling.
- Do not dump warnings for non-gen-9 platforms, it will be noise.

V4: Rebase
V5: Rebase

v6 by Jani: rebase, debug log

Signed-off-by: Shashank Sharma 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Jani Nikula 

---

Shashank, your series [1] didn't apply on nightly, so you'll need to
rebase and post again anyway. However, please let's merge this patch
from your series first, and we can even backport this so that we have
debug logging about LSPCON devices.

BR,
Jani.
---
 drivers/gpu/drm/i915/i915_drv.h   |  4 
 drivers/gpu/drm/i915/intel_bios.c | 49 +++
 drivers/gpu/drm/i915/intel_ddi.c  |  4 
 3 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b27a6bf..7c706a1ab7fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2814,6 +2814,8 @@ struct drm_i915_cmd_table {
 
 #define HAS_DP_MST(dev)(INTEL_INFO(dev)->has_dp_mst)
 
+#define HAS_LSPCON(dev_priv)   (IS_GEN9(dev_priv))
+
 #define HAS_DDI(dev_priv)  ((dev_priv)->info.has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
 #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
@@ -3631,6 +3633,8 @@ bool intel_bios_is_port_dp_dual_mode(struct 
drm_i915_private *dev_priv, enum por
 bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
 bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
+bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+ enum port port);
 
 /* intel_opregion.c */
 #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 83667e8cdd6b..6f49b2364b70 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1763,3 +1763,52 @@ intel_bios_is_port_hpd_inverted(struct drm_i915_private 
*dev_priv,
 
return false;
 }
+
+/**
+ * intel_bios_is_lspcon_present - if LSPCON is attached on %port
+ * @dev_priv:  i915 device instance
+ * @port:  port to check
+ *
+ * Return true if LSPCON is present on this port
+ */
+bool
+intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+enum port port)
+{
+   int i;
+
+   if (!HAS_LSPCON(dev_priv))
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   if (!dev_priv->vbt.child_dev[i].common.lspcon)
+   continue;
+
+   switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+   case DVO_PORT_DPA:
+   case DVO_PORT_HDMIA:
+   if (port == PORT_A)
+   return true;
+   break;
+   case DVO_PORT_DPB:
+   case DVO_PORT_HDMIB:
+   if (port == PORT_B)
+   return true;
+   break;
+   case DVO_PORT_DPC:
+   case DVO_PORT_HDMIC:
+   if (port == PORT_C)
+   return true;
+   break;
+   case DVO_PORT_DPD:
+   case DVO_PORT_HDMID:
+   if (port == PORT_D)
+   return true;
+   break;
+   default:
+   break;
+   }
+   }
+
+   return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a76afd7a6616..adf731ac189b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2470,6 +2470,10 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
init_hdmi = (dev_priv->vbt.ddi_port_info[port].supports_dvi ||
 dev_priv->vbt.ddi_port_info[port].supports_hdmi);
init_dp = dev_priv->vbt.ddi_port_info[port].supports_dp;
+
+   if (intel_bios_is_lspcon_present(dev_priv, port))
+   DRM_DEBUG_KMS("VBT says port %c has LSPCON\n", port_name(port));
+
if (!init_dp && !init_hdmi) {

Re: [Intel-gfx] [PATCH 14/41] drm/i915: Use a radixtree for random access to the object's backing storage

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 13:18, Chris Wilson wrote:

A while ago we switched from a contiguous array of pages into an sglist,
for that was both more convenient for mapping to hardware and avoided
the requirement for a vmalloc array of pages on every object. However,
certain GEM API calls (like pwrite, pread as well as performing
relocations) do desire access to individual struct pages. A quick hack
was to introduce a cache of the last access such that finding the
following page was quick - this works so long as the caller desired
sequential access. Walking backwards, or multiple callers, still hits a
slow linear search for each page. One solution is to store each
successful lookup in a radix tree.

v2: Rewrite building the radixtree for clarity, hopefully.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  69 +---
  drivers/gpu/drm/i915/i915_gem.c | 179 +---
  drivers/gpu/drm/i915/i915_gem_stolen.c  |   4 +-
  drivers/gpu/drm/i915/i915_gem_userptr.c |   4 +-
  4 files changed, 193 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38467dde1efe..53cf4b0e5359 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2273,9 +2273,12 @@ struct drm_i915_gem_object {
  
  	struct sg_table *pages;

int pages_pin_count;
-   struct get_page {
-   struct scatterlist *sg;
-   int last;
+   struct i915_gem_object_page_iter {
+   struct scatterlist *sg_pos;
+   unsigned long sg_idx;


We are not consistent in the code with type used for number of pages in 
an object. sg_alloc_table even takes an unsigned int for it, so for as 
long as we build them as we do, unsigned long is a waste.



+
+   struct radix_tree_root radix;
+   spinlock_t lock;
} get_page;
void *mapping;
  
@@ -2478,6 +2481,14 @@ static __always_inline struct sgt_iter {

return s;
  }
  
+static inline struct scatterlist *sg_next(struct scatterlist *sg)

+{
+   ++sg;
+   if (unlikely(sg_is_chain(sg)))
+   sg = sg_chain_ptr(sg);
+   return sg;
+}
+
  /**
   * __sg_next - return the next scatterlist entry in a list
   * @sg:   The current sg entry
@@ -2492,9 +2503,7 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
  #ifdef CONFIG_DEBUG_SG
BUG_ON(sg->sg_magic != SG_MAGIC);
  #endif
-   return sg_is_last(sg) ? NULL :
-   likely(!sg_is_chain(++sg)) ? sg :
-   sg_chain_ptr(sg);
+   return sg_is_last(sg) ? NULL : sg_next(sg);
  }
  
  /**

@@ -3170,45 +3179,21 @@ static inline int __sg_page_count(struct scatterlist 
*sg)
return sg->length >> PAGE_SHIFT;
  }
  
-struct page *

-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj, int n);
-
-static inline dma_addr_t
-i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj, int n)
-{
-   if (n < obj->get_page.last) {
-   obj->get_page.sg = obj->pages->sgl;
-   obj->get_page.last = 0;
-   }
-
-   while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
-   obj->get_page.last += __sg_page_count(obj->get_page.sg++);
-   if (unlikely(sg_is_chain(obj->get_page.sg)))
-   obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
-   }
-
-   return sg_dma_address(obj->get_page.sg) + ((n - obj->get_page.last) << 
PAGE_SHIFT);
-}
-
-static inline struct page *
-i915_gem_object_get_page(struct drm_i915_gem_object *obj, int n)
-{
-   if (WARN_ON(n >= obj->base.size >> PAGE_SHIFT))
-   return NULL;
+struct scatterlist *
+i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
+  unsigned long n, unsigned int *offset);
  
-	if (n < obj->get_page.last) {

-   obj->get_page.sg = obj->pages->sgl;
-   obj->get_page.last = 0;
-   }
+struct page *
+i915_gem_object_get_page(struct drm_i915_gem_object *obj,
+unsigned long n);
  
-	while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {

-   obj->get_page.last += __sg_page_count(obj->get_page.sg++);
-   if (unlikely(sg_is_chain(obj->get_page.sg)))
-   obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
-   }
+struct page *
+i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
+  unsigned long n);
  
-	return nth_page(sg_page(obj->get_page.sg), n - obj->get_page.last);

-}
+dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
+   unsigned long n);
  
  static inline void i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)

  {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 

Re: [Intel-gfx] [CI 1/4] drm/i915: Shrink cxsr_latency_table

2016-10-14 Thread Jani Nikula
On Thu, 13 Oct 2016, Tvrtko Ursulin  wrote:
> From: Tvrtko Ursulin 
>
> unsigned long is too wide - use smaller types in
> struct cxsr_latency to save 800-something bytes of .rodata.
>
> v2: All data even fits in u16 for even more saving. (Ville Syrjala)
> v3: Move bitfields to the end of the struct. (Joonas Lahtinen)
>
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: Joonas Lahtinen 

Please learn how to run sparse, make it a habit to run it on your local
branches before submitting patches, and make it a rule to run it before
pushing patches. dim has helpers for this.

The following is caused by this patch, fix or revert ASAP.

BR,
Jani.


  CHECK   drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/i915/intel_pm.c:218:39: warning: cast truncates bits from 
constant value (f8f becomes 1)
drivers/gpu/drm/i915/intel_pm.c:218:45: warning: cast truncates bits from 
constant value (84bf becomes 1)
drivers/gpu/drm/i915/intel_pm.c:219:39: warning: cast truncates bits from 
constant value (edf becomes 1)
drivers/gpu/drm/i915/intel_pm.c:219:45: warning: cast truncates bits from 
constant value (840f becomes 1)
drivers/gpu/drm/i915/intel_pm.c:220:39: warning: cast truncates bits from 
constant value (eb3 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:220:45: warning: cast truncates bits from 
constant value (83e3 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:221:39: warning: cast truncates bits from 
constant value (1ad9 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:221:45: warning: cast truncates bits from 
constant value (9009 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:222:39: warning: cast truncates bits from 
constant value (18ae becomes 0)
drivers/gpu/drm/i915/intel_pm.c:222:45: warning: cast truncates bits from 
constant value (8dde becomes 0)
drivers/gpu/drm/i915/intel_pm.c:224:39: warning: cast truncates bits from 
constant value (fb5 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:224:45: warning: cast truncates bits from 
constant value (84e5 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:225:39: warning: cast truncates bits from 
constant value (f05 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:225:45: warning: cast truncates bits from 
constant value (8435 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:226:39: warning: cast truncates bits from 
constant value (eee becomes 0)
drivers/gpu/drm/i915/intel_pm.c:226:45: warning: cast truncates bits from 
constant value (841e becomes 0)
drivers/gpu/drm/i915/intel_pm.c:227:39: warning: cast truncates bits from 
constant value (1aff becomes 1)
drivers/gpu/drm/i915/intel_pm.c:227:45: warning: cast truncates bits from 
constant value (902f becomes 1)
drivers/gpu/drm/i915/intel_pm.c:228:39: warning: cast truncates bits from 
constant value (18e9 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:228:45: warning: cast truncates bits from 
constant value (8e19 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:230:39: warning: cast truncates bits from 
constant value (104d becomes 1)
drivers/gpu/drm/i915/intel_pm.c:230:45: warning: cast truncates bits from 
constant value (857d becomes 1)
drivers/gpu/drm/i915/intel_pm.c:231:39: warning: cast truncates bits from 
constant value (f9c becomes 0)
drivers/gpu/drm/i915/intel_pm.c:231:45: warning: cast truncates bits from 
constant value (84cc becomes 0)
drivers/gpu/drm/i915/intel_pm.c:232:39: warning: cast truncates bits from 
constant value (f6a becomes 0)
drivers/gpu/drm/i915/intel_pm.c:232:45: warning: cast truncates bits from 
constant value (849a becomes 0)
drivers/gpu/drm/i915/intel_pm.c:233:39: warning: cast truncates bits from 
constant value (1b96 becomes 0)
drivers/gpu/drm/i915/intel_pm.c:233:45: warning: cast truncates bits from 
constant value (90c6 becomes 0)
drivers/gpu/drm/i915/intel_pm.c:234:39: warning: cast truncates bits from 
constant value (1965 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:234:45: warning: cast truncates bits from 
constant value (8e95 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:236:39: warning: cast truncates bits from 
constant value (fe1 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:236:45: warning: cast truncates bits from 
constant value (8511 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:237:39: warning: cast truncates bits from 
constant value (f31 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:237:45: warning: cast truncates bits from 
constant value (8461 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:238:39: warning: cast truncates bits from 
constant value (f05 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:238:45: warning: cast truncates bits from 
constant value (8435 becomes 1)
drivers/gpu/drm/i915/intel_pm.c:239:39: warning: cast truncates bits from 
constant value (1b2b becomes 1)
drivers/gpu/drm/i915/intel_pm.c:239:45: warning: cast truncates bits from 
constant value (905b becomes 1)
drivers/gpu/drm/i915/intel_pm.c:240:39: warning: cast truncates bits from 
constant value (1900 becomes 0)
drivers/gpu/drm/i915/intel_pm.c:240:45: 

[Intel-gfx] [PATCH] drm/i915: Emit telltales for extra levels of debug upon initialisation

2016-10-14 Thread Chris Wilson
After printing our welcome message to the user, also include
supplementary details on what debugging is enabled (useful for us to
sanity check what extra safeguards are on for any random kernel).

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

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 98fc6d3b2ca1..4df75e63cf22 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1241,6 +1241,10 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
 driver.name, driver.major, driver.minor, driver.patchlevel,
 driver.date, pci_name(pdev), dev_priv->drm.primary->index);
+   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
+   DRM_INFO("DRM_I915_DEBUG enabled\n");
+   if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+   DRM_INFO("DRM_I915_DEBUG_GEM enabled\n");
 
intel_runtime_pm_put(dev_priv);
 
-- 
2.9.3

___
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 [v2,1/5] drm/i915: Move user fault tracking to a separate list

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

Series: series starting with [v2,1/5] drm/i915: Move user fault tracking to a 
separate list
URL   : https://patchwork.freedesktop.org/series/13775/
State : success

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-kbl-7200u)
skip   -> PASS   (fi-skl-6700k)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2718/

e086610ff079f1bf1fe91d4ab175443590cacb8d drm-intel-nightly: 
2016y-10m-14d-11h-43m-09s UTC integration manifest
2ee5600 drm/i915: Move user fault tracking to a separate list

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


Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

2016-10-14 Thread Jani Nikula
On Fri, 14 Oct 2016, Petri Latvala  wrote:
> On Fri, Oct 14, 2016 at 02:50:49PM +0300, Jani Nikula wrote:
>> On Fri, 14 Oct 2016, Petri Latvala  wrote:
>> > On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote:
>> >> While at it, make debugfs_path point at the debugfs root, not
>> >> dri. This'll be handy in future work.
>> >> 
>> >> Signed-off-by: Jani Nikula 
>> >> ---
>> >>  tests/drm_lib.sh | 16 ++--
>> >>  1 file changed, 10 insertions(+), 6 deletions(-)
>> >> 
>> >> diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
>> >> index 113da4c7d645..87e3ad0ab547 100755
>> >> --- a/tests/drm_lib.sh
>> >> +++ b/tests/drm_lib.sh
>> >> @@ -41,18 +41,22 @@ do_or_die() {
>> >>   $@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit $IGT_EXIT_FAILURE)
>> >>  }
>> >>  
>> >> -if [ -d /debug/dri ] ; then
>> >> - debugfs_path=/debug/dri
>> >> +if [ -d /sys/kernel/debug ]; then
>> >> + debugfs_path=/sys/kernel/debug
>> >> +elif [ -d /debug ]; then
>> >> + debugfs_path=/debug
>> >> +else
>> >> + skip "debugfs not found"
>> >>  fi
>> >
>> > Would parsing the output of  `mount -t debugfs`  be an option?
>> 
>> I contemplated that, but decided that should be a separate change later
>> on. I can send a patch on top if you like.
>
>
> Yes, separate patch, but no hurry on that one. Another patch for
> making the same change in tools/intel_gpu_abrt would also be nice.
>
>
> The series is
>
> Reviewed-by: Petri Latvala 

Thanks, pushed.

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 1/4] drm/i915: Adding intel_panel_scale_none() helper function

2016-10-14 Thread Timo Aaltonen
On 14.08.2015 08:18, Zhang, Xiong Y wrote:
>> On Mon, Aug 10, 2015 at 06:23:19PM +, Rodrigo Vivi wrote:
>>> I believe this function could be added along with the next patch that
>>> is the first to use it...
>>> Or it would be good to have a good commit message explaining why this
>>> function is needed and what is be used for...
>>
>> Yes, please don't split up patches so much that you end up adding dead code
>> or dead structures - always try to have at least a minimal user for 
>> something.
>>
>> If you want to split things up really tiny then go the other way round:
>> First add the callers, then add the implementation. That way reviewers can
>> understand the big scope first and then dig into details. But this one here 
>> really
>> is small enough to just be squashed in.
>> -Daniel
>>
> [Zhang, Xiong Y] Thanks for teaching me how to handle this. I'll follow it in 
> the next version.
> thanks

Was there a second version that got submitted? I can't find it if so.


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


Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 13:18, Chris Wilson wrote:
> >+gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >+if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) {
> >+/* 965gm cannot relocate objects above 4GiB. */
> >+gfp &= ~__GFP_HIGHMEM;
> >+gfp |= __GFP_DMA32;
> >+}
> >+
> >+do {
> >+int order = min(fls(npages) - 1, max_order);
> 
> I still have reservations on going back to max_order when previous
> chunks required an order decrease. Size of the object is unbound
> since it is indirectly controlled by userspace, correct? How about
> decreasing the max_order on every repeated order decrease, following
> failed order allocation?

> >+struct page *page;
> >+
> >+do {
> >+page = alloc_pages(gfp | (order ? QUIET : 0), order);
> >+if (page)
> >+break;
> >+if (!order--)
> >+goto err;

Like:
/* Limit future allocations as well */
max_order = order;

> >+} while (1);

We do pass NORETRY | NOWARN for the higher order allocations, so it
shouldn't be as bad it seems?
-Chris

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


Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Tvrtko Ursulin


On 14/10/2016 13:18, Chris Wilson wrote:

Quite a few of our objects used for internal hardware programming do not
benefit from being swappable or from being zero initialised. As such
they do not benefit from using a shmemfs backing storage and since they
are internal and never directly exposed to the user, we do not need to
worry about providing a filp. For these we can use an
drm_i915_gem_object wrapper around a sg_table of plain struct page. They
are not swap backed and not automatically pinned. If they are reaped
by the shrinker, the pages are released and the contents discarded. For
the internal use case, this is fine as for example, ringbuffers are
pinned from being written by a request to be read by the hardware. Once
they are idle, they can be discarded entirely. As such they are a good
match for execlist ringbuffers and a small variety of other internal
objects.

In the first iteration, this is limited to the scratch batch buffers we
use (for command parsing and state initialisation).

v2: Allocate physically contiguous pages, where possible.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/i915_drv.h  |   5 +
  drivers/gpu/drm/i915/i915_gem_batch_pool.c   |  27 ++---
  drivers/gpu/drm/i915/i915_gem_internal.c | 164 +++
  drivers/gpu/drm/i915/i915_gem_render_state.c |   2 +-
  drivers/gpu/drm/i915/intel_engine_cs.c   |   2 +-
  drivers/gpu/drm/i915/intel_ringbuffer.c  |  14 ++-
  7 files changed, 191 insertions(+), 24 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/i915_gem_internal.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8790ae4fb171..efaf25b984af 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -35,6 +35,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_execbuffer.o \
  i915_gem_fence.o \
  i915_gem_gtt.o \
+ i915_gem_internal.o \
  i915_gem.o \
  i915_gem_render_state.o \
  i915_gem_request.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4c0c8ef6c084..38467dde1efe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3540,6 +3540,11 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
   u32 gtt_offset,
   u32 size);
  
+/* i915_gem_internal.c */

+struct drm_i915_gem_object *
+i915_gem_object_create_internal(struct drm_i915_private *dev_priv,
+   unsigned int size);
+
  /* i915_gem_shrinker.c */
  unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
  unsigned long target,
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index cb25cad3318c..aa4e1e043b4e 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -97,9 +97,9 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
size_t size)
  {
struct drm_i915_gem_object *obj = NULL;
-   struct drm_i915_gem_object *tmp, *next;
+   struct drm_i915_gem_object *tmp;
struct list_head *list;
-   int n;
+   int n, ret;
  
  	lockdep_assert_held(>engine->i915->drm.struct_mutex);
  
@@ -112,19 +112,12 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,

n = ARRAY_SIZE(pool->cache_list) - 1;
list = >cache_list[n];
  
-	list_for_each_entry_safe(tmp, next, list, batch_pool_link) {

+   list_for_each_entry(tmp, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
if (!i915_gem_active_is_idle(>last_read[pool->engine->id],
 >base.dev->struct_mutex))
break;
  
-		/* While we're looping, do some clean up */

-   if (tmp->madv == __I915_MADV_PURGED) {
-   list_del(>batch_pool_link);
-   i915_gem_object_put(tmp);
-   continue;
-   }
-
if (tmp->base.size >= size) {
obj = tmp;
break;
@@ -132,19 +125,15 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
}
  
  	if (obj == NULL) {

-   int ret;
-
-   obj = i915_gem_object_create(>engine->i915->drm, size);
+   obj = i915_gem_object_create_internal(pool->engine->i915, size);
if (IS_ERR(obj))
return obj;
-
-   ret = i915_gem_object_get_pages(obj);
-   if (ret)
-   return ERR_PTR(ret);
-
-   obj->madv = I915_MADV_DONTNEED;
}
  
+	ret = 

Re: [Intel-gfx] [PATCH v5 5/5] drm/i915: Add lspcon resume function

2016-10-14 Thread Sharma, Shashank

Regards

Shashak


On 10/14/2016 2:56 PM, Imre Deak wrote:

On pe, 2016-10-14 at 14:54 +0530, Shashank Sharma wrote:

As per the software design, we are driving lspcon in
PCON mode. But while resuming from suspend, lspcon can go
in LS mode (which is its default operating mode on power on)

This patch adds a resume function for lspcon, which makes sure
its operating in PCON mode, post resume.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_drv.c |  2 ++
  drivers/gpu/drm/i915/intel_drv.h|  1 +
  drivers/gpu/drm/i915/intel_lspcon.c | 38 +
  3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9b3bfc..d87281d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1574,6 +1574,8 @@ static int i915_drm_resume(struct drm_device *dev)
dev_priv->display.hpd_irq_setup(dev_priv);
spin_unlock_irq(_priv->irq_lock);
  
+	lspcon_resume(dev);

+

This should go to the encoder reset hook.

Oh, sorry, I forgot about this suggestion.
Will move it.

intel_dp_mst_resume(dev);
  
  	intel_display_resume(dev);

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 27837b0..e8760a4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1850,4 +1850,5 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state);
  
  /* intel_lspcon.c */

  bool lspcon_init(struct intel_digital_port *intel_dig_port);
+void lspcon_resume(struct drm_device *dev);
  #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index aa74b1f..ba660ecb 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -27,6 +27,29 @@
  #include
  #include "intel_drv.h"
  
+/*

+ * This function assumes only one LSPCON port on the device,
+ * and returns the first active LSPCON port.
+ */
+static struct intel_lspcon *find_active_lspcon(struct drm_device *dev)
+{
+   struct intel_lspcon *lspcon = NULL;
+   struct intel_encoder *intel_encoder;
+
+   for_each_intel_encoder(dev, intel_encoder) {
+   struct intel_digital_port *intel_dig_port;
+
+   intel_dig_port = enc_to_dig_port(_encoder->base);
+   lspcon = _dig_port->lspcon;
+   if (lspcon->active) {
+   DRM_DEBUG_KMS("LSPCON active : port %c\n",
+   port_name(intel_dig_port->port));
+   break;
+   }
+   }
+   return lspcon;
+}
+
  enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
  {
enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
@@ -89,6 +112,21 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
return true;
  }
  
+void lspcon_resume(struct drm_device *dev)

+{
+   if (IS_GEN9(dev)) {
+   struct intel_lspcon *lspcon = find_active_lspcon(dev);
+
+   if (lspcon) {
+   if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON,
+   true))
+   DRM_ERROR("LSPCON resume failed\n");
+   else
+   DRM_DEBUG_KMS("LSPCON resume success\n");
+   }
+   }
+}

Nitpick: you could reduce indentation above by using early returns.

Sure.
- Shashank




+
  bool lspcon_init(struct intel_digital_port *intel_dig_port)
  {
struct intel_dp *dp = _dig_port->dp;


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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

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

Series: Enable lspcon support for GEN9 devices (rev5)
URL   : https://patchwork.freedesktop.org/series/8024/
State : failure

== Summary ==

  LD  drivers/thermal/built-in.o
  LD  drivers/iommu/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
In file included from drivers/gpu/drm/i915/intel_drv.h:32:0,
 from drivers/gpu/drm/i915/intel_lspcon.c:28:
drivers/gpu/drm/i915/intel_lspcon.c: In function ‘lspcon_resume’:
drivers/gpu/drm/i915/i915_drv.h:2748:41: error: ‘struct drm_device’ has no 
member named ‘info’
 #define IS_GEN9(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(8)))
 ^
drivers/gpu/drm/i915/intel_lspcon.c:117:6: note: in expansion of macro ‘IS_GEN9’
  if (IS_GEN9(dev)) {
  ^
drivers/gpu/drm/i915/intel_lspcon.c: In function ‘lspcon_init’:
drivers/gpu/drm/i915/i915_drv.h:2748:41: error: ‘struct drm_device’ has no 
member named ‘info’
 #define IS_GEN9(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(8)))
 ^
drivers/gpu/drm/i915/intel_lspcon.c:136:7: note: in expansion of macro ‘IS_GEN9’
  if (!IS_GEN9(dev)) {
   ^
scripts/Makefile.build:289: recipe for target 
'drivers/gpu/drm/i915/intel_lspcon.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_lspcon.o] Error 1
make[4]: *** Waiting for unfinished jobs
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD  fs/btrfs/built-in.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/tty/serial/built-in.o
  LD  drivers/scsi/built-in.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/video/fbdev/core/fb.o
  LD  drivers/tty/built-in.o
  LD  drivers/video/fbdev/core/built-in.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/video/built-in.o
  LD  fs/ext4/ext4.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/usb/core/built-in.o
  LD  net/core/built-in.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  AR  lib/lib.a
  CC  arch/x86/kernel/cpu/capflags.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  arch/x86/kernel/built-in.o
  LD  arch/x86/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  net/ipv4/built-in.o
  LD  net/built-in.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:968: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/Patchwork_2717

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


Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

2016-10-14 Thread Petri Latvala
On Fri, Oct 14, 2016 at 02:50:49PM +0300, Jani Nikula wrote:
> On Fri, 14 Oct 2016, Petri Latvala  wrote:
> > On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote:
> >> While at it, make debugfs_path point at the debugfs root, not
> >> dri. This'll be handy in future work.
> >> 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  tests/drm_lib.sh | 16 ++--
> >>  1 file changed, 10 insertions(+), 6 deletions(-)
> >> 
> >> diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
> >> index 113da4c7d645..87e3ad0ab547 100755
> >> --- a/tests/drm_lib.sh
> >> +++ b/tests/drm_lib.sh
> >> @@ -41,18 +41,22 @@ do_or_die() {
> >>$@ > /dev/null 2>&1 || (echo "FAIL: $@ ($?)" && exit $IGT_EXIT_FAILURE)
> >>  }
> >>  
> >> -if [ -d /debug/dri ] ; then
> >> -  debugfs_path=/debug/dri
> >> +if [ -d /sys/kernel/debug ]; then
> >> +  debugfs_path=/sys/kernel/debug
> >> +elif [ -d /debug ]; then
> >> +  debugfs_path=/debug
> >> +else
> >> +  skip "debugfs not found"
> >>  fi
> >
> > Would parsing the output of  `mount -t debugfs`  be an option?
> 
> I contemplated that, but decided that should be a separate change later
> on. I can send a patch on top if you like.


Yes, separate patch, but no hurry on that one. Another patch for
making the same change in tools/intel_gpu_abrt would also be nice.


The series is

Reviewed-by: Petri Latvala 








> 
> BR,
> Jani.
> 
> >
> >
> > --
> > Petri Latvala
> >
> >
> >
> >>  
> >> -if [ -d /sys/kernel/debug/dri ] ; then
> >> -  debugfs_path=/sys/kernel/debug/dri
> >> +if [ ! -d $debugfs_path/dri ]; then
> >> +  skip "dri debugfs not found"
> >>  fi
> >>  
> >>  i915_dfs_path=x
> >>  for minor in `seq 0 16`; do
> >> -  if [ -f $debugfs_path/$minor/i915_error_state ] ; then
> >> -  i915_dfs_path=$debugfs_path/$minor
> >> +  if [ -f $debugfs_path/dri/$minor/i915_error_state ] ; then
> >> +  i915_dfs_path=$debugfs_path/dri/$minor
> >>break
> >>fi
> >>  done
> >> -- 
> >> 2.1.4
> >> 
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 36/41] drm/i915: Create a unique name for the context

2016-10-14 Thread Chris Wilson
This will be used for communicating issues with this context to
userspace, so we want to identify the parent process and the individual
context. Note that the name isn't quite unique, it makes the presumption
of there only being a single device fd per process.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 23 ++-
 3 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d62605a009f4..514c20d3e92b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -631,17 +631,10 @@ static void print_request(struct seq_file *m,
  struct drm_i915_gem_request *rq,
  const char *prefix)
 {
-   struct pid *pid = rq->ctx->pid;
-   struct task_struct *task;
-
-   rcu_read_lock();
-   task = pid ? pid_task(pid, PIDTYPE_PID) : NULL;
-   seq_printf(m, "%s%x [%x:%x] @ %d: %s [%d]\n", prefix,
+   seq_printf(m, "%s%x [%x:%x] @ %d: %s\n", prefix,
   rq->global_seqno, rq->ctx->hw_id, rq->fence.seqno,
   jiffies_to_msecs(jiffies - rq->emitted_jiffies),
-  task ? task->comm : "",
-  task ? task->pid : -1);
-   rcu_read_unlock();
+  rq->timeline->common->name);
 }
 
 static int i915_gem_request_info(struct seq_file *m, void *data)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4da7a53a30c..66b6decc97c6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -933,6 +933,7 @@ struct i915_gem_context {
struct drm_i915_file_private *file_priv;
struct i915_hw_ppgtt *ppgtt;
struct pid *pid;
+   const char *name;
 
struct i915_ctx_hang_stats hang_stats;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a2acb8bb5f34..d3118db244c4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -158,6 +158,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
__i915_gem_object_release_unless_active(ce->state->obj);
}
 
+   kfree(ctx->name);
put_pid(ctx->pid);
list_del(>link);
 
@@ -303,19 +304,28 @@ __create_hw_context(struct drm_device *dev,
}
 
/* Default context will never have a file_priv */
-   if (file_priv != NULL) {
+   ret = DEFAULT_CONTEXT_HANDLE;
+   if (file_priv) {
ret = idr_alloc(_priv->context_idr, ctx,
DEFAULT_CONTEXT_HANDLE, 0, GFP_KERNEL);
if (ret < 0)
goto err_out;
-   } else
-   ret = DEFAULT_CONTEXT_HANDLE;
+   }
+   ctx->user_handle = ret;
 
ctx->file_priv = file_priv;
-   if (file_priv)
+   if (file_priv) {
ctx->pid = get_task_pid(current, PIDTYPE_PID);
+   ctx->name = kasprintf(GFP_KERNEL, "%s[%d]/%x",
+ current->comm,
+ pid_nr(ctx->pid),
+ ctx->user_handle);
+   if (!ctx->name) {
+   ret = -ENOMEM;
+   goto err_pid;
+   }
+   }
 
-   ctx->user_handle = ret;
/* NB: Mark all slices as needing a remap so that when the context first
 * loads it will restore whatever remap state already exists. If there
 * is no remap info, it will be a NOP. */
@@ -329,6 +339,9 @@ __create_hw_context(struct drm_device *dev,
 
return ctx;
 
+err_pid:
+   put_pid(ctx->pid);
+   idr_remove(_priv->context_idr, ctx->user_handle);
 err_out:
context_close(ctx);
return ERR_PTR(ret);
-- 
2.9.3

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


[Intel-gfx] [PATCH 33/41] drm/i915: Record space required for breadcrumb emission

2016-10-14 Thread Chris Wilson
In the next patch, we will use deferred breadcrumb emission. That requires
reserving sufficient space in the ringbuffer to emit the breadcrumb, which
first requires us to know how large the breadcrumb is.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c |  1 +
 drivers/gpu/drm/i915/intel_lrc.c|  6 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 29 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
 4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5f1538b7f43c..af4827926d3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -434,6 +434,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 * away, e.g. because a GPU scheduler has deferred it.
 */
req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
+   GEM_BUG_ON(req->reserved_space < engine->emit_breadcrumb_sz);
 
if (i915.enable_execlists)
ret = intel_logical_ring_alloc_request_extras(req);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 57dba458f185..8229baebb2b3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1590,6 +1590,8 @@ static int gen8_emit_breadcrumb(struct 
drm_i915_gem_request *request)
return intel_logical_ring_advance(request);
 }
 
+static const int gen8_emit_breadcrumb_sz = 6 + WA_TAIL_DWORDS;
+
 static int gen8_emit_breadcrumb_render(struct drm_i915_gem_request *request)
 {
struct intel_ring *ring = request->ring;
@@ -1621,6 +1623,8 @@ static int gen8_emit_breadcrumb_render(struct 
drm_i915_gem_request *request)
return intel_logical_ring_advance(request);
 }
 
+static const int gen8_emit_breadcrumb_render_sz = 8 + WA_TAIL_DWORDS;
+
 static int gen8_init_rcs_context(struct drm_i915_gem_request *req)
 {
int ret;
@@ -1695,6 +1699,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs 
*engine)
engine->reset_hw = reset_common_ring;
engine->emit_flush = gen8_emit_flush;
engine->emit_breadcrumb = gen8_emit_breadcrumb;
+   engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_sz;
engine->submit_request = execlists_submit_request;
 
engine->irq_enable = gen8_logical_ring_enable_irq;
@@ -1817,6 +1822,7 @@ int logical_render_ring_init(struct intel_engine_cs 
*engine)
engine->init_context = gen8_init_rcs_context;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_breadcrumb = gen8_emit_breadcrumb_render;
+   engine->emit_breadcrumb_sz = gen8_emit_breadcrumb_render_sz;
 
ret = intel_engine_create_scratch(engine, 4096);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6a0c75c5833b..95f8b3b13351 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1350,6 +1350,8 @@ static int i9xx_emit_breadcrumb(struct 
drm_i915_gem_request *req)
return 0;
 }
 
+static const int i9xx_emit_breadcrumb_sz = 4;
+
 /**
  * gen6_sema_emit_breadcrumb - Update the semaphore mailbox registers
  *
@@ -1403,6 +1405,8 @@ static int gen8_render_emit_breadcrumb(struct 
drm_i915_gem_request *req)
return 0;
 }
 
+static const int gen8_render_emit_breadcrumb_sz = 8;
+
 /**
  * intel_ring_sync - sync the waiter to the signaller on seqno
  *
@@ -2640,8 +2644,21 @@ static void intel_ring_default_vfuncs(struct 
drm_i915_private *dev_priv,
engine->reset_hw = reset_ring_common;
 
engine->emit_breadcrumb = i9xx_emit_breadcrumb;
-   if (i915.semaphores)
+   engine->emit_breadcrumb_sz = i9xx_emit_breadcrumb_sz;
+   if (i915.semaphores) {
+   int num_rings;
+
engine->emit_breadcrumb = gen6_sema_emit_breadcrumb;
+
+   num_rings = hweight32(INTEL_INFO(dev_priv)->ring_mask) - 1;
+   if (INTEL_GEN(dev_priv) >= 8) {
+   engine->emit_breadcrumb_sz += num_rings * 6;
+   } else {
+   engine->emit_breadcrumb_sz += num_rings * 3;
+   if (num_rings & 1)
+   engine->emit_breadcrumb_sz++;
+   }
+   }
engine->submit_request = i9xx_submit_request;
 
if (INTEL_GEN(dev_priv) >= 8)
@@ -2669,9 +2686,17 @@ int intel_init_render_ring_buffer(struct intel_engine_cs 
*engine)
if (INTEL_GEN(dev_priv) >= 8) {
engine->init_context = intel_rcs_ctx_init;
engine->emit_breadcrumb = gen8_render_emit_breadcrumb;
+   engine->emit_breadcrumb_sz = gen8_render_emit_breadcrumb_sz;
engine->emit_flush = gen8_render_ring_flush;
-   if (i915.semaphores)
+   

[Intel-gfx] [PATCH 15/41] drm/i915: Use radixtree to jump start intel_partial_pages()

2016-10-14 Thread Chris Wilson
We can use the radixtree index of the obj->pages to find the start
position of the desired partial range.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 40 -
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2bbbda191e93..b3f341fe77bf 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3584,35 +3584,47 @@ intel_partial_pages(const struct i915_ggtt_view *view,
struct drm_i915_gem_object *obj)
 {
struct sg_table *st;
-   struct scatterlist *sg;
-   struct sg_page_iter obj_sg_iter;
+   struct scatterlist *sg, *iter;
+   unsigned int count = view->params.partial.size;
+   unsigned int offset;
int ret = -ENOMEM;
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
goto err_st_alloc;
 
-   ret = sg_alloc_table(st, view->params.partial.size, GFP_KERNEL);
+   ret = sg_alloc_table(st, count, GFP_KERNEL);
if (ret)
goto err_sg_alloc;
 
+   iter = i915_gem_object_get_sg(obj,
+ view->params.partial.offset,
+ );
+   GEM_BUG_ON(!iter);
+
sg = st->sgl;
st->nents = 0;
-   for_each_sg_page(obj->pages->sgl, _sg_iter, obj->pages->nents,
-   view->params.partial.offset)
-   {
-   if (st->nents >= view->params.partial.size)
-   break;
+   do {
+   unsigned int len;
 
-   sg_set_page(sg, NULL, PAGE_SIZE, 0);
-   sg_dma_address(sg) = sg_page_iter_dma_address(_sg_iter);
-   sg_dma_len(sg) = PAGE_SIZE;
+   len = min(iter->length - (offset << PAGE_SHIFT),
+ count << PAGE_SHIFT);
+   sg_set_page(sg, NULL, len, 0);
+   sg_dma_address(sg) =
+   sg_dma_address(iter) + (offset << PAGE_SHIFT);
+   sg_dma_len(sg) = len;
 
-   sg = sg_next(sg);
st->nents++;
-   }
+   count -= len >> PAGE_SHIFT;
+   if (count == 0) {
+   sg_mark_end(sg);
+   return st;
+   }
 
-   return st;
+   sg = __sg_next(sg);
+   iter = __sg_next(iter);
+   offset = 0;
+   } while (1);
 
 err_sg_alloc:
kfree(st);
-- 
2.9.3

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


[Intel-gfx] [PATCH 22/41] drm/i915: Acquire the backing storage outside of struct_mutex in set-domain

2016-10-14 Thread Chris Wilson
As we can locklessly (well struct_mutex-lessly) acquire the backing
storage, do so in set-domain-ioctl to reduce the contention on the
struct_mutex.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 99 +
 1 file changed, 61 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5d8052fbce17..f250d5bf0346 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1460,6 +1460,30 @@ write_origin(struct drm_i915_gem_object *obj, unsigned 
domain)
obj->frontbuffer_ggtt_origin : ORIGIN_CPU);
 }
 
+static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915;
+   struct list_head *list;
+   struct i915_vma *vma;
+
+   list_for_each_entry(vma, >vma_list, obj_link) {
+   if (!i915_vma_is_ggtt(vma))
+   continue;
+
+   if (i915_vma_is_active(vma))
+   continue;
+
+   if (!drm_mm_node_allocated(>node))
+   continue;
+
+   list_move_tail(>vm_link, >vm->inactive_list);
+   }
+
+   i915 = to_i915(obj->base.dev);
+   list = obj->bind_count ? >mm.bound_list : >mm.unbound_list;
+   list_move_tail(>global_list, list);
+}
+
 /**
  * Called when user space prepares to use an object with the CPU, either
  * through the mmap ioctl's mapping or a GTT mapping.
@@ -1475,7 +1499,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
uint32_t read_domains = args->read_domains;
uint32_t write_domain = args->write_domain;
-   int ret;
+   int err;
 
/* Only handle setting domains to types used by the CPU. */
if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
@@ -1495,33 +1519,48 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
 * We will repeat the flush holding the lock in the normal manner
 * to catch cases where we are gazumped.
 */
-   ret = i915_gem_object_wait(obj,
+   err = i915_gem_object_wait(obj,
   I915_WAIT_INTERRUPTIBLE |
   (write_domain ? I915_WAIT_ALL : 0),
   MAX_SCHEDULE_TIMEOUT,
   to_rps_client(file));
-   if (ret)
-   goto err;
+   if (err)
+   goto out_unlocked;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   goto err;
+   /* Flush and acquire obj->pages so that we are coherent through
+* direct access in memory with previous cached writes through
+* shmemfs and that our cache domain tracking remains valid.
+* For example, if the obj->filp was moved to swap without us
+* being notified and releasing the pages, we would mistakenly
+* continue to assume that the obj remained out of the CPU cached
+* domain.
+*/
+   err = i915_gem_object_pin_pages(obj);
+   if (err)
+   goto out_unlocked;
+
+   err = i915_mutex_lock_interruptible(dev);
+   if (err)
+   goto out_pages;
 
if (read_domains & I915_GEM_DOMAIN_GTT)
-   ret = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
+   err = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
else
-   ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
+   err = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
 
-   if (write_domain != 0)
-   intel_fb_obj_invalidate(obj, write_origin(obj, write_domain));
+   /* And bump the LRU for this access */
+   i915_gem_object_bump_inactive_ggtt(obj);
 
-   i915_gem_object_put(obj);
mutex_unlock(>struct_mutex);
-   return ret;
 
-err:
+   if (write_domain != 0)
+   intel_fb_obj_invalidate(obj, write_origin(obj, write_domain));
+
+out_pages:
+   i915_gem_object_unpin_pages(obj);
+out_unlocked:
i915_gem_object_put_unlocked(obj);
-   return ret;
+   return err;
 }
 
 /**
@@ -1742,6 +1781,10 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
if (ret)
goto err;
 
+   ret = i915_gem_object_pin_pages(obj);
+   if (ret)
+   goto err;
+
intel_runtime_pm_get(dev_priv);
 
ret = i915_mutex_lock_interruptible(dev);
@@ -1824,6 +1867,7 @@ err_unlock:
mutex_unlock(>struct_mutex);
 err_rpm:
intel_runtime_pm_put(dev_priv);
+   i915_gem_object_unpin_pages(obj);
 err:
switch (ret) {
case -EIO:
@@ -3281,24 +3325,6 @@ i915_gem_object_flush_cpu_write_domain(struct 
drm_i915_gem_object 

[Intel-gfx] [PATCH 23/41] drm/i915: Move object release to a freelist + worker

2016-10-14 Thread Chris Wilson
We want to hide the latency of releasing objects and their backing
storage from the submission, so we move the actual free to a worker.
This allows us to switch to struct_mutex freeing of the object in the
next patch.

Furthermore, if we know that the object we are dereferencing remains valid
for the duration of our access, we can forgo the usual synchronisation
barriers and atomic reference counting. To ensure this we defer freeing
an object til after an RCU grace period, such that any lookup of the
object within an RCU read critical section will remain valid until
after we exit that critical section. We also employ this delay for
rate-limiting the serialisation on reallocation - we have to slow down
object creation in order to prevent resource starvation (in particular,
files).

v2: Return early in i915_gem_tiling() ioctl to skip over superfluous
work on error.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  15 ++-
 drivers/gpu/drm/i915/i915_drv.c  |  19 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  44 +++-
 drivers/gpu/drm/i915/i915_gem.c  | 166 +--
 drivers/gpu/drm/i915/i915_gem_shrinker.c |  14 ++-
 drivers/gpu/drm/i915/i915_gem_tiling.c   |  21 ++--
 6 files changed, 202 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 118bd35f750c..27fd5370f0cc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4873,10 +4873,12 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_ring_test_irq_fops,
 #define DROP_BOUND 0x2
 #define DROP_RETIRE 0x4
 #define DROP_ACTIVE 0x8
-#define DROP_ALL (DROP_UNBOUND | \
- DROP_BOUND | \
- DROP_RETIRE | \
- DROP_ACTIVE)
+#define DROP_FREED 0x10
+#define DROP_ALL (DROP_UNBOUND | \
+ DROP_BOUND| \
+ DROP_RETIRE   | \
+ DROP_ACTIVE   | \
+ DROP_FREED)
 static int
 i915_drop_caches_get(void *data, u64 *val)
 {
@@ -4920,6 +4922,11 @@ i915_drop_caches_set(void *data, u64 val)
 unlock:
mutex_unlock(>struct_mutex);
 
+   if (val & DROP_FREED) {
+   synchronize_rcu();
+   flush_work(_priv->mm.free_work);
+   }
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5b72da6d45a2..c46f96d8bb38 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -537,14 +537,17 @@ static const struct vga_switcheroo_client_ops 
i915_switcheroo_ops = {
.can_switch = i915_switcheroo_can_switch,
 };
 
-static void i915_gem_fini(struct drm_device *dev)
+static void i915_gem_fini(struct drm_i915_private *dev_priv)
 {
-   mutex_lock(>struct_mutex);
-   i915_gem_cleanup_engines(dev);
-   i915_gem_context_fini(dev);
-   mutex_unlock(>struct_mutex);
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_gem_cleanup_engines(_priv->drm);
+   i915_gem_context_fini(_priv->drm);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   synchronize_rcu();
+   flush_work(_priv->mm.free_work);
 
-   WARN_ON(!list_empty(_i915(dev)->context_list));
+   WARN_ON(!list_empty(_priv->context_list));
 }
 
 static int i915_load_modeset_init(struct drm_device *dev)
@@ -619,7 +622,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 cleanup_gem:
if (i915_gem_suspend(dev))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
-   i915_gem_fini(dev);
+   i915_gem_fini(dev_priv);
 cleanup_irq:
intel_guc_fini(dev);
drm_irq_uninstall(dev);
@@ -1299,7 +1302,7 @@ void i915_driver_unload(struct drm_device *dev)
drain_workqueue(dev_priv->wq);
 
intel_guc_fini(dev);
-   i915_gem_fini(dev);
+   i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
 
intel_power_domains_fini(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e066284aace9..e2fe50b6b493 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1355,8 +1355,8 @@ struct i915_gem_mm {
struct list_head bound_list;
/**
 * List of objects which are not bound to the GTT (thus
-* are idle and not used by the GPU) but still have
-* (presumably uncached) pages still attached.
+* are idle and not used by the GPU). These objects may or may
+* not actually have any pages attached.
 */
struct list_head unbound_list;
 
@@ -1365,6 +1365,12 @@ struct i915_gem_mm {
 */
struct list_head userfault_list;
 
+   /**
+* List of objects which are pending destruction.
+*/
+   struct llist_head free_list;
+   struct work_struct free_work;
+
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* 

  1   2   >