Re: [Intel-gfx] [PATCH 8/9] drm/mediatek: Use drm_plane_helper_check_state()

2016-08-01 Thread CK Hu
On Tue, 2016-07-26 at 19:07 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
> 
> This also eliminates the double clipping the driver was doing
> in both check and commit phases). And it should fix src coordinate
> addr adjustement. Previously the driver was expecting negative dst
> coordinates after clipping, which is not going happen, so any clipping
> induced addr adjustment simply didn't happen. Neither did the driver
> respect any user configured src coordinates, so panning and such would
> have been totally broken. It should be all good now.
> 
> Cc: CK Hu 
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Ville Syrjälä 
> ---

Acked-by: CK Hu 

>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 72 
> +---
>  1 file changed, 20 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 3995765a90dc..5f2516fca079 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -30,15 +30,20 @@ static const u32 formats[] = {
>   DRM_FORMAT_RGB565,
>  };
>  
> -static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane, bool enable,
> -  dma_addr_t addr, struct drm_rect *dest)
> +static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane,
> +  dma_addr_t addr)
>  {
>   struct drm_plane *plane = _plane->base;
>   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
>   unsigned int pitch, format;
> - int x, y;
> + bool enable;
>  
> - if (WARN_ON(!plane->state || (enable && !plane->state->fb)))
> + if (WARN_ON(!plane->state))
> + return;
> +
> + enable = state->base.visible;
> +
> + if (WARN_ON(enable && !plane->state->fb))
>   return;
>  
>   if (plane->state->fb) {
> @@ -49,27 +54,17 @@ static void mtk_plane_enable(struct mtk_drm_plane 
> *mtk_plane, bool enable,
>   format = DRM_FORMAT_RGBA;
>   }
>  
> - x = plane->state->crtc_x;
> - y = plane->state->crtc_y;
> -
> - if (x < 0) {
> - addr -= x * 4;
> - x = 0;
> - }
> -
> - if (y < 0) {
> - addr -= y * pitch;
> - y = 0;
> - }
> + addr += (state->base.src.x1 >> 16) * 4;
> + addr += (state->base.src.y1 >> 16) * pitch;
>  
>   state->pending.enable = enable;
>   state->pending.pitch = pitch;
>   state->pending.format = format;
>   state->pending.addr = addr;
> - state->pending.x = x;
> - state->pending.y = y;
> - state->pending.width = dest->x2 - dest->x1;
> - state->pending.height = dest->y2 - dest->y1;
> + state->pending.x = state->base.dst.x1;
> + state->pending.y = state->base.dst.y1;
> + state->pending.width = drm_rect_width(>base.dst);
> + state->pending.height = drm_rect_height(>base.dst);
>   wmb(); /* Make sure the above parameters are set before update */
>   state->pending.dirty = true;
>  }
> @@ -134,20 +129,6 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>  {
>   struct drm_framebuffer *fb = state->fb;
>   struct drm_crtc_state *crtc_state;
> - bool visible;
> - struct drm_rect dest = {
> - .x1 = state->crtc_x,
> - .y1 = state->crtc_y,
> - .x2 = state->crtc_x + state->crtc_w,
> - .y2 = state->crtc_y + state->crtc_h,
> - };
> - struct drm_rect src = {
> - /* 16.16 fixed point */
> - .x1 = state->src_x,
> - .y1 = state->src_y,
> - .x2 = state->src_x + state->src_w,
> - .y2 = state->src_y + state->src_h,
> - };
>   struct drm_rect clip = { 0, };
>  
>   if (!fb)
> @@ -168,12 +149,10 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>   clip.x2 = crtc_state->mode.hdisplay;
>   clip.y2 = crtc_state->mode.vdisplay;
>  
> - return drm_plane_helper_check_update(plane, state->crtc, fb,
> -  , , ,
> -  state->rotation,
> -  DRM_PLANE_HELPER_NO_SCALING,
> -  DRM_PLANE_HELPER_NO_SCALING,
> -  true, true, );
> + return drm_plane_helper_check_state(state, ,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + true, true);
>  }
>  
>  static void mtk_plane_atomic_update(struct drm_plane *plane,
> @@ -184,24 +163,13 @@ static void 

Re: [Intel-gfx] [PATCH 8/9] drm/mediatek: Use drm_plane_helper_check_state()

2016-08-01 Thread Bibby Hsieh
On Tue, 2016-07-26 at 19:07 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
> 
> This also eliminates the double clipping the driver was doing
> in both check and commit phases). And it should fix src coordinate
> addr adjustement. Previously the driver was expecting negative dst
> coordinates after clipping, which is not going happen, so any clipping
> induced addr adjustment simply didn't happen. Neither did the driver
> respect any user configured src coordinates, so panning and such would
> have been totally broken. It should be all good now.
> 
> Cc: CK Hu 
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Ville Syrjälä 

This patch looks fine to me, thanks for your patch.

Reviewed-by: Bibby Hsieh 
Tested-by: Bibby Hsieh 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 72 
> +---
>  1 file changed, 20 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 3995765a90dc..5f2516fca079 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -30,15 +30,20 @@ static const u32 formats[] = {
>   DRM_FORMAT_RGB565,
>  };
>  
> -static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane, bool enable,
> -  dma_addr_t addr, struct drm_rect *dest)
> +static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane,
> +  dma_addr_t addr)
>  {
>   struct drm_plane *plane = _plane->base;
>   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
>   unsigned int pitch, format;
> - int x, y;
> + bool enable;
>  
> - if (WARN_ON(!plane->state || (enable && !plane->state->fb)))
> + if (WARN_ON(!plane->state))
> + return;
> +
> + enable = state->base.visible;
> +
> + if (WARN_ON(enable && !plane->state->fb))
>   return;
>  
>   if (plane->state->fb) {
> @@ -49,27 +54,17 @@ static void mtk_plane_enable(struct mtk_drm_plane 
> *mtk_plane, bool enable,
>   format = DRM_FORMAT_RGBA;
>   }
>  
> - x = plane->state->crtc_x;
> - y = plane->state->crtc_y;
> -
> - if (x < 0) {
> - addr -= x * 4;
> - x = 0;
> - }
> -
> - if (y < 0) {
> - addr -= y * pitch;
> - y = 0;
> - }
> + addr += (state->base.src.x1 >> 16) * 4;
> + addr += (state->base.src.y1 >> 16) * pitch;
>  
>   state->pending.enable = enable;
>   state->pending.pitch = pitch;
>   state->pending.format = format;
>   state->pending.addr = addr;
> - state->pending.x = x;
> - state->pending.y = y;
> - state->pending.width = dest->x2 - dest->x1;
> - state->pending.height = dest->y2 - dest->y1;
> + state->pending.x = state->base.dst.x1;
> + state->pending.y = state->base.dst.y1;
> + state->pending.width = drm_rect_width(>base.dst);
> + state->pending.height = drm_rect_height(>base.dst);
>   wmb(); /* Make sure the above parameters are set before update */
>   state->pending.dirty = true;
>  }
> @@ -134,20 +129,6 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>  {
>   struct drm_framebuffer *fb = state->fb;
>   struct drm_crtc_state *crtc_state;
> - bool visible;
> - struct drm_rect dest = {
> - .x1 = state->crtc_x,
> - .y1 = state->crtc_y,
> - .x2 = state->crtc_x + state->crtc_w,
> - .y2 = state->crtc_y + state->crtc_h,
> - };
> - struct drm_rect src = {
> - /* 16.16 fixed point */
> - .x1 = state->src_x,
> - .y1 = state->src_y,
> - .x2 = state->src_x + state->src_w,
> - .y2 = state->src_y + state->src_h,
> - };
>   struct drm_rect clip = { 0, };
>  
>   if (!fb)
> @@ -168,12 +149,10 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>   clip.x2 = crtc_state->mode.hdisplay;
>   clip.y2 = crtc_state->mode.vdisplay;
>  
> - return drm_plane_helper_check_update(plane, state->crtc, fb,
> -  , , ,
> -  state->rotation,
> -  DRM_PLANE_HELPER_NO_SCALING,
> -  DRM_PLANE_HELPER_NO_SCALING,
> -  true, true, );
> + return drm_plane_helper_check_state(state, ,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + true, true);
>  }
>  
>  

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: set proper N/M in modeset (rev2)

2016-08-01 Thread Patchwork
== Series Details ==

Series: drm/i915: set proper N/M in modeset (rev2)
URL   : https://patchwork.freedesktop.org/series/9857/
State : failure

== Summary ==

Series 9857v2 drm/i915: set proper N/M in modeset
http://patchwork.freedesktop.org/api/1.0/series/9857/revisions/2/mbox

Test gem_exec_gttfill:
Subgroup basic:
pass   -> SKIP   (fi-snb-i7-2600)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
fail   -> PASS   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (fi-hsw-i7-4770k)
pass   -> FAIL   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-hsw-i7-4770r)
fail   -> PASS   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)

fi-hsw-i7-4770k  total:207  pass:186  dwarn:0   dfail:0   fail:0   skip:20 
fi-kbl-qkkr  total:240  pass:181  dwarn:30  dfail:0   fail:2   skip:27 
fi-skl-i5-6260u  total:240  pass:224  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:240  pass:208  dwarn:0   dfail:0   fail:4   skip:28 
fi-snb-i7-2600   total:240  pass:197  dwarn:0   dfail:0   fail:0   skip:43 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:4   dfail:0   fail:1   skip:16 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:173  dwarn:1   dfail:0   fail:1   skip:65 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:198  dwarn:0   dfail:0   fail:1   skip:41 
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1660/

6f87e85 drm-intel-nightly: 2016y-08m-01d-14h-53m-17s UTC integration manifest
1608e48 drm/i915: set proper N/M in modeset

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


[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/16] drm/i915: Introduce i915_gem_active_wait_unlocked()

2016-08-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/16] drm/i915: Introduce 
i915_gem_active_wait_unlocked()
URL   : https://patchwork.freedesktop.org/series/10469/
State : failure

== Summary ==

Applying: drm/i915: Introduce i915_gem_active_wait_unlocked()
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_gem_request.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_gem_request.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_request.h
error: Failed to merge in the changes.
Patch failed at 0001 drm/i915: Introduce i915_gem_active_wait_unlocked()
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] [PATCH] drm/i915: set proper N/M in modeset

2016-08-01 Thread libin . yang
From: Libin Yang 

When modeset occurs and the LS_CLK is set to some
special values in DP mode, the N/M need to be set
manually if audio is playing.

The relationship of Maud and Naud is expressed in
the following equation:
Maud/Naud = 512 * fs / f_LS_Clk

Please refer VESA DisplayPort Standard spec for details.

Also, the patch applies
commit 7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset")
to APL platform.

Signed-off-by: Libin Yang 
---
 drivers/gpu/drm/i915/i915_reg.h|   6 ++
 drivers/gpu/drm/i915/intel_audio.c | 122 +++--
 2 files changed, 111 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8bfde75..2f9d00e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7351,6 +7351,12 @@ enum {
 #define _HSW_AUD_CONFIG_B  0x65100
 #define HSW_AUD_CFG(pipe)  _MMIO_PIPE(pipe, _HSW_AUD_CONFIG_A, 
_HSW_AUD_CONFIG_B)
 
+#define _HSW_AUD_M_CTS_ENABLE_A0x65028
+#define _HSW_AUD_M_CTS_ENABLE_B0x65128
+#define HSW_AUD_M_CTS_ENABLE(pipe) _MMIO_PIPE(pipe, 
_HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
+#define   AUD_M_CTS_M_VALUE_INDEX  (1 << 21)
+#define   AUD_M_CTS_M_PROG_ENABLE  (1 << 20)
+
 #define _HSW_AUD_MISC_CTRL_A   0x65010
 #define _HSW_AUD_MISC_CTRL_B   0x65110
 #define HSW_AUD_MISC_CTRL(pipe)_MMIO_PIPE(pipe, 
_HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 6700a7b..de55ecf 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -98,6 +98,22 @@ static const struct {
{ 192000, TMDS_297M, 20480, 247500 },
 };
 
+#define LC_540M 54
+#define LC_162M 162000
+static const struct {
+   int sample_rate;
+   int clock;
+   int n;
+   int m;
+} aud_nm[] = {
+   {48000, LC_540M, 5625, 256},
+   {44100, LC_540M, 9375, 392},
+   {32000, LC_540M, 16875, 512},
+   {48000, LC_162M, 3375, 512},
+   {44100, LC_162M, 5625, 784},
+   {32000, LC_162M, 10125, 1024},
+};
+
 /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
 static u32 audio_config_hdmi_pixel_clock(const struct drm_display_mode 
*adjusted_mode)
 {
@@ -121,20 +137,50 @@ static u32 audio_config_hdmi_pixel_clock(const struct 
drm_display_mode *adjusted
return hdmi_audio_clock[i].config;
 }
 
-static int audio_config_get_n(const struct drm_display_mode *mode, int rate)
+static int audio_config_get_n(struct intel_crtc *crtc,
+ const struct drm_display_mode *adjusted_mode,
+ int rate)
+{
+   int i;
+
+   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) {
+   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
+   if ((rate == aud_ncts[i].sample_rate) &&
+   (adjusted_mode->clock == aud_ncts[i].clock)) {
+   return aud_ncts[i].n;
+   }
+   }
+   }
+
+   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DP)) {
+   for (i = 0; i < ARRAY_SIZE(aud_nm); i++) {
+   if ((rate == aud_nm[i].sample_rate) &&
+   (crtc->config->port_clock == aud_nm[i].clock)) {
+   return aud_nm[i].n;
+   }
+   }
+   }
+   return 0;
+}
+
+static int audio_config_get_m(struct intel_crtc *crtc, int rate)
 {
int i;
 
-   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
-   if ((rate == aud_ncts[i].sample_rate) &&
-   (mode->clock == aud_ncts[i].clock)) {
-   return aud_ncts[i].n;
+   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DP)) {
+   for (i = 0; i < ARRAY_SIZE(aud_nm); i++) {
+   if ((rate == aud_nm[i].sample_rate) &&
+   (crtc->config->port_clock == aud_nm[i].clock)) {
+   return aud_nm[i].m;
+   }
}
}
+
return 0;
 }
 
-static uint32_t audio_config_setup_n_reg(int n, uint32_t val)
+static uint32_t audio_config_setup_n_reg(struct intel_crtc *crtc,
+int n, uint32_t val)
 {
int n_low, n_up;
uint32_t tmp = val;
@@ -145,17 +191,38 @@ static uint32_t audio_config_setup_n_reg(int n, uint32_t 
val)
tmp |= ((n_up << AUD_CONFIG_UPPER_N_SHIFT) |
(n_low << AUD_CONFIG_LOWER_N_SHIFT) |
AUD_CONFIG_N_PROG_ENABLE);
+   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_DP))
+   tmp |= AUD_CONFIG_N_VALUE_INDEX;
+   return tmp;
+}
+
+static uint32_t 

[Intel-gfx] Disable power management on i915

2016-08-01 Thread Sanchez, AdolfoX
Hello.

I would like to know what is the best way to disable power management on the 
GPU unit, the purpose is to avoid GPU power transitions to avoid voltage swings.

Additional information:
Platform: Bay Trail J1900
O.S: Linux Kernel 4.4

Any help would be appreciated.

Best Regards,
Adolfo Sanchez.

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


Re: [Intel-gfx] [PATCH 05/16] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 07:22:27PM +0100, Chris Wilson wrote:
> The principal motivation for this was to try and eliminate the
> struct_mutex from i915_gem_suspend - but we still need to hold the mutex
> current for the i915_gem_context_lost(). (The issue there is that there
> may be an indirect lockdep cycle between cpu_hotplug (i.e. suspend) and
> struct_mutex via the stop_machine().) For the moment, enabling last
> request tracking for the engine, allows us to do busyness checking and
> waiting without requiring the struct_mutex - which is useful in its own
> right.

Couple of mistakes here: stop-engines tweaking still from when this was
only aiming at making i915_gem_suspend() lockless (now broken out to a
separate patc) and more importantly, accessing
dev_priv->mm.interruptible not under any controlling lock. That takes
passing around bool interruptible and suddenly we have a bigger patch.
:|
-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 4/4] drm/i915: pdev cleanup

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 06:38:55PM +0300, David Weinehall wrote:
> In an effort to simplify things for a future push of dev_priv instead
> of dev wherever possible, always take pdev via dev_priv where
> feasible, eliminating the direct access from dev. Right now this
> only eliminates a few cases of dev, but it also obviates that we pass
> dev into a lot of functions where dev_priv would be the more obvious
> choice.
> 
> Signed-off-by: David Weinehall 
Reviewed-by: Chris Wilson 
-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 3/4] drm/i915: Consistent drm_minor use

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 06:38:54PM +0300, David Weinehall wrote:
> Use consistent naming for drm_minor, and always use kdev_to_drm_minor()
> to convert kdev to drm_minor.
> 
> Signed-off-by: David Weinehall 

I would have gone with struct drm_minor *minor, since there is no
confusion here (and dminor is a note ;)

Had you made kdev_to_drm_minor() typesafe (inline function) then I would
have classed it as an overall improvement and just grumbled about the
choice of name. As it stands, it doesn't make me feel the code is
substantially improved.
-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 v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences

2016-08-01 Thread Dave Gordon

On 01/08/16 14:54, Jani Nikula wrote:

On Fri, 22 Jul 2016, Dave Gordon  wrote:

The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (which could be confusing for
maintainers).

So this patch just provides and uses names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
submission options that the user can select (-1, 0, 1, 2
respectively).

This should produce identical code to the previous version!

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
 drivers/gpu/drm/i915/intel_guc.h   |  6 ++
 drivers/gpu/drm/i915/intel_guc_loader.c| 15 ---
 drivers/gpu/drm/i915/intel_lrc.c   |  6 +++---
 4 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 01c1c16..e564c976 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -971,7 +971,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
i915_guc_submission_disable(dev_priv);

-   if (!i915.enable_guc_submission)
+   if (i915.enable_guc_submission == GUC_SUBMISSION_DISABLED)
return 0; /* not enabled  */

if (guc->ctx_pool_obj)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743..52ecbba 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,6 +90,12 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };

+enum {
+   GUC_SUBMISSION_DEFAULT = -1,
+   GUC_SUBMISSION_DISABLED = 0,
+   GUC_SUBMISSION_PREFERRED,
+   GUC_SUBMISSION_MANDATORY
+};
 enum intel_guc_fw_status {
GUC_FIRMWARE_FAIL = -1,
GUC_FIRMWARE_NONE = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index b883efd..d8bd4cb 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -189,7 +189,7 @@ static void set_guc_init_params(struct drm_i915_private 
*dev_priv)
}

/* If GuC submission is enabled, set up additional parameters here */
-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
u32 pgs = i915_gem_obj_ggtt_offset(dev_priv->guc.ctx_pool_obj);
u32 ctx_in_16 = GUC_MAX_GPU_CONTEXTS / 16;

@@ -495,7 +495,7 @@ int intel_guc_setup(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));

-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
err = i915_guc_submission_enable(dev_priv);
if (err)
goto fail;
@@ -523,7 +523,7 @@ int intel_guc_setup(struct drm_device *dev)
 */
if (i915.enable_guc_loading > 1) {
ret = -EIO;
-   } else if (i915.enable_guc_submission > 1) {
+   } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {


I like the patches in general, but now these >= and <= seem rather out
of place. How about using == and != exclusively?

BR,
Jani.


That would leave us with undefined behaviour for values outside the 
recognised range. This way it clips out-of-range values to the nearest 
extremum. Of course we could make it fail completely for invalid values, 
but that's just really annoying for the developer or admin who's 
mistyped -1 as -2 or forgotten what the maximum supported value is in 
this release. Alternatively we could convert all out-of-range values to 
"system default" i.e. ignored, which might still be annoying but not 
quite as much.


Any other suggestions for how to handle out-of-range values?

But if we were changing the policy shouldn't that be a separate patch? 
This patch is supposed to change only the way the code is written, with 
no effect to existing behaviour!


.Dave.


ret = -EIO;
} else {
ret = 0;
@@ -538,7 +538,7 @@ int intel_guc_setup(struct drm_device *dev)
else
DRM_ERROR("GuC firmware load failed: %d\n", err);

-   if (i915.enable_guc_submission) {
+   if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
@@ -546,7 +546,7 @@ int intel_guc_setup(struct drm_device *dev)
else

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Consistent struct device naming

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 06:38:53PM +0300, David Weinehall wrote:
> We currently have a mix of struct device *device, struct device *kdev,
> and struct device *dev (the latter forcing us to refer to
> struct drm_device as something else than the normal dev).
> 
> To simplify things, always use kdev when referring to struct device.
> 
> Signed-off-by: David Weinehall 

kdev may be confused with kdev_t, but seems reasonable due to kobj.

This patch is an improvement, so
Reviewed-by: Chris Wilson 

but I was wondering if

struct device *dev;
struct drm_device *drm;
struct i915_device *i915;

(struct i915_device is move apt now than drm_i915_private due to the
subclassing)

made more sense as a longterm goal?
-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 13/16] drm/i915: Remove pinned check from madvise ioctl

2016-08-01 Thread Chris Wilson
We don't need to incur the overhead of checking whether the object is
pinned prior to changing its madvise. If the object is pinned, the
madvise will not take effect until it is unpinned and so we cannot free
the pages being pointed at by hardware. Marking a pinned object with
allocated pages as DONTNEED will not trigger any undue warnings. The check
is therefore superfluous, and by removing it we can remove a linear walk
over all the vma the object has.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 51ec5cd1c6ca..4b8a391912bc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3853,11 +3853,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void 
*data,
goto unlock;
}
 
-   if (i915_gem_obj_is_pinned(obj)) {
-   ret = -EINVAL;
-   goto out;
-   }
-
if (obj->pages &&
obj->tiling_mode != I915_TILING_NONE &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
@@ -3876,7 +3871,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
 
args->retained = obj->madv != __I915_MADV_PURGED;
 
-out:
i915_gem_object_put(obj);
 unlock:
mutex_unlock(>struct_mutex);
-- 
2.8.1

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


[Intel-gfx] [PATCH 15/16] drm/i915: Repack fence tiling mode and stride into a single integer

2016-08-01 Thread Chris Wilson
In the previous commit, we moved the obj->tiling_mode out of a bitfield
and into its own integer so that we could safely use READ_ONCE(). Let us
now repair some of that damage by sharing the tiling_mode with its
companion, the fence stride.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 29 --
 drivers/gpu/drm/i915/i915_gem.c| 20 ---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_fence.c  | 39 ++
 drivers/gpu/drm/i915/i915_gem_tiling.c | 16 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 drivers/gpu/drm/i915/intel_display.c   | 34 +-
 drivers/gpu/drm/i915/intel_fbc.c   |  2 +-
 drivers/gpu/drm/i915/intel_overlay.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c|  2 +-
 drivers/gpu/drm/i915/intel_sprite.c| 12 -
 12 files changed, 94 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02c077caa282..b7d0933fbbc6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -101,7 +101,7 @@ static char get_pin_flag(struct drm_i915_gem_object *obj)
 
 static char get_tiling_flag(struct drm_i915_gem_object *obj)
 {
-   switch (obj->tiling_mode) {
+   switch (i915_gem_object_get_tiling(obj)) {
default:
case I915_TILING_NONE: return ' ';
case I915_TILING_X: return 'X';
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 88b4fd8cb275..74f3e08a8a14 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2215,13 +2215,10 @@ struct drm_i915_gem_object {
 
atomic_t frontbuffer_bits;
 
-   /**
-* Current tiling mode for the object.
-*/
-   unsigned int tiling_mode;
-
/** Current tiling stride for the object, if it's tiled. */
-   uint32_t stride;
+   unsigned int tiling_and_stride;
+#define TILING_MASK 0x3
+#define STRIDE_MASK (~TILING_MASK)
 
unsigned int has_wc_mmap;
/** Count of VMA actually bound by this object */
@@ -2360,6 +2357,24 @@ i915_gem_object_has_active_engine(const struct 
drm_i915_gem_object *obj,
return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
 }
 
+static inline unsigned int
+i915_gem_object_get_tiling(struct drm_i915_gem_object *obj)
+{
+   return obj->tiling_and_stride & TILING_MASK;
+}
+
+static inline bool
+i915_gem_object_is_tiled(struct drm_i915_gem_object *obj)
+{
+   return i915_gem_object_get_tiling(obj) != I915_TILING_NONE;
+}
+
+static inline unsigned int
+i915_gem_object_get_stride(struct drm_i915_gem_object *obj)
+{
+   return obj->tiling_and_stride & STRIDE_MASK;
+}
+
 /*
  * Optimised SGL iterator for GEM objects
  */
@@ -3457,7 +3472,7 @@ static inline bool 
i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_objec
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
 
return dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17 &&
-   obj->tiling_mode != I915_TILING_NONE;
+   i915_gem_object_is_tiled(obj);
 }
 
 /* i915_debugfs.c */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4b8a391912bc..50472dfb4f30 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1035,7 +1035,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
int ret;
bool hit_slow_path = false;
 
-   if (obj->tiling_mode != I915_TILING_NONE)
+   if (i915_gem_object_is_tiled(obj))
return -EFAULT;
 
ret = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
@@ -1669,7 +1669,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
 
/* Use a partial view if the object is bigger than the aperture. */
if (obj->base.size >= ggtt->mappable_end &&
-   obj->tiling_mode == I915_TILING_NONE) {
+   !i915_gem_object_is_tiled(obj)) {
static const unsigned int chunk_size = 256; // 1 MiB
 
memset(, 0, sizeof(view));
@@ -2187,7 +2187,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj);
 
-   if (obj->tiling_mode != I915_TILING_NONE &&
+   if (i915_gem_object_is_tiled(obj) &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES)
i915_gem_object_pin_pages(obj);
 
@@ -2929,10 +2929,12 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
 
size = max(size, vma->size);
if (flags & PIN_MAPPABLE)
-   size = i915_gem_get_ggtt_size(dev_priv, size, obj->tiling_mode);
+   size = 

[Intel-gfx] [PATCH 03/16] drm/i915: Convert non-blocking userptr waits for requests over to using RCU

2016-08-01 Thread Chris Wilson
We can completely avoid taking the struct_mutex around the non-blocking
waits by switching over to the RCU request management (trading the mutex
for a RCU read lock and some complex atomic operations). The improvement
is that we gain further contention reduction, and overall the code
become simpler due to the reduced mutex dancing.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 34 +++--
 1 file changed, 7 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 53f64fcc89ef..96ab6161903a 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -63,32 +63,12 @@ struct i915_mmu_object {
 
 static void wait_rendering(struct drm_i915_gem_object *obj)
 {
-   struct drm_device *dev = obj->base.dev;
-   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
-   int i, n;
-
-   if (!i915_gem_object_is_active(obj))
-   return;
-
-   n = 0;
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   struct drm_i915_gem_request *req;
+   unsigned long active = __I915_BO_ACTIVE(obj);
+   int idx;
 
-   req = i915_gem_active_get(>last_read[i],
- >base.dev->struct_mutex);
-   if (req)
-   requests[n++] = req;
-   }
-
-   mutex_unlock(>struct_mutex);
-
-   for (i = 0; i < n; i++)
-   i915_wait_request(requests[i], false, NULL, NULL);
-
-   mutex_lock(>struct_mutex);
-
-   for (i = 0; i < n; i++)
-   i915_gem_request_put(requests[i]);
+   for_each_active(active, idx)
+   i915_gem_active_wait_unlocked(>last_read[idx],
+ false, NULL, NULL);
 }
 
 static void cancel_userptr(struct work_struct *work)
@@ -97,6 +77,8 @@ static void cancel_userptr(struct work_struct *work)
struct drm_i915_gem_object *obj = mo->obj;
struct drm_device *dev = obj->base.dev;
 
+   wait_rendering(obj);
+
mutex_lock(>struct_mutex);
/* Cancel any active worker and force us to re-evaluate gup */
obj->userptr.work = NULL;
@@ -105,8 +87,6 @@ static void cancel_userptr(struct work_struct *work)
struct drm_i915_private *dev_priv = to_i915(dev);
bool was_interruptible;
 
-   wait_rendering(obj);
-
was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;
 
-- 
2.8.1

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


[Intel-gfx] [PATCH 01/16] drm/i915: Introduce i915_gem_active_wait_unlocked()

2016-08-01 Thread Chris Wilson
It is useful to be able to wait on pending rendering without grabbing
the struct_mutex. We can do this by using the i915_gem_active_get_rcu()
primitive to acquire a reference to the pending request without
requiring struct_mutex, just the RCU read lock, and then call
i915_wait_request().

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.h | 36 +
 1 file changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 48382ac401fd..d077b023a89f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -546,6 +546,42 @@ i915_gem_active_wait(const struct i915_gem_active *active, 
struct mutex *mutex)
 }
 
 /**
+ * i915_gem_active_wait_unlocked - waits until the request is completed
+ * @active - the active request on which to wait
+ * @interruptible - whether the wait can be woken by a userspace signal
+ * @timeout - how long to wait at most
+ * @rps - userspace client to charge for a waitboost
+ *
+ * i915_gem_active_wait_unlocked() waits until the request is completed before
+ * returning, without requiring any locks to be held. Note that it does not
+ * retire any requests before returning.
+ *
+ * This function wraps i915_wait_request(), see it for the full details.
+ *
+ * Returns 0 if successful, or a negative error code.
+ */
+static inline int
+i915_gem_active_wait_unlocked(const struct i915_gem_active *active,
+ bool interruptible,
+ s64 *timeout,
+ struct intel_rps_client *rps)
+{
+   struct drm_i915_gem_request *request;
+   int ret = 0;
+
+   rcu_read_lock();
+   request = i915_gem_active_get_rcu(active);
+   rcu_read_unlock();
+
+   if (request) {
+   ret = i915_wait_request(request, interruptible, timeout, rps);
+   i915_gem_request_put(request);
+   }
+
+   return ret;
+}
+
+/**
  * i915_gem_active_retire - waits until the request is retired
  * @active - the active request on which to wait
  *
-- 
2.8.1

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


[Intel-gfx] [PATCH 04/16] drm/i915/userptr: Remove superfluous interruptible=false on waiting

2016-08-01 Thread Chris Wilson
Inside the kthread context, we can't be interrupted by signals so
touching the mm.interruptible flag is pointless and wait-request now
consumes EIO itself.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 96ab6161903a..57218cca7e05 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -84,16 +84,9 @@ static void cancel_userptr(struct work_struct *work)
obj->userptr.work = NULL;
 
if (obj->pages != NULL) {
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   bool was_interruptible;
-
-   was_interruptible = dev_priv->mm.interruptible;
-   dev_priv->mm.interruptible = false;
-
+   /* We are inside a kthread context and can't be interrupted */
WARN_ON(i915_gem_object_unbind(obj));
WARN_ON(i915_gem_object_put_pages(obj));
-
-   dev_priv->mm.interruptible = was_interruptible;
}
 
i915_gem_object_put(obj);
-- 
2.8.1

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


[Intel-gfx] [PATCH 06/16] drm/gem/shrinker: Wait before acquiring struct_mutex under oom

2016-08-01 Thread Chris Wilson
We can now wait for the GPU (all engines) to become idle without
requiring the struct_mutex. Inside the shrinker, we need to currently
take the struct_mutex in order to purge objects and to purge the objects
we need the GPU to be idle - causing a stall whilst we hold the
struct_mutex. We can hide most of that stall by performing the wait
before taking the struct_mutex and only doing essential waits for
new rendering on objects to be freed.

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

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 1341cb55b6f1..43e53e419982 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -326,9 +326,14 @@ i915_gem_shrinker_lock_uninterruptible(struct 
drm_i915_private *dev_priv,
unsigned long timeout = msecs_to_jiffies(timeout_ms) + 1;
 
while (!i915_gem_shrinker_lock(_priv->drm, >unlock)) {
+   if (i915_gem_wait_for_idle(dev_priv) == 0 &&
+   i915_gem_shrinker_lock(_priv->drm, >unlock))
+   break;
+
schedule_timeout_killable(1);
if (fatal_signal_pending(current))
return false;
+
if (--timeout == 0) {
pr_err("Unable to lock GPU to purge memory.\n");
return false;
-- 
2.8.1

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


[Intel-gfx] [PATCH 10/16] drm/i915: Remove (struct_mutex) locking for wait-ioctl

2016-08-01 Thread Chris Wilson
With a bit of care (and leniency) we can iterate over the object and
wait for previous rendering to complete with judicial use of atomic
reference counting. The ABI requires us to ensure that an active object
is eventually flushed (like the busy-ioctl) which is guaranteed by our
management of requests (i.e. everything that is submitted to hardware is
flushed in the same request). All we have to do is ensure that we can
detect when the requests are complete for reporting when the object is
idle (without triggering ETIME) - this is handled by
__i915_wait_request.

The biggest danger in the code is walking the object without holding any
locks. We iterate over the set of last requests and carefully grab a
reference upon it. (If it is changing beneath us, that is the usual
userspace race and even with locking you get the same indeterminate
results.) If the request is unreferenced beneath us, it will be disposed
of into the request cache - so we have to carefully order the retrieval
of the request pointer with its removal, and to do this we employ RCU on
the request cache and upon the last_request pointer tracking.

The impact of this is actually quite small - the return to userspace
following the wait was already lockless. What we achieve here is
completing an already finished wait without hitting the struct_mutex,
our hold is quite short and so we are typically just a victim of
contention rather than a cause.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 42 +++--
 1 file changed, 11 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a19bbcf0c19b..43069b05bdd2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2615,46 +2615,26 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
 {
struct drm_i915_gem_wait *args = data;
struct drm_i915_gem_object *obj;
-   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
-   int i, n = 0;
-   int ret;
+   unsigned long active;
+   int idx, ret = 0;
 
if (args->flags != 0)
return -EINVAL;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, args->bo_handle);
-   if (!obj) {
-   mutex_unlock(>struct_mutex);
+   if (!obj)
return -ENOENT;
-   }
-
-   if (!i915_gem_object_is_active(obj))
-   goto out;
 
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   struct drm_i915_gem_request *req;
-
-   req = i915_gem_active_get(>last_read[i],
- >base.dev->struct_mutex);
-   if (req)
-   requests[n++] = req;
+   active = __I915_BO_ACTIVE(obj);
+   for_each_active(active, idx) {
+   ret = i915_gem_active_wait_unlocked(>last_read[idx], true,
+   args->timeout_ns >= 0 ? 
>timeout_ns : NULL,
+   to_rps_client(file));
+   if (ret)
+   break;
}
 
-out:
-   i915_gem_object_put(obj);
-   mutex_unlock(>struct_mutex);
-
-   for (i = 0; i < n; i++) {
-   if (ret == 0)
-   ret = i915_wait_request(requests[i], true,
-   args->timeout_ns > 0 ? 
>timeout_ns : NULL,
-   to_rps_client(file));
-   i915_gem_request_put(requests[i]);
-   }
+   i915_gem_object_put_unlocked(obj);
return ret;
 }
 
-- 
2.8.1

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


[Intel-gfx] [PATCH 08/16] drm/i915: Remove unused no-shrinker-steal

2016-08-01 Thread Chris Wilson
After removing the user of this wart, we can remove the wart entirely.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 -
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db5dc5bd78d8..d09c87fb207d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1318,7 +1318,6 @@ struct i915_gem_mm {
struct notifier_block oom_notifier;
struct notifier_block vmap_notifier;
struct shrinker shrinker;
-   bool shrinker_no_lock_stealing;
 
/** LRU list of objects with fence regs on them. */
struct list_head fence_list;
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 43e53e419982..7a604813226d 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -244,9 +244,6 @@ static bool i915_gem_shrinker_lock(struct drm_device *dev, 
bool *unlock)
if (!mutex_is_locked_by(>struct_mutex, current))
return false;
 
-   if (to_i915(dev)->mm.shrinker_no_lock_stealing)
-   return false;
-
*unlock = false;
} else
*unlock = true;
-- 
2.8.1

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


[Intel-gfx] [PATCH 09/16] drm/i915: Do a nonblocking wait first in pread/pwrite

2016-08-01 Thread Chris Wilson
If we try and read or write to an active request, we first must wait
upon the GPU completing that request. Let's do that without holding the
mutex (and so allow someone else to access the GPU whilst we wait). Upn
completion, we will reacquire the mutex and only then start the
operation (i.e. we do not rely on state from before dropping the mutex).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 62 +++--
 1 file changed, 35 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0c5d2872649c..a19bbcf0c19b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -953,25 +953,26 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
   args->size))
return -EFAULT;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Bounds check source.  */
if (args->offset > obj->base.size ||
args->size > obj->base.size - args->offset) {
ret = -EINVAL;
-   goto out;
+   goto out_unlocked;
}
 
-   trace_i915_gem_object_pread(obj, args->offset, args->size);
+   ret = __unsafe_wait_rendering(obj, to_rps_client(file), true);
+   if (ret)
+   goto out_unlocked;
 
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   goto out_unlocked;
+
+   trace_i915_gem_object_pread(obj, args->offset, args->size);
ret = i915_gem_shmem_pread(dev, obj, args, file);
 
/* pread for non shmem backed objects */
@@ -979,10 +980,13 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
ret = i915_gem_gtt_pread(dev, obj, args->size,
args->offset, args->data_ptr);
 
-out:
i915_gem_object_put(obj);
-unlock:
mutex_unlock(>struct_mutex);
+
+   return ret;
+
+out_unlocked:
+   i915_gem_object_put_unlocked(obj);
return ret;
 }
 
@@ -1368,27 +1372,28 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
return -EFAULT;
}
 
-   intel_runtime_pm_get(dev_priv);
-
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   goto put_rpm;
-
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Bounds check destination. */
if (args->offset > obj->base.size ||
args->size > obj->base.size - args->offset) {
ret = -EINVAL;
-   goto out;
+   goto out_unlocked;
}
 
-   trace_i915_gem_object_pwrite(obj, args->offset, args->size);
+   ret = __unsafe_wait_rendering(obj, to_rps_client(file), false);
+   if (ret)
+   goto out_unlocked;
+
+   intel_runtime_pm_get(dev_priv);
 
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   goto out_rpm;
+
+   trace_i915_gem_object_pwrite(obj, args->offset, args->size);
ret = -EFAULT;
/* We can only do the GTT pwrite on untiled buffers, as otherwise
 * it would end up going through the fenced access, and we'll get
@@ -1413,14 +1418,17 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
ret = -ENODEV;
}
 
-out:
i915_gem_object_put(obj);
-unlock:
mutex_unlock(>struct_mutex);
-put_rpm:
intel_runtime_pm_put(dev_priv);
 
return ret;
+
+out_rpm:
+   intel_runtime_pm_put(dev_priv);
+out_unlocked:
+   i915_gem_object_put_unlocked(obj);
+   return ret;
 }
 
 static enum fb_op_origin
-- 
2.8.1

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


[Intel-gfx] [PATCH 12/16] drm/i915: Reduce locking inside swfinish ioctl

2016-08-01 Thread Chris Wilson
We only need to take the struct_mutex if the object is pinned to the
display engine and so requires checking for clflush. (The race with
userspace pinning the object to a framebuffer is irrelevant.)

v2: Use access once for compiler hints (or not as it is a bitfield)
v3: READ_ONCE, obj->pin_display is not a bitfield anymore

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f2f70f5ff9f4..51ec5cd1c6ca 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1510,25 +1510,28 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
*data,
 {
struct drm_i915_gem_sw_finish *args = data;
struct drm_i915_gem_object *obj;
-   int ret = 0;
-
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
+   int ret;
 
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Pinned buffers may be scanout, so flush the cache */
-   if (obj->pin_display)
+   if (READ_ONCE(obj->pin_display)) {
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   goto unref;
+
i915_gem_object_flush_cpu_write_domain(obj);
 
-   i915_gem_object_put(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+   i915_gem_object_put(obj);
+   mutex_unlock(>struct_mutex);
+   } else {
+   ret = 0;
+unref:
+   i915_gem_object_put_unlocked(obj);
+   }
+
return ret;
 }
 
-- 
2.8.1

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


[Intel-gfx] [PATCH 14/16] drm/i915: Remove locking for get_tiling

2016-08-01 Thread Chris Wilson
Since we are not concerned with userspace racing itself with set-tiling
(the order is indeterminant even if we take a lock), then we can safely
read back the single obj->tiling_mode and do the static lookup of
swizzle mode without having to take a lock.

get-tiling is reasonably frequent due to the back-channel passing around
of tiling parameters in DRI2/DRI3.

v2: Make tiling_mode a full unsigned int so that we can trivially use it
with READ_ONCE(). Separating it out into manual control over the flags
field was too noisy for a simple patch. Note, that we can use the lower
bits of obj->stride for the tiling mode.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h| 15 ---
 drivers/gpu/drm/i915/i915_gem_tiling.c | 10 +++---
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d09c87fb207d..88b4fd8cb275 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2184,10 +2184,6 @@ struct drm_i915_gem_object {
unsigned int madv:2;
 
/**
-* Current tiling mode for the object.
-*/
-   unsigned int tiling_mode:2;
-   /**
 * Whether the tiling parameters for the currently associated fence
 * register have changed. Note that for the purposes of tracking
 * tiling changes we also treat the unfenced register, the register
@@ -2219,6 +2215,14 @@ struct drm_i915_gem_object {
 
atomic_t frontbuffer_bits;
 
+   /**
+* Current tiling mode for the object.
+*/
+   unsigned int tiling_mode;
+
+   /** Current tiling stride for the object, if it's tiled. */
+   uint32_t stride;
+
unsigned int has_wc_mmap;
/** Count of VMA actually bound by this object */
unsigned int bind_count;
@@ -2246,9 +2250,6 @@ struct drm_i915_gem_object {
struct i915_gem_active last_write;
struct i915_gem_active last_fence;
 
-   /** Current tiling stride for the object, if it's tiled. */
-   uint32_t stride;
-
/** References from framebuffers, locks out tiling changes. */
unsigned long framebuffer_references;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index b7f9875f69b4..c0e01333bddf 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -303,10 +303,8 @@ i915_gem_get_tiling(struct drm_device *dev, void *data,
if (!obj)
return -ENOENT;
 
-   mutex_lock(>struct_mutex);
-
-   args->tiling_mode = obj->tiling_mode;
-   switch (obj->tiling_mode) {
+   args->tiling_mode = READ_ONCE(obj->tiling_mode);
+   switch (args->tiling_mode) {
case I915_TILING_X:
args->swizzle_mode = dev_priv->mm.bit_6_swizzle_x;
break;
@@ -330,8 +328,6 @@ i915_gem_get_tiling(struct drm_device *dev, void *data,
if (args->swizzle_mode == I915_BIT_6_SWIZZLE_9_10_17)
args->swizzle_mode = I915_BIT_6_SWIZZLE_9_10;
 
-   i915_gem_object_put(obj);
-   mutex_unlock(>struct_mutex);
-
+   i915_gem_object_put_unlocked(obj);
return 0;
 }
-- 
2.8.1

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


[Intel-gfx] [PATCH 07/16] drm/i915: Tidy generation of the GTT mmap offset

2016-08-01 Thread Chris Wilson
If we make the observation that mmap-offsets are only released when we
free an object, we can then deduce that the shrinker only creates free
space in the mmap arena indirectly by flushing the request list and
freeing expired objects. If we combine this with the lockless
vma-manager and lockless idling, we can avoid taking our big struct_mutex
until we need to actually free the requests.

One side-effect is that we defer the madvise checking until we need the
pages (i.e. the fault handler). This brings us into line with the other
delayed checks (and madvise in general).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 65 +
 1 file changed, 20 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ac9605d5125..0c5d2872649c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1891,35 +1891,27 @@ u64 i915_gem_get_ggtt_alignment(struct drm_i915_private 
*dev_priv, u64 size,
 
 static int i915_gem_object_create_mmap_offset(struct drm_i915_gem_object *obj)
 {
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+   struct drm_device *dev = obj->base.dev;
int ret;
 
-   dev_priv->mm.shrinker_no_lock_stealing = true;
-
ret = drm_gem_create_mmap_offset(>base);
-   if (ret != -ENOSPC)
-   goto out;
+   if (ret == 0)
+   return 0;
 
-   /* Badly fragmented mmap space? The only way we can recover
-* space is by destroying unwanted objects. We can't randomly release
-* mmap_offsets as userspace expects them to be persistent for the
-* lifetime of the objects. The closest we can is to release the
-* offsets on purgeable objects by truncating it and marking it purged,
-* which prevents userspace from ever using that object again.
+   /* We can idle the GPU locklessly to flush stale objects, but in order
+* to claim that space for ourselves, we need to take the big
+* struct_mutex to free the requests+objects and allocate our slot.
 */
-   i915_gem_shrink(dev_priv,
-   obj->base.size >> PAGE_SHIFT,
-   I915_SHRINK_BOUND |
-   I915_SHRINK_UNBOUND |
-   I915_SHRINK_PURGEABLE);
-   ret = drm_gem_create_mmap_offset(>base);
-   if (ret != -ENOSPC)
-   goto out;
+   ret = i915_gem_wait_for_idle(to_i915(dev));
+   if (ret)
+   return ret;
 
-   i915_gem_shrink_all(dev_priv);
-   ret = drm_gem_create_mmap_offset(>base);
-out:
-   dev_priv->mm.shrinker_no_lock_stealing = false;
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret == 0) {
+   i915_gem_retire_requests(to_i915(dev));
+   ret = drm_gem_create_mmap_offset(>base);
+   mutex_unlock(>struct_mutex);
+   }
 
return ret;
 }
@@ -1938,32 +1930,15 @@ i915_gem_mmap_gtt(struct drm_file *file,
struct drm_i915_gem_object *obj;
int ret;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
-
-   if (obj->madv != I915_MADV_WILLNEED) {
-   DRM_DEBUG("Attempting to mmap a purgeable buffer\n");
-   ret = -EFAULT;
-   goto out;
-   }
+   if (!obj)
+   return -ENOENT;
 
ret = i915_gem_object_create_mmap_offset(obj);
-   if (ret)
-   goto out;
+   if (ret == 0)
+   *offset = drm_vma_node_offset_addr(>base.vma_node);
 
-   *offset = drm_vma_node_offset_addr(>base.vma_node);
-
-out:
-   i915_gem_object_put(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+   i915_gem_object_put_unlocked(obj);
return ret;
 }
 
-- 
2.8.1

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


[Intel-gfx] [PATCH 11/16] drm/i915: Remove (struct_mutex) locking for busy-ioctl

2016-08-01 Thread Chris Wilson
By applying the same logic as for wait-ioctl, we can query whether a
request has completed without holding struct_mutex. The biggest impact
system-wide is removing the flush_active and the contention that causes.

Testcase: igt/gem_busy
Signed-off-by: Chris Wilson 
Cc: Akash Goel 
---
 drivers/gpu/drm/i915/i915_gem.c | 110 +---
 1 file changed, 80 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 43069b05bdd2..f2f70f5ff9f4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3721,49 +3721,99 @@ i915_gem_object_ggtt_unpin_view(struct 
drm_i915_gem_object *obj,
i915_vma_unpin(i915_gem_obj_to_ggtt_view(obj, view));
 }
 
+static __always_inline unsigned
+__busy_read_flag(const struct drm_i915_gem_request *request)
+{
+   return 0x1 << request->engine->exec_id;
+}
+
+static __always_inline unsigned int
+__busy_write_flag(const struct drm_i915_gem_request *request)
+{
+   return request->engine->exec_id;
+}
+
+static __always_inline unsigned
+__busy_flag(const struct i915_gem_active *active,
+   unsigned int (*flag)(const struct drm_i915_gem_request *))
+{
+   struct drm_i915_gem_request *request;
+
+   request = rcu_dereference(active->request);
+   if (!request || i915_gem_request_completed(request))
+   return 0;
+
+   return flag(request);
+}
+
+static inline unsigned
+busy_read_flag(const struct i915_gem_active *active)
+{
+   return __busy_flag(active, __busy_read_flag);
+}
+
+static inline unsigned
+busy_write_flag(const struct i915_gem_active *active)
+{
+   return __busy_flag(active, __busy_write_flag);
+}
+
 int
 i915_gem_busy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
 {
struct drm_i915_gem_busy *args = data;
struct drm_i915_gem_object *obj;
-   int ret;
-
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
+   unsigned long active;
 
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
-   /* Count all active objects as busy, even if they are currently not used
-* by the gpu. Users of this interface expect objects to eventually
-* become non-busy without any further actions.
-*/
args->busy = 0;
-   if (i915_gem_object_is_active(obj)) {
-   struct drm_i915_gem_request *req;
-   int i;
+   active = __I915_BO_ACTIVE(obj);
+   if (active) {
+   int idx;
 
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   req = i915_gem_active_peek(>last_read[i],
-  
>base.dev->struct_mutex);
-   if (req)
-   args->busy |= 1 << (16 + req->engine->exec_id);
-   }
-   req = i915_gem_active_peek(>last_write,
-  >base.dev->struct_mutex);
-   if (req)
-   args->busy |= req->engine->exec_id;
+   /* Yes, the lookups are intentionally racy.
+*
+* Even though we guard the pointer lookup by RCU, that only
+* guarantees that the pointer and its contents remain
+* dereferencable and does *not* mean that the request we
+* have is the same as the one being tracked by the object.
+*
+* Consider that we lookup the request just as it is being
+* retired and free. We take a local copy of the pointer,
+* but before we add its engine into the busy set, the other
+* thread reallocates it and assigns it to a task on another
+* engine with a fresh and incomplete seqno.
+*
+* So after we lookup the engine's id, we double check that
+* the active request is the same and only then do we add it
+* into the busy set.
+*/
+   rcu_read_lock();
+
+   for_each_active(active, idx)
+   args->busy |= busy_read_flag(>last_read[idx]);
+
+   /* For ABI sanity, we only care that the write engine is in
+* the set of read engines. This is ensured by the ordering
+* of setting last_read/last_write in i915_vma_move_to_active,
+* and then in reverse in retire.
+*
+* We don't care that the set of active read/write engines
+* may change during construction of the result, as it is
+* equally liable to change before userspace can inspect
+  

[Intel-gfx] [PATCH 16/16] drm/i915: Assert that the request hasn't been retired

2016-08-01 Thread Chris Wilson
With all callers now not playing tricks with dropping the struct_mutex
between waiting and retiring, we can assert that the request is ready to
be retired.

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

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 8289d31c0ef5..b79ee5a35079 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -170,7 +170,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
struct i915_gem_active *active, *next;
 
trace_i915_gem_request_retire(request);
-   list_del_init(>link);
+   list_del(>link);
 
/* We know the GPU must have read the request to have
 * sent us the seqno + interrupt, so use the position
@@ -228,9 +228,7 @@ void i915_gem_request_retire_upto(struct 
drm_i915_gem_request *req)
struct drm_i915_gem_request *tmp;
 
lockdep_assert_held(>i915->drm.struct_mutex);
-
-   if (list_empty(>link))
-   return;
+   GEM_BUG_ON(list_empty(>link));
 
do {
tmp = list_first_entry(>request_list,
-- 
2.8.1

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


[Intel-gfx] [PATCH 02/16] drm/i915: Convert non-blocking waits for requests over to using RCU

2016-08-01 Thread Chris Wilson
We can completely avoid taking the struct_mutex around the non-blocking
waits by switching over to the RCU request management (trading the mutex
for a RCU read lock and some complex atomic operations). The improvement
is that we gain further contention reduction, and overall the code
become simpler due to the reduced mutex dancing.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 112 +---
 1 file changed, 47 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d8d3e728230d..f164ad482bdc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -346,24 +346,20 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj,
return 0;
 }
 
-/* A nonblocking variant of the above wait. This is a highly dangerous routine
- * as the object state may change during this call.
+/* A nonblocking variant of the above wait. Must be called prior to
+ * acquiring the mutex for the object, as the object state may change
+ * during this call. A reference must be held by the caller for the object.
  */
 static __must_check int
-i915_gem_object_wait_rendering__nonblocking(struct drm_i915_gem_object *obj,
-   struct intel_rps_client *rps,
-   bool readonly)
+__unsafe_wait_rendering(struct drm_i915_gem_object *obj,
+   struct intel_rps_client *rps,
+   bool readonly)
 {
-   struct drm_device *dev = obj->base.dev;
-   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
struct i915_gem_active *active;
unsigned long active_mask;
-   int ret, i, n = 0;
-
-   lockdep_assert_held(>struct_mutex);
-   GEM_BUG_ON(!to_i915(dev)->mm.interruptible);
+   int idx;
 
-   active_mask = i915_gem_object_get_active(obj);
+   active_mask = __I915_BO_ACTIVE(obj);
if (!active_mask)
return 0;
 
@@ -374,25 +370,16 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
active = >last_write;
}
 
-   for_each_active(active_mask, i) {
-   struct drm_i915_gem_request *req;
+   for_each_active(active_mask, idx) {
+   int ret;
 
-   req = i915_gem_active_get([i],
- >base.dev->struct_mutex);
-   if (req)
-   requests[n++] = req;
+   ret = i915_gem_active_wait_unlocked([idx],
+   true, NULL, rps);
+   if (ret)
+   return ret;
}
 
-   mutex_unlock(>struct_mutex);
-   ret = 0;
-   for (i = 0; ret == 0 && i < n; i++)
-   ret = i915_wait_request(requests[i], true, NULL, rps);
-   mutex_lock(>struct_mutex);
-
-   for (i = 0; i < n; i++)
-   i915_gem_request_put(requests[i]);
-
-   return ret;
+   return 0;
 }
 
 static struct intel_rps_client *to_rps_client(struct drm_file *file)
@@ -1461,10 +1448,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
int ret;
 
/* Only handle setting domains to types used by the CPU. */
-   if (write_domain & I915_GEM_GPU_DOMAINS)
-   return -EINVAL;
-
-   if (read_domains & I915_GEM_GPU_DOMAINS)
+   if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
return -EINVAL;
 
/* Having something in the write domain implies it's in the read
@@ -1473,25 +1457,21 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
if (write_domain != 0 && read_domains != write_domain)
return -EINVAL;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Try to flush the object off the GPU without holding the lock.
 * We will repeat the flush holding the lock in the normal manner
 * to catch cases where we are gazumped.
 */
-   ret = i915_gem_object_wait_rendering__nonblocking(obj,
- to_rps_client(file),
- !write_domain);
+   ret = __unsafe_wait_rendering(obj, to_rps_client(file), !write_domain);
if (ret)
-   goto unref;
+   goto out_unlocked;
+
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   goto out_unlocked;
 
if (read_domains & I915_GEM_DOMAIN_GTT)
ret = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
@@ -1501,11 +1481,13 @@ 

[Intel-gfx] [PATCH 05/16] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

2016-08-01 Thread Chris Wilson
The principal motivation for this was to try and eliminate the
struct_mutex from i915_gem_suspend - but we still need to hold the mutex
current for the i915_gem_context_lost(). (The issue there is that there
may be an indirect lockdep cycle between cpu_hotplug (i.e. suspend) and
struct_mutex via the stop_machine().) For the moment, enabling last
request tracking for the engine, allows us to do busyness checking and
waiting without requiring the struct_mutex - which is useful in its own
right.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 37 ++---
 drivers/gpu/drm/i915/i915_gem_evict.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_request.c |  5 +++--
 drivers/gpu/drm/i915/i915_gem_request.h | 11 ++
 drivers/gpu/drm/i915/i915_gpu_error.c   |  2 +-
 drivers/gpu/drm/i915/i915_irq.c |  3 +--
 drivers/gpu/drm/i915/intel_engine_cs.c  |  8 ++-
 drivers/gpu/drm/i915/intel_pm.c |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h | 24 +++--
 10 files changed, 52 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f164ad482bdc..8ac9605d5125 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2432,13 +2432,18 @@ static void i915_gem_reset_engine_status(struct 
intel_engine_cs *engine)
 
 static void i915_gem_reset_engine_cleanup(struct intel_engine_cs *engine)
 {
+   struct drm_i915_gem_request *request;
struct intel_ring *ring;
 
+   request = i915_gem_active_peek(>last_request,
+  >i915->drm.struct_mutex);
+
/* Mark all pending requests as complete so that any concurrent
 * (lockless) lookup doesn't try and wait upon the request as we
 * reset it.
 */
-   intel_engine_init_seqno(engine, engine->last_submitted_seqno);
+   if (request)
+   intel_engine_init_seqno(engine, request->fence.seqno);
 
/*
 * Clear the execlists queue up before freeing the requests, as those
@@ -2460,15 +2465,9 @@ static void i915_gem_reset_engine_cleanup(struct 
intel_engine_cs *engine)
 * implicit references on things like e.g. ppgtt address spaces through
 * the request.
 */
-   if (!list_empty(>request_list)) {
-   struct drm_i915_gem_request *request;
-
-   request = list_last_entry(>request_list,
- struct drm_i915_gem_request,
- link);
-
+   if (request)
i915_gem_request_retire_upto(request);
-   }
+   GEM_BUG_ON(intel_engine_is_active(engine));
 
/* Having flushed all requests from all queues, we know that all
 * ringbuffers must now be empty. However, since we do not reclaim
@@ -2896,8 +2895,6 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
*dev_priv)
struct intel_engine_cs *engine;
int ret;
 
-   lockdep_assert_held(_priv->drm.struct_mutex);
-
for_each_engine(engine, dev_priv) {
if (engine->last_context == NULL)
continue;
@@ -4069,21 +4066,10 @@ struct i915_vma *i915_gem_obj_to_ggtt_view(struct 
drm_i915_gem_object *obj,
return NULL;
 }
 
-static void
-i915_gem_stop_engines(struct drm_device *dev)
+int i915_gem_suspend(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_engine_cs *engine;
-
-   for_each_engine(engine, dev_priv)
-   dev_priv->gt.stop_engine(engine);
-}
-
-int
-i915_gem_suspend(struct drm_device *dev)
-{
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   int ret = 0;
+   int ret;
 
intel_suspend_gt_powersave(dev_priv);
 
@@ -4112,7 +4098,6 @@ i915_gem_suspend(struct drm_device *dev)
 * and similar for all logical context images (to ensure they are
 * all ready for hibernation).
 */
-   i915_gem_stop_engines(dev);
i915_gem_context_lost(dev_priv);
mutex_unlock(>struct_mutex);
 
@@ -4128,7 +4113,7 @@ i915_gem_suspend(struct drm_device *dev)
return 0;
 
 err:
-   mutex_unlock(>struct_mutex);
+   mutex_unlock(_priv->drm.struct_mutex);
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 7be425826539..624c0f016c84 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -39,7 +39,7 @@ gpu_is_idle(struct drm_i915_private *dev_priv)
struct intel_engine_cs *engine;
 
for_each_engine(engine, dev_priv) {
-   if (!list_empty(>request_list))
+   if (intel_engine_is_active(engine))
return false;
}
 
diff --git 

[Intel-gfx] Put RCU request lookup to use

2016-08-01 Thread Chris Wilson
Having introduced a means for performing lockless request lookup, put it
to use and implement lockless waiting and friends. The goal is to try
and avoid holding onto the struct_mutex and avoid it entirely if
possible as execbuf likes to hog it.
-Chris

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


Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

2016-08-01 Thread Kamble, Sagar A
Reviewed-by: Sagar Arun Kamble >



On 6/27/2016 8:10 PM, akash.g...@intel.com wrote:

From: Akash Goel 

Updated the i915_drpc_info debugfs with coarse power gating & forcewake
info for Gen9.

v2: Change all IS_GEN9() by gen >= 9 (Damien)

v3: Rebase

Cc: Damien Lespiau 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 21 -
  drivers/gpu/drm/i915/i915_reg.h |  3 +++
  2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f664884..5185e02 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1588,6 +1588,7 @@ static int gen6_drpc_info(struct seq_file *m)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 rpmodectl1, gt_core_status, rcctl1, rc6vids = 0;
+   u32 gen9_powergate_enable = 0, gen9_powergate_status = 0;
unsigned forcewake_count;
int count = 0, ret;
  
@@ -1615,6 +1616,10 @@ static int gen6_drpc_info(struct seq_file *m)
  
  	rpmodectl1 = I915_READ(GEN6_RP_CONTROL);

rcctl1 = I915_READ(GEN6_RC_CONTROL);
+   if (INTEL_INFO(dev)->gen >= 9) {
+   gen9_powergate_enable = I915_READ(GEN9_PG_ENABLE);
+   gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
+   }
mutex_unlock(>struct_mutex);
mutex_lock(_priv->rps.hw_lock);
sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS, );
@@ -1633,6 +1638,12 @@ static int gen6_drpc_info(struct seq_file *m)
   yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
seq_printf(m, "RC6 Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
+   if (INTEL_INFO(dev)->gen >= 9) {
+   seq_printf(m, "Render Well Gating Enabled: %s\n",
+   yesno(gen9_powergate_enable & GEN9_RENDER_PG_ENABLE));
+   seq_printf(m, "Media Well Gating Enabled: %s\n",
+   yesno(gen9_powergate_enable & GEN9_MEDIA_PG_ENABLE));
+   }
seq_printf(m, "Deep RC6 Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC6p_ENABLE));
seq_printf(m, "Deepest RC6 Enabled: %s\n",
@@ -1661,6 +1672,14 @@ static int gen6_drpc_info(struct seq_file *m)
  
  	seq_printf(m, "Core Power Down: %s\n",

   yesno(gt_core_status & GEN6_CORE_CPD_STATE_MASK));
+   if (INTEL_INFO(dev)->gen >= 9) {
+   seq_printf(m, "Render Power Well: %s\n",
+   (gen9_powergate_status &
+GEN9_PWRGT_RENDER_STATUS_MASK) ? "Up" : "Down");
+   seq_printf(m, "Media Power Well: %s\n",
+   (gen9_powergate_status &
+GEN9_PWRGT_MEDIA_STATUS_MASK) ? "Up" : "Down");
+   }
  
  	/* Not exactly sure what this is */

seq_printf(m, "RC6 \"Locked to RPn\" residency since boot: %u\n",
@@ -1678,7 +1697,7 @@ static int gen6_drpc_info(struct seq_file *m)
   GEN6_DECODE_RC6_VID(((rc6vids >> 8) & 0xff)));
seq_printf(m, "RC6++ voltage: %dmV\n",
   GEN6_DECODE_RC6_VID(((rc6vids >> 16) & 0xff)));
-   return 0;
+   return i915_forcewake_domains(m, NULL);
  }
  
  static int i915_drpc_info(struct seq_file *m, void *unused)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c6bfbf8..1c8d029 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6955,6 +6955,9 @@ enum {
  #define  ECOBUS   _MMIO(0xa180)
  #defineFORCEWAKE_MT_ENABLE(1<<5)
  #define  VLV_SPAREG2H _MMIO(0xA194)
+#define  GEN9_PWRGT_DOMAIN_STATUS  _MMIO(0xA2A0)
+#define   GEN9_PWRGT_MEDIA_STATUS_MASK (1 << 0)
+#define   GEN9_PWRGT_RENDER_STATUS_MASK(1 << 1)
  
  #define  GTFIFODBG_MMIO(0x12)

  #defineGT_FIFO_SBDEDICATE_FREE_ENTRY_CHV  (0x1f << 20)


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


[Intel-gfx] [PATCH v2] drm/i915: Unify request submission

2016-08-01 Thread Chris Wilson
Move request submission from emit_request into its own common vfunc
from i915_add_request().

v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing
v3: Rename a few functions to match.
v4: Reenable execlists submission after disabling guc.
v5: Be aware that everyone calls i915_guc_submission_disable()!

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-23-git-send-email-ch...@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen  #v3
---
 drivers/gpu/drm/i915/i915_gem_request.c|  8 +++-
 drivers/gpu/drm/i915/i915_guc_submission.c | 15 ---
 drivers/gpu/drm/i915/intel_guc.h   |  1 -
 drivers/gpu/drm/i915/intel_lrc.c   | 26 +++---
 drivers/gpu/drm/i915/intel_lrc.h   |  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c| 23 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h| 27 +--
 7 files changed, 54 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a885905df3bb..e378eb61979b 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -466,12 +466,9 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
 */
request->postfix = ring->tail;
 
-   if (i915.enable_execlists)
-   ret = engine->emit_request(request);
-   else
-   ret = engine->add_request(request);
/* Not allowed to fail! */
-   WARN(ret, "emit|add_request failed: %d!\n", ret);
+   ret = engine->emit_request(request);
+   WARN(ret, "(%s)->emit_request failed: %d!\n", engine->name, ret);
 
/* Sanity check that the reserved size was large enough. */
ret = ring->tail - request_start;
@@ -483,6 +480,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
  reserved_tail, ret);
 
i915_gem_mark_busy(engine);
+   engine->submit_request(request);
 }
 
 static unsigned long local_clock_us(unsigned int *cpu)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index eccd34832fe6..5de867585275 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -585,7 +585,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
  * The only error here arises if the doorbell hardware isn't functioning
  * as expected, which really shouln't happen.
  */
-int i915_guc_submit(struct drm_i915_gem_request *rq)
+static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
unsigned int engine_id = rq->engine->id;
struct intel_guc *guc = >i915->guc;
@@ -602,8 +602,6 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
 
guc->submissions[engine_id] += 1;
guc->last_seqno[engine_id] = rq->fence.seqno;
-
-   return b_ret;
 }
 
 /*
@@ -992,6 +990,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
 {
struct intel_guc *guc = _priv->guc;
struct i915_guc_client *client;
+   struct intel_engine_cs *engine;
 
/* client for execbuf submission */
client = guc_client_alloc(dev_priv,
@@ -1006,6 +1005,10 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
host2guc_sample_forcewake(guc, client);
guc_init_doorbell_hw(guc);
 
+   /* Take over from manual control of ELSP (execlists) */
+   for_each_engine(engine, dev_priv)
+   engine->submit_request = i915_guc_submit;
+
return 0;
 }
 
@@ -1013,8 +1016,14 @@ void i915_guc_submission_disable(struct drm_i915_private 
*dev_priv)
 {
struct intel_guc *guc = _priv->guc;
 
+   if (!guc->execbuf_client)
+   return;
+
guc_client_free(dev_priv, guc->execbuf_client);
guc->execbuf_client = NULL;
+
+   /* Revert back to manual ELSP submission */
+   intel_execlists_enable_submission(dev_priv);
 }
 
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743740c0..623cf26cd784 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -160,7 +160,6 @@ extern int intel_guc_resume(struct drm_device *dev);
 int i915_guc_submission_init(struct drm_i915_private *dev_priv);
 int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
 int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
-int i915_guc_submit(struct drm_i915_gem_request *rq);
 void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
 void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 824f7efe4e64..8a72ee86e825 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ 

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 05:28:34PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote:
> > On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote:
> > > 
> > > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> > > > 
> > > > Space reservation is already safe with respect to the ring->size
> > > > modulus, but hardware only expects to see values in the range
> > > > 0...ring->size-1 (inclusive) and so requires the modulus to prevent us
> > > > writing the value ring->size instead of 0. As this is only required for
> > > > the register itself, we can defer the modulus to the register update and
> > > > not perform it after every command packet. We keep the
> > > > intel_ring_advance() around in the code to provide demarcation for the
> > > > end-of-packet (which then can be compared against intel_ring_begin() as
> > > > the number of dwords emitted must match the reserved space).
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Joonas Lahtinen 
> > > > Cc: Dave Gordon 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
> > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
> > > >  drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
> > > >  3 files changed, 18 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > > index bf42a66d6624..824f7efe4e64 100644
> > > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > > @@ -373,7 +373,7 @@ static void execlists_update_context(struct 
> > > > drm_i915_gem_request *rq)
> > > >     struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
> > > >     uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
> > > >  
> > > > -   reg_state[CTX_RING_TAIL+1] = rq->tail;
> > > > +   reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, 
> > > > rq->tail);
> > > >  
> > > >     /* True 32b PPGTT with dynamic page allocation: update PDP
> > > >      * registers and point the unallocated PDPs to scratch page.
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > index 3142085b5cc0..21d5e8209400 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > @@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
> > > > drm_i915_gem_request *request)
> > > >  {
> > > >     struct drm_i915_private *dev_priv = request->i915;
> > > >  
> > > > -   I915_WRITE_TAIL(request->engine, request->tail);
> > > > +   I915_WRITE_TAIL(request->engine,
> > > > +   intel_ring_offset(request->ring, 
> > > > request->tail));
> > > >  }
> > > >  
> > > >  static void
> > > > @@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
> > > > drm_i915_gem_request *request)
> > > >     DRM_ERROR("timed out waiting for the BSD ring to wake 
> > > > up\n");
> > > >  
> > > >     /* Now that the ring is fully powered up, update the tail */
> > > > -   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), 
> > > > request->tail);
> > > > +   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
> > > > +     intel_ring_offset(request->ring, request->tail));
> > > >     POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
> > > >  
> > > >     /* Let the ring send IDLE messages to the GT again,
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> > > > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > index 14d2ea36fb88..9ac96ddb01ee 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > @@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct 
> > > > intel_ring *ring, i915_reg_t reg)
> > > >  
> > > >  static inline void intel_ring_advance(struct intel_ring *ring)
> > > >  {
> > > > +   /* Dummy function.
> > > > +    *
> > > > +    * This serves as a placeholder in the code so that the reader
> > > > +    * can compare against the preceding intel_ring_begin() and
> > > > +    * check that the number of dwords emitted matches the space
> > > > +    * reserved for the command packet (i.e. the value passed to
> > > > +    * intel_ring_begin()).
> > > > +    */
> > > > +}
> > > > +
> > > > +static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
> > > > +{
> > > >     /* The modulus is required so that we avoid writing
> > > >      * request->tail == ring->size, rather than the expected 0,
> > > >      * into the RING_TAIL register as that can cause a GPU hang.
> > > > -    * As this is only strictly required for the request->tail,
> > > > -    * and only then as we write the value into hardware, we can
> > 

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 05:17:51PM +0100, Chris Wilson wrote:
> Following that reasoning, if we just:
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 15acaf6..d54c210 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2370,7 +2370,7 @@ int intel_ring_begin(struct drm_i915_gem_request *req, 
> int num_dwords)
>  
> total_bytes = bytes + req->reserved_space;
>  
> -   if (unlikely(bytes > remain_usable)) {
> +   if (unlikely(bytes >= remain_usable)) {
> 
> we can make this late modulus vanish.

Sorry, that idea is wrong at present - as we need to fixup the tail
afterwards.  It's not until later we talk about moving the tail
advancement into the equivalent of intel_ring_begin().
-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 13/73] drm/i915: Move the modulus for ring emission to the register write

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 05:28:34PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote:
> > On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote:
> > > 
> > > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> > > > 
> > > > Space reservation is already safe with respect to the ring->size
> > > > modulus, but hardware only expects to see values in the range
> > > > 0...ring->size-1 (inclusive) and so requires the modulus to prevent us
> > > > writing the value ring->size instead of 0. As this is only required for
> > > > the register itself, we can defer the modulus to the register update and
> > > > not perform it after every command packet. We keep the
> > > > intel_ring_advance() around in the code to provide demarcation for the
> > > > end-of-packet (which then can be compared against intel_ring_begin() as
> > > > the number of dwords emitted must match the reserved space).
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Joonas Lahtinen 
> > > > Cc: Dave Gordon 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
> > > >  drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
> > > >  drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
> > > >  3 files changed, 18 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > > index bf42a66d6624..824f7efe4e64 100644
> > > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > > @@ -373,7 +373,7 @@ static void execlists_update_context(struct 
> > > > drm_i915_gem_request *rq)
> > > >     struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
> > > >     uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
> > > >  
> > > > -   reg_state[CTX_RING_TAIL+1] = rq->tail;
> > > > +   reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, 
> > > > rq->tail);
> > > >  
> > > >     /* True 32b PPGTT with dynamic page allocation: update PDP
> > > >      * registers and point the unallocated PDPs to scratch page.
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > index 3142085b5cc0..21d5e8209400 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > > @@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
> > > > drm_i915_gem_request *request)
> > > >  {
> > > >     struct drm_i915_private *dev_priv = request->i915;
> > > >  
> > > > -   I915_WRITE_TAIL(request->engine, request->tail);
> > > > +   I915_WRITE_TAIL(request->engine,
> > > > +   intel_ring_offset(request->ring, 
> > > > request->tail));
> > > >  }
> > > >  
> > > >  static void
> > > > @@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
> > > > drm_i915_gem_request *request)
> > > >     DRM_ERROR("timed out waiting for the BSD ring to wake 
> > > > up\n");
> > > >  
> > > >     /* Now that the ring is fully powered up, update the tail */
> > > > -   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), 
> > > > request->tail);
> > > > +   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
> > > > +     intel_ring_offset(request->ring, request->tail));
> > > >     POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
> > > >  
> > > >     /* Let the ring send IDLE messages to the GT again,
> > > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> > > > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > index 14d2ea36fb88..9ac96ddb01ee 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > > @@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct 
> > > > intel_ring *ring, i915_reg_t reg)
> > > >  
> > > >  static inline void intel_ring_advance(struct intel_ring *ring)
> > > >  {
> > > > +   /* Dummy function.
> > > > +    *
> > > > +    * This serves as a placeholder in the code so that the reader
> > > > +    * can compare against the preceding intel_ring_begin() and
> > > > +    * check that the number of dwords emitted matches the space
> > > > +    * reserved for the command packet (i.e. the value passed to
> > > > +    * intel_ring_begin()).
> > > > +    */
> > > > +}
> > > > +
> > > > +static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
> > > > +{
> > > >     /* The modulus is required so that we avoid writing
> > > >      * request->tail == ring->size, rather than the expected 0,
> > > >      * into the RING_TAIL register as that can cause a GPU hang.
> > > > -    * As this is only strictly required for the request->tail,
> > > > -    * and only then as we write the value into hardware, we can
> > 

[Intel-gfx] ✗ Ro.CI.BAT: failure for Various cleanup

2016-08-01 Thread Patchwork
== Series Details ==

Series: Various cleanup
URL   : https://patchwork.freedesktop.org/series/10458/
State : failure

== Summary ==

Series 10458v1 Various cleanup
http://patchwork.freedesktop.org/api/1.0/series/10458/revisions/1/mbox

Test drv_module_reload_basic:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
fail   -> PASS   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (fi-hsw-i7-4770k)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-hsw-i7-4770r)
pass   -> FAIL   (ro-snb-i7-2620M)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-byt-n2820)

fi-hsw-i7-4770k  total:239  pass:217  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-qkkr  total:239  pass:181  dwarn:30  dfail:0   fail:2   skip:26 
fi-skl-i5-6260u  total:239  pass:223  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:239  pass:207  dwarn:0   dfail:0   fail:4   skip:28 
fi-snb-i7-2600   total:239  pass:197  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:4   dfail:0   fail:1   skip:16 
ro-bdw-i7-5557U  total:240  pass:224  dwarn:0   dfail:0   fail:0   skip:16 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:196  dwarn:0   dfail:0   fail:4   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:213  dwarn:0   dfail:0   fail:0   skip:27 
ro-ilk-i7-620lm  total:240  pass:173  dwarn:1   dfail:0   fail:1   skip:65 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:197  dwarn:0   dfail:0   fail:2   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1657/

6f87e85 drm-intel-nightly: 2016y-08m-01d-14h-53m-17s UTC integration manifest
41390c7 drm/i915: pdev cleanup
107bbb0 drm/i915: Consistent drm_minor use
5e1995d drm/i915: Consistent struct device naming
a8d01a3 drm/i915: Cosmetic fixes in i915_drv.h

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


[Intel-gfx] [PATCH 4/4] drm/i915: pdev cleanup

2016-08-01 Thread David Weinehall
In an effort to simplify things for a future push of dev_priv instead
of dev wherever possible, always take pdev via dev_priv where
feasible, eliminating the direct access from dev. Right now this
only eliminates a few cases of dev, but it also obviates that we pass
dev into a lot of functions where dev_priv would be the more obvious
choice.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c | 58 +++--
 drivers/gpu/drm/i915/i915_gem_gtt.c | 34 +++
 drivers/gpu/drm/i915/i915_gem_stolen.c  | 17 +-
 drivers/gpu/drm/i915/i915_gpu_error.c   |  9 ++---
 drivers/gpu/drm/i915/i915_suspend.c |  6 ++--
 drivers/gpu/drm/i915/intel_display.c| 25 +-
 drivers/gpu/drm/i915/intel_fbdev.c  |  3 +-
 drivers/gpu/drm/i915/intel_guc_loader.c |  3 +-
 drivers/gpu/drm/i915/intel_i2c.c|  3 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 30 +
 drivers/gpu/drm/i915/intel_sdvo.c   |  4 ++-
 11 files changed, 113 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b186e342f548..7a495f2bb4c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -232,6 +232,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
drm_i915_getparam_t *param = data;
int value;
 
@@ -242,10 +243,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
/* Reject all old ums/dri params. */
return -ENODEV;
case I915_PARAM_CHIPSET_ID:
-   value = dev->pdev->device;
+   value = pdev->device;
break;
case I915_PARAM_REVISION:
-   value = dev->pdev->revision;
+   value = pdev->revision;
break;
case I915_PARAM_HAS_GEM:
value = 1;
@@ -516,7 +517,7 @@ static void i915_switcheroo_set_state(struct pci_dev *pdev, 
enum vga_switcheroo_
pr_info("switched on\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
/* i915 resume handler doesn't set to D0 */
-   pci_set_power_state(dev->pdev, PCI_D0);
+   pci_set_power_state(pdev, PCI_D0);
i915_resume_switcheroo(dev);
dev->switch_power_state = DRM_SWITCH_POWER_ON;
} else {
@@ -585,6 +586,7 @@ static void i915_gem_fini(struct drm_device *dev)
 static int i915_load_modeset_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
int ret;
 
if (i915_inject_load_failure())
@@ -601,13 +603,13 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * then we do not take part in VGA arbitration and the
 * vga_client_register() fails with -ENODEV.
 */
-   ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
+   ret = vga_client_register(pdev, dev, NULL, i915_vga_set_decode);
if (ret && ret != -ENODEV)
goto out;
 
intel_register_dsm_handler();
 
-   ret = vga_switcheroo_register_client(dev->pdev, _switcheroo_ops, 
false);
+   ret = vga_switcheroo_register_client(pdev, _switcheroo_ops, false);
if (ret)
goto cleanup_vga_client;
 
@@ -659,9 +661,9 @@ cleanup_irq:
 cleanup_csr:
intel_csr_ucode_fini(dev_priv);
intel_power_domains_fini(dev_priv);
-   vga_switcheroo_unregister_client(dev->pdev);
+   vga_switcheroo_unregister_client(pdev);
 cleanup_vga_client:
-   vga_client_register(dev->pdev, NULL, NULL, NULL);
+   vga_client_register(pdev, NULL, NULL, NULL);
 out:
return ret;
 }
@@ -879,6 +881,7 @@ static void i915_driver_cleanup_early(struct 
drm_i915_private *dev_priv)
 static int i915_mmio_setup(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
int mmio_bar;
int mmio_size;
 
@@ -895,7 +898,7 @@ static int i915_mmio_setup(struct drm_device *dev)
mmio_size = 512 * 1024;
else
mmio_size = 2 * 1024 * 1024;
-   dev_priv->regs = pci_iomap(dev->pdev, mmio_bar, mmio_size);
+   dev_priv->regs = pci_iomap(pdev, mmio_bar, mmio_size);
if (dev_priv->regs == NULL) {
DRM_ERROR("failed to map registers\n");
 
@@ -911,9 +914,10 @@ static int i915_mmio_setup(struct drm_device *dev)
 static void i915_mmio_cleanup(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
 
intel_teardown_mchbar(dev);
-   

[Intel-gfx] [PATCH 2/4] drm/i915: Consistent struct device naming

2016-08-01 Thread David Weinehall
We currently have a mix of struct device *device, struct device *kdev,
and struct device *dev (the latter forcing us to refer to
struct drm_device as something else than the normal dev).

To simplify things, always use kdev when referring to struct device.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c | 96 -
 drivers/gpu/drm/i915/i915_drv.h |  4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  6 +--
 drivers/gpu/drm/i915/i915_sysfs.c   | 62 ++---
 drivers/gpu/drm/i915/intel_audio.c  | 38 ++---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 36 ++---
 6 files changed, 121 insertions(+), 121 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 83afdd0597b5..b186e342f548 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -77,7 +77,7 @@ __i915_printk(struct drm_i915_private *dev_priv, const char 
*level,
  const char *fmt, ...)
 {
static bool shown_bug_once;
-   struct device *dev = dev_priv->drm.dev;
+   struct device *kdev = dev_priv->drm.dev;
bool is_error = level[1] <= KERN_ERR[1];
bool is_debug = level[1] == KERN_DEBUG[1];
struct va_format vaf;
@@ -91,11 +91,11 @@ __i915_printk(struct drm_i915_private *dev_priv, const char 
*level,
vaf.fmt = fmt;
vaf.va = 
 
-   dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
+   dev_printk(level, kdev, "[" DRM_NAME ":%ps] %pV",
   __builtin_return_address(0), );
 
if (is_error && !shown_bug_once) {
-   dev_notice(dev, "%s", FDO_BUG_MSG);
+   dev_notice(kdev, "%s", FDO_BUG_MSG);
shown_bug_once = true;
}
 
@@ -1475,9 +1475,9 @@ out:
return error;
 }
 
-static int i915_drm_suspend_late(struct drm_device *drm_dev, bool hibernation)
+static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
 {
-   struct drm_i915_private *dev_priv = to_i915(drm_dev);
+   struct drm_i915_private *dev_priv = to_i915(dev);
bool fw_csr;
int ret;
 
@@ -1511,7 +1511,7 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
goto out;
}
 
-   pci_disable_device(drm_dev->pdev);
+   pci_disable_device(dev->pdev);
/*
 * During hibernation on some platforms the BIOS may try to access
 * the device even though it's already in D3 and hang the machine. So
@@ -1525,7 +1525,7 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
 * Acer Aspire 1830T
 */
if (!(hibernation && INTEL_INFO(dev_priv)->gen < 6))
-   pci_set_power_state(drm_dev->pdev, PCI_D3hot);
+   pci_set_power_state(dev->pdev, PCI_D3hot);
 
dev_priv->suspended_to_idle = suspend_to_idle(dev_priv);
 
@@ -1822,25 +1822,25 @@ error:
return ret;
 }
 
-static int i915_pm_suspend(struct device *dev)
+static int i915_pm_suspend(struct device *kdev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct drm_device *drm_dev = pci_get_drvdata(pdev);
+   struct pci_dev *pdev = to_pci_dev(kdev);
+   struct drm_device *dev = pci_get_drvdata(pdev);
 
-   if (!drm_dev) {
-   dev_err(dev, "DRM not initialized, aborting suspend.\n");
+   if (!dev) {
+   dev_err(kdev, "DRM not initialized, aborting suspend.\n");
return -ENODEV;
}
 
-   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
 
-   return i915_drm_suspend(drm_dev);
+   return i915_drm_suspend(dev);
 }
 
-static int i915_pm_suspend_late(struct device *dev)
+static int i915_pm_suspend_late(struct device *kdev)
 {
-   struct drm_device *drm_dev = _to_i915(dev)->drm;
+   struct drm_device *dev = _to_i915(kdev)->drm;
 
/*
 * We have a suspend ordering issue with the snd-hda driver also
@@ -1851,57 +1851,57 @@ static int i915_pm_suspend_late(struct device *dev)
 * FIXME: This should be solved with a special hdmi sink device or
 * similar so that power domains can be employed.
 */
-   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
 
-   return i915_drm_suspend_late(drm_dev, false);
+   return i915_drm_suspend_late(dev, false);
 }
 
-static int i915_pm_poweroff_late(struct device *dev)
+static int i915_pm_poweroff_late(struct device *kdev)
 {
-   struct drm_device *drm_dev = _to_i915(dev)->drm;
+   struct drm_device *dev = _to_i915(kdev)->drm;
 
-   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 

[Intel-gfx] [PATCH 1/4] drm/i915: Cosmetic fixes in i915_drv.h

2016-08-01 Thread David Weinehall
Fix minor whitespace issues plus a typo.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65ada5d2f88c..88c3acda7194 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2520,7 +2520,7 @@ struct drm_i915_cmd_table {
BUILD_BUG(); \
__p; \
 })
-#define INTEL_INFO(p)  (&__I915__(p)->info)
+#define INTEL_INFO(p)  (&__I915__(p)->info)
 #define INTEL_GEN(p)   (INTEL_INFO(p)->gen)
 #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
 
@@ -2814,7 +2814,7 @@ extern int i915_suspend_switcheroo(struct drm_device 
*dev, pm_message_t state);
 extern int i915_resume_switcheroo(struct drm_device *dev);
 
 int intel_sanitize_enable_ppgtt(struct drm_i915_private *dev_priv,
-   int enable_ppgtt);
+   int enable_ppgtt);
 
 bool intel_sanitize_semaphores(struct drm_i915_private *dev_priv, int value);
 
@@ -3768,7 +3768,7 @@ __raw_write(64, q)
 #undef __raw_write
 
 /* These are untraced mmio-accessors that are only valid to be used inside
- * criticial sections inside IRQ handlers where forcewake is explicitly
+ * critical sections inside IRQ handlers where forcewake is explicitly
  * controlled.
  * Think twice, and think again, before using these.
  * Note: Should only be used between intel_uncore_forcewake_irqlock() and
-- 
2.8.1

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


[Intel-gfx] [PATCH 0/4] Various cleanup

2016-08-01 Thread David Weinehall
To improve consistency in the driver, and to pave the way for
further cleanup patches, do various bits of tidying.

David Weinehall (4):
  drm/i915: Cosmetic fixes in i915_drv.h
  drm/i915: Consistent struct device naming
  drm/i915: Consistent drm_minor use
  drm/i915: pdev cleanup

 drivers/gpu/drm/i915/i915_drv.c | 150 +---
 drivers/gpu/drm/i915/i915_drv.h |  10 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c |  40 +
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  17 ++--
 drivers/gpu/drm/i915/i915_gpu_error.c   |   9 +-
 drivers/gpu/drm/i915/i915_suspend.c |   6 +-
 drivers/gpu/drm/i915/i915_sysfs.c   |  90 +--
 drivers/gpu/drm/i915/intel_audio.c  |  38 
 drivers/gpu/drm/i915/intel_display.c|  25 --
 drivers/gpu/drm/i915/intel_fbdev.c  |   3 +-
 drivers/gpu/drm/i915/intel_guc_loader.c |   3 +-
 drivers/gpu/drm/i915/intel_i2c.c|   3 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |  56 ++--
 drivers/gpu/drm/i915/intel_sdvo.c   |   4 +-
 14 files changed, 244 insertions(+), 210 deletions(-)

-- 
2.8.1

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


[Intel-gfx] [PATCH 3/4] drm/i915: Consistent drm_minor use

2016-08-01 Thread David Weinehall
Use consistent naming for drm_minor, and always use kdev_to_drm_minor()
to convert kdev to drm_minor.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_sysfs.c | 52 +++
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 1e679ce394b8..33797b295b64 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -76,7 +76,7 @@ show_rc6_mask(struct device *kdev, struct device_attribute 
*attr, char *buf)
 static ssize_t
 show_rc6_ms(struct device *kdev, struct device_attribute *attr, char *buf)
 {
-   struct drm_minor *dminor = dev_get_drvdata(kdev);
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
u32 rc6_residency = calc_residency(dminor->dev, GEN6_GT_GFX_RC6);
return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
 }
@@ -100,7 +100,7 @@ show_rc6pp_ms(struct device *kdev, struct device_attribute 
*attr, char *buf)
 static ssize_t
 show_media_rc6_ms(struct device *kdev, struct device_attribute *attr, char 
*buf)
 {
-   struct drm_minor *dminor = dev_get_drvdata(kdev);
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
u32 rc6_residency = calc_residency(dminor->dev, VLV_GT_MEDIA_RC6);
return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
 }
@@ -266,8 +266,8 @@ static struct bin_attribute dpf_attrs_1 = {
 static ssize_t gt_act_freq_mhz_show(struct device *kdev,
struct device_attribute *attr, char *buf)
 {
-   struct drm_minor *minor = kdev_to_drm_minor(kdev);
-   struct drm_device *dev = minor->dev;
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
int ret;
 
@@ -298,8 +298,8 @@ static ssize_t gt_act_freq_mhz_show(struct device *kdev,
 static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
struct device_attribute *attr, char *buf)
 {
-   struct drm_minor *minor = kdev_to_drm_minor(kdev);
-   struct drm_device *dev = minor->dev;
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
return snprintf(buf, PAGE_SIZE, "%d\n",
@@ -309,8 +309,8 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
 
 static ssize_t gt_boost_freq_mhz_show(struct device *kdev, struct 
device_attribute *attr, char *buf)
 {
-   struct drm_minor *minor = kdev_to_drm_minor(kdev);
-   struct drm_i915_private *dev_priv = to_i915(minor->dev);
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
+   struct drm_i915_private *dev_priv = to_i915(dminor->dev);
 
return snprintf(buf, PAGE_SIZE, "%d\n",
intel_gpu_freq(dev_priv,
@@ -321,8 +321,8 @@ static ssize_t gt_boost_freq_mhz_store(struct device *kdev,
   struct device_attribute *attr,
   const char *buf, size_t count)
 {
-   struct drm_minor *minor = kdev_to_drm_minor(kdev);
-   struct drm_device *dev = minor->dev;
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
u32 val;
ssize_t ret;
@@ -346,8 +346,8 @@ static ssize_t gt_boost_freq_mhz_store(struct device *kdev,
 static ssize_t vlv_rpe_freq_mhz_show(struct device *kdev,
 struct device_attribute *attr, char *buf)
 {
-   struct drm_minor *minor = kdev_to_drm_minor(kdev);
-   struct drm_device *dev = minor->dev;
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
return snprintf(buf, PAGE_SIZE, "%d\n",
@@ -357,8 +357,8 @@ static ssize_t vlv_rpe_freq_mhz_show(struct device *kdev,
 
 static ssize_t gt_max_freq_mhz_show(struct device *kdev, struct 
device_attribute *attr, char *buf)
 {
-   struct drm_minor *minor = kdev_to_drm_minor(kdev);
-   struct drm_device *dev = minor->dev;
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
return snprintf(buf, PAGE_SIZE, "%d\n",
@@ -370,8 +370,8 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
 struct device_attribute *attr,
 const char *buf, size_t count)
 {
-   struct drm_minor *minor = kdev_to_drm_minor(kdev);
-   struct drm_device *dev = minor->dev;
+   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
+   struct drm_device *dev = dminor->dev;
struct 

Re: [Intel-gfx] [PATCH 0/9] drm: Store clipped coordinates in drm_plane_state

2016-08-01 Thread Ville Syrjälä
On Mon, Aug 01, 2016 at 11:12:05AM -0400, Sean Paul wrote:
> On Tue, Jul 26, 2016 at 12:06 PM,   wrote:
> > From: Ville Syrjälä 
> >
> > Moving the clipped plane coordinates into drm_plane_state has been
> > discussed a few times, but as no patches seems to have materialized,
> > I decoded to do it myself. I also added a new helper function
> > like drm_plane_helper_check_update() that takes a plane state instead.
> >
> > I converted i915, rockchip, and mediatek over to the new stuff. rockchip
> > already looked pretty solid, mediatek had some bugs in there that I
> > hopefully fixed. The rest of the non-x86 drivers seem to entirely lack
> > any plane clipping code, so I decided that I don't care enough to
> > write it from scratch. I also converted drm_simple_kms_helper, but
> > there are no drivers using it so far.
> >
> > I've only actually tested i915, the rest are just compile tested.
> >
> > Entire series available here:
> > git://github.com/vsyrjala/linux.git plane_state_rects
> >
> > Ville Syrjälä (9):
> >   drm: Warn about negative sizes when calculating scale factor
> >   drm: Store clipped src/dst coordinatee in drm_plane_state
> >   drm/plane-helper: Add drm_plane_helper_check_state()
> >   drm/i915: Use drm_plane_state.{src,dst,visible}
> >   drm/i915: Use drm_plane_helper_check_state()
> >   drm/rockchip: Use drm_plane_state.{src,dst}
> >   drm/rockchip: Use drm_plane_helper_check_state()
> >   drm/mediatek: Use drm_plane_helper_check_state()
> >   drm/simple_kms_helper: Use drm_plane_helper_check_state()
> 
> 
> Looks good to me, all patches have been reviewed.
> 
> It seems like the only consumer of drm_plane_helper_check_update()
> left is armada. Are you planning on converting it as well? Then we can
> nuke the function.

IIRC that driver isn't atomic enough for the new function.

> 
> Sean
> 
> >
> >  drivers/gpu/drm/drm_plane_helper.c  | 136 
> > +--
> >  drivers/gpu/drm/drm_rect.c  |   2 +-
> >  drivers/gpu/drm/drm_simple_kms_helper.c |  27 ++
> >  drivers/gpu/drm/i915/intel_atomic_plane.c   |  18 +---
> >  drivers/gpu/drm/i915/intel_display.c| 140 
> > ++--
> >  drivers/gpu/drm/i915/intel_drv.h|   3 -
> >  drivers/gpu/drm/i915/intel_fbc.c|  12 +--
> >  drivers/gpu/drm/i915/intel_pm.c |  60 ++--
> >  drivers/gpu/drm/i915/intel_sprite.c |  94 ++-
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  72 --
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  31 ++
> >  include/drm/drm_crtc.h  |  13 +++
> >  include/drm/drm_plane_helper.h  |   5 +
> >  13 files changed, 315 insertions(+), 298 deletions(-)
> >
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [Intel-gfx] [PATCH 0/9] drm: Store clipped coordinates in drm_plane_state

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:06 PM,   wrote:
> From: Ville Syrjälä 
>
> Moving the clipped plane coordinates into drm_plane_state has been
> discussed a few times, but as no patches seems to have materialized,
> I decoded to do it myself. I also added a new helper function
> like drm_plane_helper_check_update() that takes a plane state instead.
>
> I converted i915, rockchip, and mediatek over to the new stuff. rockchip
> already looked pretty solid, mediatek had some bugs in there that I
> hopefully fixed. The rest of the non-x86 drivers seem to entirely lack
> any plane clipping code, so I decided that I don't care enough to
> write it from scratch. I also converted drm_simple_kms_helper, but
> there are no drivers using it so far.
>
> I've only actually tested i915, the rest are just compile tested.
>
> Entire series available here:
> git://github.com/vsyrjala/linux.git plane_state_rects
>
> Ville Syrjälä (9):
>   drm: Warn about negative sizes when calculating scale factor
>   drm: Store clipped src/dst coordinatee in drm_plane_state
>   drm/plane-helper: Add drm_plane_helper_check_state()
>   drm/i915: Use drm_plane_state.{src,dst,visible}
>   drm/i915: Use drm_plane_helper_check_state()
>   drm/rockchip: Use drm_plane_state.{src,dst}
>   drm/rockchip: Use drm_plane_helper_check_state()
>   drm/mediatek: Use drm_plane_helper_check_state()
>   drm/simple_kms_helper: Use drm_plane_helper_check_state()


Looks good to me, all patches have been reviewed.

It seems like the only consumer of drm_plane_helper_check_update()
left is armada. Are you planning on converting it as well? Then we can
nuke the function.

Sean

>
>  drivers/gpu/drm/drm_plane_helper.c  | 136 +--
>  drivers/gpu/drm/drm_rect.c  |   2 +-
>  drivers/gpu/drm/drm_simple_kms_helper.c |  27 ++
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  18 +---
>  drivers/gpu/drm/i915/intel_display.c| 140 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h|   3 -
>  drivers/gpu/drm/i915/intel_fbc.c|  12 +--
>  drivers/gpu/drm/i915/intel_pm.c |  60 ++--
>  drivers/gpu/drm/i915/intel_sprite.c |  94 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|  72 --
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  31 ++
>  include/drm/drm_crtc.h  |  13 +++
>  include/drm/drm_plane_helper.h  |   5 +
>  13 files changed, 315 insertions(+), 298 deletions(-)
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 6/9] drm/rockchip: Use drm_plane_state.{src, dst}

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:07 PM,   wrote:
> From: Ville Syrjälä 
>
> Replace the private drm_rects in vop_plane_state with
> the ones now living in drm_plane_state.
>
> Cc: Yao 
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 91305eb7d312..c566c740ab49 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -87,8 +87,6 @@
>  struct vop_plane_state {
> struct drm_plane_state base;
> int format;
> -   struct drm_rect src;
> -   struct drm_rect dest;
> dma_addr_t yrgb_mst;
> bool enable;
>  };
> @@ -595,8 +593,8 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
> const struct vop_win_data *win = vop_win->data;
> bool visible;
> int ret;
> -   struct drm_rect *dest = _plane_state->dest;
> -   struct drm_rect *src = _plane_state->src;
> +   struct drm_rect *dest = >dst;
> +   struct drm_rect *src = >src;
> struct drm_rect clip;
> int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
> DRM_PLANE_HELPER_NO_SCALING;
> @@ -694,8 +692,8 @@ static void vop_plane_atomic_update(struct drm_plane 
> *plane,
> unsigned int actual_w, actual_h;
> unsigned int dsp_stx, dsp_sty;
> uint32_t act_info, dsp_info, dsp_st;
> -   struct drm_rect *src = _plane_state->src;
> -   struct drm_rect *dest = _plane_state->dest;
> +   struct drm_rect *src = >src;
> +   struct drm_rect *dest = >dst;
> struct drm_gem_object *obj, *uv_obj;
> struct rockchip_gem_object *rk_obj, *rk_uv_obj;
> unsigned long offset;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 9/9] drm/simple_kms_helper: Use drm_plane_helper_check_state()

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:07 PM,   wrote:
> From: Ville Syrjälä 
>
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
>
> I don't see any actual users of drm_simple_kms_helper yet, so
> no actual plane clipping bugs to fix.
>
> Cc: Noralf Trønnes 
> Signed-off-by: Ville Syrjälä 


Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 27 ++-
>  1 file changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0db36d27e90b..0a02efe978ee 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -73,22 +73,9 @@ static const struct drm_crtc_funcs 
> drm_simple_kms_crtc_funcs = {
>  static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *plane_state)
>  {
> -   struct drm_rect src = {
> -   .x1 = plane_state->src_x,
> -   .y1 = plane_state->src_y,
> -   .x2 = plane_state->src_x + plane_state->src_w,
> -   .y2 = plane_state->src_y + plane_state->src_h,
> -   };
> -   struct drm_rect dest = {
> -   .x1 = plane_state->crtc_x,
> -   .y1 = plane_state->crtc_y,
> -   .x2 = plane_state->crtc_x + plane_state->crtc_w,
> -   .y2 = plane_state->crtc_y + plane_state->crtc_h,
> -   };
> struct drm_rect clip = { 0 };
> struct drm_simple_display_pipe *pipe;
> struct drm_crtc_state *crtc_state;
> -   bool visible;
> int ret;
>
> pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> @@ -102,17 +89,15 @@ static int drm_simple_kms_plane_atomic_check(struct 
> drm_plane *plane,
>
> clip.x2 = crtc_state->adjusted_mode.hdisplay;
> clip.y2 = crtc_state->adjusted_mode.vdisplay;
> -   ret = drm_plane_helper_check_update(plane, >crtc,
> -   plane_state->fb,
> -   , , ,
> -   plane_state->rotation,
> -   DRM_PLANE_HELPER_NO_SCALING,
> -   DRM_PLANE_HELPER_NO_SCALING,
> -   false, true, );
> +
> +   ret = drm_plane_helper_check_state(plane_state, ,
> +  DRM_PLANE_HELPER_NO_SCALING,
> +  DRM_PLANE_HELPER_NO_SCALING,
> +  false, true);
> if (ret)
> return ret;
>
> -   if (!visible)
> +   if (!plane_state->visible)
> return -EINVAL;
>
> if (!pipe->funcs || !pipe->funcs->check)
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 8/9] drm/mediatek: Use drm_plane_helper_check_state()

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:07 PM,   wrote:
> From: Ville Syrjälä 
>
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
>
> This also eliminates the double clipping the driver was doing
> in both check and commit phases). And it should fix src coordinate
> addr adjustement. Previously the driver was expecting negative dst
> coordinates after clipping, which is not going happen, so any clipping
> induced addr adjustment simply didn't happen. Neither did the driver
> respect any user configured src coordinates, so panning and such would
> have been totally broken. It should be all good now.
>
> Cc: CK Hu 
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Ville Syrjälä 


Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 72 
> +---
>  1 file changed, 20 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 3995765a90dc..5f2516fca079 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -30,15 +30,20 @@ static const u32 formats[] = {
> DRM_FORMAT_RGB565,
>  };
>
> -static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane, bool enable,
> -dma_addr_t addr, struct drm_rect *dest)
> +static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane,
> +dma_addr_t addr)
>  {
> struct drm_plane *plane = _plane->base;
> struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> unsigned int pitch, format;
> -   int x, y;
> +   bool enable;
>
> -   if (WARN_ON(!plane->state || (enable && !plane->state->fb)))
> +   if (WARN_ON(!plane->state))
> +   return;
> +
> +   enable = state->base.visible;
> +
> +   if (WARN_ON(enable && !plane->state->fb))
> return;
>
> if (plane->state->fb) {
> @@ -49,27 +54,17 @@ static void mtk_plane_enable(struct mtk_drm_plane 
> *mtk_plane, bool enable,
> format = DRM_FORMAT_RGBA;
> }
>
> -   x = plane->state->crtc_x;
> -   y = plane->state->crtc_y;
> -
> -   if (x < 0) {
> -   addr -= x * 4;
> -   x = 0;
> -   }
> -
> -   if (y < 0) {
> -   addr -= y * pitch;
> -   y = 0;
> -   }
> +   addr += (state->base.src.x1 >> 16) * 4;
> +   addr += (state->base.src.y1 >> 16) * pitch;
>
> state->pending.enable = enable;
> state->pending.pitch = pitch;
> state->pending.format = format;
> state->pending.addr = addr;
> -   state->pending.x = x;
> -   state->pending.y = y;
> -   state->pending.width = dest->x2 - dest->x1;
> -   state->pending.height = dest->y2 - dest->y1;
> +   state->pending.x = state->base.dst.x1;
> +   state->pending.y = state->base.dst.y1;
> +   state->pending.width = drm_rect_width(>base.dst);
> +   state->pending.height = drm_rect_height(>base.dst);
> wmb(); /* Make sure the above parameters are set before update */
> state->pending.dirty = true;
>  }
> @@ -134,20 +129,6 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>  {
> struct drm_framebuffer *fb = state->fb;
> struct drm_crtc_state *crtc_state;
> -   bool visible;
> -   struct drm_rect dest = {
> -   .x1 = state->crtc_x,
> -   .y1 = state->crtc_y,
> -   .x2 = state->crtc_x + state->crtc_w,
> -   .y2 = state->crtc_y + state->crtc_h,
> -   };
> -   struct drm_rect src = {
> -   /* 16.16 fixed point */
> -   .x1 = state->src_x,
> -   .y1 = state->src_y,
> -   .x2 = state->src_x + state->src_w,
> -   .y2 = state->src_y + state->src_h,
> -   };
> struct drm_rect clip = { 0, };
>
> if (!fb)
> @@ -168,12 +149,10 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
> clip.x2 = crtc_state->mode.hdisplay;
> clip.y2 = crtc_state->mode.vdisplay;
>
> -   return drm_plane_helper_check_update(plane, state->crtc, fb,
> -, , ,
> -state->rotation,
> -DRM_PLANE_HELPER_NO_SCALING,
> -DRM_PLANE_HELPER_NO_SCALING,
> -true, true, );
> +   return drm_plane_helper_check_state(state, ,
> +   DRM_PLANE_HELPER_NO_SCALING,
> +   DRM_PLANE_HELPER_NO_SCALING,
> +   true, 

Re: [Intel-gfx] [PATCH 7/9] drm/rockchip: Use drm_plane_helper_check_state()

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:07 PM,   wrote:
> From: Ville Syrjälä 
>
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
>
> Rockchip looks to handling plane clipping rather well already
> (unlikje most arm drm drivers) so there are no function changes
> here.
>
> Cc: Yao 
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Ville Syrjälä 


Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 25 +
>  1 file changed, 5 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index c566c740ab49..31744fe99b38 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -591,10 +591,7 @@ static int vop_plane_atomic_check(struct drm_plane 
> *plane,
> struct vop_win *vop_win = to_vop_win(plane);
> struct vop_plane_state *vop_plane_state = to_vop_plane_state(state);
> const struct vop_win_data *win = vop_win->data;
> -   bool visible;
> int ret;
> -   struct drm_rect *dest = >dst;
> -   struct drm_rect *src = >src;
> struct drm_rect clip;
> int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
> DRM_PLANE_HELPER_NO_SCALING;
> @@ -608,30 +605,18 @@ static int vop_plane_atomic_check(struct drm_plane 
> *plane,
> if (WARN_ON(!crtc_state))
> return -EINVAL;
>
> -   src->x1 = state->src_x;
> -   src->y1 = state->src_y;
> -   src->x2 = state->src_x + state->src_w;
> -   src->y2 = state->src_y + state->src_h;
> -   dest->x1 = state->crtc_x;
> -   dest->y1 = state->crtc_y;
> -   dest->x2 = state->crtc_x + state->crtc_w;
> -   dest->y2 = state->crtc_y + state->crtc_h;
> -
> clip.x1 = 0;
> clip.y1 = 0;
> clip.x2 = crtc_state->adjusted_mode.hdisplay;
> clip.y2 = crtc_state->adjusted_mode.vdisplay;
>
> -   ret = drm_plane_helper_check_update(plane, crtc, state->fb,
> -   src, dest, ,
> -   state->rotation,
> -   min_scale,
> -   max_scale,
> -   true, true, );
> +   ret = drm_plane_helper_check_state(state, ,
> +  min_scale, max_scale,
> +  true, true);
> if (ret)
> return ret;
>
> -   if (!visible)
> +   if (!state->visible)
> goto out_disable;
>
> vop_plane_state->format = vop_convert_format(fb->pixel_format);
> @@ -642,7 +627,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
>  * Src.x1 can be odd when do clip, but yuv plane start point
>  * need align with 2 pixel.
>  */
> -   if (is_yuv_support(fb->pixel_format) && ((src->x1 >> 16) % 2))
> +   if (is_yuv_support(fb->pixel_format) && ((state->src.x1 >> 16) % 2))
> return -EINVAL;
>
> vop_plane_state->enable = true;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use drm_plane_helper_check_state()

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:07 PM,   wrote:
> From: Ville Syrjälä 
>
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
>
> Signed-off-by: Ville Syrjälä 


Reviewed-by: Sean Paul 


> ---
>  drivers/gpu/drm/i915/intel_atomic_plane.c | 14 --
>  drivers/gpu/drm/i915/intel_display.c  | 26 +-
>  drivers/gpu/drm/i915/intel_sprite.c   | 10 ++
>  3 files changed, 19 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 14d40261db21..2d831dd43d44 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -134,20 +134,6 @@ static int intel_plane_atomic_check(struct drm_plane 
> *plane,
>
> crtc_state = to_intel_crtc_state(drm_crtc_state);
>
> -   /*
> -* The original src/dest coordinates are stored in state->base, but
> -* we want to keep another copy internal to our driver that we can
> -* clip/modify ourselves.
> -*/
> -   intel_state->base.src.x1 = state->src_x;
> -   intel_state->base.src.y1 = state->src_y;
> -   intel_state->base.src.x2 = state->src_x + state->src_w;
> -   intel_state->base.src.y2 = state->src_y + state->src_h;
> -   intel_state->base.dst.x1 = state->crtc_x;
> -   intel_state->base.dst.y1 = state->crtc_y;
> -   intel_state->base.dst.x2 = state->crtc_x + state->crtc_w;
> -   intel_state->base.dst.y2 = state->crtc_y + state->crtc_h;
> -
> /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
> intel_state->clip.x1 = 0;
> intel_state->clip.y1 = 0;
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 4f67b7c19b75..eae8a72bad5a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14126,7 +14126,6 @@ intel_check_primary_plane(struct drm_plane *plane,
>   struct intel_plane_state *state)
>  {
> struct drm_crtc *crtc = state->base.crtc;
> -   struct drm_framebuffer *fb = state->base.fb;
> int min_scale = DRM_PLANE_HELPER_NO_SCALING;
> int max_scale = DRM_PLANE_HELPER_NO_SCALING;
> bool can_position = false;
> @@ -14140,14 +14139,10 @@ intel_check_primary_plane(struct drm_plane *plane,
> can_position = true;
> }
>
> -   return drm_plane_helper_check_update(plane, crtc, fb,
> ->base.src,
> ->base.dst,
> ->base.clip,
> -state->base.rotation,
> -min_scale, max_scale,
> -can_position, true,
> ->base.visible);
> +   return drm_plane_helper_check_state(>base,
> +   >clip,
> +   min_scale, max_scale,
> +   can_position, true);
>  }
>
>  static void intel_begin_crtc_commit(struct drm_crtc *crtc,
> @@ -14327,20 +14322,17 @@ intel_check_cursor_plane(struct drm_plane *plane,
>  struct intel_crtc_state *crtc_state,
>  struct intel_plane_state *state)
>  {
> -   struct drm_crtc *crtc = crtc_state->base.crtc;
> struct drm_framebuffer *fb = state->base.fb;
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> enum pipe pipe = to_intel_plane(plane)->pipe;
> unsigned stride;
> int ret;
>
> -   ret = drm_plane_helper_check_update(plane, crtc, fb, >base.src,
> -   >base.dst,
> -   >base.clip,
> -   state->base.rotation,
> -   DRM_PLANE_HELPER_NO_SCALING,
> -   DRM_PLANE_HELPER_NO_SCALING,
> -   true, true, >base.visible);
> +   ret = drm_plane_helper_check_state(>base,
> +  >clip,
> +  DRM_PLANE_HELPER_NO_SCALING,
> +  DRM_PLANE_HELPER_NO_SCALING,
> +  true, true);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 10f10915c0bc..b38956624f04 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ 

Re: [Intel-gfx] [PATCH v2 3/9] drm/plane-helper: Add drm_plane_helper_check_state()

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 1:34 PM,   wrote:
> From: Ville Syrjälä 
>
> Add a version of drm_plane_helper_check_update() which takes a plane
> state instead of having the caller pass in everything.
>
> And to reduce code duplication, let's reimplement
> drm_plane_helper_check_update() in terms of the new function, by
> having a tempororary plane state on the stack.
>
> v2: Add a note that the functions modifies the state (Chris)
>
> Cc: Chris Wilson 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_plane_helper.c | 139 
> -
>  include/drm/drm_plane_helper.h |   5 ++
>  2 files changed, 112 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 16c4a7bd7465..ca02997b1c36 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -108,14 +108,9 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
>  }
>
>  /**
> - * drm_plane_helper_check_update() - Check plane update for validity
> - * @plane: plane object to update
> - * @crtc: owning CRTC of owning plane
> - * @fb: framebuffer to flip onto plane
> - * @src: source coordinates in 16.16 fixed point
> - * @dest: integer destination coordinates
> + * drm_plane_helper_check_state() - Check plane state for validity
> + * @state: plane state to check
>   * @clip: integer clipping coordinates
> - * @rotation: plane rotation
>   * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
>   * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
>   * @can_position: is it legal to position the plane such that it
> @@ -123,10 +118,9 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
>   *only be false for primary planes.
>   * @can_update_disabled: can the plane be updated while the crtc
>   *   is disabled?
> - * @visible: output parameter indicating whether plane is still visible after
> - *   clipping
>   *
> - * Checks that a desired plane update is valid.  Drivers that provide
> + * Checks that a desired plane update is valid, and updates various
> + * bits of derived state (clipped coordinates etc.). Drivers that provide
>   * their own plane handling rather than helper-provided implementations may
>   * still wish to call this function to avoid duplication of error checking
>   * code.
> @@ -134,29 +128,38 @@ static int get_connectors_for_crtc(struct drm_crtc 
> *crtc,
>   * RETURNS:
>   * Zero if update appears valid, error code on failure
>   */
> -int drm_plane_helper_check_update(struct drm_plane *plane,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_rect *src,
> - struct drm_rect *dest,
> - const struct drm_rect *clip,
> - unsigned int rotation,
> - int min_scale,
> - int max_scale,
> - bool can_position,
> - bool can_update_disabled,
> - bool *visible)
> +int drm_plane_helper_check_state(struct drm_plane_state *state,
> +const struct drm_rect *clip,
> +int min_scale,
> +int max_scale,
> +bool can_position,
> +bool can_update_disabled)
>  {
> +   struct drm_crtc *crtc = state->crtc;
> +   struct drm_framebuffer *fb = state->fb;
> +   struct drm_rect *src = >src;
> +   struct drm_rect *dst = >dst;
> +   unsigned int rotation = state->rotation;
> int hscale, vscale;
>
> +   src->x1 = state->src_x;
> +   src->y1 = state->src_y;
> +   src->x2 = state->src_x + state->src_w;
> +   src->y2 = state->src_y + state->src_h;
> +
> +   dst->x1 = state->crtc_x;
> +   dst->y1 = state->crtc_y;
> +   dst->x2 = state->crtc_x + state->crtc_w;
> +   dst->y2 = state->crtc_y + state->crtc_h;
> +
> if (!fb) {
> -   *visible = false;
> +   state->visible = false;
> return 0;
> }
>
> /* crtc should only be NULL when disabling (i.e., !fb) */
> if (WARN_ON(!crtc)) {
> -   *visible = false;
> +   state->visible = false;
> return 0;
> }
>
> @@ -168,20 +171,20 @@ int drm_plane_helper_check_update(struct drm_plane 
> *plane,
> drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
>
> /* Check scaling */
> -   hscale = 

Re: [Intel-gfx] [PATCH 4/9] drm/i915: Use drm_plane_state.{src, dst, visible}

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:06 PM,   wrote:
> From: Ville Syrjälä 
>
> Replace the private drm_rects/flags in intel_plane_state
> with the ones now living in drm_plane_state.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/i915/intel_atomic_plane.c |  20 ++---
>  drivers/gpu/drm/i915/intel_display.c  | 132 
> +++---
>  drivers/gpu/drm/i915/intel_drv.h  |   3 -
>  drivers/gpu/drm/i915/intel_fbc.c  |  12 +--
>  drivers/gpu/drm/i915/intel_pm.c   |  60 +++---
>  drivers/gpu/drm/i915/intel_sprite.c   |  84 +--
>  6 files changed, 156 insertions(+), 155 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 7de7721f65bc..14d40261db21 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -139,14 +139,14 @@ static int intel_plane_atomic_check(struct drm_plane 
> *plane,
>  * we want to keep another copy internal to our driver that we can
>  * clip/modify ourselves.
>  */
> -   intel_state->src.x1 = state->src_x;
> -   intel_state->src.y1 = state->src_y;
> -   intel_state->src.x2 = state->src_x + state->src_w;
> -   intel_state->src.y2 = state->src_y + state->src_h;
> -   intel_state->dst.x1 = state->crtc_x;
> -   intel_state->dst.y1 = state->crtc_y;
> -   intel_state->dst.x2 = state->crtc_x + state->crtc_w;
> -   intel_state->dst.y2 = state->crtc_y + state->crtc_h;
> +   intel_state->base.src.x1 = state->src_x;
> +   intel_state->base.src.y1 = state->src_y;
> +   intel_state->base.src.x2 = state->src_x + state->src_w;
> +   intel_state->base.src.y2 = state->src_y + state->src_h;
> +   intel_state->base.dst.x1 = state->crtc_x;
> +   intel_state->base.dst.y1 = state->crtc_y;
> +   intel_state->base.dst.x2 = state->crtc_x + state->crtc_w;
> +   intel_state->base.dst.y2 = state->crtc_y + state->crtc_h;
>
> /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
> intel_state->clip.x1 = 0;
> @@ -180,7 +180,7 @@ static int intel_plane_atomic_check(struct drm_plane 
> *plane,
> }
> }
>
> -   intel_state->visible = false;
> +   intel_state->base.visible = false;
> ret = intel_plane->check_plane(plane, crtc_state, intel_state);
> if (ret)
> return ret;
> @@ -196,7 +196,7 @@ static void intel_plane_atomic_update(struct drm_plane 
> *plane,
> to_intel_plane_state(plane->state);
> struct drm_crtc *crtc = plane->state->crtc ?: old_state->crtc;
>
> -   if (intel_state->visible)
> +   if (intel_state->base.visible)
> intel_plane->update_plane(plane,
>   to_intel_crtc_state(crtc->state),
>   intel_state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 78beb7e9d384..4f67b7c19b75 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2565,7 +2565,7 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>  * simplest solution is to just disable the primary plane now and
>  * pretend the BIOS never had it enabled.
>  */
> -   to_intel_plane_state(plane_state)->visible = false;
> +   to_intel_plane_state(plane_state)->base.visible = false;
> crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
> intel_pre_disable_primary_noatomic(_crtc->base);
> intel_plane->disable_plane(primary, _crtc->base);
> @@ -2583,14 +2583,14 @@ valid_fb:
> plane_state->crtc_w = fb->width;
> plane_state->crtc_h = fb->height;
>
> -   intel_state->src.x1 = plane_state->src_x;
> -   intel_state->src.y1 = plane_state->src_y;
> -   intel_state->src.x2 = plane_state->src_x + plane_state->src_w;
> -   intel_state->src.y2 = plane_state->src_y + plane_state->src_h;
> -   intel_state->dst.x1 = plane_state->crtc_x;
> -   intel_state->dst.y1 = plane_state->crtc_y;
> -   intel_state->dst.x2 = plane_state->crtc_x + plane_state->crtc_w;
> -   intel_state->dst.y2 = plane_state->crtc_y + plane_state->crtc_h;
> +   intel_state->base.src.x1 = plane_state->src_x;
> +   intel_state->base.src.y1 = plane_state->src_y;
> +   intel_state->base.src.x2 = plane_state->src_x + plane_state->src_w;
> +   intel_state->base.src.y2 = plane_state->src_y + plane_state->src_h;
> +   intel_state->base.dst.x1 = plane_state->crtc_x;
> +   intel_state->base.dst.y1 = plane_state->crtc_y;
> +   intel_state->base.dst.x2 = plane_state->crtc_x + plane_state->crtc_w;
> +   intel_state->base.dst.y2 = 

Re: [Intel-gfx] [PATCH 2/9] drm: Store clipped src/dst coordinatee in drm_plane_state

2016-08-01 Thread Sean Paul
On Tue, Jul 26, 2016 at 12:06 PM,   wrote:
> From: Ville Syrjälä 
>
> Pretty much all driver will have need for the clipped plane
> coordinates, so let's stuff then into drm_plane_state.
>
> Signed-off-by: Ville Syrjälä 


Reviewed-by: Sean Paul 

> ---
>  include/drm/drm_crtc.h | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3edeaf88ebc0..00a1868940b8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  struct drm_device;
>  struct drm_mode_set;
> @@ -1409,6 +1410,9 @@ struct drm_connector {
>   * @src_w: width of visible portion of plane (in 16.16)
>   * @src_h: height of visible portion of plane (in 16.16)
>   * @rotation: rotation of the plane
> + * @src: clipped source coordinates of the plane (in 16.16)
> + * @dst: clipped destination coordinates of the plane
> + * @visible: visibility of the plane
>   * @state: backpointer to global drm_atomic_state
>   */
>  struct drm_plane_state {
> @@ -1429,6 +1433,15 @@ struct drm_plane_state {
> /* Plane rotation */
> unsigned int rotation;
>
> +   /* Clipped coordinates */
> +   struct drm_rect src, dst;
> +
> +   /*
> +* Is the plane actually visible? Can be false even
> +* if fb!=NULL and crtc!=NULL, due to clipping.
> +*/
> +   bool visible;
> +
> struct drm_atomic_state *state;
>  };
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Take runtime_pm ref for sseu

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 05:48:51PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-01 at 17:33 +0300, David Weinehall wrote:
> > When reading the SSEU statistics, we need to call
> > intel_runtime_pm_get() first, otherwise we might end up
> > triggering "Device suspended during HW access".
> > 
> > Signed-off-by: David Weinehall 
> 
> Reviewed-by: Joonas Lahtinen 

Confidently pushed, thanks.
-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] ✗ Ro.CI.BAT: failure for drm/i915/debugfs: Take runtime_pm ref for sseu

2016-08-01 Thread Patchwork
== Series Details ==

Series: drm/i915/debugfs: Take runtime_pm ref for sseu
URL   : https://patchwork.freedesktop.org/series/10455/
State : failure

== Summary ==

Series 10455v1 drm/i915/debugfs: Take runtime_pm ref for sseu
http://patchwork.freedesktop.org/api/1.0/series/10455/revisions/1/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test gem_exec_gttfill:
Subgroup basic:
skip   -> PASS   (fi-snb-i7-2600)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (fi-hsw-i7-4770k)
pass   -> FAIL   (fi-skl-i7-6700k)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-hsw-i7-4770r)
fail   -> PASS   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)
dmesg-warn -> PASS   (ro-bdw-i7-5557U)

fi-hsw-i7-4770k  total:200  pass:178  dwarn:0   dfail:0   fail:1   skip:20 
fi-kbl-qkkr  total:239  pass:180  dwarn:29  dfail:0   fail:4   skip:26 
fi-skl-i5-6260u  total:239  pass:223  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:239  pass:207  dwarn:0   dfail:0   fail:4   skip:28 
fi-snb-i7-2600   total:239  pass:197  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:239  pass:219  dwarn:4   dfail:0   fail:0   skip:16 
ro-bdw-i7-5557U  total:239  pass:223  dwarn:0   dfail:0   fail:0   skip:16 
ro-bdw-i7-5600u  total:239  pass:206  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:239  pass:193  dwarn:0   dfail:0   fail:4   skip:42 
ro-hsw-i3-4010u  total:239  pass:213  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:239  pass:213  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:239  pass:172  dwarn:1   dfail:0   fail:1   skip:65 
ro-ilk1-i5-650   total:234  pass:172  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:239  pass:204  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:239  pass:208  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:239  pass:221  dwarn:0   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:239  pass:197  dwarn:0   dfail:0   fail:1   skip:41 
ro-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1655/

f1b78d2 drm-intel-nightly: 2016y-07m-29d-19h-16m-57s UTC integration manifest
a275fd2 drm/i915/debugfs: Take runtime_pm ref for sseu

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


Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Take runtime_pm ref for sseu

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 17:33 +0300, David Weinehall wrote:
> When reading the SSEU statistics, we need to call
> intel_runtime_pm_get() first, otherwise we might end up
> triggering "Device suspended during HW access".
> 
> Signed-off-by: David Weinehall 

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 9aa62c5b5f65..531ca0221c7f 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -5238,7 +5238,8 @@ static void broadwell_sseu_device_status(struct 
> drm_device *dev,
>  static int i915_sseu_status(struct seq_file *m, void *unused)
>  {
>   struct drm_info_node *node = (struct drm_info_node *) m->private;
> - struct drm_device *dev = node->minor->dev;
> + struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
> + struct drm_device *dev = _priv->drm;
>   struct sseu_dev_status stat;
>  
>   if (INTEL_INFO(dev)->gen < 8)
> @@ -5268,6 +5269,9 @@ static int i915_sseu_status(struct seq_file *m, void 
> *unused)
>  
>   seq_puts(m, "SSEU Device Status\n");
>   memset(, 0, sizeof(stat));
> +
> + intel_runtime_pm_get(dev_priv);
> +
>   if (IS_CHERRYVIEW(dev)) {
>   cherryview_sseu_device_status(dev, );
>   } else if (IS_BROADWELL(dev)) {
> @@ -5275,6 +5279,9 @@ static int i915_sseu_status(struct seq_file *m, void 
> *unused)
>   } else if (INTEL_INFO(dev)->gen >= 9) {
>   gen9_sseu_device_status(dev, );
>   }
> +
> + intel_runtime_pm_put(dev_priv);
> +
>   seq_printf(m, "  Enabled Slice Total: %u\n",
>      stat.slice_total);
>   seq_printf(m, "  Enabled Subslice Total: %u\n",
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/debugfs: Take runtime_pm ref for sseu

2016-08-01 Thread David Weinehall
When reading the SSEU statistics, we need to call
intel_runtime_pm_get() first, otherwise we might end up
triggering "Device suspended during HW access".

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9aa62c5b5f65..531ca0221c7f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5238,7 +5238,8 @@ static void broadwell_sseu_device_status(struct 
drm_device *dev,
 static int i915_sseu_status(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
+   struct drm_device *dev = _priv->drm;
struct sseu_dev_status stat;
 
if (INTEL_INFO(dev)->gen < 8)
@@ -5268,6 +5269,9 @@ static int i915_sseu_status(struct seq_file *m, void 
*unused)
 
seq_puts(m, "SSEU Device Status\n");
memset(, 0, sizeof(stat));
+
+   intel_runtime_pm_get(dev_priv);
+
if (IS_CHERRYVIEW(dev)) {
cherryview_sseu_device_status(dev, );
} else if (IS_BROADWELL(dev)) {
@@ -5275,6 +5279,9 @@ static int i915_sseu_status(struct seq_file *m, void 
*unused)
} else if (INTEL_INFO(dev)->gen >= 9) {
gen9_sseu_device_status(dev, );
}
+
+   intel_runtime_pm_put(dev_priv);
+
seq_printf(m, "  Enabled Slice Total: %u\n",
   stat.slice_total);
seq_printf(m, "  Enabled Subslice Total: %u\n",
-- 
2.8.1

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


Re: [Intel-gfx] [PATCH 14/73] drm/i915: Unify request submission

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> Move request submission from emit_request into its own common vfunc
> from i915_add_request().
> 
> v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing
> v3: Rename a few functions to match.
> v4: Reenable execlists submission after disabling guc.
> 
> Signed-off-by: Chris Wilson 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-23-git-send-email-ch...@chris-wilson.co.uk
> Reviewed-by: Joonas Lahtinen  #v3

I'll keep mine, Dave might want to give a look too (CC'd).

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_gem_request.c|  8 +++-
>  drivers/gpu/drm/i915/i915_guc_submission.c | 12 +---
>  drivers/gpu/drm/i915/intel_guc.h   |  1 -
>  drivers/gpu/drm/i915/intel_lrc.c   | 26 +++---
>  drivers/gpu/drm/i915/intel_lrc.h   |  2 ++
>  drivers/gpu/drm/i915/intel_ringbuffer.c| 23 +--
>  drivers/gpu/drm/i915/intel_ringbuffer.h| 27 +--
>  7 files changed, 51 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index a885905df3bb..e378eb61979b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -466,12 +466,9 @@ void __i915_add_request(struct drm_i915_gem_request 
> *request,
>    */
>   request->postfix = ring->tail;
>  
> - if (i915.enable_execlists)
> - ret = engine->emit_request(request);
> - else
> - ret = engine->add_request(request);
>   /* Not allowed to fail! */
> - WARN(ret, "emit|add_request failed: %d!\n", ret);
> + ret = engine->emit_request(request);
> + WARN(ret, "(%s)->emit_request failed: %d!\n", engine->name, ret);
>  
>   /* Sanity check that the reserved size was large enough. */
>   ret = ring->tail - request_start;
> @@ -483,6 +480,7 @@ void __i915_add_request(struct drm_i915_gem_request 
> *request,
>     reserved_tail, ret);
>  
>   i915_gem_mark_busy(engine);
> + engine->submit_request(request);
>  }
>  
>  static unsigned long local_clock_us(unsigned int *cpu)
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index eccd34832fe6..23bbd0ff86c7 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -585,7 +585,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
>   * The only error here arises if the doorbell hardware isn't functioning
>   * as expected, which really shouln't happen.
>   */
> -int i915_guc_submit(struct drm_i915_gem_request *rq)
> +static void i915_guc_submit(struct drm_i915_gem_request *rq)
>  {
>   unsigned int engine_id = rq->engine->id;
>   struct intel_guc *guc = >i915->guc;
> @@ -602,8 +602,6 @@ int i915_guc_submit(struct drm_i915_gem_request *rq)
>  
>   guc->submissions[engine_id] += 1;
>   guc->last_seqno[engine_id] = rq->fence.seqno;
> -
> - return b_ret;
>  }
>  
>  /*
> @@ -992,6 +990,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
> *dev_priv)
>  {
>   struct intel_guc *guc = _priv->guc;
>   struct i915_guc_client *client;
> + struct intel_engine_cs *engine;
>  
>   /* client for execbuf submission */
>   client = guc_client_alloc(dev_priv,
> @@ -1006,6 +1005,10 @@ int i915_guc_submission_enable(struct drm_i915_private 
> *dev_priv)
>   host2guc_sample_forcewake(guc, client);
>   guc_init_doorbell_hw(guc);
>  
> + /* Take over from manual control of ELSP (execlists) */
> + for_each_engine(engine, dev_priv)
> + engine->submit_request = i915_guc_submit;
> +
>   return 0;
>  }
>  
> @@ -1015,6 +1018,9 @@ void i915_guc_submission_disable(struct 
> drm_i915_private *dev_priv)
>  
>   guc_client_free(dev_priv, guc->execbuf_client);
>   guc->execbuf_client = NULL;
> +
> + /* Revert back to manual ELSP submission */
> + intel_execlists_enable_submission(dev_priv);
>  }
>  
>  void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> b/drivers/gpu/drm/i915/intel_guc.h
> index 3e3e743740c0..623cf26cd784 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -160,7 +160,6 @@ extern int intel_guc_resume(struct drm_device *dev);
>  int i915_guc_submission_init(struct drm_i915_private *dev_priv);
>  int i915_guc_submission_enable(struct drm_i915_private *dev_priv);
>  int i915_guc_wq_check_space(struct drm_i915_gem_request *rq);
> -int i915_guc_submit(struct drm_i915_gem_request *rq);
>  void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
>  void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
>  
> diff 

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote:
> On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote:
> > 
> > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> > > 
> > > Space reservation is already safe with respect to the ring->size
> > > modulus, but hardware only expects to see values in the range
> > > 0...ring->size-1 (inclusive) and so requires the modulus to prevent us
> > > writing the value ring->size instead of 0. As this is only required for
> > > the register itself, we can defer the modulus to the register update and
> > > not perform it after every command packet. We keep the
> > > intel_ring_advance() around in the code to provide demarcation for the
> > > end-of-packet (which then can be compared against intel_ring_begin() as
> > > the number of dwords emitted must match the reserved space).
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Joonas Lahtinen 
> > > Cc: Dave Gordon 
> > > ---
> > >  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
> > >  drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
> > >  drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
> > >  3 files changed, 18 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > index bf42a66d6624..824f7efe4e64 100644
> > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > @@ -373,7 +373,7 @@ static void execlists_update_context(struct 
> > > drm_i915_gem_request *rq)
> > >   struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
> > >   uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
> > >  
> > > - reg_state[CTX_RING_TAIL+1] = rq->tail;
> > > + reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, rq->tail);
> > >  
> > >   /* True 32b PPGTT with dynamic page allocation: update PDP
> > >    * registers and point the unallocated PDPs to scratch page.
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > index 3142085b5cc0..21d5e8209400 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > @@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
> > > drm_i915_gem_request *request)
> > >  {
> > >   struct drm_i915_private *dev_priv = request->i915;
> > >  
> > > - I915_WRITE_TAIL(request->engine, request->tail);
> > > + I915_WRITE_TAIL(request->engine,
> > > + intel_ring_offset(request->ring, request->tail));
> > >  }
> > >  
> > >  static void
> > > @@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
> > > drm_i915_gem_request *request)
> > >   DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
> > >  
> > >   /* Now that the ring is fully powered up, update the tail */
> > > - I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), request->tail);
> > > + I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
> > > +   intel_ring_offset(request->ring, request->tail));
> > >   POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
> > >  
> > >   /* Let the ring send IDLE messages to the GT again,
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > index 14d2ea36fb88..9ac96ddb01ee 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > > @@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct 
> > > intel_ring *ring, i915_reg_t reg)
> > >  
> > >  static inline void intel_ring_advance(struct intel_ring *ring)
> > >  {
> > > + /* Dummy function.
> > > +  *
> > > +  * This serves as a placeholder in the code so that the reader
> > > +  * can compare against the preceding intel_ring_begin() and
> > > +  * check that the number of dwords emitted matches the space
> > > +  * reserved for the command packet (i.e. the value passed to
> > > +  * intel_ring_begin()).
> > > +  */
> > > +}
> > > +
> > > +static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
> > > +{
> > >   /* The modulus is required so that we avoid writing
> > >    * request->tail == ring->size, rather than the expected 0,
> > >    * into the RING_TAIL register as that can cause a GPU hang.
> > > -  * As this is only strictly required for the request->tail,
> > > -  * and only then as we write the value into hardware, we can
> > > -  * one day remove the modulus after every command packet.
> > >    */
> > > - ring->tail &= ring->size - 1;
> > > + return value & (ring->size - 1);
> > >  }
> > The comment seems outdated-ish as it speaks of modulus which is nowhere
> > to be seen. I'd speak of 'masking'. With that,
> The operation is a modulus. The common optimisation for moduli with
> a power-of-two divisor being applied.

Yes, I'm perfectly aware of that, but as discussed in IRC, that

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences

2016-08-01 Thread Jani Nikula
On Fri, 22 Jul 2016, Dave Gordon  wrote:
> The existing code that accesses the "enable_guc_submission"
> parameter uses explicit numerical values for the various
> possibilities, including in one case relying on boolean 0/1
> mapping to specific values (which could be confusing for
> maintainers).
>
> So this patch just provides and uses names for the values
> representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
> submission options that the user can select (-1, 0, 1, 2
> respectively).
>
> This should produce identical code to the previous version!
>
> Signed-off-by: Dave Gordon 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c |  2 +-
>  drivers/gpu/drm/i915/intel_guc.h   |  6 ++
>  drivers/gpu/drm/i915/intel_guc_loader.c| 15 ---
>  drivers/gpu/drm/i915/intel_lrc.c   |  6 +++---
>  4 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 01c1c16..e564c976 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -971,7 +971,7 @@ int i915_guc_submission_init(struct drm_i915_private 
> *dev_priv)
>   bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
>   i915_guc_submission_disable(dev_priv);
>  
> - if (!i915.enable_guc_submission)
> + if (i915.enable_guc_submission == GUC_SUBMISSION_DISABLED)
>   return 0; /* not enabled  */
>  
>   if (guc->ctx_pool_obj)
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> b/drivers/gpu/drm/i915/intel_guc.h
> index 3e3e743..52ecbba 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -90,6 +90,12 @@ struct i915_guc_client {
>   uint64_t submissions[I915_NUM_ENGINES];
>  };
>  
> +enum {
> + GUC_SUBMISSION_DEFAULT = -1,
> + GUC_SUBMISSION_DISABLED = 0,
> + GUC_SUBMISSION_PREFERRED,
> + GUC_SUBMISSION_MANDATORY
> +};
>  enum intel_guc_fw_status {
>   GUC_FIRMWARE_FAIL = -1,
>   GUC_FIRMWARE_NONE = 0,
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index b883efd..d8bd4cb 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -189,7 +189,7 @@ static void set_guc_init_params(struct drm_i915_private 
> *dev_priv)
>   }
>  
>   /* If GuC submission is enabled, set up additional parameters here */
> - if (i915.enable_guc_submission) {
> + if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
>   u32 pgs = i915_gem_obj_ggtt_offset(dev_priv->guc.ctx_pool_obj);
>   u32 ctx_in_16 = GUC_MAX_GPU_CONTEXTS / 16;
>  
> @@ -495,7 +495,7 @@ int intel_guc_setup(struct drm_device *dev)
>   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
>   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
>  
> - if (i915.enable_guc_submission) {
> + if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
>   err = i915_guc_submission_enable(dev_priv);
>   if (err)
>   goto fail;
> @@ -523,7 +523,7 @@ int intel_guc_setup(struct drm_device *dev)
>*/
>   if (i915.enable_guc_loading > 1) {
>   ret = -EIO;
> - } else if (i915.enable_guc_submission > 1) {
> + } else if (i915.enable_guc_submission >= GUC_SUBMISSION_MANDATORY) {

I like the patches in general, but now these >= and <= seem rather out
of place. How about using == and != exclusively?

BR,
Jani.

>   ret = -EIO;
>   } else {
>   ret = 0;
> @@ -538,7 +538,7 @@ int intel_guc_setup(struct drm_device *dev)
>   else
>   DRM_ERROR("GuC firmware load failed: %d\n", err);
>  
> - if (i915.enable_guc_submission) {
> + if (i915.enable_guc_submission != GUC_SUBMISSION_DISABLED) {
>   if (fw_path == NULL)
>   DRM_INFO("GuC submission without firmware not 
> supported\n");
>   if (ret == 0)
> @@ -546,7 +546,7 @@ int intel_guc_setup(struct drm_device *dev)
>   else
>   DRM_ERROR("GuC init failed: %d\n", ret);
>   }
> - i915.enable_guc_submission = 0;
> + i915.enable_guc_submission = GUC_SUBMISSION_DISABLED;
>  
>   return ret;
>  }
> @@ -690,8 +690,9 @@ void intel_guc_init(struct drm_device *dev)
>   /* 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 (i915.enable_guc_submission <= GUC_SUBMISSION_DEFAULT)
> + i915.enable_guc_submission = HAS_GUC_SCHED(dev) ?
> + 

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Extract bdw_get_buf_trans_edp()

2016-08-01 Thread Imre Deak
On ti, 2016-07-12 at 15:59 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Make the BDW and SKL code a bit more similar by extracting the
> low vswing handling for BDW into a helper, as we already have
> it like that for SKL+.
> 
> Cc: Mika Kahola 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c581751a645a..fc2ef2d76091 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -320,6 +320,18 @@ enum port intel_ddi_get_encoder_port(struct 
> intel_encoder *encoder)
>  }
>  
>  static const struct ddi_buf_trans *
> +bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> +{
> + if (dev_priv->vbt.edp.low_vswing) {
> + *n_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> + return bdw_ddi_translations_edp;
> + } else {
> + *n_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> + return bdw_ddi_translations_dp;
> + }
> +}
> +
> +static const struct ddi_buf_trans *
>  skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
>   if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv)) {
> @@ -436,13 +448,7 @@ void intel_prepare_dp_ddi_buffers(struct intel_encoder 
> *encoder)
>   } else if (IS_BROADWELL(dev_priv)) {
>   ddi_translations_fdi = bdw_ddi_translations_fdi;
>   ddi_translations_dp = bdw_ddi_translations_dp;
> - if (dev_priv->vbt.edp.low_vswing) {
> - ddi_translations_edp = bdw_ddi_translations_edp;
> - n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> - } else {
> - ddi_translations_edp = bdw_ddi_translations_dp;
> - n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> - }
> + ddi_translations_edp = bdw_get_buf_trans_edp(dev_priv, 
> _edp_entries);
>   n_dp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
>   } else if (IS_HASWELL(dev_priv)) {
>   ddi_translations_fdi = hsw_ddi_translations_fdi;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [Eaglelake][i915] pipe state doesn't match

2016-08-01 Thread Jani Nikula
On Fri, 15 Jul 2016, Felix Miata  wrote:
> I looked for a match on https://bugs.freedesktop.org/query.cgi but found
> nothing looking like a close match that hadn't been marked fixed or
> duplicate.

So please file a new one?

BR,
Jani.


>
> This is happening on a Dell Optiplex 780 in every openSUSE boot at least
> as far back as kernel 3.16 in v13.2, but is not evident in v13.1 running
> 3.12.59. It's also evident in Knoppix 7.6.1 & kernel 4.2.6. This is full
> dmesg from Tumbleweed's kernel 4.6.3, vaapi-intel-driver-1.7.0 and
> libdrm2-2.4.68/libdrm_intel1-2.4.68, with the following cmdline:
> audit=0 ipv6.disable=1 net.ifnames=0 noresume splash=0 vga=791 
> video=1024x768@60 video=1440x900@60 3 
> http://fm.no-ip.com/Tmp/SUSE/Factory/dmsg-gx780-tw20160710-k4631.txt
>
> Dmesg excerpt:
> [   11.571101] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> has_audio (expected 1, found 0)
> [   11.571102] [ cut here ]
> [   11.571128] WARNING: CPU: 0 PID: 71 at 
> ../drivers/gpu/drm/i915/intel_display.c:12921 
> intel_modeset_check_state+0x6b6/0x840 [i915]
> [   11.571129] pipe state doesn't match!
> [   11.571149] Modules linked in: snd_hda_core snd_hwdep mei_wdt snd_pcm i915 
> snd_timer drm_kms_helper dm_mod snd mei_me drm e1000e fb_sys_fops mei 
> coretemp kvm_intel kvm dell_wmi ptp sparse_keymap acpi_cpufreq dell_smbios 
> video ppdev tpm_tis syscopyarea button iTCO_wdt tpm shpchp parport_pc 
> gpio_ich sysfillrect dcdbas parport wmi iTCO_vendor_support sysimgblt 
> pps_core i2c_i801 floppy(+) lpc_ich mfd_core irqbypass soundcore i2c_algo_bit 
> 8250_fintek pcspkr hid_generic usbhid uhci_hcd ehci_pci ehci_hcd serio_raw 
> sr_mod cdrom usbcore usb_common ata_generic sg
> [   11.571151] CPU: 0 PID: 71 Comm: kworker/u16:6 Not tainted 4.6.3-1-default 
> #1
> [   11.571152] Hardware name: Dell Inc. OptiPlex 780 /03NVJ6, 
> BIOS A14 08/21/2012
> [   11.571155] Workqueue: events_unbound async_run_entry_fn
> [   11.571157]   8138a6f4 8800d7b83988 
> 
> [   11.571158]  8107b10e 8800d4f7b800 8800d7b839d8 
> 880112574000
> [   11.571159]  880112a00c00 8800d3734400 8800d7b24000 
> 8107b17f
> [   11.571160] Call Trace:
> [   11.571168]  [] dump_trace+0x5e/0x300
> [   11.571171]  [] show_stack_log_lvl+0x10c/0x180
> [   11.571173]  [] show_stack+0x21/0x40
> [   11.571175]  [] dump_stack+0x5c/0x78
> [   11.571178]  [] __warn+0xbe/0xe0
> [   11.571180]  [] warn_slowpath_fmt+0x4f/0x60
> [   11.571206]  [] intel_modeset_check_state+0x6b6/0x840 
> [i915]
> [   11.571240]  [] intel_atomic_commit+0x832/0xc50 [i915]
> [   11.571252]  [] restore_fbdev_mode+0x22c/0x260 
> [drm_kms_helper]
> [   11.571261]  [] 
> drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70 [drm_kms_helper]
> [   11.571267]  [] drm_fb_helper_set_par+0x29/0x50 
> [drm_kms_helper]
> [   11.571293]  [] intel_fbdev_set_par+0x16/0x60 [i915]
> [   11.571297]  [] fbcon_init+0x563/0x5f0
> [   11.571301]  [] visual_init+0xc3/0x120
> [   11.571303]  [] do_bind_con_driver+0x1cf/0x3b0
> [   11.571305]  [] do_take_over_console+0x14e/0x1c0
> [   11.571308]  [] do_fbcon_takeover+0x58/0xb0
> [   11.571311]  [] notifier_call_chain+0x45/0x70
> [   11.571313]  [] __blocking_notifier_call_chain+0x41/0x60
> [   11.571315]  [] register_framebuffer+0x202/0x330
> [   11.571322]  [] drm_fb_helper_initial_config+0x26c/0x420 
> [drm_kms_helper]
> [   11.571348]  [] intel_fbdev_initial_config+0x1b/0x30 
> [i915]
> [   11.571350]  [] async_run_entry_fn+0x43/0x140
> [   11.571352]  [] process_one_work+0x1ed/0x4b0
> [   11.571354]  [] worker_thread+0x47/0x4c0
> [   11.571357]  [] kthread+0xbd/0xe0
> [   11.571360]  [] ret_from_fork+0x22/0x40
> [   11.572001] DWARF2 unwinder stuck at ret_from_fork+0x22/0x40
> [   11.572001] Leftover inexact backtrace:
> [   11.572001]  [] ? kthread_worker_fn+0x170/0x170
> [   11.572932] ---[ end trace a60da7830c1f6140 ]---
> [   11.653070] Console: switching to colour frame buffer device 180x56

-- 
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] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

2016-08-01 Thread Jani Nikula
On Fri, 15 Jul 2016, Sedat Dilek  wrote:
> Hi,
>
> I see the below call-trace with latest d-i-n, guess latest linux-next

FWIW, "d-i-n" is ambiguous (drm-intel-next vs. drm-intel-nightly) and we
don't use that ourselves.

BR,
Jani.


> will cause same issues.
> ( Beyond this, there exist also a build failure which me and Stephen
> have reported. )
> The call-trace is reproducible with my setup and seen on every boot.
>
> Not sure if this is a problem in intel-gfx or fbdev.
>
> My linux-config and full dmesg-output is attached.
>
> If you need additional informations, please let me know.
>
> Regards,
> - Sedat -
>
> [1] https://lists.freedesktop.org/archives/intel-gfx/2016-July/100693.html
> [2] https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html
>
> P.S.: INFO: possible circular locking dependency detected
>
> [   16.955703] fbcon: inteldrmfb (fb0) is primary device
> [   16.956579]
> [   16.956580] ==
> [   16.956581] [ INFO: possible circular locking dependency detected ]
> [   16.956583] 4.7.0-rc7-4-iniza-small #1 Not tainted
> [   16.956583] ---
> [   16.956585] kworker/u16:1/79 is trying to acquire lock:
> [   16.956618]  (>mode_config.mutex){+.+.+.}, at:
> [] drm_modeset_lock_all+0x40/0x120 [drm]
> [   16.956619]
> [   16.956619] but task is already holding lock:
> [   16.956626]  ((fb_notifier_list).rwsem){.+}, at:
> [] __blocking_notifier_call_chain+0x35/0x70
> [   16.956627]
> [   16.956627] which lock already depends on the new lock.
> [   16.956627]
> [   16.956627]
> [   16.956627] the existing dependency chain (in reverse order) is:
> [   16.956631]
> [   16.956631] -> #1 ((fb_notifier_list).rwsem){.+}:
> [   16.956635][] lock_acquire+0x119/0x220
> [   16.956639][] down_write+0x49/0x80
> [   16.956642][]
> blocking_notifier_chain_register+0x21/0xb0
> [   16.956646][] fb_register_client+0x18/0x20
> [   16.956648][] 
> backlight_device_register+0x12b/0x240
> [   16.956710][]
> intel_backlight_device_register+0xa2/0x170 [i915]
> [   16.956764][]
> intel_connector_register+0xe/0x10 [i915]
> [   16.956778][]
> drm_connector_register+0x4a/0x80 [drm]
> [   16.956792][]
> drm_modeset_register_all+0x163/0x1c0 [drm]
> [   16.956805][] drm_dev_register+0xc2/0xd0 [drm]
> [   16.956848][] i915_driver_load+0x753/0x13e0 
> [i915]
> [   16.956892][] i915_pci_probe+0x4f/0x70 [i915]
> [   16.956896][] local_pci_probe+0x45/0xa0
> [   16.956899][] pci_device_probe+0xdd/0x130
> [   16.956901][] driver_probe_device+0x18e/0x2d0
> [   16.956902][] __driver_attach+0x97/0xa0
> [   16.956905][] bus_for_each_dev+0x66/0xa0
> [   16.956908][] driver_attach+0x1e/0x20
> [   16.956910][] bus_add_driver+0x1b8/0x230
> [   16.956911][] driver_register+0x60/0xe0
> [   16.956913][] __pci_register_driver+0x60/0x70
> [   16.956949][] i915_init+0x5d/0x64 [i915]
> [   16.956952][] do_one_initcall+0x3d/0x160
> [   16.956954][] do_init_module+0x60/0x1dc
> [   16.956957][] load_module+0x2012/0x2610
> [   16.956959][] SYSC_init_module+0x126/0x140
> [   16.956962][] SyS_init_module+0xe/0x10
> [   16.956964][] entry_SYSCALL_64_fastpath+0x23/0xc1
> [   16.956966]
> [   16.956966] -> #0 (>mode_config.mutex){+.+.+.}:
> [   16.956968][] __lock_acquire+0x19ed/0x1aa0
> [   16.956970][] lock_acquire+0x119/0x220
> [   16.956971][] mutex_lock_nested+0x69/0x3c0
> [   16.956988][] drm_modeset_lock_all+0x40/0x120 
> [drm]
> [   16.956998][]
> drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
> [   16.957004][]
> drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
> [   16.957043][] intel_fbdev_set_par+0x1a/0x60 
> [i915]
> [   16.957046][] fbcon_init+0x53c/0x5b0
> [   16.957048][] visual_init+0xd6/0x130
> [   16.957050][] do_bind_con_driver+0x167/0x3a0
> [   16.957052][] do_take_over_console+0x12f/0x1a0
> [   16.957054][] do_fbcon_takeover+0x57/0xb0
> [   16.957056][] fbcon_event_notify+0x752/0x860
> [   16.957058][] notifier_call_chain+0x5d/0x80
> [   16.957060][]
> __blocking_notifier_call_chain+0x4d/0x70
> [   16.957062][]
> blocking_notifier_call_chain+0x16/0x20
> [   16.957064][] fb_notifier_call_chain+0x1b/0x20
> [   16.957065][] register_framebuffer+0x253/0x340
> [   16.957072][]
> drm_fb_helper_initial_config+0x23a/0x3d0 [drm_kms_helper]
> [   16.957108][]
> intel_fbdev_initial_config+0x18/0x30 [i915]
> [   16.957110][] async_run_entry_fn+0x37/0xe0
> [   16.957113][] process_one_work+0x1d2/0x690
> [   16.957115][] worker_thread+0x69/0x4c0
> [   16.957116][] 

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

2016-08-01 Thread Jani Nikula
On Wed, 20 Jul 2016, "Vivi, Rodrigo"  wrote:
> We don't hardcode all userspace libraries in the userspace side for
> the graphics stack and we do not validate all possible combinations of
> libdrm, mesa, ddx, libva, etc... Why should we need this with
> firmware?

Because the firmware blob is more like a binary kernel module that works
with a specific kernel version than an open source userspace component
written on top of a stable ABI.

You do not know what the firmware does, nor what the future versions of
it will do. The kernel provides an ABI with a strict no regressions
policy for its users. The firmware has no such guarantees, and it is
expected to go hand in hand with the operating system versions it has
been validated against. And as I've explained numerous times, we do not
have the resources to validate all kernel releases against all firmware
releases.


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 00/23] drm/i915: Organize most GPU features by platform

2016-08-01 Thread Jani Nikula
On Wed, 20 Jul 2016, Carlos Santa  wrote:
> This patchset includes the following changes:
>
>  - organize most GPU features so that they are easy to group by platforms.
>It seems some of the ground work was already done for Gen7 features.
>Reuse some of that work for the rest of the Gen platforms (GEN6, GEN5, 
> GEN4, GEN3
>and GEN2).
>
>  - make most of these GPU features now a device_info flag also based on
>previous work done by others. The idea is here is to have a central place 
> where
>to add new features and also now it should be possible to see what the 
> supported 
>features are for a given platform by dumping of the struct definitions.
>The list of the features that were converted to a device_info flag 
> include: PSR,
>RUNTIME_PM, CORE_RING_FREQ, CSR, GUC, GUC_UCODE, GUC_SCHED, 
> RESOURCE_STREAMER, RC6,
>RC6p, DP_MST, GMBUS_IRQ, FW_BLC, HW_CONTEXTS, LOGICAL_RING_CONTEXTS, 
> L3_DPF, and
>GMCH_DISPLAY.

Ack on the general approach. I didn't do actual review. Please check the
spelling in commit messages.

BR,
Jani.


>
> Carlos Santa (23):
>   drm/i915: Move HAS_PSR definition to platform struct definition
>   drm/i915: Introduce GEN6_FEATURES for device info
>   drm/i915: Move HAS_RUNTIME_PM definition to platform
>   drm/i915: Move HAS_CORE_RING_FREQ definition to platform definition
>   drm/i915: Move HAS_CSR definition to platform definition
>   drm/i915: Move HAS_GUC definition to platform definition
>   drm/i915: Move HAS_GUC_UCODE definition to platform definition
>   drm/i915: Move HAS_GUC_SCHED definition to platform definition
>   drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition
>   drm/i915: Move HAS_RC6 definition to platform definition
>   drm/i915: Move HAS_RC6p definition to platform definition
>   drm/i915: Move HAS_DP_MST definition to platform definition
>   drm/i915: Introduce GEN5_FEATURES for device info
>   drm/i915: Move HAS_AUX_IRQ definition to platform definition
>   drm/i915: Move HAS_GMBUS_IRQ definition to platform definition
>   drm/i915: Introduce GEN4_FEATURES for device info
>   drm/i915: Introduce GEN3_FEATURES for device info
>   drm/i915: Introduce GEN2 FEATURES for device info
>   drm/915: Move HAS_FW_BLC definition to platform
>   drm/i915: Move HAS_HW_CONTEXTS definition to platform
>   drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform
> definition
>   drm/i915: Move HAS_L3_DPF definition to platform definition
>   drm/i915: Move HAS_GMCH_DISPLAY definition to platform
>
>  drivers/gpu/drm/i915/i915_drv.h |  67 +-
>  drivers/gpu/drm/i915/i915_pci.c | 272 
> +---
>  2 files changed, 206 insertions(+), 133 deletions(-)

-- 
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 13/23] drm/i915: Introduce GEN5_FEATURES for device info

2016-08-01 Thread Jani Nikula
On Wed, 20 Jul 2016, Carlos Santa  wrote:
> Based on the GEN7_FEATURES changes from Ben W.
>
> Use it for ilk.
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 099f134..3844840 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -177,21 +177,22 @@ static const struct intel_device_info 
> intel_pineview_info = {
>   CURSOR_OFFSETS,
>  };
>  
> +#define GEN5_FEATURES \
> + .gen = 5, .num_pipes = 2, \
> + .need_gfx_hws = 1, .has_hotplug = 1, \
> + .ring_mask = RENDER_RING | BSD_RING, \
> + GEN_DEFAULT_PIPEOFFSETS, \
> + CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_ironlake_d_info = {
> - .gen = 5, .num_pipes = 2,
> - .need_gfx_hws = 1, .has_hotplug = 1,
> - .ring_mask = RENDER_RING | BSD_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
> + GEN5_FEATURES

Like before, please stick the comma at the end.

>  };
>  
>  static const struct intel_device_info intel_ironlake_m_info = {
> - .gen = 5, .is_mobile = 1, .num_pipes = 2,
> - .need_gfx_hws = 1, .has_hotplug = 1,
> + GEN5_FEATURES,
> + .is_mobile = 1,
>   .has_fbc = 1,
> - .ring_mask = RENDER_RING | BSD_RING,
> - GEN_DEFAULT_PIPEOFFSETS,
> - CURSOR_OFFSETS,
> +

Do not add superfluous empty lines.

BR,
Jani.

>  };
>  
>  #define GEN6_FEATURES \

-- 
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 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

2016-08-01 Thread Jani Nikula
On Wed, 20 Jul 2016, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
>   - standard place when adding new features from new platforms
>   - possible to see supported features when dumping struct
> definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 6 ++
>  drivers/gpu/drm/i915/i915_pci.c | 7 ++-
>  2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6569eb7..7443b9a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -769,6 +769,7 @@ struct intel_csr {
>   func(is_preliminary) sep \
>   func(has_fbc) sep \
>   func(has_psr) sep \
> + func(has_runtime_pm) sep \
>   func(has_pipe_cxsr) sep \
>   func(has_hotplug) sep \
>   func(cursor_needs_physical) sep \
> @@ -2848,10 +2849,7 @@ struct drm_i915_cmd_table {
>  #define HAS_DDI(dev) (INTEL_INFO(dev)->has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)  (INTEL_INFO(dev)->has_fpga_dbg)
>  #define HAS_PSR(dev) (INTEL_INFO(dev)->has_psr)
> -#define HAS_RUNTIME_PM(dev)  (IS_GEN6(dev) || IS_HASWELL(dev) || \
> -  IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
> -  IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
> -  IS_KABYLAKE(dev) || IS_BROXTON(dev))
> +#define HAS_RUNTIME_PM(dev)  (INTEL_INFO(dev)->has_runtime_pm)
>  #define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_RC6p(dev)(IS_GEN6(dev) || IS_IVYBRIDGE(dev))
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 8b1311d..92ab3c2 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -198,6 +198,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
>   .gen = 6, .num_pipes = 2, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
>   .has_fbc = 1, \
> + .has_runtime_pm = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .has_llc = 1, \
>   GEN_DEFAULT_PIPEOFFSETS, \
> @@ -241,6 +242,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>  #define VLV_FEATURES  \
>   .gen = 7, .num_pipes = 2, \
>   .has_psr = 1, \
> + .has_runtime_pm = 1, \
>   .need_gfx_hws = 1, .has_hotplug = 1, \
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
>   .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -263,7 +265,8 @@ static const struct intel_device_info 
> intel_valleyview_d_info = {
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
>   .has_ddi = 1, \
>   .has_fpga_dbg = 1, \
> - .has_psr = 1
> + .has_psr = 1, \
> + .has_runtime_pm = 1

Drive by bikeshedding, please always add the comma in the end even for
the last line so that you can add new ones without touching the
preceding lines like here.

BR,
Jani.

>  
>  static const struct intel_device_info intel_haswell_d_info = {
>   HSW_FEATURES,
> @@ -312,6 +315,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
>   .is_cherryview = 1,
>   .has_psr = 1,
> + .has_runtime_pm = 1,
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> @@ -340,6 +344,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
>   .has_ddi = 1,
>   .has_fpga_dbg = 1,
>   .has_fbc = 1,
> + .has_runtime_pm = 1,
>   .has_pooled_eu = 0,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,

-- 
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 36/73] drm/i915: Refactor activity tracking for requests

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> With the introduction of requests, we amplified the number of atomic
> refcounted objects we use and update every execbuffer; from none to
> several references, and a set of references that need to be changed. We
> also introduced interesting side-effects in the order of retiring
> requests and objects.
> 
> Instead of independently tracking the last request for an object, track
> the active objects for each request. The object will reside in the
> buffer list of its most recent active request and so we reduce the kref
> interchange to a list_move. Now retirements are entirely driven by the
> request, dramatically simplifying activity tracking on the object
> themselves, and removing the ambiguity between retiring objects and
> retiring requests.
> 
> Furthermore with the consolidation of managing the activity tracking
> centrally, we can look forward to using RCU to enable lockless lookup of
> the current active requests for an object. In the future, we will be
> able to query the status or wait upon rendering to an object without
> even touching the struct_mutex BKL.
> 
> All told, less code, simpler and faster, and more extensible.
> 
> v2: Add a typedef for the function pointer for convenience later.
> v3: Make the noop retirement callback explicit. Allow passing NULL to
> the init_gem_active() which is expanded to a common noop function.

s/init_gem_active/init_request_active/

Assuming you kept the changes to those,

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

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


Re: [Intel-gfx] [PATCH i-g-t] tools/intel_reg: enable quiet option for mmio

2016-08-01 Thread Jani Nikula
On Wed, 20 Jul 2016, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
>
> Skip decode options and formatting when the quiet option is used during
> mmio reads. Makes intel_reg usable by scripts to return MMIO values.
>
> Signed-off-by: Clint Taylor 
> ---
>  tools/intel_reg.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
> index 73fbd6d..e869292 100644
> --- a/tools/intel_reg.c
> +++ b/tools/intel_reg.c
> @@ -202,7 +202,9 @@ static void dump_decode(struct config *config, struct reg 
> *reg, uint32_t val)
>  
>   if (reg->port_desc.port == PORT_MMIO) {
>   /* Omit port name for MMIO, optionally include MMIO offset. */
> - if (reg->mmio_offset)
> + if (config->verbosity < 0)
> + printf("0x%08x\n", val);

Please do not conflate verbosity with output format. Please add, say,
--raw or --output=raw option instead.

> + else if (reg->mmio_offset)
>   printf("%24s (0x%08x:0x%08x): 0x%08x%s",
>  reg->name ?: "",
>  reg->mmio_offset, reg->addr,
> @@ -706,6 +708,9 @@ static int read_reg_spec(struct config *config)
>   struct stat st;
>   int r;
>  
> + if (config->verbosity < 0)
> + goto builtin;
> +

This is just wrong. Why should *verbosity* matter in the selection of
spec file? Why should verbosity potentially *change* the interpretation
of a register name?

BR,
Jani.

>   path = config->specfile;
>   if (!path)
>   path = getenv("INTEL_REG_SPEC");

-- 
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 70/73] drm/i915: Move obj->active:5 to obj->flags

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote:
> We are motivated to avoid using a bitfield for obj->active for a couple
> of reasons. Firstly, we wish to document our lockless read of obj->active
> using READ_ONCE inside i915_gem_busy_ioctl() and that requires an
> integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code
> when presented with a bitfield and that shows up high on the profiles of
> request tracking (mainly due to excess memory traffic as it converts
> the bitfield to a register and back and generates frequent AGI in the
> process).
> 
> v2: BIT, break up a long line in compute the other engines, new paint
> for i915_gem_object_is_active (now i915_gem_object_get_active).
> 
> Signed-off-by: Chris Wilson 

Patch reads much better now,

Reviewed-by: Joonas Lahtinen 

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


Re: [Intel-gfx] [PATCH 61/73] drm/i915: Record allocated vma size

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 03:36:27PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote:
> > Tracking the size of the VMA as allocated allows us to dramatically
> > reduce the complexity of later functions (like inserting the VMA in to
> > the drm_mm range manager).
> > 
> 
> I assume this new revision only removed the extra hunk of code, right?

Yeah, it was just rebased after the hunk was moved out. I've been lax in
not mentioning every single time the patches have been touched after a
rebase.
-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 61/73] drm/i915: Record allocated vma size

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote:
> Tracking the size of the VMA as allocated allows us to dramatically
> reduce the complexity of later functions (like inserting the VMA in to
> the drm_mm range manager).
> 

I assume this new revision only removed the extra hunk of code, right?

If so,

Reviewed-by: Joonas Lahtinen 

> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 103 
> ++--
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  67 ---
>  drivers/gpu/drm/i915/i915_gem_gtt.h |   5 +-
>  3 files changed, 63 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f11bf6c4f86a..d89fbee5c48a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2976,53 +2976,36 @@ i915_gem_object_insert_into_vm(struct 
> drm_i915_gem_object *obj,
>      u64 alignment,
>      u64 flags)
>  {
> - struct drm_device *dev = obj->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - u64 start, end;
> - u32 search_flag, alloc_flag;
> + struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
>   struct i915_vma *vma;
> + u64 start, end;
> + u64 min_alignment;
>   int ret;
>  
> - if (i915_is_ggtt(vm)) {
> - u32 fence_size, fence_alignment, unfenced_alignment;
> - u64 view_size;
> -
> - if (WARN_ON(!ggtt_view))
> - return ERR_PTR(-EINVAL);
> -
> - view_size = i915_ggtt_view_size(obj, ggtt_view);
> -
> - fence_size = i915_gem_get_ggtt_size(dev_priv,
> - view_size,
> - obj->tiling_mode);
> - fence_alignment = i915_gem_get_ggtt_alignment(dev_priv,
> -   view_size,
> -   obj->tiling_mode,
> -   true);
> - unfenced_alignment = i915_gem_get_ggtt_alignment(dev_priv,
> -  view_size,
> -  
> obj->tiling_mode,
> -  false);
> - size = max(size, view_size);
> - if (flags & PIN_MAPPABLE)
> - size = max_t(u64, size, fence_size);
> -
> - if (alignment == 0)
> - alignment = flags & PIN_MAPPABLE ? fence_alignment :
> - unfenced_alignment;
> - if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
> - DRM_DEBUG("Invalid object (view type=%u) alignment 
> requested %llx\n",
> -   ggtt_view ? ggtt_view->type : 0,
> -   (long long)alignment);
> - return ERR_PTR(-EINVAL);
> - }
> - } else {
> - size = max_t(u64, size, obj->base.size);
> - alignment = 4096;
> + vma = ggtt_view ?
> + i915_gem_obj_lookup_or_create_ggtt_vma(obj, ggtt_view) :
> + i915_gem_obj_lookup_or_create_vma(obj, vm);
> + if (IS_ERR(vma))
> + return vma;
> +
> + size = max(size, vma->size);
> + if (flags & PIN_MAPPABLE)
> + size = i915_gem_get_ggtt_size(dev_priv, size, obj->tiling_mode);
> +
> + min_alignment =
> + i915_gem_get_ggtt_alignment(dev_priv, size, obj->tiling_mode,
> + flags & PIN_MAPPABLE);
> + if (alignment == 0)
> + alignment = min_alignment;
> + if (alignment & (min_alignment - 1)) {
> + DRM_DEBUG("Invalid object alignment requested %llu, minimum 
> %llu\n",
> +   alignment, min_alignment);
> + return ERR_PTR(-EINVAL);
>   }
>  
>   start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
> - end = vm->total;
> +
> + end = vma->vm->total;
>   if (flags & PIN_MAPPABLE)
>   end = min_t(u64, end, dev_priv->ggtt.mappable_end);
>   if (flags & PIN_ZONE_4G)
> @@ -3033,8 +3016,7 @@ i915_gem_object_insert_into_vm(struct 
> drm_i915_gem_object *obj,
>    * attempt to find space.
>    */
>   if (size > end) {
> - DRM_DEBUG("Attempting to bind an object (view type=%u) larger 
> than the aperture: request=%llu [object=%zd] > %s aperture=%llu\n",
> -   ggtt_view ? ggtt_view->type : 0,
> + DRM_DEBUG("Attempting to bind an object larger than the 
> aperture: request=%llu [object=%zd] > %s aperture=%llu\n",
>     size, obj->base.size,
>     

Re: [Intel-gfx] [PATCH 60/73] drm/i915: Update i915_gem_get_ggtt_size/_alignment to use drm_i915_private

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote:
> For consistency, internal functions should take drm_i915_private rather
> than drm_device. Now that we are subclassing drm_device, there are no
> more size wins, but being consistent is its own blessing.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_drv.h|  5 +++--
>  drivers/gpu/drm/i915/i915_gem.c| 30 --
>  drivers/gpu/drm/i915/i915_gem_tiling.c |  8 
>  3 files changed, 23 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b6e56ecb8637..3d73394b52d7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3241,8 +3241,9 @@ int i915_gem_object_attach_phys(struct 
> drm_i915_gem_object *obj,
>  int i915_gem_open(struct drm_device *dev, struct drm_file *file);
>  void i915_gem_release(struct drm_device *dev, struct drm_file *file);
>  
> -u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 size, int 
> tiling_mode);
> -u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, u64 size,
> +u64 i915_gem_get_ggtt_size(struct drm_i915_private *dev_priv, u64 size,
> +    int tiling_mode);
> +u64 i915_gem_get_ggtt_alignment(struct drm_i915_private *dev_priv, u64 size,
>   int tiling_mode, bool fenced);
>  
>  int i915_gem_object_set_cache_level(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 432868eafa60..f11bf6c4f86a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1846,25 +1846,26 @@ i915_gem_release_all_mmaps(struct drm_i915_private 
> *dev_priv)
>  
>  /**
>   * i915_gem_get_ggtt_size - return required global GTT size for an object
> - * @dev: drm device
> + * @dev_priv: i915 device
>   * @size: object size
>   * @tiling_mode: tiling mode
>   *
>   * Return the required GTT size for an object, taking into account
>   * potential fence register mapping.
>   */
> -u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 size, int tiling_mode)
> +u64 i915_gem_get_ggtt_size(struct drm_i915_private *dev_priv,
> +    u64 size, int tiling_mode)
>  {
>   u64 ggtt_size;
>  
>   GEM_BUG_ON(size == 0);
>  
> - if (INTEL_GEN(dev) >= 4 ||
> + if (INTEL_GEN(dev_priv) >= 4 ||
>   tiling_mode == I915_TILING_NONE)
>   return size;
>  
>   /* Previous chips need a power-of-two fence region when tiling */
> - if (IS_GEN3(dev))
> + if (IS_GEN3(dev_priv))
>   ggtt_size = 1024*1024;
>   else
>   ggtt_size = 512*1024;
> @@ -1877,7 +1878,7 @@ u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 
> size, int tiling_mode)
>  
>  /**
>   * i915_gem_get_ggtt_alignment - return required GTT alignment for an object
> - * @dev: drm device
> + * @dev_priv: i915 device
>   * @size: object size
>   * @tiling_mode: tiling mode
>   * @fenced: is fenced alignemned required or not
> @@ -1885,7 +1886,7 @@ u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 
> size, int tiling_mode)
>   * Return the required GTT alignment for an object, taking into account
>   * potential fence register mapping.
>   */
> -u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, u64 size,
> +u64 i915_gem_get_ggtt_alignment(struct drm_i915_private *dev_priv, u64 size,
>   int tiling_mode, bool fenced)
>  {
>   GEM_BUG_ON(size == 0);
> @@ -1894,7 +1895,7 @@ u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, 
> u64 size,
>    * Minimum alignment is 4k (GTT page size), but might be greater
>    * if a fence register is needed for the object.
>    */
> - if (INTEL_GEN(dev) >= 4 || (!fenced && IS_G33(dev)) ||
> + if (INTEL_GEN(dev_priv) >= 4 || (!fenced && IS_G33(dev_priv)) ||
>   tiling_mode == I915_TILING_NONE)
>   return 4096;
>  
> @@ -1902,7 +1903,7 @@ u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, 
> u64 size,
>    * Previous chips need to be aligned to the size of the smallest
>    * fence register that can contain the object.
>    */
> - return i915_gem_get_ggtt_size(dev, size, tiling_mode);
> + return i915_gem_get_ggtt_size(dev_priv, size, tiling_mode);
>  }
>  
>  static int i915_gem_object_create_mmap_offset(struct drm_i915_gem_object 
> *obj)
> @@ -2991,14 +2992,14 @@ i915_gem_object_insert_into_vm(struct 
> drm_i915_gem_object *obj,
>  
>   view_size = i915_ggtt_view_size(obj, ggtt_view);
>  
> - fence_size = i915_gem_get_ggtt_size(dev,
> + fence_size = i915_gem_get_ggtt_size(dev_priv,
>   view_size,
>   obj->tiling_mode);
> - 

Re: [Intel-gfx] [PATCH 59/73] drm/i915: Update the GGTT size/alignment query functions

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote:
>  
> -uint32_t
> -i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode)
> +/**
> + * i915_gem_get_ggtt_size - return required global GTT size for an object
> + * @dev: drm device
> + * @size: object size
> + * @tiling_mode: tiling mode
> + *
> + * Return the required GTT size for an object, taking into account
         + global ---^

> + * potential fence register mapping.
> + */
> +u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 size, int tiling_mode)
>  {
> - uint32_t gtt_size;
> + u64 ggtt_size;
>  



> - gtt_size <<= 1;
> + while (ggtt_size < size)
> + ggtt_size <<= 1;
>  
> - return gtt_size;
> + return ggtt_size;
>  }
>  
>  /**
> - * i915_gem_get_gtt_alignment - return required GTT alignment for an object
> + * i915_gem_get_ggtt_alignment - return required GTT alignment for an object
                                     + global -^

>   * @dev: drm device
>   * @size: object size
>   * @tiling_mode: tiling mode
> @@ -1875,15 +1885,16 @@ i915_gem_get_gtt_size(struct drm_device *dev, 
> uint32_t size, int tiling_mode)
>   * Return the required GTT alignment for an object, taking into account
       + global -^

With those,

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

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


Re: [Intel-gfx] [PATCH 54/73] drm/i915: Fix up vma alignment to be u64

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote:
> This is not the full fix, as we are required to percolate the u64 nature
> down through the drm_mm stack, but this is required now to prevent
> explosions due to mismatch between execbuf (eb_vma_misplaced) and vma
> binding (i915_vma_misplaced) - and reduces the risk of spurious changes
> as we adjust the vma interface in the next patches.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   | 14 ++
>  drivers/gpu/drm/i915/i915_gem.c   | 26 +-
>  drivers/gpu/drm/i915/i915_gem_evict.c |  5 +++--
>  3 files changed, 22 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2de3d16f7b80..74a31358fd87 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3032,13 +3032,13 @@ void i915_gem_free_object(struct drm_gem_object *obj);
>  int __must_check
>  i915_gem_object_pin(struct drm_i915_gem_object *obj,
>   struct i915_address_space *vm,
> - uint32_t alignment,
> - uint64_t flags);
> + u64 alignment,
> + u64 flags);
>  int __must_check
>  i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
>    const struct i915_ggtt_view *view,
> -  uint32_t alignment,
> -  uint64_t flags);
> +  u64 alignment,
> +  u64 flags);
>  
>  int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
>     u32 flags);
> @@ -3398,11 +3398,9 @@ int i915_gem_context_reset_stats_ioctl(struct 
> drm_device *dev, void *data,
>  
>  /* i915_gem_evict.c */
>  int __must_check i915_gem_evict_something(struct i915_address_space *vm,
> -   int min_size,
> -   unsigned alignment,
> +   u64 min_size, u64 alignment,
>     unsigned cache_level,
> -   unsigned long start,
> -   unsigned long end,
> +   u64 start, u64 end,
>     unsigned flags);
>  int __must_check i915_gem_evict_for_vma(struct i915_vma *target);
>  int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3402fec5e33c..6039e46af69a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2960,8 +2960,8 @@ static struct i915_vma *
>  i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
>      struct i915_address_space *vm,
>      const struct i915_ggtt_view *ggtt_view,
> -    unsigned alignment,
> -    uint64_t flags)
> +    u64 alignment,
> +    u64 flags)
>  {
>   struct drm_device *dev = obj->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -3020,9 +3020,9 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
> *obj,
>   alignment = flags & PIN_MAPPABLE ? fence_alignment :
>   unfenced_alignment;
>   if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
> - DRM_DEBUG("Invalid object (view type=%u) alignment requested 
> %u\n",
> + DRM_DEBUG("Invalid object (view type=%u) alignment requested 
> %llx\n",
>     ggtt_view ? ggtt_view->type : 0,
> -   alignment);
> +   (long long)alignment);
>   return ERR_PTR(-EINVAL);
>   }
>  
> @@ -3675,7 +3675,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct 
> drm_file *file)
>  }
>  
>  static bool
> -i915_vma_misplaced(struct i915_vma *vma, uint32_t alignment, uint64_t flags)
> +i915_vma_misplaced(struct i915_vma *vma, u64 alignment, u64 flags)
>  {
>   struct drm_i915_gem_object *obj = vma->obj;
>  
> @@ -3724,8 +3724,8 @@ static int
>  i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
>      struct i915_address_space *vm,
>      const struct i915_ggtt_view *ggtt_view,
> -    uint32_t alignment,
> -    uint64_t flags)
> +    u64 alignment,
> +    u64 flags)
>  {
>   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
>   struct i915_vma *vma;
> @@ -3754,12 +3754,12 @@ i915_gem_object_do_pin(struct drm_i915_gem_object 
> *obj,
>   if (i915_vma_misplaced(vma, alignment, flags)) {
>   WARN(vma->pin_count,
>    "bo is already pinned in %s with incorrect 
> 

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

2016-08-01 Thread Patchwork
== Series Details ==

Series: drm/i915: cleanup_plane_fb: also drop reference to current state 
wait_req
URL   : https://patchwork.freedesktop.org/series/10448/
State : failure

== Summary ==

Applying: drm/i915: cleanup_plane_fb: also drop reference to current state 
wait_req
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_display.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_display.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_display.c
error: Failed to merge in the changes.
Patch failed at 0001 drm/i915: cleanup_plane_fb: also drop reference to current 
state wait_req
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

2016-08-01 Thread Keith Packard
There are two paths into intel_cleanup_plane_fb, the normal completion
path and the failure path.

In the failure case, intel_cleanup_plane_fb is called before
drm_atomic_helper_swap_state, so any wait_req reference made in
intel_prepare_plane_fb will be in old_intel_state->wait_req.

In the normal completion path, drm_atomic_helper_swap_state has
already been called, so the plane state holding the just-used wait_req
will not be in old_intel_state->wait_req, rather it will be in the
state associated with the plane itself.

Clearing this reference ensures that the wait_req will be freed as
soon as it the related mode setting operation is complete, rather than
waiting for some future mode setting operation to eventually
dereference it.

The existing dereference of old_intel_state->wait_req is still
required as that will hold the wait_req when the mode setting
operation fails.

cc: Daniel Vetter 
cc: David Airlie 
cc: intel-gfx@lists.freedesktop.org
cc: dri-de...@lists.freedesktop.org
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3074c56..dbabaf3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13924,6 +13924,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
struct drm_device *dev = plane->dev;
struct intel_plane *intel_plane = to_intel_plane(plane);
struct intel_plane_state *old_intel_state;
+   struct intel_plane_state *intel_state = 
to_intel_plane_state(plane->state);
struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
struct drm_i915_gem_object *obj = intel_fb_obj(plane->state->fb);
 
@@ -13941,6 +13942,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
(obj && !(obj->frontbuffer_bits & intel_plane->frontbuffer_bit)))
i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
 
+   i915_gem_request_assign(_state->wait_req, NULL);
i915_gem_request_assign(_intel_state->wait_req, NULL);
 }
 
-- 
2.8.1

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


Re: [Intel-gfx] drm-intel.git Committers: Reminder about tagging bugfixes

2016-08-01 Thread Jani Nikula
On Thu, 14 Jul 2016, Daniel Vetter  wrote:
> Hi all,
>
> Apparently this wasn't known to everyone, hence this small reminder
> about correctly tagging bugfixes when pushing them:
> - add a Bugzilla: or References: link for any bug reported anywhere
> (bugzilla or mailing list). Also add Reported-by:/Tested-by: for
> credits.

FWIW, greping git logs says we should prefer "Reference:" over
"References:".

BR,
Jani.

> - add Fixes: if it's a regression fix. Run "dim fixes $sha1" for
> convenience, to generate this correctly
> - add correct Cc: tags, Cc: stable for backporting to all kernels
> (including -rc), Cc: drm-intel-fixes if it's only needed in current
> -rc series.
>
> Special note about pre-production hw: We only backport fixes when the
> prelim_hw_support tag is lifted, before that point we don't bother.
> But after that _all_ bugfixes need one of the above tags, and right
> now both kbl and apl/bxt aren't preliminary any more!
>
> For full details see the docs:
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
> If you haven't read them in a while would be good to check them out
> again, quite a few improvements and clarifications over the past few
> months.
>
> Thanks, Daniel

-- 
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 v4 0/6] Finally fix watermarks

2016-08-01 Thread Ville Syrjälä
On Fri, Jul 29, 2016 at 01:41:26PM -0700, Matt Roper wrote:
> On Fri, Jul 29, 2016 at 10:26:20PM +0300, Ville Syrjälä wrote:
> > On Fri, Jul 29, 2016 at 02:48:09PM -0400, Lyude wrote:
> > > So I've been working on trying to fix this entirely again (e.g. writing
> > > the ddb properly), since from bug reports it still doesn't sound like
> > > we've got enough workarounds to make this tolerable. I've shown this to
> > > matt roper, but I should probably post what I've been trying to do for
> > > you as well.
> > > 
> > > So the approach I came up with is here
> > > 
> > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2
> > > 
> > > My approach differs a little bit from what the bspec recommends, but I
> > > think it's going to be a bit easier to implement. At the end of all the
> > > changes I'm attempting it should look like this:
> > > 
> > >  * We no longer have a global watermark update for skl
> > >  * A new hook called "update_ddbs" is added to i915_display_funcs. This
> > >gets called in intel_atomic_commit_tail() after we've disabled any
> > >CRTCs that needed disabling, and before we begin enabling/updating
> > >CRTCs
> > >  * Because pipe ddb allocations (not the inner-pipe ddb allocations
> > >that apply to each pipe's planes) only change while
> > >enabling/disabling crtcs:
> > > * Pass 1: Find which pipe's new ddb allocation won't overlap with
> > >   another pipe's previous allocation, and update that pipe first
> > > * Pass 2: Update the allocation of the remaining pipe
> > > 
> > > Here's an illustration of what this looks like. Parts of the ddb not
> > > being used by any CRTCs are marked out with 'x's:
> > > 
> > > With pipe A enabled, we enable pipe B:
> > > Initial DDB:    |           A           |
> > > update_ddbs:    |     A     |xxx| Pass 1
> > > Enable pipe B:  |     A     |     B     |
> > > 
> > > With pipes B and A active, we enable pipe C:
> > > 
> > > Initial DDB:    |     B     |     A     |
> > > update_ddbs:    |   B   |xxx|     A     | Pass 1
> > > update_ddbs:    |   B   |   A   |xxx| Pass 2
> > > Enable pipe C:  |   B   |   A   |   C   |
> > > 
> > > With pipes A, B, and C active, we disable B:
> > > Initial DDB:    |   A   |   B   |   C   |
> > > Disable pipe B: |   A   |xxx|   C   |
> > > update_ddbs:    |     A     |     C     | Pass 1
> > > Since neither pipe's new allocation overlapped, we skip pass 2
> > > 
> > > Another allocation with A, B, and C active, disabling A:
> > > Initial DDB:    |   A   |   B   |   C   |
> > > Disable pipe A: |xxx|   B   |   C   |
> > > update_ddbs:    |     B     |xxx|   C   | Pass 1
> > > update_ddbs:    |     B     |     C     | Pass 2
> > > 
> > > This should ensure we can always move around the allocations of pipes
> > > without them ever overlapping and exploding.
> > 
> > That's what the current flush thing does, or at least that what it used
> > to do at least. Not sure it's really doing it anymore, but I'm pretty
> > sure the order in which it did things was sound at some point.
> > 
> > > 
> > > This branch doesn't entirely fix underrun issues, but I'm mostly sure
> > > that's the fault of still not having removed the global wm update hook
> > > yet (which is leading to additional pipe flushes in places they
> > > shouldn't be):
> > 
> > Well it should basically boil down to s/update_wm/update_ddb/
> > Only DDB reallocation really warrants a global hook. Everything else
> > should be handled via per-crtc hooks, on all platforms.
> 
> I don't think we want even update_ddb.  We want *calculate_ddb* to be a
> global hook during the atomic check phase (and we do have that today),
> but when we get around to the commit phase and start writing stuff to
> hardware, we want to program the per-pipe DDB entries at the same time
> we program the WM's and regular plane registers (since they should be
> double buffered and flushed out the same way).  We just need to make
> sure that the order we process pipes in follows the special flushing
> rules noted above, which is what my pseudo-patches were trying to
> describe.

My comments are w.r.t. the scheme where we don't lock down all the crtcs
for every DDB update.

> 
> > 
> > > 
> > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2
> > > 
> > > As for updating inner-pipe ddb allocations for each plane on a pipe, we
> > > should be able to just do that at the same time we update each pipe's
> > > watermarks
> > 
> > Yes.
> > 
> > None of that changes what I said before though. Either you need to
> > lock down everything when the DDB needs to be repartitioned, or you
> > do what I outlined in the previous mail. Otherwise a plane update
> > etc. happening in parallel will still blow up on account of the DDB
> > state changing underneath the plane update somewhere between compute
> > and commit. I can't really think of third option that would work.
> 
> Yep, I agree with all of this as well (and we do lock everything down
> 

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

2016-08-01 Thread Ville Syrjälä
On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote:
> Op 29-07-16 om 22:33 schreef Matt Roper:
> > On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote:
> >> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote:
> >>> This is completely untested (and probably horribly broken/buggy), but
> >>> here's a quick mockup of the general approach I was thinking for
> >>> ensuring DDB & WM's can be updated together while ensuring the
> >>> three-step pipe flushing process is honored:
> >>>
> >>> https://github.com/mattrope/kernel/commits/experimental/lyude_ddb
> >>>
> >>> Basically the idea is to take note of what's happening to the pipe's DDB
> >>> allocation (shrinking, growing, unchanged, etc.) during the atomic check
> >>> phase;
> >> Didn't look too closely, but I think you can't actually do that unless
> >> you lock all the crtcs whenever the number of active pipes is goind to
> >> change. Meaning we'd essentially be back to the one-big-modeset-lock
> >> apporach, which will cause missed flips and whanot on the other pipes.
> >>
> >> The alternative I think would consist of:
> >> - make sure level 0 watermark never exceeds total_ddb_size/max_pipes,
> >>   so that a modeset doesn't have to care about the wms for the other
> >>   pipes not fitting in
> > Unfortunately this part is the problem.  You might get away with doing
> > this on SKL/KBL which only have three planes max per pipe and a large
> > (896 block) DDB, but on BXT you have up to four planes (we don't
> > actually enable the topmost plane in a full-featured manner just yet,
> > but need to soon), yet the total DDB is only 512 blocks.  Sadly, the
> > platform with more planes was given a smaller DDB...   :-(
> > We're already in trouble because users that are running setups like 3x
> > 4K with most/all planes in use at large sizes can't find level 0
> > watermarks that satisfy their needs and we have to reject the whole
> > configuration.  If we further limit each pipe's usage to total/maxpipes
> > (i.e., 170 blocks per pipe on BXT), then we're going to hit similar
> > issues when only driving one or two displays with with all of the planes
> > in use, even though we should have had more DDB space to work with.
> >
> > I guess serious plane usage isn't too common in desktop setups today,
> > but it's a very critical feature in the embedded world; we can't really
> > afford to cripple plane usage further.  Unfortunately, as you point out
> > above, this means that we have to follow the bspec's DDB allocation
> > method, which in turn means we need to grab _all_ CRTC locks any time
> > _any_ CRTC is being turned on or turned off which is a BKL-style way of
> > doing things.
> Meh, I'm running into a similar issue on vlv/chv. I don't see a way around 
> it. :(

Now are you hitting it w/ vlv/chv? They don't even have a shared DDB.

> Only thing we could do is split up the state to make the non-modeset
> crtc's complete early.

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


[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/73] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

2016-08-01 Thread Patchwork
== Series Details ==

Series: series starting with [01/73] drm/i915: Unify intel_logical_ring_emit 
and intel_ring_emit
URL   : https://patchwork.freedesktop.org/series/10444/
State : failure

== Summary ==

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

Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-bdw-i5-5250u)
pass   -> FAIL   (fi-skl-i7-6700k)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-bdw-i5-5250u)

fi-kbl-qkkr  total:239  pass:180  dwarn:28  dfail:0   fail:3   skip:28 
fi-skl-i5-6260u  total:239  pass:223  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:239  pass:207  dwarn:0   dfail:0   fail:4   skip:28 
ro-bdw-i5-5250u  total:239  pass:218  dwarn:4   dfail:0   fail:1   skip:16 
ro-bdw-i7-5557U  total:239  pass:222  dwarn:1   dfail:0   fail:0   skip:16 
ro-bsw-n3050 total:239  pass:193  dwarn:0   dfail:0   fail:4   skip:42 
ro-skl3-i5-6260u total:239  pass:221  dwarn:0   dfail:0   fail:4   skip:14 
fi-hsw-i7-4770k failed to connect after reboot
fi-snb-i7-2600 failed to connect after reboot
ro-bdw-i7-5600u failed to connect after reboot
ro-byt-n2820 failed to connect after reboot
ro-hsw-i3-4010u failed to connect after reboot
ro-hsw-i7-4770r failed to connect after reboot
ro-ivb2-i7-3770 failed to connect after reboot
ro-ivb-i7-3770 failed to connect after reboot
ro-snb-i7-2620M failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1649/

f1b78d2 drm-intel-nightly: 2016y-07m-29d-19h-16m-57s UTC integration manifest
df1c140 drm/i915: Export our request as a dma-buf fence on the reservation 
object
263d4e8 drm/i915: Enable lockless lookup of request tracking via RCU
8174b2f drm/i915: Move i915_gem_object_wait_rendering()
6f6370b drm/i915: Move obj->active:5 to obj->flags
36251b6 drm/i915: Use dev_priv consistently through the intel_frontbuffer 
interface
b7ae095 drm/i915: Use atomics to manipulate obj->frontbuffer_bits
4925855 drm/i915: Make fb_tracking.lock a spinlock
27c4661 drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()
88651c8 drm/i915: Make i915_vma_pin() small and inline
5e6ac34 drm/i915: Combine all i915_vma bitfields into a single set of flags
fbf6f72 drm/i915: Start passing around i915_vma from execbuffer
01bc26b drm/i915: Wrap vma->pin_count accessors with small inline helpers
3b44fa5 drm/i915: Record allocated vma size
50855fb drm/i915: Update i915_gem_get_ggtt_size/_alignment to use 
drm_i915_private
72b5ff8 drm/i915: Update the GGTT size/alignment query functions
70c2139 drm/i915: Convert 4096 alignment request to 0 for drm_mm allocations
45bb3f4 drm/i915: Split insertion/binding of an object into the VM
80e55ab drm/i915: Reduce WARN(i915_gem_valid_gtt_space) to a debug-only check
32ac54e drm/i915: Pad GTT views of exec objects up to user specified size
bded2eb drm/i915: Fix up vma alignment to be u64
8147236 drm/i915: Remove i915_gem_execbuffer_retire_commands()
94be894 drm/i915: Remove request retirement before each batch
3558502 drm/i915: Double check the active status on the batch pool
70c107e drm/i915: Remove surplus drm_device parameter to 
i915_gem_evict_something()
0610eca drm/i915: Combine loops within i915_gem_evict_something
67f61eb Revert "drm/i915: Clean up associated VMAs on context destruction"
91a7255 drm/i915: Mark the context and address space as closed
7199dbd drm/i915: Release vma when the handle is closed
6c0a97e drm/i915: Track active vma requests
77ae8f4 drm/i915: i915_vma_move_to_active prep patch
c1876f1 drm/i915: Move request list retirement to i915_gem_request.c
9ebfe3f drm/i915: Double check activity before relocations
405589d drm/i915: s/__i915_wait_request/i915_wait_request/
7ec3b4d drm/i915: Disable waitboosting for a saturated engine
3cce71d drm/i915: Move the special case wait-request handling to its one caller
45d740d3 drm/i915: Convert intel_overlay to request tracking
9865233 drm/i915: Track requests inside each intel_ring
0c3ecda drm/i915: Refactor activity tracking for requests
a9b8ad0 drm/i915: Remove obsolete i915_gem_object_flush_active()
be0e9ed drm/i915: Rename request->list to link for consistency
a90256d drm/i915: Refactor blocking waits
842fd46 drm/i915: Mark up i915_gem_active for locking annotation
f989dd8 drm/i915: Prepare i915_gem_active for annotations
c662f3e drm/i915: Introduce i915_gem_active for request tracking
5dabc19 drm/i915: Kill drop_pages()
12919f3 drm/i915: Be more careful when unbinding vma
db6b7cd drm/i915: Count how many VMA are bound for an object
1a519bb drm/i915: Store owning file on the i915_address_space
8f90320 drm/i915: Split early global GTT initialisation
8038cb4 drm/i915: Amalgamate GGTT/ppGTT vma debug list walkers
660476d drm/i915: Rename engine->semaphore.sync_to, engine->sempahore.signal 
locals
af5b9c6 drm/i915: Simplify calling 

Re: [Intel-gfx] [PATCH 46/73] drm/i915: Release vma when the handle is closed

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> In order to prevent a leak of the vma on shared objects, we need to
> hook into the object_close callback to destroy the vma on the object for
> this file. However, if we destroyed that vma immediately we may cause
> unexpected application stalls as we try to unbind a busy vma - hence we
> defer the unbind to when we retire the vma.
> 
> v2: Keep vma allocated until closed. This is useful for a later
> optimisation, but it is required now in order to handle potential
> recursion of i915_vma_unbind() by retiring itself.
> v3: Comments are important.
> 
> Testcase: igt/gem_ppggtt/flink-and-close-vma-leak
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Daniele Ceraolo Spurio 

Already added to previous series;

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_drv.c   |  1 +
>  drivers/gpu/drm/i915/i915_drv.h   |  4 +-
>  drivers/gpu/drm/i915/i915_gem.c   | 88 
> ++-
>  drivers/gpu/drm/i915/i915_gem_evict.c |  8 +---
>  drivers/gpu/drm/i915/i915_gem_gtt.c   | 25 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.h   |  1 +
>  6 files changed, 77 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 478e8168ad94..869baa6a5196 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2574,6 +2574,7 @@ static struct drm_driver driver = {
>   .postclose = i915_driver_postclose,
>   .set_busid = drm_pci_set_busid,
>  
> + .gem_close_object = i915_gem_close_object,
>   .gem_free_object = i915_gem_free_object,
>   .gem_vm_ops = _gem_vm_ops,
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a1c4c768c0c3..f470ea195253 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3014,8 +3014,8 @@ 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_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);
>  void i915_gem_free_object(struct drm_gem_object *obj);
> -void i915_gem_vma_destroy(struct i915_vma *vma);
>  
>  /* Flags used by pin/bind */
>  #define PIN_MAPPABLE (1<<0)
> @@ -3048,6 +3048,8 @@ int __must_check i915_vma_unbind(struct i915_vma *vma);
>   * _guarantee_ VMA in question is _not in use_ anywhere.
>   */
>  int __must_check __i915_vma_unbind_no_wait(struct i915_vma *vma);
> +void i915_vma_close(struct i915_vma *vma);
> +void i915_vma_destroy(struct i915_vma *vma);
>  
>  int i915_gem_object_unbind(struct drm_i915_gem_object *obj);
>  int i915_gem_object_put_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 3ebbeb4e0a24..74d24d7e3ca2 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2596,6 +2596,19 @@ out_rearm:
>   }
>  }
>  
> +void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
> +{
> + struct drm_i915_gem_object *obj = to_intel_bo(gem);
> + struct drm_i915_file_private *fpriv = file->driver_priv;
> + struct i915_vma *vma, *vn;
> +
> + mutex_lock(>base.dev->struct_mutex);
> + list_for_each_entry_safe(vma, vn, >vma_list, obj_link)
> + if (vma->vm->file == fpriv)
> + i915_vma_close(vma);
> + mutex_unlock(>base.dev->struct_mutex);
> +}
> +
>  /**
>   * i915_gem_wait_ioctl - implements DRM_IOCTL_I915_GEM_WAIT
>   * @dev: drm device pointer
> @@ -2803,26 +2816,32 @@ static int __i915_vma_unbind(struct i915_vma *vma, 
> bool wait)
>   if (active && wait) {
>   int idx;
>  
> + /* When a closed VMA is retired, it is unbound - eek.
> +  * In order to prevent it from being recursively closed,
> +  * take a pin on the vma so that the second unbind is
> +  * aborted.
> +  */
> + vma->pin_count++;
> +
>   for_each_active(active, idx) {
>   ret = i915_gem_active_retire(>last_read[idx],
>      >vm->dev->struct_mutex);
>   if (ret)
> - return ret;
> + break;
>   }
>  
> + vma->pin_count--;
> + if (ret)
> + return ret;
> +
>   GEM_BUG_ON(i915_vma_is_active(vma));
>   }
>  
>   if (vma->pin_count)
>   return -EBUSY;
>  
> - if (list_empty(>obj_link))
> - return 0;
> -
> - if 

Re: [Intel-gfx] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

2016-08-01 Thread Peter Antoine

On Mon, 1 Aug 2016, Chris Wilson wrote:


On Mon, Aug 01, 2016 at 11:03:48AM +0100, Peter Antoine wrote:

On Mon, 1 Aug 2016, Chris Wilson wrote:


On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote:

This change adds a RC6 test for the MOCS. The MOCS registers are loaded
and saved as part of the RC6 cycle but not all the registers are
saved/restored. This tests that those registers are correctly restored.

Signed-off-by: Peter Antoine 
---
tests/gem_mocs_settings.c | 56 +++
1 file changed, 56 insertions(+)

diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
index 4fb3a02..66d02d9 100644
--- a/tests/gem_mocs_settings.c
+++ b/tests/gem_mocs_settings.c
@@ -518,6 +518,59 @@ static void run_tests(unsigned mode)
intel_register_access_fini();
}

+static unsigned int readit(const char *path)
+{
+   unsigned int ret = 0;
+   int scanned = 0;
+   FILE *file;
+
+   file = fopen(path, "r");
+   igt_assert(file);
+   scanned = fscanf(file, "%u", );
+   igt_assert_eq(scanned, 1);
+
+   fclose(file);
+
+   return ret;
+}
+
+static int read_rc6_residency(void)
+{
+   unsigned int residency;
+   const int device = drm_get_card();
+   static const char path_format[] =
+   "/sys/class/drm/card%d/power/rc6_residency_ms";
+   char path[sizeof(path_format)];
+   int  ret;
+
+   ret = snprintf(path, sizeof(path)-1, path_format, device);
+
+   igt_assert_neq(ret, -1);
+   residency = readit(path);


This is duplicating code from igt_sysfs.c


PS: Not in the current tree. The code is based on code from
pm_rc6_residency.


Your tree is a couple of months out of date.
-Chris


Am I pulling from the wrong repo?

git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools re_pull
Cloning into 're_pull'...
remote: Counting objects: 25319, done.
remote: Compressing objects: 100% (5802/5802), done.
remote: Total 25319 (delta 19840), reused 24789 (delta 19458)
Receiving objects: 100% (25319/25319), 16.67 MiB | 1.35 MiB/s, done.
Resolving deltas: 100% (19840/19840), done.
Checking connectivity... done.

Top 10 commits:
53b4dfd tests: Skip if we cannot reserve infinite fd for ourselves
5c10362 igt/gem_busy: Don't run hang tests under the hangchecker
b2e8d2c igt/gem_concurrent_blit: More subtest grouping
d199ad8 igt/gem_concurrent_all: Fix up copy sizes
9315399 docs: minimal docs for igt_vgem.c

I get 62 references to the following search:
:vimgrep _residen ./**/*.c

All in:
overlay/rc6.c
tests/pm_rc6_residency.c
tests/pm_rpm.c
tools/intel_reg_decode.c
tools/intel_residency.c

Only the first 3 yielding code. What am I missing?

Peter.






--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> > Space reservation is already safe with respect to the ring->size
> > modulus, but hardware only expects to see values in the range
> > 0...ring->size-1 (inclusive) and so requires the modulus to prevent us
> > writing the value ring->size instead of 0. As this is only required for
> > the register itself, we can defer the modulus to the register update and
> > not perform it after every command packet. We keep the
> > intel_ring_advance() around in the code to provide demarcation for the
> > end-of-packet (which then can be compared against intel_ring_begin() as
> > the number of dwords emitted must match the reserved space).
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Dave Gordon 
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
> >  drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
> >  drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
> >  3 files changed, 18 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index bf42a66d6624..824f7efe4e64 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -373,7 +373,7 @@ static void execlists_update_context(struct 
> > drm_i915_gem_request *rq)
> >     struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
> >     uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
> >  
> > -   reg_state[CTX_RING_TAIL+1] = rq->tail;
> > +   reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, rq->tail);
> >  
> >     /* True 32b PPGTT with dynamic page allocation: update PDP
> >      * registers and point the unallocated PDPs to scratch page.
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 3142085b5cc0..21d5e8209400 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
> > drm_i915_gem_request *request)
> >  {
> >     struct drm_i915_private *dev_priv = request->i915;
> >  
> > -   I915_WRITE_TAIL(request->engine, request->tail);
> > +   I915_WRITE_TAIL(request->engine,
> > +   intel_ring_offset(request->ring, request->tail));
> >  }
> >  
> >  static void
> > @@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
> > drm_i915_gem_request *request)
> >     DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
> >  
> >     /* Now that the ring is fully powered up, update the tail */
> > -   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), request->tail);
> > +   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
> > +     intel_ring_offset(request->ring, request->tail));
> >     POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
> >  
> >     /* Let the ring send IDLE messages to the GT again,
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > index 14d2ea36fb88..9ac96ddb01ee 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > @@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct 
> > intel_ring *ring, i915_reg_t reg)
> >  
> >  static inline void intel_ring_advance(struct intel_ring *ring)
> >  {
> > +   /* Dummy function.
> > +    *
> > +    * This serves as a placeholder in the code so that the reader
> > +    * can compare against the preceding intel_ring_begin() and
> > +    * check that the number of dwords emitted matches the space
> > +    * reserved for the command packet (i.e. the value passed to
> > +    * intel_ring_begin()).
> > +    */
> > +}
> > +
> > +static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
> > +{
> >     /* The modulus is required so that we avoid writing
> >      * request->tail == ring->size, rather than the expected 0,
> >      * into the RING_TAIL register as that can cause a GPU hang.
> > -    * As this is only strictly required for the request->tail,
> > -    * and only then as we write the value into hardware, we can
> > -    * one day remove the modulus after every command packet.
> >      */
> > -   ring->tail &= ring->size - 1;
> > +   return value & (ring->size - 1);
> >  }
> 
> The comment seems outdated-ish as it speaks of modulus which is nowhere
> to be seen. I'd speak of 'masking'. With that,

Instead of that,

@@ -2081,6 +2082,8 @@ intel_engine_create_ring(struct intel_engine_cs *engine, 
int size)
struct intel_ring *ring;
int ret;
 
+   GEM_BUG_ON(!is_power_of_2(size));
+
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (ring == NULL) {
DRM_DEBUG_DRIVER("Failed to allocate ringbuffer %s\n",

-- 
Chris 

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> > Space reservation is already safe with respect to the ring->size
> > modulus, but hardware only expects to see values in the range
> > 0...ring->size-1 (inclusive) and so requires the modulus to prevent us
> > writing the value ring->size instead of 0. As this is only required for
> > the register itself, we can defer the modulus to the register update and
> > not perform it after every command packet. We keep the
> > intel_ring_advance() around in the code to provide demarcation for the
> > end-of-packet (which then can be compared against intel_ring_begin() as
> > the number of dwords emitted must match the reserved space).
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Dave Gordon 
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
> >  drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
> >  drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
> >  3 files changed, 18 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index bf42a66d6624..824f7efe4e64 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -373,7 +373,7 @@ static void execlists_update_context(struct 
> > drm_i915_gem_request *rq)
> >     struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
> >     uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
> >  
> > -   reg_state[CTX_RING_TAIL+1] = rq->tail;
> > +   reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, rq->tail);
> >  
> >     /* True 32b PPGTT with dynamic page allocation: update PDP
> >      * registers and point the unallocated PDPs to scratch page.
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 3142085b5cc0..21d5e8209400 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
> > drm_i915_gem_request *request)
> >  {
> >     struct drm_i915_private *dev_priv = request->i915;
> >  
> > -   I915_WRITE_TAIL(request->engine, request->tail);
> > +   I915_WRITE_TAIL(request->engine,
> > +   intel_ring_offset(request->ring, request->tail));
> >  }
> >  
> >  static void
> > @@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
> > drm_i915_gem_request *request)
> >     DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
> >  
> >     /* Now that the ring is fully powered up, update the tail */
> > -   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), request->tail);
> > +   I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
> > +     intel_ring_offset(request->ring, request->tail));
> >     POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
> >  
> >     /* Let the ring send IDLE messages to the GT again,
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > index 14d2ea36fb88..9ac96ddb01ee 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> > @@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct 
> > intel_ring *ring, i915_reg_t reg)
> >  
> >  static inline void intel_ring_advance(struct intel_ring *ring)
> >  {
> > +   /* Dummy function.
> > +    *
> > +    * This serves as a placeholder in the code so that the reader
> > +    * can compare against the preceding intel_ring_begin() and
> > +    * check that the number of dwords emitted matches the space
> > +    * reserved for the command packet (i.e. the value passed to
> > +    * intel_ring_begin()).
> > +    */
> > +}
> > +
> > +static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
> > +{
> >     /* The modulus is required so that we avoid writing
> >      * request->tail == ring->size, rather than the expected 0,
> >      * into the RING_TAIL register as that can cause a GPU hang.
> > -    * As this is only strictly required for the request->tail,
> > -    * and only then as we write the value into hardware, we can
> > -    * one day remove the modulus after every command packet.
> >      */
> > -   ring->tail &= ring->size - 1;
> > +   return value & (ring->size - 1);
> >  }
> 
> The comment seems outdated-ish as it speaks of modulus which is nowhere
> to be seen. I'd speak of 'masking'. With that,

The operation is a modulus. The common optimisation for moduli with
a power-of-two divisor being applied.
-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] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

2016-08-01 Thread Chris Wilson
On Mon, Aug 01, 2016 at 11:03:48AM +0100, Peter Antoine wrote:
> On Mon, 1 Aug 2016, Chris Wilson wrote:
> 
> >On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote:
> >>This change adds a RC6 test for the MOCS. The MOCS registers are loaded
> >>and saved as part of the RC6 cycle but not all the registers are
> >>saved/restored. This tests that those registers are correctly restored.
> >>
> >>Signed-off-by: Peter Antoine 
> >>---
> >> tests/gem_mocs_settings.c | 56 
> >> +++
> >> 1 file changed, 56 insertions(+)
> >>
> >>diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
> >>index 4fb3a02..66d02d9 100644
> >>--- a/tests/gem_mocs_settings.c
> >>+++ b/tests/gem_mocs_settings.c
> >>@@ -518,6 +518,59 @@ static void run_tests(unsigned mode)
> >>intel_register_access_fini();
> >> }
> >>
> >>+static unsigned int readit(const char *path)
> >>+{
> >>+   unsigned int ret = 0;
> >>+   int scanned = 0;
> >>+   FILE *file;
> >>+
> >>+   file = fopen(path, "r");
> >>+   igt_assert(file);
> >>+   scanned = fscanf(file, "%u", );
> >>+   igt_assert_eq(scanned, 1);
> >>+
> >>+   fclose(file);
> >>+
> >>+   return ret;
> >>+}
> >>+
> >>+static int read_rc6_residency(void)
> >>+{
> >>+   unsigned int residency;
> >>+   const int device = drm_get_card();
> >>+   static const char path_format[] =
> >>+   "/sys/class/drm/card%d/power/rc6_residency_ms";
> >>+   char path[sizeof(path_format)];
> >>+   int  ret;
> >>+
> >>+   ret = snprintf(path, sizeof(path)-1, path_format, device);
> >>+
> >>+   igt_assert_neq(ret, -1);
> >>+   residency = readit(path);
> >
> >This is duplicating code from igt_sysfs.c
> 
> PS: Not in the current tree. The code is based on code from
> pm_rc6_residency.

Your tree is a couple of months out of date.
-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 4/5] drm/i915: Check live status before reading edid

2016-08-01 Thread Chris Wilson
On Tue, Jul 12, 2016 at 02:39:47PM +0300, David Weinehall wrote:
> On Thu, Jul 09, 2015 at 07:27:57PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote:
> > > Adding this for SKL onwards.
> > > 
> > > Signed-off-by: Sonika Jindal 
> > 
> > I think this is the critical piece really, and I'd like to roll it out for
> > all platforms. git has the code for all the old ones, so no big deal to
> > digg that out. Also we need your fix for the interrupt handling first ofc,
> > otherwise this won't work.
> > 
> > Then we can apply this and give it some good testing before we start
> > relying on it with caching hdmi probe status. I know this means that
> > things will be slower, but I've been burned a bit too much the last few
> > times we've tried this. And I really think we need the most amount of
> > testing we can get (hence rolling this out for all platforms). If your
> > hpd irq handling bugfix is indeed the bug that will be confirmed quickly,
> > otherwise it means back to debugging.
> 
> "things will be slower" is a bit of an understatement, sadly.
> On machines with no external display connected (the typical usecase for
> any device with an eDP, such as a laptop, tablet, etc.), the approach to
> repeat live status reads until buggy displays can be bothered to reply
> makes us spend twice as long as needed on resume.

Also this is causing stall during runtime hotplug. ~90ms stall causes
3-4 frames to be dropped in 24Hz movie. Even a single frame dropped
during movie playback is enough to be noticed.

This coupled with 

commit f8d03ea0053b23de42c828d559016eabe0b91523
Author: Gary Wang 
Date:   Wed Dec 23 16:11:35 2015 +0800

drm/i915: increase the tries for HDMI hotplug live status checking

which purports to "fix" live status for bdw+.

Afaict using live status is as broken as we told you it would be from
earlier experience.
-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 13/73] drm/i915: Move the modulus for ring emission to the register write

2016-08-01 Thread Joonas Lahtinen
On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote:
> Space reservation is already safe with respect to the ring->size
> modulus, but hardware only expects to see values in the range
> 0...ring->size-1 (inclusive) and so requires the modulus to prevent us
> writing the value ring->size instead of 0. As this is only required for
> the register itself, we can defer the modulus to the register update and
> not perform it after every command packet. We keep the
> intel_ring_advance() around in the code to provide demarcation for the
> end-of-packet (which then can be compared against intel_ring_begin() as
> the number of dwords emitted must match the reserved space).
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c |  6 --
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
>  3 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index bf42a66d6624..824f7efe4e64 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -373,7 +373,7 @@ static void execlists_update_context(struct 
> drm_i915_gem_request *rq)
>   struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
>   uint32_t *reg_state = rq->ctx->engine[engine->id].lrc_reg_state;
>  
> - reg_state[CTX_RING_TAIL+1] = rq->tail;
> + reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, rq->tail);
>  
>   /* True 32b PPGTT with dynamic page allocation: update PDP
>    * registers and point the unallocated PDPs to scratch page.
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 3142085b5cc0..21d5e8209400 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1718,7 +1718,8 @@ static void i9xx_submit_request(struct 
> drm_i915_gem_request *request)
>  {
>   struct drm_i915_private *dev_priv = request->i915;
>  
> - I915_WRITE_TAIL(request->engine, request->tail);
> + I915_WRITE_TAIL(request->engine,
> + intel_ring_offset(request->ring, request->tail));
>  }
>  
>  static void
> @@ -2505,7 +2506,8 @@ static void gen6_bsd_submit_request(struct 
> drm_i915_gem_request *request)
>   DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
>  
>   /* Now that the ring is fully powered up, update the tail */
> - I915_WRITE_FW(RING_TAIL(request->engine->mmio_base), request->tail);
> + I915_WRITE_FW(RING_TAIL(request->engine->mmio_base),
> +   intel_ring_offset(request->ring, request->tail));
>   POSTING_READ_FW(RING_TAIL(request->engine->mmio_base));
>  
>   /* Let the ring send IDLE messages to the GT again,
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 14d2ea36fb88..9ac96ddb01ee 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -460,14 +460,23 @@ static inline void intel_ring_emit_reg(struct 
> intel_ring *ring, i915_reg_t reg)
>  
>  static inline void intel_ring_advance(struct intel_ring *ring)
>  {
> + /* Dummy function.
> +  *
> +  * This serves as a placeholder in the code so that the reader
> +  * can compare against the preceding intel_ring_begin() and
> +  * check that the number of dwords emitted matches the space
> +  * reserved for the command packet (i.e. the value passed to
> +  * intel_ring_begin()).
> +  */
> +}
> +
> +static inline u32 intel_ring_offset(struct intel_ring *ring, u32 value)
> +{
>   /* The modulus is required so that we avoid writing
>    * request->tail == ring->size, rather than the expected 0,
>    * into the RING_TAIL register as that can cause a GPU hang.
> -  * As this is only strictly required for the request->tail,
> -  * and only then as we write the value into hardware, we can
> -  * one day remove the modulus after every command packet.
>    */
> - ring->tail &= ring->size - 1;
> + return value & (ring->size - 1);
>  }

The comment seems outdated-ish as it speaks of modulus which is nowhere
to be seen. I'd speak of 'masking'. With that,

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

>  
>  int __intel_ring_space(int head, int tail, int size);
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 07/12] drm/i915: Move DP link retraining into intel_dp_detect()

2016-08-01 Thread Ville Syrjälä
On Fri, Jul 29, 2016 at 02:45:29PM -0700, Manasi Navare wrote:
> On Thu, Jul 28, 2016 at 05:36:14PM -0700, Manasi Navare wrote:
> > On Thu, Jul 28, 2016 at 11:15:22PM +0300, Ville Syrjälä wrote:
> > > On Thu, Jul 28, 2016 at 12:48:53PM -0700, Manasi Navare wrote:
> > > > On Thu, Jul 28, 2016 at 05:50:43PM +0300, ville.syrj...@linux.intel.com 
> > > > wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > DP link retraining needs to grab some modeset locks to not race with
> > > > > modesets, so we can't really do it safely from the hpd_pulse, lest we
> > > > > risk deadlocking due to MST sideband stuff.
> > > > > 
> > > > > Move the link retraining to happen from the hotplug work instead.
> > > > > Doing at the end of intel_dp_detect() seems like a good place in case
> > > > > the sink already got disconnected, in which case retraining is
> > > > > pointless.
> > > > > 
> > > > > To determine if we need to schedule the hotplug work, we'll just check
> > > > > the sink lane status without locks from hpd_pulse. A little racy
> > > > > still eg. due to useing intel_dp->lane_count, but no less racy than
> > > > > what we already had. We'll repeat the check in from intel_dp_detect()
> > > > > with proper locking, where we'll also check if the link as actually
> > > > > active or not.
> > > > > 
> > > > > Cc: Ander Conselvan de Oliveira 
> > > > > 
> > > > > Cc: Jim Bride 
> > > > > Cc: Manasi D Navare 
> > > > > Cc: Durgadoss R 
> > > > > Signed-off-by: Ville Syrjälä 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 154 
> > > > > +---
> > > > >  1 file changed, 66 insertions(+), 88 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 4a4184c21989..675b83f57a07 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -3842,15 +3842,6 @@ intel_dp_check_mst_status(struct intel_dp 
> > > > > *intel_dp)
> > > > >   bret = intel_dp_get_sink_irq_esi(intel_dp, esi);
> > > > >  go_again:
> > > > >   if (bret == true) {
> > > > > -
> > > > > - /* check link status - esi[10] = 0x200c */
> > > > > - if (intel_dp->active_streams &&
> > > > > - !drm_dp_channel_eq_ok([10], 
> > > > > intel_dp->lane_count)) {
> > > > > - DRM_DEBUG_KMS("channel EQ not ok, 
> > > > > retraining\n");
> > > > > - intel_dp_start_link_train(intel_dp);
> > > > > - intel_dp_stop_link_train(intel_dp);
> > > > > - }
> > > > > -
> > > > >   DRM_DEBUG_KMS("got esi %3ph\n", esi);
> > > > >   ret = drm_dp_mst_hpd_irq(_dp->mst_mgr, 
> > > > > esi, );
> > > > >  
> > > > > @@ -3886,34 +3877,42 @@ go_again:
> > > > >   return -EINVAL;
> > > > >  }
> > > > >  
> > > > > -static void
> > > > > -intel_dp_check_link_status(struct intel_dp *intel_dp)
> > > > > +static bool
> > > > > +intel_dp_link_needs_retrain(struct intel_dp *intel_dp)
> > > > >  {
> > > > > - struct intel_encoder *intel_encoder = 
> > > > > _to_dig_port(intel_dp)->base;
> > > > > - struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > > > >   u8 link_status[DP_LINK_STATUS_SIZE];
> > > > >  
> > > > > - 
> > > > > WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> > > > > + if (intel_dp->active_streams == 0)
> > > > > + return false;
> > > > > +
> > > > > + if (intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING)
> > > > > + return true;
> > > > >  
> > > > >   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > > > >   DRM_ERROR("Failed to get link status\n");
> > > > > - return;
> > > > > + return false;
> > > > >   }
> > > > >  
> > > > > - if (!intel_encoder->base.crtc)
> > > > > - return;
> > > > > + return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> > > > 
> > > > According to the DP spec, we should also check for the clock recovery 
> > > > bit in DPCD
> > > > We should also add a check drm_dp_clock_recovery_ok(link_status, 
> > > > intel_dp->lane_count)
> > > 
> > > I think drm_dp_channel_eq_ok() checks all the bits: INTERLANE_ALIGN_DONE,
> > > CR_DONE, EQ_DONE, and SYMBOL_LOCKED.
> > 
> > It only checks for EQ_DONE and INTERLANE_ALIGN_DONE.
> > drm_dp_clock_recovery_ok() checks for DP_LANE_CR_DONE bit.
> > > 
> > > Anyways, while I was looking at the short pulse handling a bit more, I 
> > > came
> > > to the conclusion that we should rewrite it a bit.
> > > 
> > > The CTS docs seem to say that we're expected to read DPCD 0x200-0x205 

Re: [Intel-gfx] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

2016-08-01 Thread Peter Antoine

On Mon, 1 Aug 2016, Chris Wilson wrote:


On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote:

This change adds a RC6 test for the MOCS. The MOCS registers are loaded
and saved as part of the RC6 cycle but not all the registers are
saved/restored. This tests that those registers are correctly restored.

Signed-off-by: Peter Antoine 
---
 tests/gem_mocs_settings.c | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
index 4fb3a02..66d02d9 100644
--- a/tests/gem_mocs_settings.c
+++ b/tests/gem_mocs_settings.c
@@ -518,6 +518,59 @@ static void run_tests(unsigned mode)
intel_register_access_fini();
 }

+static unsigned int readit(const char *path)
+{
+   unsigned int ret = 0;
+   int scanned = 0;
+   FILE *file;
+
+   file = fopen(path, "r");
+   igt_assert(file);
+   scanned = fscanf(file, "%u", );
+   igt_assert_eq(scanned, 1);
+
+   fclose(file);
+
+   return ret;
+}
+
+static int read_rc6_residency(void)
+{
+   unsigned int residency;
+   const int device = drm_get_card();
+   static const char path_format[] =
+   "/sys/class/drm/card%d/power/rc6_residency_ms";
+   char path[sizeof(path_format)];
+   int  ret;
+
+   ret = snprintf(path, sizeof(path)-1, path_format, device);
+
+   igt_assert_neq(ret, -1);
+   residency = readit(path);


This is duplicating code from igt_sysfs.c


PS: Not in the current tree. The code is based on code from 
pm_rc6_residency.





+
+   return residency;
+}
+
+static void context_rc6_test(void)
+{
+   int fd = drm_open_driver(DRIVER_INTEL);
+   int res_ms;
+   uint32_t ctx_id = gem_context_create(fd);
+
+   igt_debug("RC6 Context Test\n");
+   check_control_registers(fd, I915_EXEC_RENDER, ctx_id, false);
+   check_l3cc_registers(fd, I915_EXEC_RENDER, ctx_id, false);
+
+   res_ms = read_rc6_residency();
+   sleep(3);


Still a large and arbitrary delay.


+   igt_assert_neq(res_ms, read_rc6_residency());


Still an assert rather than skipping when the user has disabled rc6.
-Chris




--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount of cascading failures

2016-08-01 Thread Peter Antoine

On Mon, 1 Aug 2016, Chris Wilson wrote:


On Fri, Jul 29, 2016 at 10:34:36AM +0100, Peter Antoine wrote:

If one of the previous tests fails then the following tests fail.
This patch means that the following tests do not fail when the previous
test fails (for some cases).


The problem is just gem_mocs_settings hasn't split its tests up into
subtests.

Chris,

Can you expand? The tests are at the minimal size for sensible results (I 
think). The problem is opening the driver for master when the test fails 
then the following tests will fail as master is not closed.


Is there a mechanism in the igt framework for doing this close on 
failure/skip?


If I move the master open code in the fixtures will this get called on all 
exit cases?


Peter.


-Chris




--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 04/12] drm/i915: Reject mixing MST and SST/HDMI on the same digital port

2016-08-01 Thread Maarten Lankhorst
Op 28-07-16 om 16:50 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> We can't mix MST with SST/HDMI on the same physical port, so we'll need
> to reject such configurations in check_digital_port_conflicts(). Nothing
> else will prevent this as MST has its fake encoders and its own connectors
> so the cloning checks won't catch this.
>
> The same digital port can be used multiple times, but only if all the
> encoders involved are MST encoders, so we only want to check MST vs.
> SST/HDMI, not MST vs. MST. And SST/HDMI vs. SST/HDMI we already check.

I guess this is to prevent DP1 and DP1-2 to be both set simultaneously?
I'm not sure kms_setmode would handle this case correctly, but the idea
is correct.

Reviewed-by: Maarten Lankhorst 


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


Re: [Intel-gfx] [PATCH 03/12] drm/i915: Avoid mixing up SST and MST in DDI setup

2016-08-01 Thread Maarten Lankhorst
Op 28-07-16 om 16:50 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> The MST vs. SST selection should depend purely on the choice of the
> connector/encoder. So don't try to determine the correct DDI mode
> based on the intel_dp->is_mst, which simply tells us whether the sink
> is in MST mode or not. Instead derive the information from the encoder
> type. Since the link training code deals in non-fake encoders, we'll
> also need to keep a second copy of that information around, which we'll
> now designate as 'link_mst'.
>
> Cc: Maarten Lankhorst 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Maarten Lankhorst 

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


Re: [Intel-gfx] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

2016-08-01 Thread Peter Antoine

On Mon, 1 Aug 2016, Chris Wilson wrote:


On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote:

This change adds a RC6 test for the MOCS. The MOCS registers are loaded
and saved as part of the RC6 cycle but not all the registers are
saved/restored. This tests that those registers are correctly restored.

Signed-off-by: Peter Antoine 
---
 tests/gem_mocs_settings.c | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
index 4fb3a02..66d02d9 100644
--- a/tests/gem_mocs_settings.c
+++ b/tests/gem_mocs_settings.c
@@ -518,6 +518,59 @@ static void run_tests(unsigned mode)
intel_register_access_fini();
 }

+static unsigned int readit(const char *path)
+{
+   unsigned int ret = 0;
+   int scanned = 0;
+   FILE *file;
+
+   file = fopen(path, "r");
+   igt_assert(file);
+   scanned = fscanf(file, "%u", );
+   igt_assert_eq(scanned, 1);
+
+   fclose(file);
+
+   return ret;
+}
+
+static int read_rc6_residency(void)
+{
+   unsigned int residency;
+   const int device = drm_get_card();
+   static const char path_format[] =
+   "/sys/class/drm/card%d/power/rc6_residency_ms";
+   char path[sizeof(path_format)];
+   int  ret;
+
+   ret = snprintf(path, sizeof(path)-1, path_format, device);
+
+   igt_assert_neq(ret, -1);
+   residency = readit(path);


This is duplicating code from igt_sysfs.c

Ok. Will fix.



+
+   return residency;
+}
+
+static void context_rc6_test(void)
+{
+   int fd = drm_open_driver(DRIVER_INTEL);
+   int res_ms;
+   uint32_t ctx_id = gem_context_create(fd);
+
+   igt_debug("RC6 Context Test\n");
+   check_control_registers(fd, I915_EXEC_RENDER, ctx_id, false);
+   check_l3cc_registers(fd, I915_EXEC_RENDER, ctx_id, false);
+
+   res_ms = read_rc6_residency();
+   sleep(3);

Distracted. Will fix.


Still a large and arbitrary delay.


+   igt_assert_neq(res_ms, read_rc6_residency());

Will change.


Still an assert rather than skipping when the user has disabled rc6.
-Chris




--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 51/73] drm/i915: Double check the active status on the batch pool

2016-08-01 Thread Chris Wilson
We should not rely on obj->active being uptodate unless we manually
flush it. Instead, we can verify that the next available batch object is
idle by looking at its last active request (and checking it for
completion).

v2: remove the struct drm_device forward declaration added in the
process of removing its necessity

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 15 ---
 drivers/gpu/drm/i915/i915_gem_batch_pool.h |  6 --
 drivers/gpu/drm/i915/intel_engine_cs.c |  2 +-
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 825981b5aa40..ed989596d9a3 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -41,15 +41,15 @@
 
 /**
  * i915_gem_batch_pool_init() - initialize a batch buffer pool
- * @dev: the drm device
+ * @engine: the associated request submission engine
  * @pool: the batch buffer pool
  */
-void i915_gem_batch_pool_init(struct drm_device *dev,
+void i915_gem_batch_pool_init(struct intel_engine_cs *engine,
  struct i915_gem_batch_pool *pool)
 {
int n;
 
-   pool->dev = dev;
+   pool->engine = engine;
 
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++)
INIT_LIST_HEAD(>cache_list[n]);
@@ -65,7 +65,7 @@ void i915_gem_batch_pool_fini(struct i915_gem_batch_pool 
*pool)
 {
int n;
 
-   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
+   lockdep_assert_held(>engine->i915->drm.struct_mutex);
 
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) {
struct drm_i915_gem_object *obj, *next;
@@ -101,7 +101,7 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
struct list_head *list;
int n;
 
-   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
+   lockdep_assert_held(>engine->i915->drm.struct_mutex);
 
/* Compute a power-of-two bucket, but throw everything greater than
 * 16KiB into the same bucket: i.e. the the buckets hold objects of
@@ -114,7 +114,8 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
 
list_for_each_entry_safe(tmp, next, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
-   if (tmp->active)
+   if (!i915_gem_active_is_idle(>last_read[pool->engine->id],
+>base.dev->struct_mutex))
break;
 
/* While we're looping, do some clean up */
@@ -133,7 +134,7 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
if (obj == NULL) {
int ret;
 
-   obj = i915_gem_object_create(pool->dev, size);
+   obj = i915_gem_object_create(>engine->i915->drm, size);
if (IS_ERR(obj))
return obj;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.h 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
index 848e90703eed..10d5ac4c00d3 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.h
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
@@ -27,13 +27,15 @@
 
 #include "i915_drv.h"
 
+struct intel_engine_cs;
+
 struct i915_gem_batch_pool {
-   struct drm_device *dev;
+   struct intel_engine_cs *engine;
struct list_head cache_list[4];
 };
 
 /* i915_gem_batch_pool.c */
-void i915_gem_batch_pool_init(struct drm_device *dev,
+void i915_gem_batch_pool_init(struct intel_engine_cs *engine,
  struct i915_gem_batch_pool *pool);
 void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
 struct drm_i915_gem_object*
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7dc214dfc2a8..6665068e583c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -185,7 +185,7 @@ void intel_engine_setup_common(struct intel_engine_cs 
*engine)
engine->fence_context = fence_context_alloc(1);
 
intel_engine_init_hangcheck(engine);
-   i915_gem_batch_pool_init(>i915->drm, >batch_pool);
+   i915_gem_batch_pool_init(engine, >batch_pool);
 }
 
 /**
-- 
2.8.1

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


[Intel-gfx] [PATCH 73/73] drm/i915: Export our request as a dma-buf fence on the reservation object

2016-08-01 Thread Chris Wilson
If the GEM objects being rendered with in this request have been
exported via dma-buf to a third party, hook ourselves into the dma-buf
reservation object so that the third party can serialise with our
rendering via the dma-buf fences.

Testcase: igt/prime_busy
Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 58 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31 ++--
 2 files changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 3a00ab3ad06e..c60a8d5bbad0 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -23,9 +23,13 @@
  * Authors:
  * Dave Airlie 
  */
+
+#include 
+#include 
+
 #include 
+
 #include "i915_drv.h"
-#include 
 
 static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
 {
@@ -218,25 +222,73 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
.end_cpu_access = i915_gem_end_cpu_access,
 };
 
+static void export_fences(struct drm_i915_gem_object *obj,
+ struct dma_buf *dma_buf)
+{
+   struct reservation_object *resv = dma_buf->resv;
+   struct drm_i915_gem_request *req;
+   unsigned long active;
+   int idx;
+
+   active = __I915_BO_ACTIVE(obj);
+   if (!active)
+   return;
+
+   /* Serialise with execbuf to prevent concurrent fence-loops */
+   mutex_lock(>base.dev->struct_mutex);
+
+   /* Mark the object for future fences before racily adding old fences */
+   obj->base.dma_buf = dma_buf;
+
+   ww_mutex_lock(>lock, NULL);
+
+   for_each_active(active, idx) {
+   req = i915_gem_active_get(>last_read[idx],
+ >base.dev->struct_mutex);
+   if (!req)
+   continue;
+
+   if (reservation_object_reserve_shared(resv) == 0)
+   reservation_object_add_shared_fence(resv, >fence);
+
+   i915_gem_request_put(req);
+   }
+
+   req = i915_gem_active_get(>last_write,
+ >base.dev->struct_mutex);
+   if (req) {
+   reservation_object_add_excl_fence(resv, >fence);
+   i915_gem_request_put(req);
+   }
+
+   ww_mutex_unlock(>lock);
+   mutex_unlock(>base.dev->struct_mutex);
+}
+
 struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
  struct drm_gem_object *gem_obj, int flags)
 {
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+   struct dma_buf *dma_buf;
 
exp_info.ops = _dmabuf_ops;
exp_info.size = gem_obj->size;
exp_info.flags = flags;
exp_info.priv = gem_obj;
 
-
if (obj->ops->dmabuf_export) {
int ret = obj->ops->dmabuf_export(obj);
if (ret)
return ERR_PTR(ret);
}
 
-   return dma_buf_export(_info);
+   dma_buf = dma_buf_export(_info);
+   if (IS_ERR(dma_buf))
+   return dma_buf;
+
+   export_fences(obj, dma_buf);
+   return dma_buf;
 }
 
 static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3a68ffaa55e6..f92bfafd1f49 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -26,13 +26,17 @@
  *
  */
 
+#include 
+#include 
+#include 
+
 #include 
 #include 
+
 #include "i915_drv.h"
+#include "i915_gem_dmabuf.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
-#include 
-#include 
 
 #define  __EXEC_OBJECT_HAS_PIN (1<<31)
 #define  __EXEC_OBJECT_HAS_FENCE   (1<<30)
@@ -1204,6 +1208,28 @@ void i915_vma_move_to_active(struct i915_vma *vma,
list_move_tail(>vm_link, >vm->active_list);
 }
 
+static void eb_export_fence(struct drm_i915_gem_object *obj,
+   struct drm_i915_gem_request *req,
+   unsigned int flags)
+{
+   struct reservation_object *resv;
+
+   resv = i915_gem_object_get_dmabuf_resv(obj);
+   if (!resv)
+   return;
+
+   /* Ignore errors from failing to allocate the new fence, we can't
+* handle an error right now. Worst case should be missed
+* synchronisation leading to rendering corruption.
+*/
+   ww_mutex_lock(>lock, NULL);
+   if (flags & EXEC_OBJECT_WRITE)
+   reservation_object_add_excl_fence(resv, >fence);
+   else if (reservation_object_reserve_shared(resv) == 0)
+   reservation_object_add_shared_fence(resv, >fence);
+   ww_mutex_unlock(>lock);
+}
+
 static void
 

[Intel-gfx] [PATCH 45/73] drm/i915: Track active vma requests

2016-08-01 Thread Chris Wilson
Hook the vma itself into the i915_gem_request_retire() so that we can
accurately track when a solitary vma is inactive (as opposed to having
to wait for the entire object to be idle). This improves the interaction
when using multiple contexts (with full-ppgtt) and eliminates some
frequent list walking when retiring objects after a completed request.

A side-effect is that we get an active vma reference for free. The
consequence of this is shown in the next patch...

v2: Update inline names to be consistent with
i915_gem_object_get_active()

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 50 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 20 
 drivers/gpu/drm/i915/i915_gem_gtt.h| 33 
 5 files changed, 91 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f5a16797659..6285d50e6876 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -365,7 +365,7 @@ static int per_file_stats(int id, void *ptr, void *data)
continue;
}
 
-   if (obj->active) /* XXX per-vma statistic */
+   if (i915_vma_is_active(vma))
stats->active += vma->node.size;
else
stats->inactive += vma->node.size;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index da0e4c01fd25..3ebbeb4e0a24 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2347,7 +2347,6 @@ i915_gem_object_retire__read(struct i915_gem_active 
*active,
int idx = request->engine->id;
struct drm_i915_gem_object *obj =
container_of(active, struct drm_i915_gem_object, 
last_read[idx]);
-   struct i915_vma *vma;
 
GEM_BUG_ON((obj->active & (1 << idx)) == 0);
 
@@ -2359,12 +2358,9 @@ i915_gem_object_retire__read(struct i915_gem_active 
*active,
 * so that we don't steal from recently used but inactive objects
 * (unless we are forced to ofc!)
 */
-   list_move_tail(>global_list, >i915->mm.bound_list);
-
-   list_for_each_entry(vma, >vma_list, obj_link) {
-   if (!list_empty(>vm_link))
-   list_move_tail(>vm_link, >vm->inactive_list);
-   }
+   if (obj->bind_count)
+   list_move_tail(>global_list,
+  >i915->mm.bound_list);
 
i915_gem_object_put(obj);
 }
@@ -2797,8 +2793,29 @@ static void __i915_vma_iounmap(struct i915_vma *vma)
 static int __i915_vma_unbind(struct i915_vma *vma, bool wait)
 {
struct drm_i915_gem_object *obj = vma->obj;
+   unsigned long active;
int ret;
 
+   /* First wait upon any activity as retiring the request may
+* have side-effects such as unpinning or even unbinding this vma.
+*/
+   active = i915_vma_get_active(vma);
+   if (active && wait) {
+   int idx;
+
+   for_each_active(active, idx) {
+   ret = i915_gem_active_retire(>last_read[idx],
+  >vm->dev->struct_mutex);
+   if (ret)
+   return ret;
+   }
+
+   GEM_BUG_ON(i915_vma_is_active(vma));
+   }
+
+   if (vma->pin_count)
+   return -EBUSY;
+
if (list_empty(>obj_link))
return 0;
 
@@ -2807,18 +2824,9 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
return 0;
}
 
-   if (vma->pin_count)
-   return -EBUSY;
-
GEM_BUG_ON(obj->bind_count == 0);
GEM_BUG_ON(!obj->pages);
 
-   if (wait) {
-   ret = i915_gem_object_wait_rendering(obj, false);
-   if (ret)
-   return ret;
-   }
-
if (vma->is_ggtt && vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
i915_gem_object_finish_gtt(obj);
 
@@ -3201,9 +3209,6 @@ i915_gem_object_flush_cpu_write_domain(struct 
drm_i915_gem_object *obj)
 int
 i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
 {
-   struct drm_device *dev = obj->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
uint32_t old_write_domain, old_read_domains;
struct i915_vma *vma;
int ret;
@@ -3256,9 +3261,10 @@ i915_gem_object_set_to_gtt_domain(struct 
drm_i915_gem_object *obj, bool write)
 
/* And bump the LRU for this access */
vma = i915_gem_obj_to_ggtt(obj);
-   if (vma && drm_mm_node_allocated(>node) && 

[Intel-gfx] [PATCH 57/73] drm/i915: Split insertion/binding of an object into the VM

2016-08-01 Thread Chris Wilson
Split the insertion into the address space's range manager and binding
of that object into the GTT to simplify the code flow when pinning a
VMA.

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

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ba89d98e2aed..a6a30c7514e0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2957,12 +2957,12 @@ static bool i915_gem_valid_gtt_space(struct i915_vma 
*vma,
  * @flags: mask of PIN_* flags to use
  */
 static struct i915_vma *
-i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
-  struct i915_address_space *vm,
-  const struct i915_ggtt_view *ggtt_view,
-  u64 size,
-  u64 alignment,
-  u64 flags)
+i915_gem_object_insert_into_vm(struct drm_i915_gem_object *obj,
+  struct i915_address_space *vm,
+  const struct i915_ggtt_view *ggtt_view,
+  u64 size,
+  u64 alignment,
+  u64 flags)
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3088,19 +3088,12 @@ search_free:
}
GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level));
 
-   trace_i915_vma_bind(vma, flags);
-   ret = i915_vma_bind(vma, obj->cache_level, flags);
-   if (ret)
-   goto err_remove_node;
-
list_move_tail(>global_list, _priv->mm.bound_list);
list_move_tail(>vm_link, >inactive_list);
obj->bind_count++;
 
return vma;
 
-err_remove_node:
-   drm_mm_remove_node(>node);
 err_vma:
vma = ERR_PTR(ret);
 err_unpin:
@@ -3760,24 +3753,26 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
}
}
 
-   bound = vma ? vma->bound : 0;
if (vma == NULL || !drm_mm_node_allocated(>node)) {
-   vma = i915_gem_object_bind_to_vm(obj, vm, ggtt_view,
-size, alignment, flags);
+   vma = i915_gem_object_insert_into_vm(obj, vm, ggtt_view,
+size, alignment, flags);
if (IS_ERR(vma))
return PTR_ERR(vma);
-   } else {
-   ret = i915_vma_bind(vma, obj->cache_level, flags);
-   if (ret)
-   return ret;
}
 
+   bound = vma->bound;
+   ret = i915_vma_bind(vma, obj->cache_level, flags);
+   if (ret)
+   return ret;
+
if (ggtt_view && ggtt_view->type == I915_GGTT_VIEW_NORMAL &&
(bound ^ vma->bound) & GLOBAL_BIND) {
__i915_vma_set_map_and_fenceable(vma);
WARN_ON(flags & PIN_MAPPABLE && !obj->map_and_fenceable);
}
 
+   GEM_BUG_ON(i915_vma_misplaced(vma, size, alignment, flags));
+
vma->pin_count++;
return 0;
 }
-- 
2.8.1

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


[Intel-gfx] [PATCH 49/73] drm/i915: Combine loops within i915_gem_evict_something

2016-08-01 Thread Chris Wilson
Slight micro-optimise to produce combine loops so that gcc is able to
optimise the inner-loops concisely. Since we are reviewing the loops, we
can update the comments to describe the current state of affairs, in
particular the distinction between evicting from the global GTT (which
may contain untracked items and transient global pins) and the
per-process GTT.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_evict.c | 143 +-
 1 file changed, 70 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 3437ced76cb6..016be7316676 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -34,6 +34,19 @@
 #include "i915_trace.h"
 
 static bool
+gpu_is_idle(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   for_each_engine(engine, dev_priv) {
+   if (!list_empty(>request_list))
+   return false;
+   }
+
+   return true;
+}
+
+static bool
 mark_free(struct i915_vma *vma, struct list_head *unwind)
 {
if (vma->pin_count)
@@ -76,37 +89,31 @@ i915_gem_evict_something(struct drm_device *dev, struct 
i915_address_space *vm,
 unsigned long start, unsigned long end,
 unsigned flags)
 {
-   struct list_head eviction_list, unwind_list;
-   struct i915_vma *vma;
-   int ret = 0;
-   int pass = 0;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct list_head eviction_list;
+   struct list_head *phases[] = {
+   >inactive_list,
+   >active_list,
+   NULL,
+   }, **phase;
+   struct i915_vma *vma, *next;
+   int ret;
 
trace_i915_gem_evict(dev, min_size, alignment, flags);
 
/*
 * The goal is to evict objects and amalgamate space in LRU order.
 * The oldest idle objects reside on the inactive list, which is in
-* retirement order. The next objects to retire are those on the (per
-* ring) active list that do not have an outstanding flush. Once the
-* hardware reports completion (the seqno is updated after the
-* batchbuffer has been finished) the clean buffer objects would
-* be retired to the inactive list. Any dirty objects would be added
-* to the tail of the flushing list. So after processing the clean
-* active objects we need to emit a MI_FLUSH to retire the flushing
-* list, hence the retirement order of the flushing list is in
-* advance of the dirty objects on the active lists.
+* retirement order. The next objects to retire are those in flight,
+* on the active list, again in retirement order.
 *
 * The retirement sequence is thus:
 *   1. Inactive objects (already retired)
-*   2. Clean active objects
-*   3. Flushing list
-*   4. Dirty active objects.
+*   2. Active objects (will stall on unbinding)
 *
 * On each list, the oldest objects lie at the HEAD with the freshest
 * object on the TAIL.
 */
-
-   INIT_LIST_HEAD(_list);
if (start != 0 || end != vm->total) {
drm_mm_init_scan_with_range(>mm, min_size,
alignment, cache_level,
@@ -114,79 +121,71 @@ i915_gem_evict_something(struct drm_device *dev, struct 
i915_address_space *vm,
} else
drm_mm_init_scan(>mm, min_size, alignment, cache_level);
 
-search_again:
-   /* First see if there is a large enough contiguous idle region... */
-   list_for_each_entry(vma, >inactive_list, vm_link) {
-   if (mark_free(vma, _list))
-   goto found;
-   }
-
if (flags & PIN_NONBLOCK)
-   goto none;
+   phases[1] = NULL;
 
-   /* Now merge in the soon-to-be-expired objects... */
-   list_for_each_entry(vma, >active_list, vm_link) {
-   if (mark_free(vma, _list))
-   goto found;
-   }
+search_again:
+   INIT_LIST_HEAD(_list);
+   phase = phases;
+   do {
+   list_for_each_entry(vma, *phase, vm_link)
+   if (mark_free(vma, _list))
+   goto found;
+   } while (*++phase);
 
-none:
/* Nothing found, clean up and bail out! */
-   while (!list_empty(_list)) {
-   vma = list_first_entry(_list,
-  struct i915_vma,
-  exec_list);
+   list_for_each_entry_safe(vma, next, _list, exec_list) {
ret = drm_mm_scan_remove_block(>node);
BUG_ON(ret);
 
-   list_del_init(>exec_list);
+   

[Intel-gfx] [PATCH 70/73] drm/i915: Move obj->active:5 to obj->flags

2016-08-01 Thread Chris Wilson
We are motivated to avoid using a bitfield for obj->active for a couple
of reasons. Firstly, we wish to document our lockless read of obj->active
using READ_ONCE inside i915_gem_busy_ioctl() and that requires an
integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code
when presented with a bitfield and that shows up high on the profiles of
request tracking (mainly due to excess memory traffic as it converts
the bitfield to a register and back and generates frequent AGI in the
process).

v2: BIT, break up a long line in compute the other engines, new paint
for i915_gem_object_is_active (now i915_gem_object_get_active).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 37 +-
 drivers/gpu/drm/i915/i915_gem.c| 16 ++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 20 
 drivers/gpu/drm/i915/i915_gem_shrinker.c   |  5 ++--
 drivers/gpu/drm/i915/i915_gem_userptr.c|  2 +-
 6 files changed, 64 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 10a346237795..920a2de95cd5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -91,7 +91,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
 
 static char get_active_flag(struct drm_i915_gem_object *obj)
 {
-   return obj->active ? '*' : ' ';
+   return i915_gem_object_is_active(obj) ? '*' : ' ';
 }
 
 static char get_pin_flag(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3de75e82ca76..db5dc5bd78d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2155,12 +2155,16 @@ struct drm_i915_gem_object {
 
struct list_head batch_pool_link;
 
+   unsigned long flags;
/**
 * This is set if the object is on the active lists (has pending
 * rendering and so a non-zero seqno), and is not set if it i s on
 * inactive (ready to be unbound) list.
 */
-   unsigned int active:I915_NUM_ENGINES;
+#define I915_BO_ACTIVE_SHIFT 0
+#define I915_BO_ACTIVE_MASK ((1 << I915_NUM_ENGINES) - 1)
+#define __I915_BO_ACTIVE(bo) \
+   ((READ_ONCE((bo)->flags) >> I915_BO_ACTIVE_SHIFT) & I915_BO_ACTIVE_MASK)
 
/**
 * This is set if the object has been written to since last bound
@@ -2325,6 +2329,37 @@ i915_gem_object_has_struct_page(const struct 
drm_i915_gem_object *obj)
return obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE;
 }
 
+static inline unsigned long
+i915_gem_object_get_active(const struct drm_i915_gem_object *obj)
+{
+   return (obj->flags >> I915_BO_ACTIVE_SHIFT) & I915_BO_ACTIVE_MASK;
+}
+
+static inline bool
+i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
+{
+   return i915_gem_object_get_active(obj);
+}
+
+static inline void
+i915_gem_object_set_active(struct drm_i915_gem_object *obj, int engine)
+{
+   obj->flags |= BIT(engine + I915_BO_ACTIVE_SHIFT);
+}
+
+static inline void
+i915_gem_object_clear_active(struct drm_i915_gem_object *obj, int engine)
+{
+   obj->flags &= ~BIT(engine + I915_BO_ACTIVE_SHIFT);
+}
+
+static inline bool
+i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
+ int engine)
+{
+   return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
+}
+
 /*
  * Optimised SGL iterator for GEM objects
  */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c4e5c7c1891b..b44a8e036373 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1354,7 +1354,7 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj,
 
if (!readonly) {
active = obj->last_read;
-   active_mask = obj->active;
+   active_mask = i915_gem_object_get_active(obj);
} else {
active_mask = 1;
active = >last_write;
@@ -1398,7 +1398,7 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
BUG_ON(!mutex_is_locked(>struct_mutex));
BUG_ON(!dev_priv->mm.interruptible);
 
-   active_mask = obj->active;
+   active_mask = i915_gem_object_get_active(obj);
if (!active_mask)
return 0;
 
@@ -2361,10 +2361,10 @@ i915_gem_object_retire__read(struct i915_gem_active 
*active,
struct drm_i915_gem_object *obj =
container_of(active, struct drm_i915_gem_object, 
last_read[idx]);
 
-   GEM_BUG_ON((obj->active & (1 << idx)) == 0);
+   GEM_BUG_ON(!i915_gem_object_has_active_engine(obj, idx));
 
-   obj->active &= ~(1 << idx);
-   if (obj->active)
+   i915_gem_object_clear_active(obj, idx);
+   if (i915_gem_object_is_active(obj))
return;
 
  

[Intel-gfx] [PATCH 61/73] drm/i915: Record allocated vma size

2016-08-01 Thread Chris Wilson
Tracking the size of the VMA as allocated allows us to dramatically
reduce the complexity of later functions (like inserting the VMA in to
the drm_mm range manager).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 103 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c |  67 ---
 drivers/gpu/drm/i915/i915_gem_gtt.h |   5 +-
 3 files changed, 63 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f11bf6c4f86a..d89fbee5c48a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2976,53 +2976,36 @@ i915_gem_object_insert_into_vm(struct 
drm_i915_gem_object *obj,
   u64 alignment,
   u64 flags)
 {
-   struct drm_device *dev = obj->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   u64 start, end;
-   u32 search_flag, alloc_flag;
+   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct i915_vma *vma;
+   u64 start, end;
+   u64 min_alignment;
int ret;
 
-   if (i915_is_ggtt(vm)) {
-   u32 fence_size, fence_alignment, unfenced_alignment;
-   u64 view_size;
-
-   if (WARN_ON(!ggtt_view))
-   return ERR_PTR(-EINVAL);
-
-   view_size = i915_ggtt_view_size(obj, ggtt_view);
-
-   fence_size = i915_gem_get_ggtt_size(dev_priv,
-   view_size,
-   obj->tiling_mode);
-   fence_alignment = i915_gem_get_ggtt_alignment(dev_priv,
- view_size,
- obj->tiling_mode,
- true);
-   unfenced_alignment = i915_gem_get_ggtt_alignment(dev_priv,
-view_size,
-
obj->tiling_mode,
-false);
-   size = max(size, view_size);
-   if (flags & PIN_MAPPABLE)
-   size = max_t(u64, size, fence_size);
-
-   if (alignment == 0)
-   alignment = flags & PIN_MAPPABLE ? fence_alignment :
-   unfenced_alignment;
-   if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
-   DRM_DEBUG("Invalid object (view type=%u) alignment 
requested %llx\n",
- ggtt_view ? ggtt_view->type : 0,
- (long long)alignment);
-   return ERR_PTR(-EINVAL);
-   }
-   } else {
-   size = max_t(u64, size, obj->base.size);
-   alignment = 4096;
+   vma = ggtt_view ?
+   i915_gem_obj_lookup_or_create_ggtt_vma(obj, ggtt_view) :
+   i915_gem_obj_lookup_or_create_vma(obj, vm);
+   if (IS_ERR(vma))
+   return vma;
+
+   size = max(size, vma->size);
+   if (flags & PIN_MAPPABLE)
+   size = i915_gem_get_ggtt_size(dev_priv, size, obj->tiling_mode);
+
+   min_alignment =
+   i915_gem_get_ggtt_alignment(dev_priv, size, obj->tiling_mode,
+   flags & PIN_MAPPABLE);
+   if (alignment == 0)
+   alignment = min_alignment;
+   if (alignment & (min_alignment - 1)) {
+   DRM_DEBUG("Invalid object alignment requested %llu, minimum 
%llu\n",
+ alignment, min_alignment);
+   return ERR_PTR(-EINVAL);
}
 
start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
-   end = vm->total;
+
+   end = vma->vm->total;
if (flags & PIN_MAPPABLE)
end = min_t(u64, end, dev_priv->ggtt.mappable_end);
if (flags & PIN_ZONE_4G)
@@ -3033,8 +3016,7 @@ i915_gem_object_insert_into_vm(struct drm_i915_gem_object 
*obj,
 * attempt to find space.
 */
if (size > end) {
-   DRM_DEBUG("Attempting to bind an object (view type=%u) larger 
than the aperture: request=%llu [object=%zd] > %s aperture=%llu\n",
- ggtt_view ? ggtt_view->type : 0,
+   DRM_DEBUG("Attempting to bind an object larger than the 
aperture: request=%llu [object=%zd] > %s aperture=%llu\n",
  size, obj->base.size,
  flags & PIN_MAPPABLE ? "mappable" : "total",
  end);
@@ -3047,31 +3029,27 @@ i915_gem_object_insert_into_vm(struct 
drm_i915_gem_object *obj,
 
i915_gem_object_pin_pages(obj);
 
-   vma = ggtt_view ? 

[Intel-gfx] [PATCH 41/73] drm/i915: s/__i915_wait_request/i915_wait_request/

2016-08-01 Thread Chris Wilson
There is only one wait on request function now, so drop the "expert"
indication of leading __.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 18 +-
 drivers/gpu/drm/i915/i915_gem_request.c | 16 
 drivers/gpu/drm/i915/i915_gem_request.h | 12 ++--
 drivers/gpu/drm/i915/i915_gem_userptr.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c| 14 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c |  8 
 6 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c47c9f95eafa..d320d3711fa5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1420,7 +1420,7 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
mutex_unlock(>struct_mutex);
ret = 0;
for (i = 0; ret == 0 && i < n; i++)
-   ret = __i915_wait_request(requests[i], true, NULL, rps);
+   ret = i915_wait_request(requests[i], true, NULL, rps);
mutex_lock(>struct_mutex);
 
for (i = 0; i < n; i++)
@@ -2726,9 +2726,9 @@ out:
 
for (i = 0; i < n; i++) {
if (ret == 0)
-   ret = __i915_wait_request(requests[i], true,
- args->timeout_ns > 0 ? 
>timeout_ns : NULL,
- to_rps_client(file));
+   ret = i915_wait_request(requests[i], true,
+   args->timeout_ns > 0 ? 
>timeout_ns : NULL,
+   to_rps_client(file));
i915_gem_request_put(requests[i]);
}
return ret;
@@ -2744,10 +2744,10 @@ __i915_gem_object_sync(struct drm_i915_gem_request *to,
return 0;
 
if (!i915.semaphores) {
-   ret = __i915_wait_request(from,
- from->i915->mm.interruptible,
- NULL,
- NO_WAITBOOST);
+   ret = i915_wait_request(from,
+   from->i915->mm.interruptible,
+   NULL,
+   NO_WAITBOOST);
if (ret)
return ret;
} else {
@@ -3712,7 +3712,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct 
drm_file *file)
if (target == NULL)
return 0;
 
-   ret = __i915_wait_request(target, true, NULL, NULL);
+   ret = i915_wait_request(target, true, NULL, NULL);
i915_gem_request_put(target);
 
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 85ec5ca5c36b..8549375aa75e 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -70,9 +70,9 @@ static signed long i915_fence_wait(struct fence *fence,
timeout = NULL;
}
 
-   ret = __i915_wait_request(to_request(fence),
- interruptible, timeout,
- NO_WAITBOOST);
+   ret = i915_wait_request(to_request(fence),
+   interruptible, timeout,
+   NO_WAITBOOST);
if (ret == -ETIME)
return 0;
 
@@ -579,7 +579,7 @@ bool __i915_spin_request(const struct drm_i915_gem_request 
*req,
 }
 
 /**
- * __i915_wait_request - wait until execution of request has finished
+ * i915_wait_request - wait until execution of request has finished
  * @req: duh!
  * @interruptible: do an interruptible wait (normally yes)
  * @timeout: in - how long to wait (NULL forever); out - how much time 
remaining
@@ -595,10 +595,10 @@ bool __i915_spin_request(const struct 
drm_i915_gem_request *req,
  * Returns 0 if the request was found within the alloted time. Else returns the
  * errno with remaining time filled in timeout argument.
  */
-int __i915_wait_request(struct drm_i915_gem_request *req,
-   bool interruptible,
-   s64 *timeout,
-   struct intel_rps_client *rps)
+int i915_wait_request(struct drm_i915_gem_request *req,
+ bool interruptible,
+ s64 *timeout,
+ struct intel_rps_client *rps)
 {
int state = interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
DEFINE_WAIT(reset);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 2d8d36976c41..4241d49a024c 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -214,10 +214,10 @@ struct intel_rps_client;
 #define IS_RPS_CLIENT(p) 

[Intel-gfx] [PATCH 67/73] drm/i915: Make fb_tracking.lock a spinlock

2016-08-01 Thread Chris Wilson
We only need a very lightweight mechanism here as the locking is only
used for co-ordinating a bitfield.

v2: Move the cheap unlikely tests into the caller

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtien 

Cc: Daniel Vetter 
[After some kerneldoc fixes, which I hope Daniel explains better,
Reviewed-by: Daniel Vetter ]
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_gem.c  |  2 +-
 drivers/gpu/drm/i915/intel_drv.h | 29 +++---
 drivers/gpu/drm/i915/intel_frontbuffer.c | 52 ++--
 4 files changed, 50 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ba99057c317..b26f5b1f466b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1669,7 +1669,7 @@ struct intel_pipe_crc {
 };
 
 struct i915_frontbuffer_tracking {
-   struct mutex lock;
+   spinlock_t lock;
 
/*
 * Tracking bits for delayed frontbuffer flushing du to gpu activity or
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 72935f5c6ed1..5d57258d96cd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4446,7 +4446,7 @@ i915_gem_load_init(struct drm_device *dev)
 
dev_priv->mm.interruptible = true;
 
-   mutex_init(_priv->fb_tracking.lock);
+   spin_lock_init(_priv->fb_tracking.lock);
 }
 
 void i915_gem_load_cleanup(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e74d851868c5..01056ce8d461 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1135,8 +1135,6 @@ void intel_ddi_set_vc_payload_alloc(struct drm_crtc 
*crtc, bool state);
 uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
 
 /* intel_frontbuffer.c */
-void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
-enum fb_op_origin origin);
 void intel_frontbuffer_flip_prepare(struct drm_device *dev,
unsigned frontbuffer_bits);
 void intel_frontbuffer_flip_complete(struct drm_device *dev,
@@ -1147,8 +1145,31 @@ unsigned int intel_fb_align_height(struct drm_device 
*dev,
   unsigned int height,
   uint32_t pixel_format,
   uint64_t fb_format_modifier);
-void intel_fb_obj_flush(struct drm_i915_gem_object *obj, bool retire,
-   enum fb_op_origin origin);
+
+void __intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
+  enum fb_op_origin origin);
+static inline void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
+  enum fb_op_origin origin)
+{
+   if (!obj->frontbuffer_bits)
+   return;
+
+   __intel_fb_obj_invalidate(obj, origin);
+}
+
+void __intel_fb_obj_flush(struct drm_i915_gem_object *obj,
+ bool retire,
+ enum fb_op_origin origin);
+static inline void intel_fb_obj_flush(struct drm_i915_gem_object *obj,
+ bool retire,
+ enum fb_op_origin origin)
+{
+   if (!obj->frontbuffer_bits)
+   return;
+
+   __intel_fb_obj_flush(obj, retire, origin);
+}
+
 u32 intel_fb_stride_alignment(const struct drm_i915_private *dev_priv,
  uint64_t fb_modifier, uint32_t pixel_format);
 
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index ac85357010b4..939d0e8cf63d 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -76,24 +76,19 @@
  * until the rendering completes or a flip on this frontbuffer plane is
  * scheduled.
  */
-void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
-enum fb_op_origin origin)
+void __intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
+  enum fb_op_origin origin)
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
WARN_ON(!mutex_is_locked(>struct_mutex));
 
-   if (!obj->frontbuffer_bits)
-   return;
-
if (origin == ORIGIN_CS) {
-   mutex_lock(_priv->fb_tracking.lock);
-   dev_priv->fb_tracking.busy_bits
-   |= obj->frontbuffer_bits;
-   dev_priv->fb_tracking.flip_bits
-   &= ~obj->frontbuffer_bits;
-   mutex_unlock(_priv->fb_tracking.lock);
+   spin_lock(_priv->fb_tracking.lock);
+   dev_priv->fb_tracking.busy_bits |= obj->frontbuffer_bits;
+   

[Intel-gfx] [PATCH 43/73] drm/i915: Move request list retirement to i915_gem_request.c

2016-08-01 Thread Chris Wilson
As the list retirement is now clean of implementation details, we can
move it closer to the request management.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 44 -
 drivers/gpu/drm/i915/i915_gem_request.c | 35 ++
 2 files changed, 35 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d320d3711fa5..ac89c4c2008a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2534,50 +2534,6 @@ void i915_gem_reset(struct drm_device *dev)
i915_gem_restore_fences(dev);
 }
 
-/**
- * This function clears the request list as sequence numbers are passed.
- * @engine: engine to retire requests on
- */
-void
-i915_gem_retire_requests_ring(struct intel_engine_cs *engine)
-{
-   while (!list_empty(>request_list)) {
-   struct drm_i915_gem_request *request;
-
-   request = list_first_entry(>request_list,
-  struct drm_i915_gem_request,
-  link);
-
-   if (!i915_gem_request_completed(request))
-   break;
-
-   i915_gem_request_retire_upto(request);
-   }
-}
-
-void i915_gem_retire_requests(struct drm_i915_private *dev_priv)
-{
-   struct intel_engine_cs *engine;
-
-   lockdep_assert_held(_priv->drm.struct_mutex);
-
-   if (dev_priv->gt.active_engines == 0)
-   return;
-
-   GEM_BUG_ON(!dev_priv->gt.awake);
-
-   for_each_engine(engine, dev_priv) {
-   i915_gem_retire_requests_ring(engine);
-   if (list_empty(>request_list))
-   dev_priv->gt.active_engines &= 
~intel_engine_flag(engine);
-   }
-
-   if (dev_priv->gt.active_engines == 0)
-   queue_delayed_work(dev_priv->wq,
-  _priv->gt.idle_work,
-  msecs_to_jiffies(100));
-}
-
 static void
 i915_gem_retire_work_handler(struct work_struct *work)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 8549375aa75e..6faa84832ade 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -731,3 +731,38 @@ complete:
 
return ret;
 }
+
+void i915_gem_retire_requests_ring(struct intel_engine_cs *engine)
+{
+   struct drm_i915_gem_request *request, *next;
+
+   list_for_each_entry_safe(request, next, >request_list, link) {
+   if (!i915_gem_request_completed(request))
+   break;
+
+   i915_gem_request_retire(request);
+   }
+}
+
+void i915_gem_retire_requests(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   lockdep_assert_held(_priv->drm.struct_mutex);
+
+   if (dev_priv->gt.active_engines == 0)
+   return;
+
+   GEM_BUG_ON(!dev_priv->gt.awake);
+
+   for_each_engine(engine, dev_priv) {
+   i915_gem_retire_requests_ring(engine);
+   if (list_empty(>request_list))
+   dev_priv->gt.active_engines &= 
~intel_engine_flag(engine);
+   }
+
+   if (dev_priv->gt.active_engines == 0)
+   queue_delayed_work(dev_priv->wq,
+  _priv->gt.idle_work,
+  msecs_to_jiffies(100));
+}
-- 
2.8.1

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


  1   2   >