Re: [Intel-gfx] linux-next: build warnings after merge of the drm-intel tree

[Zhenyu Wang]

On 2016.10.19 10:57:53 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
> 
> drivers/gpu/drm/i915/gvt/execlist.c: In function 
> 'release_shadow_batch_buffer':
> drivers/gpu/drm/i915/gvt/execlist.c:501:4: warning: 
> 'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
> drm_gem_object_unreference(&(entry_obj->obj->base));
> ^
> In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
> drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
>  extern void drm_gem_object_unreference(struct drm_gem_object *);
>  ^
> drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_shadow_wa_ctx':
> drivers/gpu/drm/i915/gvt/execlist.c:514:2: warning: 
> 'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
>   drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
>   ^
> In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
> drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
>  extern void drm_gem_object_unreference(struct drm_gem_object *);
>  ^
> 
> Introduced by commit
> 
>   be1da7070aea ("drm/i915/gvt: vGPU command scanner")
> 
> interacting with commit
> 
>   f8c417cdb1b8 ("drm/i915: Rename drm_gem_object_unreference in preparation 
> for lockless free")
> 
> from Linus' tree.
> 

Sorry for this, we will fix that in next pull request to replace old interface.

-- 
Open Source Technology Center, Intel ltd.

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


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

Re: [Intel-gfx] [PULL] GVT-g device model core

[Zhenyu Wang]

On 2016.10.18 14:59:14 +0300, Jani Nikula wrote:
> On Mon, 17 Oct 2016, Jani Nikula  wrote:
> > On Mon, 17 Oct 2016, Daniel Vetter  wrote:
> >> Ok applied, but a few things to keep in mind before your next pull
> >> request:
> >>
> >> - Dont rebase everything 5 seconds before sending out the pull request.
> >>   That just invalidates all the testing you've done, so not a good idea.
> >>   In general try to avoid rebases as much as possible, and only rebase to
> >>   take out a truly embarassing mistake. And then only rebase up to the
> >>   patch that needs a hotfix, not your entire tree.
> >
> > CONFIG_DRM_I915_GVT=y
> >
> > drivers/gpu/drm/i915/gvt/handlers.c: In function ‘render_mmio_to_ring_id’:
> > drivers/gpu/drm/i915/gvt/handlers.c:137:31: error: request for member 
> > ‘mmio_base’ in something not a structure or union
> >if (gvt->dev_priv->engine[i].mmio_base == reg)
> 
> This is now fixed, thanks, but there's still a load of sparse warnings
> coming from gvt. Please install sparse, and run e.g.
> 
> $ make
> $ rm drivers/gpu/drm/i915/gvt/*.o
> $ make C=1
> 
> Below is a list of current warnings.
> 

yeah, sorry that we ignored sparse step, will address that in next pull request 
too.

thanks.

-- 
Open Source Technology Center, Intel ltd.

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


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

[Intel-gfx] [PATCH] drm/i915/dp: Debug log MST active links explicitly

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

No functional change. Just printing the number of active links without
stating what the number means is not very useful. So, add relevant text.

Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Jim Bride 
---
No changes, sending with Jim's R-B

 drivers/gpu/drm/i915/intel_dp_mst.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..62a69b5 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -86,7 +86,7 @@ static void intel_mst_disable_dp(struct intel_encoder 
*encoder,
to_intel_connector(old_conn_state->connector);
int ret;
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
+   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
 
drm_dp_mst_reset_vcpi_slots(_dp->mst_mgr, connector->port);
 
@@ -106,7 +106,7 @@ static void intel_mst_post_disable_dp(struct intel_encoder 
*encoder,
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
+   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
 
/* this can fail */
drm_dp_check_act_status(_dp->mst_mgr);
@@ -147,7 +147,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
connector->encoder = encoder;
intel_mst->connector = connector;
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
+   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
 
if (intel_dp->active_mst_links == 0) {
intel_ddi_clk_select(_dig_port->base,
@@ -194,7 +194,7 @@ static void intel_mst_enable_dp(struct intel_encoder 
*encoder,
enum port port = intel_dig_port->port;
int ret;
 
-   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
+   DRM_DEBUG_KMS("active MST links: %d\n", intel_dp->active_mst_links);
 
if (intel_wait_for_register(dev_priv,
DP_TP_STATUS(port),
-- 
2.7.4

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

[Intel-gfx] [i-g-t PATCH v2] igt/tools: Update intel_watermark with SKL support

[Dhinakaran Pandiyan]

Added support to print SKL watermark and DDB registers.

v2: Printed raw register data, renamed planes and combined two printf()'s
(Ville)

Signed-off-by: Dhinakaran Pandiyan 
---
 tools/intel_watermark.c | 150 +++-
 1 file changed, 149 insertions(+), 1 deletion(-)

diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
index e9a2b05..81e394c 100644
--- a/tools/intel_watermark.c
+++ b/tools/intel_watermark.c
@@ -120,6 +120,11 @@ static const char *endis(bool enabled)
return enabled ? "enabled" : "disabled";
 }
 
+static const char endis_ast(bool enabled)
+{
+   return enabled ? '*' : ' ';
+}
+
 static int is_gen7_plus(uint32_t d)
 {
return !(IS_GEN5(d) || IS_GEN6(d));
@@ -130,6 +135,147 @@ static int is_hsw_plus(uint32_t d)
return !(IS_GEN5(d) || IS_GEN6(d) || IS_IVYBRIDGE(d));
 }
 
+
+static void skl_wm_dump(void)
+{
+   int pipe, plane, level;
+   int num_pipes = 3;
+   int num_planes = 5;
+   int num_levels = 8;
+   uint32_t base_addr = 0x7, addr, wm_offset;
+   uint32_t wm[num_levels][num_pipes][num_planes];
+   uint32_t wm_trans[num_pipes][num_planes];
+   uint32_t buf_cfg[num_pipes][num_planes];
+   char reg_name[20];
+
+   intel_register_access_init(intel_get_pci_device(), 0);
+
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   for (plane = 0; plane < num_planes; plane++) {
+   addr =  base_addr +  pipe * 0x1000 + plane * 0x100;
+
+   wm_trans[pipe][plane] = read_reg(addr + 0x00168);
+   buf_cfg[pipe][plane] = read_reg(addr + 0x0017C);
+   for (level = 0; level < num_levels; level++) {
+   wm_offset = addr + 0x00140 + level * 0x4;
+   wm[level][pipe][plane] = read_reg(wm_offset);
+   }
+   }
+   }
+
+   for (plane = 0; plane < num_planes; plane++) {
+   for (level = 0; level < num_levels; level++) {
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   if (plane == 0)
+   snprintf(reg_name, sizeof(reg_name), 
"%s_WM_%c_%1d","CUR",
+pipe_name(pipe), level);
+   else
+   snprintf(reg_name, sizeof(reg_name), 
"%s_WM_%1d_%c_%1d","PLANE",
+plane, pipe_name(pipe), level);
+
+   printf("%-19s %8x\t\t" , reg_name, 
wm[level][pipe][plane]);
+   }
+   printf("\n");
+   }
+   printf("\n");
+   }
+
+   for (plane = 0; plane < num_planes; plane++) {
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   if (plane == 0)
+   snprintf(reg_name, sizeof(reg_name), 
"%s_WM_TRANS_%c", "CUR",
+pipe_name(pipe));
+   else
+   snprintf(reg_name, sizeof(reg_name), 
"%s_WM_TRANS_%1d_%c", "PLANE",
+plane, pipe_name(pipe));
+
+   printf("%-19s %8x\t\t", reg_name, 
wm_trans[pipe][plane]);
+
+   }
+   printf("\n");
+   }
+   printf("\n");
+
+   for (plane = 0; plane < num_planes; plane++) {
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   if (plane == 0)
+   snprintf(reg_name, sizeof(reg_name), 
"%s_BUF_CFG_%c", "CUR",
+pipe_name(pipe));
+   else
+   snprintf(reg_name, sizeof(reg_name), 
"%s_BUF_CFG_%1d_%c", "PLANE",
+plane, pipe_name(pipe));
+
+   printf("%-19s %8x\t\t", reg_name, 
buf_cfg[pipe][plane]);
+   }
+   printf("\n");
+   }
+   printf("\n");
+
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   uint32_t start, end, size;
+   uint32_t lines, blocks, enable;
+
+   printf("PIPE_%c\n", pipe_name(pipe));
+   printf("LEVEL   CURSOR   PLANE_1   PLANE_2   PLANE_3   
PLANE_4\n");
+   for (level = 0; level < num_levels; level++) {
+   printf("%5d  ", level);
+   for (plane = 0; plane < num_planes; plane++) {
+   blocks = REG_DECODE1(wm[level][pipe][plane], 0, 
9);
+   lines = REG_DECODE1(wm[level][pipe][plane], 14, 
5);
+   enable = REG_DECODE1(wm[level][pipe][plane], 
31, 

[Intel-gfx] linux-next: build warnings after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_shadow_batch_buffer':
drivers/gpu/drm/i915/gvt/execlist.c:501:4: warning: 
'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
drm_gem_object_unreference(&(entry_obj->obj->base));
^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_shadow_wa_ctx':
drivers/gpu/drm/i915/gvt/execlist.c:514:2: warning: 
'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
  drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
  ^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^

Introduced by commit

  be1da7070aea ("drm/i915/gvt: vGPU command scanner")

interacting with commit

  f8c417cdb1b8 ("drm/i915: Rename drm_gem_object_unreference in preparation for 
lockless free")

from Linus' tree.

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

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

[Matthew Auld]

On 14 October 2016 at 14:27, Chris Wilson  wrote:
> After printing our welcome message to the user, also include
> supplementary details on what debugging is enabled (useful for us to
> sanity check what extra safeguards are on for any random kernel).
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

[Manasi Navare]

On Tue, Oct 18, 2016 at 08:57:36AM -0700, Rodrigo Vivi wrote:
> According to spec: "KBL re-uses SKL values, except where
> specific KBL values are listed."
> 
> And recently spec has changed adding different table for Display Port only.
> But for all SKUs (H,S,U,Y) we have slightly different values.
> 
> v2: Fix wrong condition spotted by Jani.
> v3: Fix 7th entry of KBL H and S table - by Manasi.
> 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
Reviewed-by: Manasi Navare 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 88 
> +++-
>  1 file changed, 78 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0def25d..6f793e5 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -167,8 +167,47 @@ struct ddi_buf_trans {
>   { 0x80005012, 0x00C0, 0x3 },
>  };
>  
> +/* Kabylake H and S */
> +static const struct ddi_buf_trans kbl_ddi_translations_dp[] = {
> + { 0x2016, 0x00A0, 0x0 },
> + { 0x5012, 0x009B, 0x0 },
> + { 0x7011, 0x0088, 0x0 },
> + { 0x80009010, 0x00C0, 0x1 },
> + { 0x2016, 0x009B, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00C0, 0x1 },
> + { 0x2016, 0x0097, 0x0 },
> + { 0x80005012, 0x00C0, 0x1 },
> +};
> +
> +/* Kabylake U */
> +static const struct ddi_buf_trans kbl_u_ddi_translations_dp[] = {
> + { 0x201B, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x80009010, 0x00C0, 0x3 },
> + { 0x201B, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x2016, 0x004F, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
> +/* Kabylake Y */
> +static const struct ddi_buf_trans kbl_y_ddi_translations_dp[] = {
> + { 0x1017, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x8000800F, 0x00C0, 0x3 },
> + { 0x1017, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x1017, 0x004C, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
>  /*
> - * Skylake H and S
> + * Skylake/Kabylake H and S
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
> @@ -185,7 +224,7 @@ struct ddi_buf_trans {
>  };
>  
>  /*
> - * Skylake U
> + * Skylake/Kabylake U
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_u_ddi_translations_edp[] = {
> @@ -202,7 +241,7 @@ struct ddi_buf_trans {
>  };
>  
>  /*
> - * Skylake Y
> + * Skylake/Kabylake Y
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
> @@ -218,7 +257,7 @@ struct ddi_buf_trans {
>   { 0x0018, 0x008A, 0x0 },
>  };
>  
> -/* Skylake U, H and S */
> +/* Skylake/Kabylake U, H and S */
>  static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00AC, 0x0 },
>   { 0x5012, 0x009D, 0x0 },
> @@ -233,7 +272,7 @@ struct ddi_buf_trans {
>   { 0x8018, 0x00C0, 0x1 },
>  };
>  
> -/* Skylake Y */
> +/* Skylake/Kabylake Y */
>  static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00A1, 0x0 },
>   { 0x5012, 0x00DF, 0x0 },
> @@ -334,10 +373,10 @@ enum port intel_ddi_get_encoder_port(struct 
> intel_encoder *encoder)
>  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)) {
> + if (IS_SKL_ULX(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
>   return skl_y_ddi_translations_dp;
> - } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv)) {
> + } else if (IS_SKL_ULT(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
>   return skl_u_ddi_translations_dp;
>   } else {
> @@ -347,6 +386,21 @@ enum port intel_ddi_get_encoder_port(struct 
> intel_encoder *encoder)
>  }
>  
>  static const struct ddi_buf_trans *
> +kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> +{
> + if (IS_KBL_ULX(dev_priv)) {
> + *n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
> + return kbl_y_ddi_translations_dp;
> + } else if (IS_KBL_ULT(dev_priv)) {
> + *n_entries = ARRAY_SIZE(kbl_u_ddi_translations_dp);
> + return kbl_u_ddi_translations_dp;
> + } else {
> + *n_entries = ARRAY_SIZE(kbl_ddi_translations_dp);
> +  

[Intel-gfx] [PATCH] dim: autodetect branches in rebuild-nightly

[Daniel Vetter]

Needs new url-mapping information in nightly.conf to work properly.

v2:
- Fix typo when calling rr_cache_dir. Oops.
- Use cut -f 1 instead of sed/regex horrors (jani).

Signed-off-by: Daniel Vetter 
---
 dim | 50 +-
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/dim b/dim
index 48d5e7b6477a..09879b166cee 100755
--- a/dim
+++ b/dim
@@ -197,7 +197,7 @@ function get_remote_name
local remote_url=$1
 
local remote=`git remote -v | grep $remote_url | \
-   head -n1 | sed -e 's/^\(.*\)\t.*/\1/'`
+   head -n1 | cut -f 1`
 
if [[ $remote == "" ]] ; then
echoerr No git remote for $remote_url found in `pwd`.
@@ -235,20 +235,30 @@ function dim_commit_add_tag
done
 }
 
+function map_nightly_remote
+{
+   local nightly_remote=$1
+   local remote_url=`eval echo 
"\\\$nightly_remote_url_${nightly_remote/-/_}"`
+
+   get_remote_name $remote_url
+}
+
 function update_linux_next
 {
cd $DIM_PREFIX/drm-intel-nightly
 
+   local nightly_origin=`map_nightly_remote origin`
+
# always update drm-intel-fixes
echo -n "Pushing drm-intel-fixes to for-linux-next-fixes... "
-   git push $DRY_RUN origin +origin/drm-intel-fixes:for-linux-next-fixes 
>& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-fixes:for-linux-next-fixes >& /dev/null
echo "Done."
 
-   if git merge-base --is-ancestor origin/drm-intel-next-fixes 
origin/drm-intel-fixes ; then
+   if git merge-base --is-ancestor $nightly_origin/drm-intel-next-fixes 
$nightly_origin/drm-intel-fixes ; then
# -fixes has caught up to dinf, i.e. we're out of the merge
# window. Push the next queue.
echo -n "Out of merge window. Pushing drm-intel-next-queued to 
for-linux-next... "
-   git push $DRY_RUN origin 
+origin/drm-intel-next-queued:for-linux-next >& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-next-queued:for-linux-next >& /dev/null
echo "Done."
else
# dinf is ahead of -fixes, i.e. drm-next has already closed for
@@ -256,7 +266,7 @@ function update_linux_next
# for the current -next cycle. Push dinf
 
echo -n "Pushing drm-intel-next-fixes to for-linux-next... "
-   git push $DRY_RUN origin 
+origin/drm-intel-next-fixes:for-linux-next >& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-next-fixes:for-linux-next >& /dev/null
echo "Done."
fi
 }
@@ -272,11 +282,20 @@ function check_conflicts
true
 }
 
+function rr_cache_dir
+{
+   if [ -d $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ ] ; then
+   echo $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/
+   else
+   echo $DIM_PREFIX/$DIM_DRM_INTEL/.git/rr-cache/
+   fi
+}
+
 function update_rerere_cache
 {
cd $DIM_PREFIX/drm-intel-rerere/
git pull
-   cp rr-cache/* $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ -r
+   cp rr-cache/* `rr_cache_dir` -r
cd -
 }
 
@@ -307,9 +326,10 @@ function dim_rebuild_nightly
fi
 
for remote in $(echo $nightly_branches | tr " " "\n" | sed 's|/.*$||g' 
| sort -u); do
-   echo -n "Fetching $remote... "
+   local nightly_remote=`map_nightly_remote $remote`
+   echo -n "Fetching $remote (as $nightly_remote) ... "
# git fetch returns 128 if there's nothing to be fetched
-   git fetch $remote >& /dev/null || true
+   git fetch $nightly_remote >& /dev/null || true
echo "Done."
done
 
@@ -329,12 +349,14 @@ function dim_rebuild_nightly
if [[ -n $sha1 ]] ; then
echo -n "Using override sha1: $sha1... "
else
-   sha1=$branch
+   local remote=${branch%%/*}
+   local nightly_remote=`map_nightly_remote $remote`
+   sha1=`echo $branch | sed -e s/^$remote/$nightly_remote/`
fi
 
if [ $first == 1 ] ; then
+   git reset --hard $sha1 &> /dev/null
echo "Reset. Done."
-   git reset --hard $sha1 >& /dev/null
first=0
elif git merge --rerere-autoupdate --ff-only $sha1 >& /dev/null 
; then
# nothing to do if just fast-forward
@@ -370,14 +392,16 @@ function dim_rebuild_nightly
git commit --quiet -m "$integration_branch: $time integration manifest"
echo "Done."
 
+   local nightly_origin=`map_nightly_remote origin`
+
echo -n "Pushing $integration_branch... "
-   git push $DRY_RUN origin +HEAD >& /dev/null && echo "Done."
+   git 

Re: [Intel-gfx] [PATCH 07/10] dim: autodetect branches in rebuild-nightly

[Daniel Vetter]

On Tue, Oct 18, 2016 at 3:52 PM, Jani Nikula
 wrote:
> On Tue, 18 Oct 2016, Daniel Vetter  wrote:
>> Needs new url-mapping information in nightly.conf to work properly.
>
> I think in the long run the right fix would be to make nightly.conf
> independent of remote names. Not sure if that's worth the trouble at
> this point.

It is with this. The remote names in nightly.conf are now entirely
fiction. The magic here takes those, then looks up the corresponding
url (againg from nigthly.conf) and then uses get_remote_name to figure
out the appropriate git remote in the local repo. Or complain and quit
if it doesn't exist. My drm-tip now has an "origin" remote pointing at
Linus' repo, while the "origin" from nightly.conf gets remapped to
"drm-tip". Sample output from running rebuild-nightly:

Updating rerere cache and nightly.conf... Done.
Fetching drm-intel (as danvet) ... Done.
Fetching drm-upstream (as airlied) ... Done.
Fetching sound-upstream (as takashi) ... Done.
Merging drm-intel/drm-intel-fixes... Reset. Done.
Merging drm-upstream/drm-fixes... Fast-forward. Done.
Merging drm-intel/drm-intel-next-fixes... Fast-forward. Done.
...

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/10] dim: Nuke nightly-forget

[Daniel Vetter]

On Tue, Oct 18, 2016 at 3:39 PM, Jani Nikula
 wrote:
> On Tue, 18 Oct 2016, Daniel Vetter  wrote:
>> With our proliferation of branches it's become long useless. Nowadays
>> my MO is to revert the offending commit in the rerere-cache branch
>> explicitly, remove drm-intel-nightly/.git/rr-cache and then re-run
>> rebuild-nightly. That works much better, hence nuke this helper.
>
> Agreed.
>
> Later, we should add a helper to do the better MO.

dim revert-rerere  sounds like a sweet thing. Let
me type that up and write some docs for it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/10] dim: support git worktree for aux checkouts

[Daniel Vetter]

On Tue, Oct 18, 2016 at 3:38 PM, Jani Nikula
 wrote:
>> + if git help worktree &> /dev/null ; then
>> + cd $DIM_PREFIX/$DIM_DRM_INTEL
>> + remote=`get_remote_name $remote_url`
>> + if ! git branch | grep $name > /dev/null ; then
>
> The failure modes are annoying if there's a substring match for
> $name. Unfortunately grep -w is no good if you need to handle "-" too.

Hm, right. I copypasted this all over, but with drm-intel-* we have a
few clashes. Played around, and the following does exact matches and
gets the job done:

if [[ `git branch --list $name` != "" ]]

I'll roll this out in a follow up patch everywhere.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/41] drm/i915: Rearrange i915_wait_request() accounting with callers

[Matthew Auld]

>   * 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,
> - unsigned int flags,
> - s64 *timeout,
> - struct intel_rps_client *rps)
> +long i915_wait_request(struct drm_i915_gem_request *req,
> +  unsigned int flags,
> +  long timeout)
>  {
A good time to update the kernel doc here?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Paulo Zanoni]

Em Sex, 2016-10-14 às 17:31 -0400, Lyude escreveu:
> There's not much of a reason this should have the locations to read
> out
> the hardware state hardcoded, so allow the caller to specify the
> location and add this function to intel_drv.h. As well, we're going
> to
> need this function to be reusable for the next patch.
> 
> Changes since v1:
> - Fix accidental behavior change in the code that Paulo pointed out

Reviewed-by: Paulo Zanoni 

I just submitted v4 of patch 5 solving the conflicts I created. With
that + this review, we can merge this series. If you give me an ack on
patch 5 I can just go and merge these, so we can move to Maarten's
series and then later to Mahesh's series.

> 
> Signed-off-by: Lyude 
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Cc: Matt Roper  Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 28 ++--
>  2 files changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index a85ce2c..7036310 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1756,6 +1756,8 @@ void ilk_wm_get_hw_state(struct drm_device
> *dev);
>  void skl_wm_get_hw_state(struct drm_device *dev);
>  void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
>     struct skl_ddb_allocation *ddb /* out */);
> +void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
> +   struct skl_pipe_wm *out);
>  bool intel_can_enable_sagv(struct drm_atomic_state *state);
>  int intel_enable_sagv(struct drm_i915_private *dev_priv);
>  int intel_disable_sagv(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 2fe851e..6eaeb87 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4288,15 +4288,13 @@ static inline void
> skl_wm_level_from_reg_val(uint32_t val,
>   PLANE_WM_LINES_MASK;
>  }
>  
> -static void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc)
> +void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
> +   struct skl_pipe_wm *out)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct skl_wm_values *hw = _priv->wm.skl_hw;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - struct intel_crtc_state *cstate = to_intel_crtc_state(crtc-
> >state);
>   struct intel_plane *intel_plane;
> - struct skl_pipe_wm *active = >wm.skl.optimal;
>   struct skl_plane_wm *wm;
>   enum pipe pipe = intel_crtc->pipe;
>   int level, id, max_level;
> @@ -4306,7 +4304,7 @@ static void skl_pipe_wm_get_hw_state(struct
> drm_crtc *crtc)
>  
>   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
>   id = skl_wm_plane_id(intel_plane);
> - wm = >wm.skl.optimal.planes[id];
> + wm = >planes[id];
>  
>   for (level = 0; level <= max_level; level++) {
>   if (id != PLANE_CURSOR)
> @@ -4328,20 +4326,30 @@ static void skl_pipe_wm_get_hw_state(struct
> drm_crtc *crtc)
>   if (!intel_crtc->active)
>   return;
>  
> - hw->dirty_pipes |= drm_crtc_mask(crtc);
> - active->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
> - intel_crtc->wm.active.skl = *active;
> + out->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
>  }
>  
>  void skl_wm_get_hw_state(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> + struct skl_wm_values *hw = _priv->wm.skl_hw;
>   struct skl_ddb_allocation *ddb = _priv->wm.skl_hw.ddb;
>   struct drm_crtc *crtc;
> + struct intel_crtc *intel_crtc;
> + struct intel_crtc_state *cstate;
>  
>   skl_ddb_get_hw_state(dev_priv, ddb);
> - list_for_each_entry(crtc, >mode_config.crtc_list, head)
> - skl_pipe_wm_get_hw_state(crtc);
> + list_for_each_entry(crtc, >mode_config.crtc_list, head)
> {
> + intel_crtc = to_intel_crtc(crtc);
> + cstate = to_intel_crtc_state(crtc->state);
> +
> + skl_pipe_wm_get_hw_state(crtc, 
> >wm.skl.optimal);
> +
> + if (intel_crtc->active) {
> + hw->dirty_pipes |= drm_crtc_mask(crtc);
> + intel_crtc->wm.active.skl = cstate-
> >wm.skl.optimal;
> + }
> + }
>  
>   if (dev_priv->active_crtcs) {
>   /* Fully recompute DDB on first atomic commit */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Paulo Zanoni]

From: "cp...@redhat.com" 

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

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

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


I just merged my fixes, and that caused conflicts on the part of this patch that
touches intel_can_enable_sagv(). So I decided to just resolve the conflicts
since I created them.


diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 33c44c6..456bab9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1648,8 +1648,6 @@ struct skl_ddb_allocation {
 struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
-   uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
-   uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
 };
 
 struct skl_wm_level {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9395878..0e18cf47 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3385,6 +3385,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
const struct skl_wm_values *wm = _priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   _state->wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
@@ -3421,7 +3423,7 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_y = src_y;
 
if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
-   skl_write_plane_wm(intel_crtc, wm, 0);
+   skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
@@ -3455,6 +3457,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
+   const struct skl_plane_wm *p_wm = >wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
 
/*
@@ -3462,7 +3466,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
 * plane's visiblity isn't actually changing neither is its watermarks.
 */
if (!crtc->primary->state->visible)
-   skl_write_plane_wm(intel_crtc, _priv->wm.skl_results, 0);
+   skl_write_plane_wm(intel_crtc, p_wm,
+  _priv->wm.skl_results.ddb, 0);
 
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
@@ -10833,12 +10838,15 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
const struct skl_wm_values *wm = _priv->wm.skl_results;
+   const struct skl_plane_wm *p_wm =
+   >wm.skl.optimal.planes[PLANE_CURSOR];
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
 
if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & drm_crtc_mask(crtc))
-   

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Bump object bookkeeping to u64 from size_t

[Saarinen, Jani]

> On Tue, Oct 18, 2016 at 01:05:24PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [CI,1/4] drm/i915: Bump object bookkeeping to
> u64 from size_t
> > URL   : https://patchwork.freedesktop.org/series/13950/
> > State : failure
> >
> > == Summary ==
> >
> > Series 13950v1 Series without cover letter
> > https://patchwork.freedesktop.org/api/1.0/series/13950/revisions/1/mbo
> > x/
> >
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > pass   -> INCOMPLETE (fi-snb-2600)
> > dmesg-warn -> INCOMPLETE (fi-skl-6700hq)
> 
> New sporadic failures not observed on the prior trybot pass.
> Challenge for CI to gather some logs.
Or is this actually just still not covered from all rc1 breakages?

> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre


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


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

Re: [Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios in DRM layer

[Jim Bride]

On Mon, Oct 17, 2016 at 08:02:49AM +0200, Daniel Vetter wrote:
> On Thu, Oct 13, 2016 at 10:28:14AM -0700, Jim Bride wrote:
> > On Tue, Aug 09, 2016 at 08:25:50PM +0530, Shashank Sharma wrote:
> > > HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> > > - 64:27
> > > - 256:135
> > > 
> > > This patch:
> > > -  Adds new DRM flags for to represent these new aspect ratios.
> > > -  Adds new cases to handle these aspect ratios while converting
> > > from user->kernel mode or vise versa.
> > > 
> > > V2: Rebase
> > > 
> > > Signed-off-by: Shashank Sharma 
> > > Reviewed-by: Sean Paul 
> > > Cc: Daniel Vetter 
> > > Cc: Emil Velikov 
> > > ---
> > >  drivers/gpu/drm/drm_modes.c | 12 
> > >  include/uapi/drm/drm_mode.h |  6 ++
> > >  2 files changed, 18 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > index 9d8f00d..ed1b07b 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1481,6 +1481,12 @@ void drm_mode_convert_to_umode(struct 
> > > drm_mode_modeinfo *out,
> > >   case HDMI_PICTURE_ASPECT_16_9:
> > >   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> > >   break;
> > > + case HDMI_PICTURE_ASPECT_64_27:
> > > + out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> > > + break;
> > > + case DRM_MODE_PICTURE_ASPECT_256_135:
> > > + out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> > > + break;
> > >   case HDMI_PICTURE_ASPECT_RESERVED:
> > >   default:
> > >   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> > > @@ -1542,6 +1548,12 @@ int drm_mode_convert_umode(struct drm_display_mode 
> > > *out,
> > >   case DRM_MODE_FLAG_PIC_AR_16_9:
> > >   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> > >   break;
> > > + case DRM_MODE_FLAG_PIC_AR_64_27:
> > > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> > > + break;
> > > + case DRM_MODE_FLAG_PIC_AR_256_135:
> > > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> > > + break;
> > >   default:
> > >   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> > >   break;
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index 77c869d6..4d3429b 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -81,6 +81,8 @@ extern "C" {
> > >  #define DRM_MODE_PICTURE_ASPECT_NONE 0
> > >  #define DRM_MODE_PICTURE_ASPECT_4_3  1
> > >  #define DRM_MODE_PICTURE_ASPECT_16_9 2
> > > +#define DRM_MODE_PICTURE_ASPECT_64_273
> > > +#define DRM_MODE_PICTURE_ASPECT_256_135  4
> > 
> > Minor nit here, but in my tree the '4' above doesn't line up
> > with the three previous definitions.  I downloaded the series as
> > a mbox from patchwork.
> 
> r-b with that bikeshed addressed or not? Also any reason you didn't r-b
> patch 3?

I'm happy with both 3 and 4, so sure.  They both had r-b already by Sean
so I didn't bother tacking my own r-b on there.

Jim


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

Re: [Intel-gfx] IGT contributions and reviews

[Jani Nikula]

On Tue, 18 Oct 2016, Petri Latvala  wrote:
> The current contributing docs for IGT state:
>
> <<
>   There is no formal review requirement and regular contributors with
>   commit access can push patches right after submitting them to the
>   mailing lists. But invasive changes, new helper libraries and
>   contributions from newcomers should go through a proper review to
>   ensure overall consistency in the codebase.
>>>
>
>
> While not requiring reviews or acks has definitely increased the
> speed of development, I feel the time for slowing down a bit has
> come.

Agreed. (Though a more rigorous review requirement doesn't necessarily
slow things down in the big picture.)

> At the very least I would like to see all commits have a visit to the
> mailing list before pushing, as the current docs already ask for. The
> "right after" part would be changed to a $period of quarantine, maybe
> 24 hours?

Sounds good to me.

> As for requiring reviews or acks before pushing, how do the developers
> at large feel about that? Different rules for different parts of IGT?
> (Benchmarks, tools, tests, CI test sets, lib)

I think there are two big buckets here:

* Tests in BAT and the BAT set list. I think we need r-b/ack on the
  mailing list on these changes before pushing. (In the long run, I'd
  like to have these go through a CI run with everything else unchanged
  too.)

* Everything else. Other tests and tools. I'd be happy with requiring
  the patches are sent to the list, and either receiving r-b/ack or 24
  hrs during weekdays without negative feedback.

> The goal with this discussion is to reach a suitable tradeoff between
> stability from CI point of view and fruitful use of programmer time.

Thanks for starting the discussion.

BR,
Jani.


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

[Intel-gfx] [PATCH v2] mm/vmalloc: Replace opencoded 4-level page walkers

[Chris Wilson]

Rather than open-code the intricacies of walking the 4-level page
tables, use the generic page table walker apply_to_page_range() instead.

The important change is that it now cleans up after an
unsuccessful insertion and propagates the correct error. The current
failure may lead to a WARN if we encounter ENOMEM in one
vmap_pte_range() and later retry with the same page range.

WARNING: CPU: 0 PID: 605 at mm/vmalloc.c:136 vmap_page_range_noflush+0x2c1/0x340
i.e. WARN_ON(!pte_none(*pte))

v2: Don't convert the vunmap code over to apply_to_page_range() as it
may try to allocate during atomic sections, such as exiting a task:

[9.837563]  [] pte_alloc_one_kernel+0x10/0x20
[9.837568]  [] __pte_alloc_kernel+0x16/0xa0
[9.837572]  [] apply_to_page_range+0x3f6/0x460
[9.837576]  [] free_unmap_vmap_area_noflush+0x28/0x40
[9.837579]  [] remove_vm_area+0x4d/0x60
[9.837582]  [] __vunmap+0x29/0x130
[9.837585]  [] vfree+0x3d/0x90
[9.837589]  [] put_task_stack+0x76/0x130

References: https://bugs.freedesktop.org/show_bug.cgi?id=98269
Signed-off-by: Chris Wilson 
Cc: Andrew Morton 
Cc: David Rientjes 
Cc: Vladimir Davydov 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Wang Xiaoqiang 
Cc: Jerome Marchand 
Cc: Joonsoo Kim 
Cc: linux...@kvack.org
---
 mm/vmalloc.c | 93 ++--
 1 file changed, 27 insertions(+), 66 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index f2481cb4e6b2..7e945c63c7ef 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -117,63 +117,27 @@ static void vunmap_page_range(unsigned long addr, 
unsigned long end)
} while (pgd++, addr = next, addr != end);
 }
 
-static int vmap_pte_range(pmd_t *pmd, unsigned long addr,
-   unsigned long end, pgprot_t prot, struct page **pages, int *nr)
-{
-   pte_t *pte;
-
-   /*
-* nr is a running index into the array which helps higher level
-* callers keep track of where we're up to.
-*/
-
-   pte = pte_alloc_kernel(pmd, addr);
-   if (!pte)
-   return -ENOMEM;
-   do {
-   struct page *page = pages[*nr];
-
-   if (WARN_ON(!pte_none(*pte)))
-   return -EBUSY;
-   if (WARN_ON(!page))
-   return -ENOMEM;
-   set_pte_at(_mm, addr, pte, mk_pte(page, prot));
-   (*nr)++;
-   } while (pte++, addr += PAGE_SIZE, addr != end);
-   return 0;
-}
+struct vmap_page {
+   pgprot_t prot;
+   struct page **pages;
+   unsigned long count;
+};
 
-static int vmap_pmd_range(pud_t *pud, unsigned long addr,
-   unsigned long end, pgprot_t prot, struct page **pages, int *nr)
+static int vmap_page(pte_t *pte, pgtable_t token,
+unsigned long addr, void *data)
 {
-   pmd_t *pmd;
-   unsigned long next;
-
-   pmd = pmd_alloc(_mm, pud, addr);
-   if (!pmd)
-   return -ENOMEM;
-   do {
-   next = pmd_addr_end(addr, end);
-   if (vmap_pte_range(pmd, addr, next, prot, pages, nr))
-   return -ENOMEM;
-   } while (pmd++, addr = next, addr != end);
-   return 0;
-}
+   struct vmap_page *v = data;
+   struct page *page;
 
-static int vmap_pud_range(pgd_t *pgd, unsigned long addr,
-   unsigned long end, pgprot_t prot, struct page **pages, int *nr)
-{
-   pud_t *pud;
-   unsigned long next;
+   if (WARN_ON(!pte_none(*pte)))
+   return -EBUSY;
 
-   pud = pud_alloc(_mm, pgd, addr);
-   if (!pud)
+   page = v->pages[v->count];
+   if (WARN_ON(!page))
return -ENOMEM;
-   do {
-   next = pud_addr_end(addr, end);
-   if (vmap_pmd_range(pud, addr, next, prot, pages, nr))
-   return -ENOMEM;
-   } while (pud++, addr = next, addr != end);
+
+   set_pte_at(_mm, addr, pte, mk_pte(page, v->prot));
+   v->count++;
return 0;
 }
 
@@ -186,22 +150,19 @@ static int vmap_pud_range(pgd_t *pgd, unsigned long addr,
 static int vmap_page_range_noflush(unsigned long start, unsigned long end,
   pgprot_t prot, struct page **pages)
 {
-   pgd_t *pgd;
-   unsigned long next;
-   unsigned long addr = start;
-   int err = 0;
-   int nr = 0;
+   struct vmap_page v = { prot, pages };
+   int err;
 
-   BUG_ON(addr >= end);
-   pgd = pgd_offset_k(addr);
-   do {
-   next = pgd_addr_end(addr, end);
-   err = vmap_pud_range(pgd, addr, next, prot, pages, );
-   if (err)
-   return err;
-   } while (pgd++, addr = next, addr != end);
+   if ((end - start) >> PAGE_SHIFT > 

[Intel-gfx] [PATCH] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

[Rodrigo Vivi]

According to spec: "KBL re-uses SKL values, except where
specific KBL values are listed."

And recently spec has changed adding different table for Display Port only.
But for all SKUs (H,S,U,Y) we have slightly different values.

v2: Fix wrong condition spotted by Jani.
v3: Fix 7th entry of KBL H and S table - by Manasi.

Cc: Jani Nikula 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 88 +++-
 1 file changed, 78 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0def25d..6f793e5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -167,8 +167,47 @@ struct ddi_buf_trans {
{ 0x80005012, 0x00C0, 0x3 },
 };
 
+/* Kabylake H and S */
+static const struct ddi_buf_trans kbl_ddi_translations_dp[] = {
+   { 0x2016, 0x00A0, 0x0 },
+   { 0x5012, 0x009B, 0x0 },
+   { 0x7011, 0x0088, 0x0 },
+   { 0x80009010, 0x00C0, 0x1 },
+   { 0x2016, 0x009B, 0x0 },
+   { 0x5012, 0x0088, 0x0 },
+   { 0x80007011, 0x00C0, 0x1 },
+   { 0x2016, 0x0097, 0x0 },
+   { 0x80005012, 0x00C0, 0x1 },
+};
+
+/* Kabylake U */
+static const struct ddi_buf_trans kbl_u_ddi_translations_dp[] = {
+   { 0x201B, 0x00A1, 0x0 },
+   { 0x5012, 0x0088, 0x0 },
+   { 0x80007011, 0x00CD, 0x3 },
+   { 0x80009010, 0x00C0, 0x3 },
+   { 0x201B, 0x009D, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+   { 0x80007011, 0x00C0, 0x3 },
+   { 0x2016, 0x004F, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+};
+
+/* Kabylake Y */
+static const struct ddi_buf_trans kbl_y_ddi_translations_dp[] = {
+   { 0x1017, 0x00A1, 0x0 },
+   { 0x5012, 0x0088, 0x0 },
+   { 0x80007011, 0x00CD, 0x3 },
+   { 0x8000800F, 0x00C0, 0x3 },
+   { 0x1017, 0x009D, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+   { 0x80007011, 0x00C0, 0x3 },
+   { 0x1017, 0x004C, 0x0 },
+   { 0x80005012, 0x00C0, 0x3 },
+};
+
 /*
- * Skylake H and S
+ * Skylake/Kabylake H and S
  * eDP 1.4 low vswing translation parameters
  */
 static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
@@ -185,7 +224,7 @@ struct ddi_buf_trans {
 };
 
 /*
- * Skylake U
+ * Skylake/Kabylake U
  * eDP 1.4 low vswing translation parameters
  */
 static const struct ddi_buf_trans skl_u_ddi_translations_edp[] = {
@@ -202,7 +241,7 @@ struct ddi_buf_trans {
 };
 
 /*
- * Skylake Y
+ * Skylake/Kabylake Y
  * eDP 1.4 low vswing translation parameters
  */
 static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
@@ -218,7 +257,7 @@ struct ddi_buf_trans {
{ 0x0018, 0x008A, 0x0 },
 };
 
-/* Skylake U, H and S */
+/* Skylake/Kabylake U, H and S */
 static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
{ 0x0018, 0x00AC, 0x0 },
{ 0x5012, 0x009D, 0x0 },
@@ -233,7 +272,7 @@ struct ddi_buf_trans {
{ 0x8018, 0x00C0, 0x1 },
 };
 
-/* Skylake Y */
+/* Skylake/Kabylake Y */
 static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
{ 0x0018, 0x00A1, 0x0 },
{ 0x5012, 0x00DF, 0x0 },
@@ -334,10 +373,10 @@ enum port intel_ddi_get_encoder_port(struct intel_encoder 
*encoder)
 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)) {
+   if (IS_SKL_ULX(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
return skl_y_ddi_translations_dp;
-   } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv)) {
+   } else if (IS_SKL_ULT(dev_priv)) {
*n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
return skl_u_ddi_translations_dp;
} else {
@@ -347,6 +386,21 @@ enum port intel_ddi_get_encoder_port(struct intel_encoder 
*encoder)
 }
 
 static const struct ddi_buf_trans *
+kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
+{
+   if (IS_KBL_ULX(dev_priv)) {
+   *n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
+   return kbl_y_ddi_translations_dp;
+   } else if (IS_KBL_ULT(dev_priv)) {
+   *n_entries = ARRAY_SIZE(kbl_u_ddi_translations_dp);
+   return kbl_u_ddi_translations_dp;
+   } else {
+   *n_entries = ARRAY_SIZE(kbl_ddi_translations_dp);
+   return kbl_ddi_translations_dp;
+   }
+}
+
+static const struct ddi_buf_trans *
 skl_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
 {
if (dev_priv->vbt.edp.low_vswing) {
@@ -362,7 +416,10 @@ enum port intel_ddi_get_encoder_port(struct 

Re: [Intel-gfx] [PATCH] i915: don't call drm_atomic_state_put on invalid pointer

[Chris Wilson]

On Tue, Oct 18, 2016 at 05:16:23PM +0200, Arnd Bergmann wrote:
> The introduction of reference counting on the state structures caused
> sanitize_watermarks() in i915 to break in the error handling case,
> as pointed out by gcc -Wmaybe-uninitialized
> 
> drivers/gpu/drm/i915/intel_display.c: In function ‘intel_modeset_init’:
> include/drm/drm_atomic.h:224:2: error: ‘state’ may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
> 
> This changes the function back to only drop the reference count
> when it was successfully allocated first.
> 
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Signed-off-by: Arnd Bergmann 

Yup, missed that it jumps to fail before allocating state.

Function still looks a bit odd, but nvm
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] [Regression report] Weekly regression report WW42

[Jairo Miramontes]

On 10/18/2016 9:13 AM, Jani Nikula wrote:

On Tue, 18 Oct 2016, "Vega, Ricardo"  wrote:

Jairo had to manually go into every bug and include the correct
"keyword" but this is done.

I know it had to be done manually. Thank you very much for the effort!


He's script will continue to look for both keywords field and also
specific strings in the summary at least until we are consistent using
the keyword field.

If the keywords are there now, it might be good to make the
scripts/queries check when there's an inconsistency, so they can be
fixed.
Sounds like a good idea, already placed some code to check regressions 
that do not have keywords assigned


Regards!




In addition will include the following query into the report this is only 
looking for keyword field =
https://bugs.freedesktop.org/buglist.cgi?action=wrap_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=NEEDINFO_status=PLEASETEST=DRM%2FIntel=bisected%2C%20bisect_pending%2C%20regression%2C%20_type=anywords_id=595992=DRI

I created a short URL to make it easier to share - https://goo.gl/OtzzzS

Thanks!

BR,
Jani.


RV

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Tuesday, October 18, 2016 3:20 AM
To: Jairo Miramontes ; 
intel-gfx@lists.freedesktop.org; otc gfx qa 
Subject: Re: [Intel-gfx] [Regression report] Weekly regression report WW42


Do all the bugs at fdo now have the appropriate regression/bisected keywords? 
Can we start using a bugzilla query link to get all the information in this 
report?

BR,
Jani.


On Mon, 17 Oct 2016, Jairo Miramontes 
 wrote:

This weeknew regressions
+---+---+++
| BugId | Summary   | Created on |
Bisect |
+---+---+++
| 98213 | REGRESSION: GPU hangs when enable_fbc=1   | 2016-10-12 |
No |
+---+---+++

Previous regressions
+---+---+++
| BugId | Summary   | Created on |
Bisect |
+---+---+++
| 98036 | [BYT] constant screen flicker and rendering e | 2016-10-03 |
No |
| 97994 | [REGRESS] [BISECT] [i915] Monitor resolution  | 2016-09-30 |
Yes| |
| 97918 | [bdw regression 4.8] Severe graphics regressi | 2016-09-25 |
No |
| 97878 | [SKL][REGRESSION][BISECTED] Dropped frames an | 2016-09-20 |
Yes|
| 97867 | [HSW][Regression] 4.6.7 and beyond causes scr | 2016-09-19 |
No |
| 97450 | [SKL] [regression] Random display flickering  | 2016-08-23 |
No |
| 97017 | [SKL GT3e guc bisected] ~10% performance drop | 2016-07-21 |
Yes|
| 96938 | [HSW modeset regression] i915/drm locks up wh | 2016-07-15 |
No |
| 96916 | Regression: screen flashes with PSR enabled   | 2016-07-13 |
No |
| 96800 | [regression] The drm-intel-nightly branch no  | 2016-07-04 |
No |
| 96736 | kernel 4.6 regression: PSR causes screen to f | 2016-06-29 |
No |
| 96704 | kernel 4.6 regression: PSR on Haswell causes  | 2016-06-28 |
No |
| 96645 | [regression 4.7] [BISECT]Low package c-states | 2016-06-22 |
Yes|
| 96428 | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR*  | 2016-06-07 |
Yes|
| 95736 | [IVB bisected] *ERROR* uncleared fifo underru | 2016-05-24 |
Yes|
| 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 |
No |
| 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 |
No |
| 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 |
No |
| 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 |
No |
| 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 |
No |
| 93971 | video framerate performance regression with U | 2016-02-02 |
No |
| 93802 | [IVB bisected] switching to tty1 causes fifo  | 2016-01-20 |
Yes|
| 93782 | [i9xx TV][BISECT] vblank wait timeout on crtc | 2016-01-19 |
Yes|
| 93486 | [HP Compaq dc7800 Small Form Factor PC][REGRE | 2015-12-23 |
No |
| 93393 | Regression for Skylake modesetting in kernel  | 2015-12-16 |
No |
| 93263 | 945GM regression since 4.3| 2015-12-05 |
No |
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 |
Yes|
| 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 |
No |
| 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 |
No |
| 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 |
Yes|
| 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 |
No |
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 |
Yes|

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

[Michal Hocko]

On Thu 13-10-16 01:20:10, Lorenzo Stoakes wrote:
> This patch series adjusts functions in the get_user_pages* family such that
> desired FOLL_* flags are passed as an argument rather than implied by flags.
> 
> The purpose of this change is to make the use of FOLL_FORCE explicit so it is
> easier to grep for and clearer to callers that this flag is being used. The 
> use
> of FOLL_FORCE is an issue as it overrides missing VM_READ/VM_WRITE flags for 
> the
> VMA whose pages we are reading from/writing to, which can result in surprising
> behaviour.
> 
> The patch series came out of the discussion around commit 38e0885, which
> addressed a BUG_ON() being triggered when a page was faulted in with PROT_NONE
> set but having been overridden by FOLL_FORCE. do_numa_page() was run on the
> assumption the page _must_ be one marked for NUMA node migration as an actual
> PROT_NONE page would have been dealt with prior to this code path, however
> FOLL_FORCE introduced a situation where this assumption did not hold.
> 
> See https://marc.info/?l=linux-mm=147585445805166 for the patch proposal.

I like this cleanup. Tracking FOLL_FORCE users was always a nightmare
and the flag behavior is really subtle so we should better be explicit
about it. I haven't gone through each patch separately but rather
applied the whole series and checked the resulting diff. This all seems
OK to me and feel free to add
Acked-by: Michal Hocko 

I am wondering whether we can go further. E.g. it is not really clear to
me whether we need an explicit FOLL_REMOTE when we can in fact check
mm != current->mm and imply that. Maybe there are some contexts which
wouldn't work, I haven't checked.

Then I am also wondering about FOLL_TOUCH behavior.
__get_user_pages_unlocked has only few callers which used to be
get_user_pages_unlocked before 1e9877902dc7e ("mm/gup: Introduce
get_user_pages_remote()"). To me a dropped FOLL_TOUCH seems
unintentional. Now that get_user_pages_unlocked has gup_flags argument I
guess we might want to get rid of the __g-u-p-u version altogether, no?

__get_user_pages is quite low level and imho shouldn't be exported. It's
only user - kvm - should rather pull those two functions to gup instead
and export them. There is nothing really KVM specific in them.

I also cannot say I would be entirely thrilled about get_user_pages_locked,
we only have one user which can simply do lock g-u-p unlock AFAICS.

I guess there is more work in that area and I do not want to impose all
that work on you, but I couldn't resist once I saw you playing in that
area ;) Definitely a good start!
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: don't call drm_atomic_state_put on invalid pointer

[Eric Engestrom]

On Tuesday, 2016-10-18 17:16:23 +0200, Arnd Bergmann wrote:
> The introduction of reference counting on the state structures caused
> sanitize_watermarks() in i915 to break in the error handling case,
> as pointed out by gcc -Wmaybe-uninitialized
> 
> drivers/gpu/drm/i915/intel_display.c: In function ‘intel_modeset_init’:
> include/drm/drm_atomic.h:224:2: error: ‘state’ may be used uninitialized in 
> this function [-Werror=maybe-uninitialized]
> 
> This changes the function back to only drop the reference count
> when it was successfully allocated first.
> 
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Eric Engestrom 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 6d168685bbda..6a26da143aa6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -16314,7 +16314,7 @@ static void sanitize_watermarks(struct drm_device 
> *dev)
>* BIOS-programmed watermarks untouched and hope for the best.
>*/
>   WARN(true, "Could not determine valid watermarks for inherited 
> state\n");
> - goto fail;
> + goto put_state;
>   }
>  
>   /* Write calculated watermark values back */
> @@ -16325,8 +16325,9 @@ static void sanitize_watermarks(struct drm_device 
> *dev)
>   dev_priv->display.optimize_watermarks(cs);
>   }
>  
> -fail:
> +put_state:
>   drm_atomic_state_put(state);
> +fail:
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
>  }
> -- 
> 2.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] IGT contributions and reviews

[Petri Latvala]

The current contributing docs for IGT state:

<<
  There is no formal review requirement and regular contributors with
  commit access can push patches right after submitting them to the
  mailing lists. But invasive changes, new helper libraries and
  contributions from newcomers should go through a proper review to
  ensure overall consistency in the codebase.
>>


While not requiring reviews or acks has definitely increased the
speed of development, I feel the time for slowing down a bit has
come.

At the very least I would like to see all commits have a visit to the
mailing list before pushing, as the current docs already ask for. The
"right after" part would be changed to a $period of quarantine, maybe
24 hours?

As for requiring reviews or acks before pushing, how do the developers
at large feel about that? Different rules for different parts of IGT?
(Benchmarks, tools, tests, CI test sets, lib)

The goal with this discussion is to reach a suitable tradeoff between
stability from CI point of view and fruitful use of programmer time.


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

[Intel-gfx] [PATCH v2] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

[Arkadiusz Hiler]

Dropping WA because it was for early steppings.

It is fixed in newer preproduction and all production revisions.

v2: add references, updated commit message

References: HSD#2126385, HSD#2131381, BSID#0764
Cc: Mika Kuoppala 
Cc: Chris Wilson 
Cc: Michal Winiarski 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e107455..32786ba 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -849,10 +849,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
 */
}
 
-   /* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt,kbl */
/* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt,kbl */
WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
- GEN9_ENABLE_YV12_BUGFIX |
  GEN9_ENABLE_GPGPU_PREEMPTION);
 
/* Wa4x4STCOptimizationDisable:skl,bxt,kbl */
-- 
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Mark GVT as BROKEN

[Patchwork]

== Series Details ==

Series: drm/i915: Mark GVT as BROKEN
URL   : https://patchwork.freedesktop.org/series/13959/
State : warning

== Summary ==

Series 13959v1 drm/i915: Mark GVT as BROKEN
https://patchwork.freedesktop.org/api/1.0/series/13959/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-ivb-3520m)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-kbl-7200u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:208  pass:175  dwarn:0   dfail:0   fail:0   skip:32 

Results at /archive/results/CI_IGT_test/Patchwork_2745/

5b633f423e27af3a7f30d303e243f5a2e82917ae drm-intel-nightly: 
2016y-10m-18d-13h-24m-11s UTC integration manifest
467b87d drm/i915: Mark GVT as BROKEN

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

Re: [Intel-gfx] [PULL] GVT-g device model core

[Chris Wilson]

On Fri, Oct 14, 2016 at 06:30:30PM +0800, Zhenyu Wang wrote:
> 
> Hi,
> 
> This is first pull request to merge GVT-g device model in i915
> which contains core GVT-g device model work to virtualize GPU
> resources. This tries to add feature of Intel GVT-g technology
> for full GPU virtualization. This version will support KVM based
> virtualization solution named as KVMGT.

The fence stealing code is broken wrt runtime pm.

The command parser duplicated dead code, the whole shadow copy needs to
be rewritten from scratch to remove the duplicated bugs.

VMA insertion is incorrect and will cause random corruption (cut'n'paste
bugs for the win).

VMA pinning is broken and will cause corruption on memory pressure, or
worse allow exploitation of a read/write to reallocated system pages.
-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] [Regression report] Weekly regression report WW42

[Jani Nikula]

On Tue, 18 Oct 2016, "Vega, Ricardo"  wrote:
> Jairo had to manually go into every bug and include the correct
> "keyword" but this is done.

I know it had to be done manually. Thank you very much for the effort!

> He's script will continue to look for both keywords field and also
> specific strings in the summary at least until we are consistent using
> the keyword field.

If the keywords are there now, it might be good to make the
scripts/queries check when there's an inconsistency, so they can be
fixed.

> In addition will include the following query into the report this is only 
> looking for keyword field = 
> https://bugs.freedesktop.org/buglist.cgi?action=wrap_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=NEEDINFO_status=PLEASETEST=DRM%2FIntel=bisected%2C%20bisect_pending%2C%20regression%2C%20_type=anywords_id=595992=DRI
>
> I created a short URL to make it easier to share - https://goo.gl/OtzzzS

Thanks!

BR,
Jani.

>
> RV
>
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
> Sent: Tuesday, October 18, 2016 3:20 AM
> To: Jairo Miramontes ; 
> intel-gfx@lists.freedesktop.org; otc gfx qa 
> Subject: Re: [Intel-gfx] [Regression report] Weekly regression report WW42
>
>
> Do all the bugs at fdo now have the appropriate regression/bisected keywords? 
> Can we start using a bugzilla query link to get all the information in this 
> report?
>
> BR,
> Jani.
>
>
> On Mon, 17 Oct 2016, Jairo Miramontes 
>  wrote:
>> This weeknew regressions
>> +---+---+++
>> | BugId | Summary   | Created on | 
>> Bisect |
>> +---+---+++
>> | 98213 | REGRESSION: GPU hangs when enable_fbc=1   | 2016-10-12 | 
>> No |
>> +---+---+++
>>
>> Previous regressions
>> +---+---+++
>> | BugId | Summary   | Created on | 
>> Bisect |
>> +---+---+++
>> | 98036 | [BYT] constant screen flicker and rendering e | 2016-10-03 |
>> No |
>> | 97994 | [REGRESS] [BISECT] [i915] Monitor resolution  | 2016-09-30 |
>> Yes| |
>> | 97918 | [bdw regression 4.8] Severe graphics regressi | 2016-09-25 |
>> No |
>> | 97878 | [SKL][REGRESSION][BISECTED] Dropped frames an | 2016-09-20 |
>> Yes|
>> | 97867 | [HSW][Regression] 4.6.7 and beyond causes scr | 2016-09-19 |
>> No |
>> | 97450 | [SKL] [regression] Random display flickering  | 2016-08-23 |
>> No |
>> | 97017 | [SKL GT3e guc bisected] ~10% performance drop | 2016-07-21 |
>> Yes|
>> | 96938 | [HSW modeset regression] i915/drm locks up wh | 2016-07-15 |
>> No |
>> | 96916 | Regression: screen flashes with PSR enabled   | 2016-07-13 | 
>> No |
>> | 96800 | [regression] The drm-intel-nightly branch no  | 2016-07-04 |
>> No |
>> | 96736 | kernel 4.6 regression: PSR causes screen to f | 2016-06-29 |
>> No |
>> | 96704 | kernel 4.6 regression: PSR on Haswell causes  | 2016-06-28 |
>> No |
>> | 96645 | [regression 4.7] [BISECT]Low package c-states | 2016-06-22 |
>> Yes|
>> | 96428 | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR*  | 2016-06-07 |
>> Yes|
>> | 95736 | [IVB bisected] *ERROR* uncleared fifo underru | 2016-05-24 |
>> Yes|
>> | 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 |
>> No |
>> | 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | 
>> No |
>> | 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 |
>> No |
>> | 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 |
>> No |
>> | 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 |
>> No |
>> | 93971 | video framerate performance regression with U | 2016-02-02 |
>> No |
>> | 93802 | [IVB bisected] switching to tty1 causes fifo  | 2016-01-20 |
>> Yes|
>> | 93782 | [i9xx TV][BISECT] vblank wait timeout on crtc | 2016-01-19 |
>> Yes|
>> | 93486 | [HP Compaq dc7800 Small Form Factor PC][REGRE | 2015-12-23 |
>> No |
>> | 93393 | Regression for Skylake modesetting in kernel  | 2015-12-16 |
>> No |
>> | 93263 | 945GM regression since 4.3| 2015-12-05 | 
>> No |
>> | 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 |
>> Yes|
>> | 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 |
>> No |
>> | 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 |
>> No |
>> | 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 |
>> Yes|
>> | 91959 | [865g Linux regression] GPU hang 

Re: [Intel-gfx] 4.8-rc1: it is now common that machine needs re-run of xrandr after resume

[Pavel Machek]

Hi!

On Wed 2016-09-14 14:14:35, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Jani Nikula  wrote:
> > On Wed, 14 Sep 2016, Pavel Machek  wrote:
> >> For the "sometimes need xrandr after resume": I don't think I can
> >> bisect that. It only happens sometimes :-(. But there's something
> >> helpful in the logs:
> >
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
> >
> > Pavel, Martin, do you always see this when the display fails to resume?
> > Is it HDMI/DVI for both of you?
> 
> Please try this patch, backported from our next.

Sorry, spam filter hidden your emails.

I believe I still see the issue on v4.9-rc1. ... does it still make
sense to retry the patch?

What I also is re-aranged windows. So I get resume, I get both
monitors, but I also see that X windows lost connection with the big
monitor (and re-arranged my windows for me).

Oh and I guess I should mention:

1) Yes, I only see the issue on the DVI output. VGA seems to work.

2) I do have power switch on the monitors, so it is possible that
during resume, monitors have no AC power. (Not merely turned off by
the soft switch. No AC power.)

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [Intel-gfx] [PATCH 04/10] dim: autodetect remotes, first part for dim_setup

[Jani Nikula]

On Tue, 18 Oct 2016, Ville Syrjälä  wrote:
> On Tue, Oct 18, 2016 at 04:27:05PM +0300, Jani Nikula wrote:
>> On Tue, 18 Oct 2016, Daniel Vetter  wrote:
>> > The goals here are multiple:
>> > - simpler configuration through autodetection
>> > - allows seamless upgrading to git worktree for the aux checkouts
>> > - eventually I want to split up drm-misc into a separate remote ...
>> >
>> > And yes this is just a start.
>> >
>> > v2: Print errors to stderr, otherwise they can't be seen when directly
>> > assigning the result of get_remote_name to a variable.
>> >
>> > Signed-off-by: Daniel Vetter 
>> > ---
>> >  dim | 112 
>> > +++-
>> >  1 file changed, 58 insertions(+), 54 deletions(-)
>> >
>> > diff --git a/dim b/dim
>> > index 2601bb7dbbad..90eb553c6575 100755
>> > --- a/dim
>> > +++ b/dim
>> > @@ -192,6 +192,24 @@ if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then
>> >  dim_uptodate
>> >  fi
>> >  
>> > +function get_remote_name
>> > +{
>> > +  local remote_url=$1
>> > +
>> > +  local remote=`git remote -v | grep $remote_url | \
>> > +  head -n1 | sed -e 's/^\(.*\)\t.*/\1/'`
>> 
>> 'cut -f 1' seems cleaner than the sed.
>
> Or just replace the lot with awk?

Then I'd have to refresh my awk-fu, but awk is not trendy anymore...

J.


>
>> 
>> > +
>> > +  if [[ $remote == "" ]] ; then
>> 
>> I'd prefer
>> 
>>  if [[ -z "$remote" ]]; then
>> 
>> > +  echoerr No git remote for $remote_url found in `pwd`.
>> > +  echoerr Please set it up using
>> > +  echoerr $ git remote add '' $remote_url
>> > +  echoerr with a name of your choice.
>> 
>> I'm fond of wrapping the strings in double quotes. Gives me nicer
>> highlighting in the editor. ;)
>> 
>> Otherwise seems nice.
>> 
>> BR,
>> Jani.
>> 
>> > +  exit 1
>> > +  fi
>> > +
>> > +  echo $remote
>> > +}
>> > +
>> >  # get message id from file
>> >  # $1 = file
>> >  message_get_id ()
>> > @@ -1044,8 +1062,36 @@ function dim_update_branches
>> >update_rerere_cache
>> >  }
>> >  
>> > +function setup_aux_checkout # name remote
>> > +{
>> > +  local name=$1
>> > +  local remote_url=$2
>> > +  local dir=$3
>> > +  local remote
>> > +
>> > +  echo "Setting up $dir ..."
>> > +
>> > +  if [ ! -d $dir ]; then
>> > +  git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
>> > $remote_url $dir
>> > +  cd $dir
>> > +  git config remote.origin.url $remote_url
>> > +  echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
>> > .git/objects/info/alternates
>> > +  git repack -a -d -l
>> > +  remote=origin
>> > +  else
>> > +  cd $dir
>> > +  remote=`get_remote_name $drm_intel_ssh`
>> > +  fi
>> > +  if ! git branch | grep $name > /dev/null ; then
>> > +  git checkout -t $remote/$name
>> > +  fi
>> > +  cd ..
>> > +}
>> > +
>> >  function dim_setup
>> >  {
>> > +  local remote
>> > +
>> >if [ ! -d $DIM_PREFIX ]; then
>> >echo "please set up your repository directory with:"
>> >echo "mkdir -p $DIM_PREFIX"
>> > @@ -1062,76 +1108,34 @@ function dim_setup
>> >exit 1
>> >fi
>> >cd $DIM_DRM_INTEL
>> > -  if ! git remote -v | grep "^origin[[:space:]]" | grep 
>> > $linux_upstream_git > /dev/null; then
>> > -  echo "please set up remote origin for $linux_upstream_git"
>> > -  exit 1
>> > -  fi
>> > -  if ! git remote -v | grep "^$DIM_DRM_INTEL_REMOTE[[:space:]]" | grep 
>> > $drm_intel_ssh > /dev/null; then
>> > -  echo "please set up remote $DIM_DRM_INTEL_REMOTE for 
>> > $drm_intel_ssh with:"
>> > -  echo "git remote add $DIM_DRM_INTEL_REMOTE $drm_intel_ssh"
>> > -  echo "or update your configuration."
>> > -  exit 1
>> > -  fi
>> > -  if ! git remote -v | grep "^$DIM_DRM_UPSTREAM_REMOTE[[:space:]]" | grep 
>> > $drm_upstream_git > /dev/null; then
>> > -  echo "please set up remote $DIM_DRM_UPSTREAM_REMOTE for 
>> > $drm_upstream_git with:"
>> > -  echo "git remote add $DIM_DRM_UPSTREAM_REMOTE 
>> > $drm_upstream_git"
>> > -  echo "or update your configuration."
>> > -  exit 1
>> > -  fi
>> > -  cd ..
>> >  
>> > -  echo "Setting up maintainer-tools ..."
>> > -  if [ ! -d maintainer-tools ]; then
>> > -  git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
>> > $drm_intel_ssh maintainer-tools
>> > -  fi
>> > -  cd maintainer-tools
>> > -  git config remote.origin.url $drm_intel_ssh
>> > -  echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
>> > .git/objects/info/alternates
>> > -  git repack -a -d -l
>> > -  if ! git branch | grep maintainer-tools > /dev/null ; then
>> > -  git checkout -t origin/maintainer-tools
>> > -  fi
>> > -  cd ..
>> > +  # check remote configuration
>> > +  remote=`get_remote_name $linux_upstream_git`
>> > +  

[Intel-gfx] [PATCH] drm/i915: Mark GVT as BROKEN

[Chris Wilson]

It contains oodles of unreviewed code that has numerous bugs in just the
few minutes I spent looking at it.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index e1b32da8954e..e0f2443bcb9a 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -87,6 +87,7 @@ config DRM_I915_USERPTR
 config DRM_I915_GVT
 bool "Enable Intel GVT-g graphics virtualization host support"
 depends on DRM_I915
+depends on BROKEN
 default n
 help
  Choose this option if you want to enable Intel GVT-g graphics
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

[Mika Kuoppala]

Chris Wilson  writes:

> On Tue, Oct 18, 2016 at 04:15:22PM +0300, Mika Kuoppala wrote:
>> Mika Kuoppala  writes:
>> 
>> > Arkadiusz Hiler  writes:
>> >
>> >> Dropping WA because it was for early steppings.
>> >>
>> >> It is fixed in newer preproduction and all production revisions.
>> >>
>> >
>> > We have used References tag to point to a relevant document
>> > that has more information. Like for this, it should be:
>> >
>> > References: HSD#2126385
>> >
>> > From there I did figure out that this should be from skl:C0 onwards.
>> >
>> > So based on that, we need this wa still.
>> 
>> I fell victim of out-of-date/conflicting information.
>> Arkadiusz kindly pointed me to the correct sources and cleared
>> the confusion. I am convinced we can drop this workaround.
>
> So documentation link / hint to clear the confusion?

Wa database had FROM_C0 and hsd,bspec has UNTIL_B0.
-Mika

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

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

[Paulo Zanoni]

Em Sex, 2016-10-14 às 16:47 -0700, Anusha Srivatsa escreveu:
> i915.enable_guc_loading/submission=2 forces the usage of GuC.
> For platforms that do not have a GuC, asking the kernel to use a GuC
> should not result in an error state. Do extra checks to see if the
> platform even has a GuC or not, regardless of the kernel parameter.
> 
> v2: Based on Rodrigo's patch and Paulo's suggestion(Paulo, Rodrigo)
> v3: Correct the Indentation(Jani, Paulo)
> v4: Added the blank line(Jani, Paulo)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97573
> Cc: Rodrigo Vivi 
> Cc: Zanoni Paulo 
> Cc: Jani Nikula 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_guc_loader.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 678b51a..94c3ad9 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -719,11 +719,17 @@ void intel_guc_init(struct drm_device *dev)
>   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
>   const char *fw_path;
>  
> - /* A negative value means "use platform default" */
> - if (i915.enable_guc_loading < 0)
> - i915.enable_guc_loading = HAS_GUC_UCODE(dev);
> - if (i915.enable_guc_submission < 0)
> - i915.enable_guc_submission = HAS_GUC_SCHED(dev);
> + if (!HAS_GUC(dev)) {
> + i915.enable_guc_loading = 0;
> + i915.enable_guc_submission = 0;
> + } else {
> + /* A negative value means "use platform default" */
> + if (i915.enable_guc_loading < 0)
> + i915.enable_guc_loading =
> HAS_GUC_UCODE(dev);
> + if (i915.enable_guc_submission < 0)
> + i915.enable_guc_submission =
> HAS_GUC_SCHED(dev);
> + }
> +

Previously you were removing the blank line at this spot, leaving the
code without any empty lines between the two "if" statements. Now in
this version, instead of just not removing the blank line, you added an
extra one, so there are two blank lines between the two "if"
statements. Again, this is not the usual coding style.

Anyway, I amended your patch, added a R-B tag and merged it. Thanks for
the patch.

>  
>   if (!HAS_GUC_UCODE(dev)) {
>   fw_path = NULL;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/10] dim: Autocheck for up-to-dateness

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> On Tue, Oct 18, 2016 at 04:15:01PM +0300, Jani Nikula wrote:
>> On Tue, 18 Oct 2016, Daniel Vetter  wrote:
>> > Exits script to annoy people roughly every 100th time ...
>> 
>> Annoyingly random, but we can improve this later.
>
> I had it non-random, then realized it makes improving dim impossible ;-)

I thought about just warning on every Nth day $((`date +%j` % N)) == 0,
and not exiting the script. Warning every time is annoying because it
talks to the network.

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 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

[Lorenzo Stoakes]

On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote:
> > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned 
> > long nr_pages,
> > int write, int force, struct page **pages,
> > struct vm_area_struct **vmas);
> >  long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
> > -   int write, int force, struct page **pages, int *locked);
> > +   unsigned int gup_flags, struct page **pages, int *locked);
>
> Hum, the prototype is inconsistent with e.g. __get_user_pages_unlocked()
> where gup_flags come after **pages argument. Actually it makes more sense
> to have it before **pages so that input arguments come first and output
> arguments second but I don't care that much. But it definitely should be
> consistent...

It was difficult to decide quite how to arrange parameters as there was
inconsitency with regards to parameter ordering already - for example
__get_user_pages() places its flags argument before pages whereas, as you note,
__get_user_pages_unlocked() puts them afterwards.

I ended up compromising by trying to match the existing ordering of the function
as much as I could by replacing write, force pairs with gup_flags in the same
location (with the exception of get_user_pages_unlocked() which I felt should
match __get_user_pages_unlocked() in signature) or if there was already a
gup_flags parameter as in the case of __get_user_pages_unlocked() I simply
removed the write, force pair and left the flags as the last parameter.

I am happy to rearrange parameters as needed, however I am not sure if it'd be
worthwhile for me to do so (I am keen to try to avoid adding too much noise here
:)

If we were to rearrange parameters for consistency I'd suggest adjusting
__get_user_pages_unlocked() to put gup_flags before pages and do the same with
get_user_pages_unlocked(), let me know what you think.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/10] dim: autodetect branches in rebuild-nightly

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> Needs new url-mapping information in nightly.conf to work properly.

I think in the long run the right fix would be to make nightly.conf
independent of remote names. Not sure if that's worth the trouble at
this point.

BR,
Jani.



>
> Signed-off-by: Daniel Vetter 
> ---
>  dim | 48 
>  1 file changed, 36 insertions(+), 12 deletions(-)
>
> diff --git a/dim b/dim
> index 48d5e7b6477a..f9b28d5fd241 100755
> --- a/dim
> +++ b/dim
> @@ -235,20 +235,30 @@ function dim_commit_add_tag
>   done
>  }
>  
> +function map_nightly_remote
> +{
> + local nightly_remote=$1
> + local remote_url=`eval echo 
> "\\\$nightly_remote_url_${nightly_remote/-/_}"`
> +
> + get_remote_name $remote_url
> +}
> +
>  function update_linux_next
>  {
>   cd $DIM_PREFIX/drm-intel-nightly
>  
> + local nightly_origin=`map_nightly_remote origin`
> +
>   # always update drm-intel-fixes
>   echo -n "Pushing drm-intel-fixes to for-linux-next-fixes... "
> - git push $DRY_RUN origin +origin/drm-intel-fixes:for-linux-next-fixes 
> >& /dev/null
> + git push $DRY_RUN $nightly_origin 
> +$nightly_origin/drm-intel-fixes:for-linux-next-fixes >& /dev/null
>   echo "Done."
>  
> - if git merge-base --is-ancestor origin/drm-intel-next-fixes 
> origin/drm-intel-fixes ; then
> + if git merge-base --is-ancestor $nightly_origin/drm-intel-next-fixes 
> $nightly_origin/drm-intel-fixes ; then
>   # -fixes has caught up to dinf, i.e. we're out of the merge
>   # window. Push the next queue.
>   echo -n "Out of merge window. Pushing drm-intel-next-queued to 
> for-linux-next... "
> - git push $DRY_RUN origin 
> +origin/drm-intel-next-queued:for-linux-next >& /dev/null
> + git push $DRY_RUN $nightly_origin 
> +$nightly_origin/drm-intel-next-queued:for-linux-next >& /dev/null
>   echo "Done."
>   else
>   # dinf is ahead of -fixes, i.e. drm-next has already closed for
> @@ -256,7 +266,7 @@ function update_linux_next
>   # for the current -next cycle. Push dinf
>  
>   echo -n "Pushing drm-intel-next-fixes to for-linux-next... "
> - git push $DRY_RUN origin 
> +origin/drm-intel-next-fixes:for-linux-next >& /dev/null
> + git push $DRY_RUN $nightly_origin 
> +$nightly_origin/drm-intel-next-fixes:for-linux-next >& /dev/null
>   echo "Done."
>   fi
>  }
> @@ -272,11 +282,20 @@ function check_conflicts
>   true
>  }
>  
> +function rr_cache_dir
> +{
> + if [ -d $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ ] ; then
> + echo $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/
> + else
> + echo $DIM_PREFIX/$DIM_DRM_INTEL/.git/rr-cache/
> + fi
> +}
> +
>  function update_rerere_cache
>  {
>   cd $DIM_PREFIX/drm-intel-rerere/
>   git pull
> - cp rr-cache/* $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ -r
> + cp rr-cache/* `rr_cache-dir` -r
>   cd -
>  }
>  
> @@ -307,9 +326,10 @@ function dim_rebuild_nightly
>   fi
>  
>   for remote in $(echo $nightly_branches | tr " " "\n" | sed 's|/.*$||g' 
> | sort -u); do
> - echo -n "Fetching $remote... "
> + local nightly_remote=`map_nightly_remote $remote`
> + echo -n "Fetching $remote (as $nightly_remote) ... "
>   # git fetch returns 128 if there's nothing to be fetched
> - git fetch $remote >& /dev/null || true
> + git fetch $nightly_remote >& /dev/null || true
>   echo "Done."
>   done
>  
> @@ -329,12 +349,14 @@ function dim_rebuild_nightly
>   if [[ -n $sha1 ]] ; then
>   echo -n "Using override sha1: $sha1... "
>   else
> - sha1=$branch
> + local remote=${branch%%/*}
> + local nightly_remote=`map_nightly_remote $remote`
> + sha1=`echo $branch | sed -e s/^$remote/$nightly_remote/`
>   fi
>  
>   if [ $first == 1 ] ; then
> + git reset --hard $sha1 &> /dev/null
>   echo "Reset. Done."
> - git reset --hard $sha1 >& /dev/null
>   first=0
>   elif git merge --rerere-autoupdate --ff-only $sha1 >& /dev/null 
> ; then
>   # nothing to do if just fast-forward
> @@ -370,14 +392,16 @@ function dim_rebuild_nightly
>   git commit --quiet -m "$integration_branch: $time integration manifest"
>   echo "Done."
>  
> + local nightly_origin=`map_nightly_remote origin`
> +
>   echo -n "Pushing $integration_branch... "
> - git push $DRY_RUN origin +HEAD >& /dev/null && echo "Done."
> + git push $DRY_RUN $nightly_origin +HEAD >& /dev/null && echo "Done."
>  
>   echo -n "Updating 

Re: [Intel-gfx] [PATCH 06/10] dim: Nuke nightly-forget

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> With our proliferation of branches it's become long useless. Nowadays
> my MO is to revert the offending commit in the rerere-cache branch
> explicitly, remove drm-intel-nightly/.git/rr-cache and then re-run
> rebuild-nightly. That works much better, hence nuke this helper.

Agreed.

Later, we should add a helper to do the better MO.

BR,
Jani.


>
> Signed-off-by: Daniel Vetter 
> ---
>  TODO | 2 --
>  dim  | 9 -
>  2 files changed, 11 deletions(-)
>
> diff --git a/TODO b/TODO
> index ac0f27763dfa..c1c6e20eb0e3 100644
> --- a/TODO
> +++ b/TODO
> @@ -1,8 +1,6 @@
>  dim:
>  - extract the integration tree logic and make it generally useful, maybe for 
> a
>drm-integration tree ...
> -- Improve nightly-forget to forget a specific merge instead of just the first
> -  dinq/dif merge.
>  - add option to check-patch to check stdin
>  - integrate ninja-check? Or too much checkers considered harmful?
>
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html
> diff --git a/dim b/dim
> index 80baf24e4ad7..48d5e7b6477a 100755
> --- a/dim
> +++ b/dim
> @@ -395,15 +395,6 @@ function dim_rebuild_nightly
>   update_linux_next
>  }
>  
> -function dim_nightly_forget
> -{
> - cd $DIM_PREFIX/drm-intel-nightly
> - git fetch origin >& /dev/null
> - git reset --hard origin/drm-intel-next-queued >& /dev/null
> - git merge origin/drm-intel-fixes
> - git rerere forget
> -}
> -
>  # push branch $1, rebuild nightly. the rest of the arguments are passed to 
> git
>  # push.
>  function dim_push_branch

-- 
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 2/2] drm/i915: Make GPU pages movable

[Chris Wilson]

On Tue, Oct 18, 2016 at 06:55:12PM +0530, Goel, Akash wrote:
> 
> 
> On 10/18/2016 5:35 PM, Joonas Lahtinen wrote:
> >On ma, 2016-04-04 at 14:18 +0100, Chris Wilson wrote:
> >>From: Akash Goel 
> >>
> >>On a long run of more than 2-3 days, physical memory tends to get
> >>fragmented severely, which considerably slows down the system. In such a
> >>scenario, the shrinker is also unable to help as lack of memory is not
> >>the actual problem, since it has been observed that there are enough free
> >>pages of 0 order. This also manifests itself when an indiviual zone in
> >>the mm runs out of pages and if we cannot migrate pages between zones,
> >>the kernel hits an out-of-memory even though there are free pages (and
> >>often all of swap) available.
> >>
> >>To address the issue of external fragementation, kernel does a compaction
> >>(which involves migration of pages) but it's efficacy depends upon how
> >>many pages are marked as MOVABLE, as only those pages can be migrated.
> >>
> >>Currently the backing pages for GFX buffers are allocated from shmemfs
> >>with GFP_RECLAIMABLE flag, in units of 4KB pages.  In the case of limited
> >>swap space, it may not be possible always to reclaim or swap-out pages of
> >>all the inactive objects, to make way for free space allowing formation
> >>of higher order groups of physically-contiguous pages on compaction.
> >>
> >>Just marking the GPU pages as MOVABLE will not suffice, as i915.ko has to
> >>pin the pages if they are in use by GPU, which will prevent their
> >>migration. So the migratepage callback in shmem is also hooked up to get
> >>a notification when kernel initiates the page migration. On the
> >>notification, i915.ko appropriately unpin the pages.  With this we can
> >>effectively mark the GPU pages as MOVABLE and hence mitigate the
> >>fragmentation problem.
> >>
> >>v2:
> >> - Rename the migration routine to gem_shrink_migratepage, move it to the
> >>   shrinker file, and use the existing constructs (Chris)
> >> - To cleanup, add a new helper function to encapsulate all page migration
> >>   skip conditions (Chris)
> >> - Add a new local helper function in shrinker file, for dropping the
> >>   backing pages, and call the same from gem_shrink() also (Chris)
> >>
> >>v3:
> >> - Fix/invert the check on the return value of unsafe_drop_pages (Chris)
> >>
> >>v4:
> >> - Minor tidy
> >>
> >>Testcase: igt/gem_shrink
> >>Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
> >>Cc: Hugh Dickins 
> >>Cc: linux...@kvack.org
> >>Signed-off-by: Sourab Gupta 
> >>Signed-off-by: Akash Goel 
> >>Reviewed-by: Chris Wilson 
> >
> >Could this patch be re-spinned on top of current nightly?
> >
> Sure will rebase it on top of nightly.

It's in my tree (on top of nightly) already with Joonas' r-b.
-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 05/10] dim: support git worktree for aux checkouts

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> If available by default. This saves quite a pile of disk-space that
> imo making it the default is justified.
>
> Note that this will break the rebuild-nightly script for now,
> follow-up patches will fix that.
>
> Signed-off-by: Daniel Vetter 
> ---
>  dim | 23 ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/dim b/dim
> index 90eb553c6575..80baf24e4ad7 100755
> --- a/dim
> +++ b/dim
> @@ -1072,15 +1072,24 @@ function setup_aux_checkout # name remote
>   echo "Setting up $dir ..."
>  
>   if [ ! -d $dir ]; then
> - git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
> $remote_url $dir
> - cd $dir
> - git config remote.origin.url $remote_url
> - echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
> .git/objects/info/alternates
> - git repack -a -d -l
> - remote=origin
> + if git help worktree &> /dev/null ; then
> + cd $DIM_PREFIX/$DIM_DRM_INTEL
> + remote=`get_remote_name $remote_url`
> + if ! git branch | grep $name > /dev/null ; then

The failure modes are annoying if there's a substring match for
$name. Unfortunately grep -w is no good if you need to handle "-" too.

> + git branch --track $name $remote/$name
> + fi
> + git worktree add ../$dir $name
> + else
> + git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
> $remote_url $dir
> + cd $dir
> + git config remote.origin.url $remote_url
> + echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
> .git/objects/info/alternates
> + git repack -a -d -l
> + remote=origin
> + fi
>   else
>   cd $dir
> - remote=`get_remote_name $drm_intel_ssh`
> + remote=`get_remote_name $remote_url`
>   fi
>   if ! git branch | grep $name > /dev/null ; then
>   git checkout -t $remote/$name

-- 
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] [Regression report] Weekly regression report WW42

[Vega, Ricardo]

Jairo had to manually go into every bug and include the correct "keyword" but 
this is done.  He's script will continue to look for both keywords field and 
also specific strings in the summary at least until we are consistent using the 
keyword field.

In addition will include the following query into the report this is only 
looking for keyword field = 
https://bugs.freedesktop.org/buglist.cgi?action=wrap_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=NEEDINFO_status=PLEASETEST=DRM%2FIntel=bisected%2C%20bisect_pending%2C%20regression%2C%20_type=anywords_id=595992=DRI

I created a short URL to make it easier to share - https://goo.gl/OtzzzS

RV

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
Sent: Tuesday, October 18, 2016 3:20 AM
To: Jairo Miramontes ; 
intel-gfx@lists.freedesktop.org; otc gfx qa 
Subject: Re: [Intel-gfx] [Regression report] Weekly regression report WW42


Do all the bugs at fdo now have the appropriate regression/bisected keywords? 
Can we start using a bugzilla query link to get all the information in this 
report?

BR,
Jani.


On Mon, 17 Oct 2016, Jairo Miramontes 
 wrote:
> This weeknew regressions
> +---+---+++
> | BugId | Summary   | Created on | 
> Bisect |
> +---+---+++
> | 98213 | REGRESSION: GPU hangs when enable_fbc=1   | 2016-10-12 | 
> No |
> +---+---+++
>
> Previous regressions
> +---+---+++
> | BugId | Summary   | Created on | 
> Bisect |
> +---+---+++
> | 98036 | [BYT] constant screen flicker and rendering e | 2016-10-03 |
> No |
> | 97994 | [REGRESS] [BISECT] [i915] Monitor resolution  | 2016-09-30 |
> Yes| |
> | 97918 | [bdw regression 4.8] Severe graphics regressi | 2016-09-25 |
> No |
> | 97878 | [SKL][REGRESSION][BISECTED] Dropped frames an | 2016-09-20 |
> Yes|
> | 97867 | [HSW][Regression] 4.6.7 and beyond causes scr | 2016-09-19 |
> No |
> | 97450 | [SKL] [regression] Random display flickering  | 2016-08-23 |
> No |
> | 97017 | [SKL GT3e guc bisected] ~10% performance drop | 2016-07-21 |
> Yes|
> | 96938 | [HSW modeset regression] i915/drm locks up wh | 2016-07-15 |
> No |
> | 96916 | Regression: screen flashes with PSR enabled   | 2016-07-13 | 
> No |
> | 96800 | [regression] The drm-intel-nightly branch no  | 2016-07-04 |
> No |
> | 96736 | kernel 4.6 regression: PSR causes screen to f | 2016-06-29 |
> No |
> | 96704 | kernel 4.6 regression: PSR on Haswell causes  | 2016-06-28 |
> No |
> | 96645 | [regression 4.7] [BISECT]Low package c-states | 2016-06-22 |
> Yes|
> | 96428 | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR*  | 2016-06-07 |
> Yes|
> | 95736 | [IVB bisected] *ERROR* uncleared fifo underru | 2016-05-24 |
> Yes|
> | 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 |
> No |
> | 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | 
> No |
> | 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 |
> No |
> | 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 |
> No |
> | 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 |
> No |
> | 93971 | video framerate performance regression with U | 2016-02-02 |
> No |
> | 93802 | [IVB bisected] switching to tty1 causes fifo  | 2016-01-20 |
> Yes|
> | 93782 | [i9xx TV][BISECT] vblank wait timeout on crtc | 2016-01-19 |
> Yes|
> | 93486 | [HP Compaq dc7800 Small Form Factor PC][REGRE | 2015-12-23 |
> No |
> | 93393 | Regression for Skylake modesetting in kernel  | 2015-12-16 |
> No |
> | 93263 | 945GM regression since 4.3| 2015-12-05 | 
> No |
> | 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 |
> Yes|
> | 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 |
> No |
> | 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 |
> No |
> | 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 |
> Yes|
> | 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 |
> No |
> | 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 |
> Yes|
> | 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 |
> Yes|
> | 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 |
> Yes|
> | 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 |
> No |
> | 89629 | [i965 

Re: [Intel-gfx] [PATCH 04/10] dim: autodetect remotes, first part for dim_setup

[Ville Syrjälä]

On Tue, Oct 18, 2016 at 04:27:05PM +0300, Jani Nikula wrote:
> On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> > The goals here are multiple:
> > - simpler configuration through autodetection
> > - allows seamless upgrading to git worktree for the aux checkouts
> > - eventually I want to split up drm-misc into a separate remote ...
> >
> > And yes this is just a start.
> >
> > v2: Print errors to stderr, otherwise they can't be seen when directly
> > assigning the result of get_remote_name to a variable.
> >
> > Signed-off-by: Daniel Vetter 
> > ---
> >  dim | 112 
> > +++-
> >  1 file changed, 58 insertions(+), 54 deletions(-)
> >
> > diff --git a/dim b/dim
> > index 2601bb7dbbad..90eb553c6575 100755
> > --- a/dim
> > +++ b/dim
> > @@ -192,6 +192,24 @@ if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then
> >  dim_uptodate
> >  fi
> >  
> > +function get_remote_name
> > +{
> > +   local remote_url=$1
> > +
> > +   local remote=`git remote -v | grep $remote_url | \
> > +   head -n1 | sed -e 's/^\(.*\)\t.*/\1/'`
> 
> 'cut -f 1' seems cleaner than the sed.

Or just replace the lot with awk?

> 
> > +
> > +   if [[ $remote == "" ]] ; then
> 
> I'd prefer
> 
>   if [[ -z "$remote" ]]; then
> 
> > +   echoerr No git remote for $remote_url found in `pwd`.
> > +   echoerr Please set it up using
> > +   echoerr $ git remote add '' $remote_url
> > +   echoerr with a name of your choice.
> 
> I'm fond of wrapping the strings in double quotes. Gives me nicer
> highlighting in the editor. ;)
> 
> Otherwise seems nice.
> 
> BR,
> Jani.
> 
> > +   exit 1
> > +   fi
> > +
> > +   echo $remote
> > +}
> > +
> >  # get message id from file
> >  # $1 = file
> >  message_get_id ()
> > @@ -1044,8 +1062,36 @@ function dim_update_branches
> > update_rerere_cache
> >  }
> >  
> > +function setup_aux_checkout # name remote
> > +{
> > +   local name=$1
> > +   local remote_url=$2
> > +   local dir=$3
> > +   local remote
> > +
> > +   echo "Setting up $dir ..."
> > +
> > +   if [ ! -d $dir ]; then
> > +   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
> > $remote_url $dir
> > +   cd $dir
> > +   git config remote.origin.url $remote_url
> > +   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
> > .git/objects/info/alternates
> > +   git repack -a -d -l
> > +   remote=origin
> > +   else
> > +   cd $dir
> > +   remote=`get_remote_name $drm_intel_ssh`
> > +   fi
> > +   if ! git branch | grep $name > /dev/null ; then
> > +   git checkout -t $remote/$name
> > +   fi
> > +   cd ..
> > +}
> > +
> >  function dim_setup
> >  {
> > +   local remote
> > +
> > if [ ! -d $DIM_PREFIX ]; then
> > echo "please set up your repository directory with:"
> > echo "mkdir -p $DIM_PREFIX"
> > @@ -1062,76 +1108,34 @@ function dim_setup
> > exit 1
> > fi
> > cd $DIM_DRM_INTEL
> > -   if ! git remote -v | grep "^origin[[:space:]]" | grep 
> > $linux_upstream_git > /dev/null; then
> > -   echo "please set up remote origin for $linux_upstream_git"
> > -   exit 1
> > -   fi
> > -   if ! git remote -v | grep "^$DIM_DRM_INTEL_REMOTE[[:space:]]" | grep 
> > $drm_intel_ssh > /dev/null; then
> > -   echo "please set up remote $DIM_DRM_INTEL_REMOTE for 
> > $drm_intel_ssh with:"
> > -   echo "git remote add $DIM_DRM_INTEL_REMOTE $drm_intel_ssh"
> > -   echo "or update your configuration."
> > -   exit 1
> > -   fi
> > -   if ! git remote -v | grep "^$DIM_DRM_UPSTREAM_REMOTE[[:space:]]" | grep 
> > $drm_upstream_git > /dev/null; then
> > -   echo "please set up remote $DIM_DRM_UPSTREAM_REMOTE for 
> > $drm_upstream_git with:"
> > -   echo "git remote add $DIM_DRM_UPSTREAM_REMOTE 
> > $drm_upstream_git"
> > -   echo "or update your configuration."
> > -   exit 1
> > -   fi
> > -   cd ..
> >  
> > -   echo "Setting up maintainer-tools ..."
> > -   if [ ! -d maintainer-tools ]; then
> > -   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
> > $drm_intel_ssh maintainer-tools
> > -   fi
> > -   cd maintainer-tools
> > -   git config remote.origin.url $drm_intel_ssh
> > -   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
> > .git/objects/info/alternates
> > -   git repack -a -d -l
> > -   if ! git branch | grep maintainer-tools > /dev/null ; then
> > -   git checkout -t origin/maintainer-tools
> > -   fi
> > -   cd ..
> > +   # check remote configuration
> > +   remote=`get_remote_name $linux_upstream_git`
> > +   remote=`get_remote_name $drm_intel_ssh`
> > +   remote=`get_remote_name $drm_upstream_git`
> >  
> > -   echo "Setting up drm-intel-rerere ..."
> > -   if [ ! -d drm-intel-rerere ]; then
> > -   git clone 

Re: [Intel-gfx] [PATCH 02/10] dim: Autocheck for up-to-dateness

[Daniel Vetter]

On Tue, Oct 18, 2016 at 04:15:01PM +0300, Jani Nikula wrote:
> On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> > Exits script to annoy people roughly every 100th time ...
> 
> Annoyingly random, but we can improve this later.

I had it non-random, then realized it makes improving dim impossible ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/10] dim: autodetect remotes, first part for dim_setup

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> The goals here are multiple:
> - simpler configuration through autodetection
> - allows seamless upgrading to git worktree for the aux checkouts
> - eventually I want to split up drm-misc into a separate remote ...
>
> And yes this is just a start.
>
> v2: Print errors to stderr, otherwise they can't be seen when directly
> assigning the result of get_remote_name to a variable.
>
> Signed-off-by: Daniel Vetter 
> ---
>  dim | 112 
> +++-
>  1 file changed, 58 insertions(+), 54 deletions(-)
>
> diff --git a/dim b/dim
> index 2601bb7dbbad..90eb553c6575 100755
> --- a/dim
> +++ b/dim
> @@ -192,6 +192,24 @@ if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then
>  dim_uptodate
>  fi
>  
> +function get_remote_name
> +{
> + local remote_url=$1
> +
> + local remote=`git remote -v | grep $remote_url | \
> + head -n1 | sed -e 's/^\(.*\)\t.*/\1/'`

'cut -f 1' seems cleaner than the sed.

> +
> + if [[ $remote == "" ]] ; then

I'd prefer

if [[ -z "$remote" ]]; then

> + echoerr No git remote for $remote_url found in `pwd`.
> + echoerr Please set it up using
> + echoerr $ git remote add '' $remote_url
> + echoerr with a name of your choice.

I'm fond of wrapping the strings in double quotes. Gives me nicer
highlighting in the editor. ;)

Otherwise seems nice.

BR,
Jani.

> + exit 1
> + fi
> +
> + echo $remote
> +}
> +
>  # get message id from file
>  # $1 = file
>  message_get_id ()
> @@ -1044,8 +1062,36 @@ function dim_update_branches
>   update_rerere_cache
>  }
>  
> +function setup_aux_checkout # name remote
> +{
> + local name=$1
> + local remote_url=$2
> + local dir=$3
> + local remote
> +
> + echo "Setting up $dir ..."
> +
> + if [ ! -d $dir ]; then
> + git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
> $remote_url $dir
> + cd $dir
> + git config remote.origin.url $remote_url
> + echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
> .git/objects/info/alternates
> + git repack -a -d -l
> + remote=origin
> + else
> + cd $dir
> + remote=`get_remote_name $drm_intel_ssh`
> + fi
> + if ! git branch | grep $name > /dev/null ; then
> + git checkout -t $remote/$name
> + fi
> + cd ..
> +}
> +
>  function dim_setup
>  {
> + local remote
> +
>   if [ ! -d $DIM_PREFIX ]; then
>   echo "please set up your repository directory with:"
>   echo "mkdir -p $DIM_PREFIX"
> @@ -1062,76 +1108,34 @@ function dim_setup
>   exit 1
>   fi
>   cd $DIM_DRM_INTEL
> - if ! git remote -v | grep "^origin[[:space:]]" | grep 
> $linux_upstream_git > /dev/null; then
> - echo "please set up remote origin for $linux_upstream_git"
> - exit 1
> - fi
> - if ! git remote -v | grep "^$DIM_DRM_INTEL_REMOTE[[:space:]]" | grep 
> $drm_intel_ssh > /dev/null; then
> - echo "please set up remote $DIM_DRM_INTEL_REMOTE for 
> $drm_intel_ssh with:"
> - echo "git remote add $DIM_DRM_INTEL_REMOTE $drm_intel_ssh"
> - echo "or update your configuration."
> - exit 1
> - fi
> - if ! git remote -v | grep "^$DIM_DRM_UPSTREAM_REMOTE[[:space:]]" | grep 
> $drm_upstream_git > /dev/null; then
> - echo "please set up remote $DIM_DRM_UPSTREAM_REMOTE for 
> $drm_upstream_git with:"
> - echo "git remote add $DIM_DRM_UPSTREAM_REMOTE 
> $drm_upstream_git"
> - echo "or update your configuration."
> - exit 1
> - fi
> - cd ..
>  
> - echo "Setting up maintainer-tools ..."
> - if [ ! -d maintainer-tools ]; then
> - git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
> $drm_intel_ssh maintainer-tools
> - fi
> - cd maintainer-tools
> - git config remote.origin.url $drm_intel_ssh
> - echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
> .git/objects/info/alternates
> - git repack -a -d -l
> - if ! git branch | grep maintainer-tools > /dev/null ; then
> - git checkout -t origin/maintainer-tools
> - fi
> - cd ..
> + # check remote configuration
> + remote=`get_remote_name $linux_upstream_git`
> + remote=`get_remote_name $drm_intel_ssh`
> + remote=`get_remote_name $drm_upstream_git`
>  
> - echo "Setting up drm-intel-rerere ..."
> - if [ ! -d drm-intel-rerere ]; then
> - git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
> $drm_intel_ssh drm-intel-rerere
> - fi
> - cd drm-intel-rerere
> - git config remote.origin.url $drm_intel_ssh
> - echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
> .git/objects/info/alternates
> - git repack -a -d -l
> 

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

[Chris Wilson]

On Tue, Oct 18, 2016 at 04:15:22PM +0300, Mika Kuoppala wrote:
> Mika Kuoppala  writes:
> 
> > Arkadiusz Hiler  writes:
> >
> >> Dropping WA because it was for early steppings.
> >>
> >> It is fixed in newer preproduction and all production revisions.
> >>
> >
> > We have used References tag to point to a relevant document
> > that has more information. Like for this, it should be:
> >
> > References: HSD#2126385
> >
> > From there I did figure out that this should be from skl:C0 onwards.
> >
> > So based on that, we need this wa still.
> 
> I fell victim of out-of-date/conflicting information.
> Arkadiusz kindly pointed me to the correct sources and cleared
> the confusion. I am convinced we can drop this workaround.

So documentation link / hint to clear the confusion?
-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 v4 2/2] drm/i915: Make GPU pages movable

[Goel, Akash]

On 10/18/2016 5:35 PM, Joonas Lahtinen wrote:

On ma, 2016-04-04 at 14:18 +0100, Chris Wilson wrote:

From: Akash Goel 

On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been observed that there are enough free
pages of 0 order. This also manifests itself when an indiviual zone in
the mm runs out of pages and if we cannot migrate pages between zones,
the kernel hits an out-of-memory even though there are free pages (and
often all of swap) available.

To address the issue of external fragementation, kernel does a compaction
(which involves migration of pages) but it's efficacy depends upon how
many pages are marked as MOVABLE, as only those pages can be migrated.

Currently the backing pages for GFX buffers are allocated from shmemfs
with GFP_RECLAIMABLE flag, in units of 4KB pages.  In the case of limited
swap space, it may not be possible always to reclaim or swap-out pages of
all the inactive objects, to make way for free space allowing formation
of higher order groups of physically-contiguous pages on compaction.

Just marking the GPU pages as MOVABLE will not suffice, as i915.ko has to
pin the pages if they are in use by GPU, which will prevent their
migration. So the migratepage callback in shmem is also hooked up to get
a notification when kernel initiates the page migration. On the
notification, i915.ko appropriately unpin the pages.  With this we can
effectively mark the GPU pages as MOVABLE and hence mitigate the
fragmentation problem.

v2:
 - Rename the migration routine to gem_shrink_migratepage, move it to the
   shrinker file, and use the existing constructs (Chris)
 - To cleanup, add a new helper function to encapsulate all page migration
   skip conditions (Chris)
 - Add a new local helper function in shrinker file, for dropping the
   backing pages, and call the same from gem_shrink() also (Chris)

v3:
 - Fix/invert the check on the return value of unsafe_drop_pages (Chris)

v4:
 - Minor tidy

Testcase: igt/gem_shrink
Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
Cc: Hugh Dickins 
Cc: linux...@kvack.org
Signed-off-by: Sourab Gupta 
Signed-off-by: Akash Goel 
Reviewed-by: Chris Wilson 


Could this patch be re-spinned on top of current nightly?


Sure will rebase it on top of nightly.


After removing;


WARN(page_count(newpage) != 1, "Unexpected ref count for newpage\n")


and


if (ret)
DRM_DEBUG_DRIVER("page=%p migration returned %d\n", page, ret);


This is;

Reviewed-by: Joonas Lahtinen 

Thanks much for the review.
But there is a precursor patch also, there has been no traction on that.
[1/2] shmem: Support for registration of Driver/file owner specific ops
https://patchwork.freedesktop.org/patch/77935/

Best regards
Akash



Regards, Joonas


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Bump object bookkeeping to u64 from size_t

[Chris Wilson]

On Tue, Oct 18, 2016 at 01:05:24PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,1/4] drm/i915: Bump object bookkeeping to 
> u64 from size_t
> URL   : https://patchwork.freedesktop.org/series/13950/
> State : failure
> 
> == Summary ==
> 
> Series 13950v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/13950/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> INCOMPLETE (fi-snb-2600)
> dmesg-warn -> INCOMPLETE (fi-skl-6700hq)

New sporadic failures not observed on the prior trybot pass.
Challenge for CI to gather some logs.
-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] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

[Mika Kuoppala]

Mika Kuoppala  writes:

> Arkadiusz Hiler  writes:
>
>> Dropping WA because it was for early steppings.
>>
>> It is fixed in newer preproduction and all production revisions.
>>
>
> We have used References tag to point to a relevant document
> that has more information. Like for this, it should be:
>
> References: HSD#2126385
>
> From there I did figure out that this should be from skl:C0 onwards.
>
> So based on that, we need this wa still.

I fell victim of out-of-date/conflicting information.
Arkadiusz kindly pointed me to the correct sources and cleared
the confusion. I am convinced we can drop this workaround.

Reviewed-by: Mika Kuoppala 

>
> -Mika
>
>
>> Cc: Michal Winiarski 
>> Signed-off-by: Arkadiusz Hiler 
>> ---
>>  drivers/gpu/drm/i915/intel_ringbuffer.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index e107455..32786ba 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -849,10 +849,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
>> *engine)
>>   */
>>  }
>>  
>> -/* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt,kbl */
>>  /* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt,kbl */
>>  WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
>> -  GEN9_ENABLE_YV12_BUGFIX |
>>GEN9_ENABLE_GPGPU_PREEMPTION);
>>  
>>  /* Wa4x4STCOptimizationDisable:skl,bxt,kbl */
>> -- 
>> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/10] dim: Autocheck for up-to-dateness

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> Exits script to annoy people roughly every 100th time ...

Annoyingly random, but we can improve this later.

LGTM.

> Also switch to the magic @{upstream} reference, in case the remote is
> not called origin (which is pretty normal in case of using git
> worktree).
>
> Signed-off-by: Daniel Vetter 
> ---
>  dim | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/dim b/dim
> index 57ad4fcf9767..192d6ee10838 100755
> --- a/dim
> +++ b/dim
> @@ -176,13 +176,17 @@ function dim_uptodate
>   exit 1
>   fi
>  
> - if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show 
> origin/maintainer-tools:dim |\
> + if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show 
> @{upstream}:dim |\
>   diff "$using" - >& /dev/null; then
>   echo "$dim: not running upstream version of the script." >&2
>   exit 1
>   fi
>  }
>  
> +if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then
> +dim_uptodate
> +fi
> +
>  # get message id from file
>  # $1 = file
>  message_get_id ()

-- 
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 01/10] dim: Extract TODO

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> Just maybe a bit more visibility, the scripts are growing.
>
> Signed-off-by: Daniel Vetter 

LGTM

> ---
>  TODO | 27 +++
>  dim  | 17 -
>  qf   | 11 ---
>  3 files changed, 27 insertions(+), 28 deletions(-)
>  create mode 100644 TODO
>
> diff --git a/TODO b/TODO
> new file mode 100644
> index ..ac0f27763dfa
> --- /dev/null
> +++ b/TODO
> @@ -0,0 +1,27 @@
> +dim:
> +- extract the integration tree logic and make it generally useful, maybe for 
> a
> +  drm-integration tree ...
> +- Improve nightly-forget to forget a specific merge instead of just the first
> +  dinq/dif merge.
> +- add option to check-patch to check stdin
> +- integrate ninja-check? Or too much checkers considered harmful?
> +  
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html
> +- add patchwork Link: also after manually resolving conflicts in drm
> +  apply-resolved
> +- pull in dim extract-tags tool from Ville
> +- allow dim rebuild-nightly to pull branches from local trees in dry-run 
> mode.
> +  This is useful to confirm a backmerge is indeed correct, by comparing the
> +  resulting -nightly with the old one. Current the branch must be pushed out
> +  first for rebuild-nightly to pick it up, which means the merge can't be
> +  fixed any more.
> +
> +qf:
> +- get better at preventing and cleaning up a mess when switching branches
> +  while there's still applied quilt patches around ...
> +- combine quilt annotate and git blame into one tool
> +- use the index a bit more to e.g. stage all applied quilt patches, then use
> +  the output of git diff to refresh a quilt patch
> +- use git commit-tree and git write-tree in the setup code instead of the
> +  current high-level hacks
> +- track/restore the topmost patch maybe?
> +- synchronize quilt notes in qf push and qf fetch
> diff --git a/dim b/dim
> index 5fb3a0fee7ff..57ad4fcf9767 100755
> --- a/dim
> +++ b/dim
> @@ -27,23 +27,6 @@
>  
>  # drm-intel-next maintainer script
>  
> -# TODO
> -# - extract the integration tree logic and make it generally useful, maybe 
> for a
> -#   drm-integration tree ...
> -# - Improve nightly-forget to forget a specific merge instead of just the 
> first
> -#   dinq/dif merge.
> -# - add option to check-patch to check stdin
> -# - integrate ninja-check? Or too much checkers considered harmful?
> -#   
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html
> -# - add patchwork Link: also after manually resolving conflicts in drm
> -#   apply-resolved
> -# - pull in dim extract-tags tool from Ville
> -# - allow dim rebuild-nightly to pull branches from local trees in dry-run 
> mode.
> -#   This is useful to confirm a backmerge is indeed correct, by comparing the
> -#   resulting -nightly with the old one. Current the branch must be pushed 
> out
> -#   first for rebuild-nightly to pick it up, which means the merge can't be
> -#   fixed any more.
> -
>  # fail on any goof-up
>  set -e
>  
> diff --git a/qf b/qf
> index 4e9cb03f31fe..31b9f3bae0a2 100755
> --- a/qf
> +++ b/qf
> @@ -26,17 +26,6 @@
>  
>  # quilt git flow script
>  
> -# TODO
> -# - get better at preventing and cleaning up a mess when switching branches
> -# while there's still applied quilt patches around ...
> -# - combine quilt annotate and git blame into one tool
> -# - use the index a bit more to e.g. stage all applied quilt patches, then 
> use
> -# the output of git diff to refresh a quilt patch
> -# - use git commit-tree and git write-tree in the setup code instead of the
> -# current high-level hacks
> -# - track/restore the topmost patch maybe?
> -# - synchronize quilt notes in qf push and qf fetch
> -
>  # config
>  QUILT_PREFIX=quilt/

-- 
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/10] dim: echoerr helper for printing to stderr

[Jani Nikula]

On Tue, 18 Oct 2016, Daniel Vetter  wrote:
> Signed-off-by: Daniel Vetter 
> ---
>  dim | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/dim b/dim
> index 192d6ee10838..2601bb7dbbad 100755
> --- a/dim
> +++ b/dim
> @@ -102,12 +102,17 @@ DRY=
>  FORCE=
>  HELP=
>  
> +function echoerr
> +{
> + echo "$@" >&2
> +}

I guess you could move the "$dim: " prefix here, to ensure all places
will have that. Can be a follow-up.

BR,
Jani.

> +
>  function warn_or_fail
>  {
>   if [[ $FORCE ]] ; then
> - echo WARNING: $1, but continuing
> + echoerr WARNING: $1, but continuing
>   else
> - echo ERROR: $1, aborting
> + echoerr ERROR: $1, aborting
>   exit 1
>   fi
>  }
> @@ -128,7 +133,7 @@ while getopts hdfi opt; do
>   HELP=1
>   ;;
>   *)
> - echo "See '$dim help' for more information." >&2
> + echoerr "See '$dim help' for more information."
>   exit
>   esac
>  done
> @@ -167,18 +172,18 @@ function dim_uptodate
>   local using="${BASH_SOURCE[0]}"
>  
>   if [[ ! -e "$using" ]]; then
> - echo "$dim: could not figure out the version being used 
> ($using)." >&2
> + echoerr "$dim: could not figure out the version being used 
> ($using)."
>   exit 1
>   fi
>  
>   if [[ ! -e "$DIM_PREFIX/maintainer-tools/.git" ]]; then
> - echo "$dim: could not find the upstream repo for $dim." >&2
> + echoerr "$dim: could not find the upstream repo for $dim."
>   exit 1
>   fi
>  
>   if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show 
> @{upstream}:dim |\
>   diff "$using" - >& /dev/null; then
> - echo "$dim: not running upstream version of the script." >&2
> + echoerr "$dim: not running upstream version of the script."
>   exit 1
>   fi
>  }
> @@ -1280,6 +1285,6 @@ subcmd_func=dim_${subcmd//-/_}
>  if declare -f $subcmd_func >/dev/null; then
>   $subcmd_func "$@"
>  else
> - echo "$dim: '$subcommand' is not a dim command." >&2
> + echoerr "$dim: '$subcommand' is not a dim command."
>   dim_usage
>  fi

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Bump object bookkeeping to u64 from size_t

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Bump object bookkeeping to u64 
from size_t
URL   : https://patchwork.freedesktop.org/series/13950/
State : failure

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-snb-2600)
dmesg-warn -> INCOMPLETE (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
fail   -> DMESG-FAIL (fi-ilk-650)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-bdw-5557u)
skip   -> PASS   (fi-kbl-7200u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:1   fail:4   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700hqtotal:76   pass:64   dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:76   pass:59   dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 failed to collect. IGT log at Patchwork_2744/fi-bsw-n3050/igt.log
fi-skl-6260u failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2744/

7cdf5d9e9e8e0e0fdf3034f949f72a6d64783f6c drm-intel-nightly: 
2016y-10m-18d-10h-27m-08s UTC integration manifest
f1998964 drm/i915: Restrict pagefault disabling to just around copy_from_user()
b6e81ed drm/i915: Limit the scattergather coalescing to 32bits
a0fbb36 drm/i915: Document our internal limit on object size
f50a6a7 drm/i915: Bump object bookkeeping to u64 from size_t

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

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

[Petri Latvala]

On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote:
> vgem doesn't have the same delayed close as i915. For vgem, closing the
> fd (i.e. on process exit) will first signal all fences and drop
> references for that fd, so effectively all work will be completed. The
> external references to the vgem.ko's object (via dma-buf) will only
> exist if they were constructed by the test and if they were, e.g. i915,
> they too should be will be flushed by igt in its exithandlers.
> 
> Other drivers may have similar bridges to cross ofc.
> -Chris

Ok, excellent.


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

Re: [Intel-gfx] [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags

[Jan Kara]

On Thu 13-10-16 01:20:14, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from get_user_pages_locked()
> and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
> explicit in callers as use of this flag can result in surprising behaviour 
> (and
> hence bugs) within the mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 
> ---
>  include/linux/mm.h |  2 +-
>  mm/frame_vector.c  |  8 +++-
>  mm/gup.c   | 12 +++-
>  mm/nommu.c |  5 -
>  4 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6adc4bc..27ab538 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned long 
> nr_pages,
>   int write, int force, struct page **pages,
>   struct vm_area_struct **vmas);
>  long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
> - int write, int force, struct page **pages, int *locked);
> + unsigned int gup_flags, struct page **pages, int *locked);

Hum, the prototype is inconsistent with e.g. __get_user_pages_unlocked()
where gup_flags come after **pages argument. Actually it makes more sense
to have it before **pages so that input arguments come first and output
arguments second but I don't care that much. But it definitely should be
consistent...

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/10] mm: replace get_user_pages_unlocked() write/force parameters with gup_flags

[Jan Kara]

On Thu 13-10-16 01:20:13, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from 
> get_user_pages_unlocked()
> and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
> explicit in callers as use of this flag can result in surprising behaviour 
> (and
> hence bugs) within the mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

[Chris Wilson]

On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote:
> How should vgem work be flushed properly? With this i915 flushing is
> guaranteed even if vgem is opened first, then i915, but such
> flushing won't be done if only vgem is opened (I see only vgem_slow
> doing that)...

vgem doesn't have the same delayed close as i915. For vgem, closing the
fd (i.e. on process exit) will first signal all fences and drop
references for that fd, so effectively all work will be completed. The
external references to the vgem.ko's object (via dma-buf) will only
exist if they were constructed by the test and if they were, e.g. i915,
they too should be will be flushed by igt in its exithandlers.

Other drivers may have similar bridges to cross ofc.
-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 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()

[Jan Kara]

On Thu 13-10-16 01:20:12, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from
> __get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers 
> as
> use of this flag can result in surprising behaviour (and hence bugs) within 
> the
> mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 

The patch looks good. You can add:

Reviewed-by: Jan Kara 

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: fix sparse warnings on undeclared symbols in crc debugfs

[Patchwork]

== Series Details ==

Series: drm: fix sparse warnings on undeclared symbols in crc debugfs
URL   : https://patchwork.freedesktop.org/series/13948/
State : failure

== Summary ==

Series 13948v1 drm: fix sparse warnings on undeclared symbols in crc debugfs
https://patchwork.freedesktop.org/api/1.0/series/13948/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-bdw-5557u)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-kbl-7200u)

fi-bdw-5557u total:208  pass:194  dwarn:0   dfail:0   fail:0   skip:13 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2743/

7cdf5d9e9e8e0e0fdf3034f949f72a6d64783f6c drm-intel-nightly: 
2016y-10m-18d-10h-27m-08s UTC integration manifest

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

Re: [Intel-gfx] [PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked()

[Jan Kara]

On Thu 13-10-16 01:20:11, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from 
> __get_user_pages_locked()
> to make the use of FOLL_FORCE explicit in callers as use of this flag can 
> result
> in surprising behaviour (and hence bugs) within the mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

[Petri Latvala]

On 10/18/2016 02:36 PM, Chris Wilson wrote:

On Tue, Oct 18, 2016 at 02:25:21PM +0300, Petri Latvala wrote:

If executed too soon after prime_vgem tests, the vgem unload test
fails due to its execbuffers still being handled in the kernel. Retry
the unload three times with sleeps before reporting a skip.

What happened to igt ensuring that the driver was idle before closing a
test? I guess that is complicated by the use of multiple drivers in
vgem.

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 40bbff6..5d3aaa8 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -344,14 +344,18 @@ int drm_open_driver(int chipset)
 fd = __drm_open_driver(chipset);
 igt_skip_on_f(fd<0, "No known gpu found\n");
  
-   if (__sync_fetch_and_add(_count, 1))

-   return fd;
-
+   /* For i915, at least, we ensure that the driver is idle before
+* starting a test and we install an exit handler to wait until
+* idle before quitting.
+*/
 if (is_i915_device(fd)) {
-   gem_quiescent_gpu(fd);
-   igt_install_exit_handler(quiescent_gpu_at_exit);
+   if (__sync_fetch_and_add(_count, 1) == 0) {
+   gem_quiescent_gpu(fd);
+
+   at_exit_drm_fd = __drm_open_driver(chipset);
+   igt_install_exit_handler(quiescent_gpu_at_exit);
+   }
 }
-   at_exit_drm_fd = __drm_open_driver(chipset);
  
 return fd;

  }



Well I'll be damned, that's an obvious bugfix, regardless of its effects 
on vgem unload. Please push that with a descriptive commit message and 
Reviewed-by: Petri Latvala .


How should vgem work be flushed properly? With this i915 flushing is 
guaranteed even if vgem is opened first, then i915, but such flushing 
won't be done if only vgem is opened (I see only vgem_slow doing that)...


Jari will soon reply about vgem unload with this change applied.


--
Petri Latvala

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: make is_lspcon_adaptor static

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm: make is_lspcon_adaptor static
URL   : https://patchwork.freedesktop.org/series/13944/
State : failure

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-ivb-3770)
Test gem_sync:
Subgroup basic-store-each:
pass   -> FAIL   (fi-ivb-3520m)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-bdw-5557u)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:1   skip:25 
fi-ivb-3770  total:76   pass:63   dwarn:0   dfail:0   fail:0   skip:12 
fi-kbl-7200u total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2742/

7cdf5d9e9e8e0e0fdf3034f949f72a6d64783f6c drm-intel-nightly: 
2016y-10m-18d-10h-27m-08s UTC integration manifest
84c7054 drm/i915: make lspcon_get_current_mode static
1eccec0 drm: make is_lspcon_adaptor static

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

[Intel-gfx] [PATCH 10/10] dim: s/drm-nightly/drm-tip

[Daniel Vetter]

tip = testing and integration pile

Also rename drm-intel-rerere directory to drm-rerere.

Signed-off-by: Daniel Vetter 
---
 dim| 48 
 dim.rst| 16 +++-
 dimrc.sample   |  2 +-
 drm-intel-flow.dot | 18 +-
 drm-intel.rst  | 20 +++-
 5 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/dim b/dim
index de01f0addeaf..fd3800e8c078 100755
--- a/dim
+++ b/dim
@@ -78,7 +78,7 @@ dim=$(basename $0)
 today=`date +%Y-%m-%d`
 
 drm_intel_ssh=ssh://git.freedesktop.org/git/drm-intel
-drm_nightly_ssh=ssh://git.freedesktop.org/git/drm-nightly
+drm_tip_ssh=ssh://git.freedesktop.org/git/drm-tip
 drm_intel_git=git://anongit.freedesktop.org/drm-intel
 drm_upstream_git=git://people.freedesktop.org/~airlied/linux
 
linux_upstream_git=git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
@@ -151,7 +151,7 @@ fi
 #
 
 if [ "$subcommand" != "setup" -a "$subcommand" != "help" -a "$subcommand" != 
"usage" ]; then
-   for d in $DIM_PREFIX $DIM_PREFIX/$DIM_DRM_INTEL 
$DIM_PREFIX/drm-intel-rerere $DIM_PREFIX/drm-intel-nightly; do
+   for d in $DIM_PREFIX $DIM_PREFIX/$DIM_DRM_INTEL $DIM_PREFIX/drm-rerere 
$DIM_PREFIX/drm-tip; do
if [ ! -d $d ]; then
echo "$d is missing, please check your configuration 
and/or run dim setup"
exit 1
@@ -162,7 +162,7 @@ if [ "$subcommand" != "setup" -a "$subcommand" != "help" -a 
"$subcommand" != "us
# Internal configuration that depends on a sane setup.
#
 
-   dim_branches=`(source $DIM_PREFIX/drm-intel-rerere/nightly.conf ; echo 
$nightly_branches) | \
+   dim_branches=`(source $DIM_PREFIX/drm-rerere/nightly.conf ; echo 
$nightly_branches) | \
xargs -n 1 echo | grep '^origin' | sed -e 's/^origin\///'`
 fi
 
@@ -244,7 +244,7 @@ function map_nightly_remote
 
 function update_linux_next
 {
-   cd $DIM_PREFIX/drm-intel-nightly
+   cd $DIM_PREFIX/drm-tip
 
local nightly_origin=`map_nightly_remote origin`
 
@@ -283,8 +283,8 @@ function check_conflicts
 
 function rr_cache_dir
 {
-   if [ -d $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ ] ; then
-   echo $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/
+   if [ -d $DIM_PREFIX/drm-tip/.git/rr-cache/ ] ; then
+   echo $DIM_PREFIX/drm-tip/.git/rr-cache/
else
echo $DIM_PREFIX/$DIM_DRM_INTEL/.git/rr-cache/
fi
@@ -292,7 +292,7 @@ function rr_cache_dir
 
 function update_rerere_cache
 {
-   cd $DIM_PREFIX/drm-intel-rerere/
+   cd $DIM_PREFIX/drm-rerere/
git pull
cp rr-cache/* `rr_cache-dir` -r
cd -
@@ -300,12 +300,12 @@ function update_rerere_cache
 
 function dim_rebuild_nightly
 {
-   local integration_branch=drm-intel-nightly
+   local integration_branch=drm-tip
local specfile=`mktemp`
local time="`date --utc +%Yy-%mm-%dd-%Hh-%Mm-%Ss` UTC"
local first=1
 
-   local rerere=$DIM_PREFIX/drm-intel-rerere
+   local rerere=$DIM_PREFIX/drm-rerere
 
cd $rerere
if [[ `git status --porcelain | grep -v "^[ ?][ ?]" | wc -l` -gt 0 ]]; 
then
@@ -512,7 +512,7 @@ function dim_apply_next_fixes
 
 function dim_cherry_pick
 {
-   local nightly_remote=`get_remote_name $drm_nightly_ssh`
+   local nightly_remote=`get_remote_name $drm_tip_ssh`
 
if [[ "x$1" = "x" ]]; then
echo "usage: $dim $subcommand commit-ish"
@@ -524,7 +524,7 @@ function dim_cherry_pick
# need latest -nightly
git fetch $nightly_remote
echo Possible fixup patches for your cherry-pick:
-   git log --grep=$sha_short --pretty=oneline 
$sha..$nightly_remote/drm-intel-nightly
+   git log --grep=$sha_short --pretty=oneline $sha..$nightly_remote/drm-tip
$DRY git cherry-pick -s -x -e $1
 }
 
@@ -649,7 +649,7 @@ function dim_create_branch
 
$DRY git branch $branch $start
git push $DRY_RUN $DIM_DRM_INTEL_REMOTE +$branch --set-upstream
-   cd $DIM_PREFIX/drm-intel-rerere
+   cd $DIM_PREFIX/drm-rerere
$DRY echo "nightly_branches=\"\$nightly_branches origin/$branch\"" \
 >> nightly.conf
$DRY git add nightly.conf
@@ -674,10 +674,10 @@ function dim_remove_branch
rm -R $DIM_PREFIX/$branch
fi
 
-   cd $DIM_PREFIX/drm-intel-nightly
+   cd $DIM_PREFIX/drm-tip
git push $DRY_RUN origin --delete $branch
$DRY git fetch origin --prune
-   cd $DIM_PREFIX/drm-intel-rerere
+   cd $DIM_PREFIX/drm-rerere
full_branch="origin/$branch"
$DRY sed -e "/${full_branch//\//\\\/}/d" -i nightly.conf
$DRY git add nightly.conf
@@ -893,17 +893,17 @@ function dim_for_each_workdirs
 
 function dim_update_next
 {
-   local nightly_remote=`get_remote_name $drm_nightly_ssh`
+   local nightly_remote=`get_remote_name 

[Intel-gfx] [PATCH 03/10] dim: echoerr helper for printing to stderr

[Daniel Vetter]

Signed-off-by: Daniel Vetter 
---
 dim | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/dim b/dim
index 192d6ee10838..2601bb7dbbad 100755
--- a/dim
+++ b/dim
@@ -102,12 +102,17 @@ DRY=
 FORCE=
 HELP=
 
+function echoerr
+{
+   echo "$@" >&2
+}
+
 function warn_or_fail
 {
if [[ $FORCE ]] ; then
-   echo WARNING: $1, but continuing
+   echoerr WARNING: $1, but continuing
else
-   echo ERROR: $1, aborting
+   echoerr ERROR: $1, aborting
exit 1
fi
 }
@@ -128,7 +133,7 @@ while getopts hdfi opt; do
HELP=1
;;
*)
-   echo "See '$dim help' for more information." >&2
+   echoerr "See '$dim help' for more information."
exit
esac
 done
@@ -167,18 +172,18 @@ function dim_uptodate
local using="${BASH_SOURCE[0]}"
 
if [[ ! -e "$using" ]]; then
-   echo "$dim: could not figure out the version being used 
($using)." >&2
+   echoerr "$dim: could not figure out the version being used 
($using)."
exit 1
fi
 
if [[ ! -e "$DIM_PREFIX/maintainer-tools/.git" ]]; then
-   echo "$dim: could not find the upstream repo for $dim." >&2
+   echoerr "$dim: could not find the upstream repo for $dim."
exit 1
fi
 
if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show 
@{upstream}:dim |\
diff "$using" - >& /dev/null; then
-   echo "$dim: not running upstream version of the script." >&2
+   echoerr "$dim: not running upstream version of the script."
exit 1
fi
 }
@@ -1280,6 +1285,6 @@ subcmd_func=dim_${subcmd//-/_}
 if declare -f $subcmd_func >/dev/null; then
$subcmd_func "$@"
 else
-   echo "$dim: '$subcommand' is not a dim command." >&2
+   echoerr "$dim: '$subcommand' is not a dim command."
dim_usage
 fi
-- 
2.9.3

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

[Intel-gfx] [PATCH 05/10] dim: support git worktree for aux checkouts

[Daniel Vetter]

If available by default. This saves quite a pile of disk-space that
imo making it the default is justified.

Note that this will break the rebuild-nightly script for now,
follow-up patches will fix that.

Signed-off-by: Daniel Vetter 
---
 dim | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/dim b/dim
index 90eb553c6575..80baf24e4ad7 100755
--- a/dim
+++ b/dim
@@ -1072,15 +1072,24 @@ function setup_aux_checkout # name remote
echo "Setting up $dir ..."
 
if [ ! -d $dir ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$remote_url $dir
-   cd $dir
-   git config remote.origin.url $remote_url
-   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
-   git repack -a -d -l
-   remote=origin
+   if git help worktree &> /dev/null ; then
+   cd $DIM_PREFIX/$DIM_DRM_INTEL
+   remote=`get_remote_name $remote_url`
+   if ! git branch | grep $name > /dev/null ; then
+   git branch --track $name $remote/$name
+   fi
+   git worktree add ../$dir $name
+   else
+   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$remote_url $dir
+   cd $dir
+   git config remote.origin.url $remote_url
+   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
+   git repack -a -d -l
+   remote=origin
+   fi
else
cd $dir
-   remote=`get_remote_name $drm_intel_ssh`
+   remote=`get_remote_name $remote_url`
fi
if ! git branch | grep $name > /dev/null ; then
git checkout -t $remote/$name
-- 
2.9.3

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

[Intel-gfx] [PATCH 07/10] dim: autodetect branches in rebuild-nightly

[Daniel Vetter]

Needs new url-mapping information in nightly.conf to work properly.

Signed-off-by: Daniel Vetter 
---
 dim | 48 
 1 file changed, 36 insertions(+), 12 deletions(-)

diff --git a/dim b/dim
index 48d5e7b6477a..f9b28d5fd241 100755
--- a/dim
+++ b/dim
@@ -235,20 +235,30 @@ function dim_commit_add_tag
done
 }
 
+function map_nightly_remote
+{
+   local nightly_remote=$1
+   local remote_url=`eval echo 
"\\\$nightly_remote_url_${nightly_remote/-/_}"`
+
+   get_remote_name $remote_url
+}
+
 function update_linux_next
 {
cd $DIM_PREFIX/drm-intel-nightly
 
+   local nightly_origin=`map_nightly_remote origin`
+
# always update drm-intel-fixes
echo -n "Pushing drm-intel-fixes to for-linux-next-fixes... "
-   git push $DRY_RUN origin +origin/drm-intel-fixes:for-linux-next-fixes 
>& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-fixes:for-linux-next-fixes >& /dev/null
echo "Done."
 
-   if git merge-base --is-ancestor origin/drm-intel-next-fixes 
origin/drm-intel-fixes ; then
+   if git merge-base --is-ancestor $nightly_origin/drm-intel-next-fixes 
$nightly_origin/drm-intel-fixes ; then
# -fixes has caught up to dinf, i.e. we're out of the merge
# window. Push the next queue.
echo -n "Out of merge window. Pushing drm-intel-next-queued to 
for-linux-next... "
-   git push $DRY_RUN origin 
+origin/drm-intel-next-queued:for-linux-next >& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-next-queued:for-linux-next >& /dev/null
echo "Done."
else
# dinf is ahead of -fixes, i.e. drm-next has already closed for
@@ -256,7 +266,7 @@ function update_linux_next
# for the current -next cycle. Push dinf
 
echo -n "Pushing drm-intel-next-fixes to for-linux-next... "
-   git push $DRY_RUN origin 
+origin/drm-intel-next-fixes:for-linux-next >& /dev/null
+   git push $DRY_RUN $nightly_origin 
+$nightly_origin/drm-intel-next-fixes:for-linux-next >& /dev/null
echo "Done."
fi
 }
@@ -272,11 +282,20 @@ function check_conflicts
true
 }
 
+function rr_cache_dir
+{
+   if [ -d $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ ] ; then
+   echo $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/
+   else
+   echo $DIM_PREFIX/$DIM_DRM_INTEL/.git/rr-cache/
+   fi
+}
+
 function update_rerere_cache
 {
cd $DIM_PREFIX/drm-intel-rerere/
git pull
-   cp rr-cache/* $DIM_PREFIX/drm-intel-nightly/.git/rr-cache/ -r
+   cp rr-cache/* `rr_cache-dir` -r
cd -
 }
 
@@ -307,9 +326,10 @@ function dim_rebuild_nightly
fi
 
for remote in $(echo $nightly_branches | tr " " "\n" | sed 's|/.*$||g' 
| sort -u); do
-   echo -n "Fetching $remote... "
+   local nightly_remote=`map_nightly_remote $remote`
+   echo -n "Fetching $remote (as $nightly_remote) ... "
# git fetch returns 128 if there's nothing to be fetched
-   git fetch $remote >& /dev/null || true
+   git fetch $nightly_remote >& /dev/null || true
echo "Done."
done
 
@@ -329,12 +349,14 @@ function dim_rebuild_nightly
if [[ -n $sha1 ]] ; then
echo -n "Using override sha1: $sha1... "
else
-   sha1=$branch
+   local remote=${branch%%/*}
+   local nightly_remote=`map_nightly_remote $remote`
+   sha1=`echo $branch | sed -e s/^$remote/$nightly_remote/`
fi
 
if [ $first == 1 ] ; then
+   git reset --hard $sha1 &> /dev/null
echo "Reset. Done."
-   git reset --hard $sha1 >& /dev/null
first=0
elif git merge --rerere-autoupdate --ff-only $sha1 >& /dev/null 
; then
# nothing to do if just fast-forward
@@ -370,14 +392,16 @@ function dim_rebuild_nightly
git commit --quiet -m "$integration_branch: $time integration manifest"
echo "Done."
 
+   local nightly_origin=`map_nightly_remote origin`
+
echo -n "Pushing $integration_branch... "
-   git push $DRY_RUN origin +HEAD >& /dev/null && echo "Done."
+   git push $DRY_RUN $nightly_origin +HEAD >& /dev/null && echo "Done."
 
echo -n "Updating rerere cache... "
cd $rerere
if git branch | grep rerere-cache | grep '\*' >& /dev/null ; then
git pull >& /dev/null
-   cp $DIM_PREFIX/$integration_branch/.git/rr-cache/* rr-cache -r
+   cp `rr_cache_dir` rr-cache -r
git add *.patch >& /dev/null || true
git 

[Intel-gfx] [PATCH 01/10] dim: Extract TODO

[Daniel Vetter]

Just maybe a bit more visibility, the scripts are growing.

Signed-off-by: Daniel Vetter 
---
 TODO | 27 +++
 dim  | 17 -
 qf   | 11 ---
 3 files changed, 27 insertions(+), 28 deletions(-)
 create mode 100644 TODO

diff --git a/TODO b/TODO
new file mode 100644
index ..ac0f27763dfa
--- /dev/null
+++ b/TODO
@@ -0,0 +1,27 @@
+dim:
+- extract the integration tree logic and make it generally useful, maybe for a
+  drm-integration tree ...
+- Improve nightly-forget to forget a specific merge instead of just the first
+  dinq/dif merge.
+- add option to check-patch to check stdin
+- integrate ninja-check? Or too much checkers considered harmful?
+  
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html
+- add patchwork Link: also after manually resolving conflicts in drm
+  apply-resolved
+- pull in dim extract-tags tool from Ville
+- allow dim rebuild-nightly to pull branches from local trees in dry-run mode.
+  This is useful to confirm a backmerge is indeed correct, by comparing the
+  resulting -nightly with the old one. Current the branch must be pushed out
+  first for rebuild-nightly to pick it up, which means the merge can't be
+  fixed any more.
+
+qf:
+- get better at preventing and cleaning up a mess when switching branches
+  while there's still applied quilt patches around ...
+- combine quilt annotate and git blame into one tool
+- use the index a bit more to e.g. stage all applied quilt patches, then use
+  the output of git diff to refresh a quilt patch
+- use git commit-tree and git write-tree in the setup code instead of the
+  current high-level hacks
+- track/restore the topmost patch maybe?
+- synchronize quilt notes in qf push and qf fetch
diff --git a/dim b/dim
index 5fb3a0fee7ff..57ad4fcf9767 100755
--- a/dim
+++ b/dim
@@ -27,23 +27,6 @@
 
 # drm-intel-next maintainer script
 
-# TODO
-# - extract the integration tree logic and make it generally useful, maybe for 
a
-#   drm-integration tree ...
-# - Improve nightly-forget to forget a specific merge instead of just the first
-#   dinq/dif merge.
-# - add option to check-patch to check stdin
-# - integrate ninja-check? Or too much checkers considered harmful?
-#   
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html
-# - add patchwork Link: also after manually resolving conflicts in drm
-#   apply-resolved
-# - pull in dim extract-tags tool from Ville
-# - allow dim rebuild-nightly to pull branches from local trees in dry-run 
mode.
-#   This is useful to confirm a backmerge is indeed correct, by comparing the
-#   resulting -nightly with the old one. Current the branch must be pushed out
-#   first for rebuild-nightly to pick it up, which means the merge can't be
-#   fixed any more.
-
 # fail on any goof-up
 set -e
 
diff --git a/qf b/qf
index 4e9cb03f31fe..31b9f3bae0a2 100755
--- a/qf
+++ b/qf
@@ -26,17 +26,6 @@
 
 # quilt git flow script
 
-# TODO
-# - get better at preventing and cleaning up a mess when switching branches
-# while there's still applied quilt patches around ...
-# - combine quilt annotate and git blame into one tool
-# - use the index a bit more to e.g. stage all applied quilt patches, then use
-# the output of git diff to refresh a quilt patch
-# - use git commit-tree and git write-tree in the setup code instead of the
-# current high-level hacks
-# - track/restore the topmost patch maybe?
-# - synchronize quilt notes in qf push and qf fetch
-
 # config
 QUILT_PREFIX=quilt/
 
-- 
2.9.3

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

[Intel-gfx] [PATCH 08/10] dim: remove integration-tree remotes

[Daniel Vetter]

With the remotes stored in nightly.conf and git worktrees we can avoid
hard-coding them in even more places.

Signed-off-by: Daniel Vetter 
---
 dim | 12 
 1 file changed, 12 deletions(-)

diff --git a/dim b/dim
index f9b28d5fd241..20a3143a5c1e 100755
--- a/dim
+++ b/dim
@@ -80,8 +80,6 @@ today=`date +%Y-%m-%d`
 drm_intel_ssh=ssh://git.freedesktop.org/git/drm-intel
 drm_intel_git=git://anongit.freedesktop.org/drm-intel
 drm_upstream_git=git://people.freedesktop.org/~airlied/linux
-sound_upstream_git=git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
-driver_core_upstream_git=git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
 
linux_upstream_git=git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 # email aliases
@@ -1151,16 +1149,6 @@ function dim_setup
else
remote=`get_remote_name $drm_upstream_git`
fi
-   if git remote | grep sound-upstream > /dev/null ; then
-   git config remote.sound-upstream.url $sound_upstream_git
-   else
-   remote=`get_remote_name $sound_upstream_git`
-   fi
-   if git remote | grep driver-core-upstream > /dev/null ; then
-   git config remote.driver-core-upstream.url 
$driver_core_upstream_git
-   else
-   remote=`get_remote_name $driver_core_upstream_git`
-   fi
 
echo "dim setup successfully completed!"
 }
-- 
2.9.3

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

[Intel-gfx] [PATCH 06/10] dim: Nuke nightly-forget

[Daniel Vetter]

With our proliferation of branches it's become long useless. Nowadays
my MO is to revert the offending commit in the rerere-cache branch
explicitly, remove drm-intel-nightly/.git/rr-cache and then re-run
rebuild-nightly. That works much better, hence nuke this helper.

Signed-off-by: Daniel Vetter 
---
 TODO | 2 --
 dim  | 9 -
 2 files changed, 11 deletions(-)

diff --git a/TODO b/TODO
index ac0f27763dfa..c1c6e20eb0e3 100644
--- a/TODO
+++ b/TODO
@@ -1,8 +1,6 @@
 dim:
 - extract the integration tree logic and make it generally useful, maybe for a
   drm-integration tree ...
-- Improve nightly-forget to forget a specific merge instead of just the first
-  dinq/dif merge.
 - add option to check-patch to check stdin
 - integrate ninja-check? Or too much checkers considered harmful?
   
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000554.html
diff --git a/dim b/dim
index 80baf24e4ad7..48d5e7b6477a 100755
--- a/dim
+++ b/dim
@@ -395,15 +395,6 @@ function dim_rebuild_nightly
update_linux_next
 }
 
-function dim_nightly_forget
-{
-   cd $DIM_PREFIX/drm-intel-nightly
-   git fetch origin >& /dev/null
-   git reset --hard origin/drm-intel-next-queued >& /dev/null
-   git merge origin/drm-intel-fixes
-   git rerere forget
-}
-
 # push branch $1, rebuild nightly. the rest of the arguments are passed to git
 # push.
 function dim_push_branch
-- 
2.9.3

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

[Intel-gfx] [PATCH 02/10] dim: Autocheck for up-to-dateness

[Daniel Vetter]

Exits script to annoy people roughly every 100th time ...

Also switch to the magic @{upstream} reference, in case the remote is
not called origin (which is pretty normal in case of using git
worktree).

Signed-off-by: Daniel Vetter 
---
 dim | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index 57ad4fcf9767..192d6ee10838 100755
--- a/dim
+++ b/dim
@@ -176,13 +176,17 @@ function dim_uptodate
exit 1
fi
 
-   if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show 
origin/maintainer-tools:dim |\
+   if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show 
@{upstream}:dim |\
diff "$using" - >& /dev/null; then
echo "$dim: not running upstream version of the script." >&2
exit 1
fi
 }
 
+if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then
+dim_uptodate
+fi
+
 # get message id from file
 # $1 = file
 message_get_id ()
-- 
2.9.3

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

[Intel-gfx] [PATCH 04/10] dim: autodetect remotes, first part for dim_setup

[Daniel Vetter]

The goals here are multiple:
- simpler configuration through autodetection
- allows seamless upgrading to git worktree for the aux checkouts
- eventually I want to split up drm-misc into a separate remote ...

And yes this is just a start.

v2: Print errors to stderr, otherwise they can't be seen when directly
assigning the result of get_remote_name to a variable.

Signed-off-by: Daniel Vetter 
---
 dim | 112 +++-
 1 file changed, 58 insertions(+), 54 deletions(-)

diff --git a/dim b/dim
index 2601bb7dbbad..90eb553c6575 100755
--- a/dim
+++ b/dim
@@ -192,6 +192,24 @@ if [[ "$((`date +%s` % 100))" -eq "0" ]] ; then
 dim_uptodate
 fi
 
+function get_remote_name
+{
+   local remote_url=$1
+
+   local remote=`git remote -v | grep $remote_url | \
+   head -n1 | sed -e 's/^\(.*\)\t.*/\1/'`
+
+   if [[ $remote == "" ]] ; then
+   echoerr No git remote for $remote_url found in `pwd`.
+   echoerr Please set it up using
+   echoerr $ git remote add '' $remote_url
+   echoerr with a name of your choice.
+   exit 1
+   fi
+
+   echo $remote
+}
+
 # get message id from file
 # $1 = file
 message_get_id ()
@@ -1044,8 +1062,36 @@ function dim_update_branches
update_rerere_cache
 }
 
+function setup_aux_checkout # name remote
+{
+   local name=$1
+   local remote_url=$2
+   local dir=$3
+   local remote
+
+   echo "Setting up $dir ..."
+
+   if [ ! -d $dir ]; then
+   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$remote_url $dir
+   cd $dir
+   git config remote.origin.url $remote_url
+   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
+   git repack -a -d -l
+   remote=origin
+   else
+   cd $dir
+   remote=`get_remote_name $drm_intel_ssh`
+   fi
+   if ! git branch | grep $name > /dev/null ; then
+   git checkout -t $remote/$name
+   fi
+   cd ..
+}
+
 function dim_setup
 {
+   local remote
+
if [ ! -d $DIM_PREFIX ]; then
echo "please set up your repository directory with:"
echo "mkdir -p $DIM_PREFIX"
@@ -1062,76 +1108,34 @@ function dim_setup
exit 1
fi
cd $DIM_DRM_INTEL
-   if ! git remote -v | grep "^origin[[:space:]]" | grep 
$linux_upstream_git > /dev/null; then
-   echo "please set up remote origin for $linux_upstream_git"
-   exit 1
-   fi
-   if ! git remote -v | grep "^$DIM_DRM_INTEL_REMOTE[[:space:]]" | grep 
$drm_intel_ssh > /dev/null; then
-   echo "please set up remote $DIM_DRM_INTEL_REMOTE for 
$drm_intel_ssh with:"
-   echo "git remote add $DIM_DRM_INTEL_REMOTE $drm_intel_ssh"
-   echo "or update your configuration."
-   exit 1
-   fi
-   if ! git remote -v | grep "^$DIM_DRM_UPSTREAM_REMOTE[[:space:]]" | grep 
$drm_upstream_git > /dev/null; then
-   echo "please set up remote $DIM_DRM_UPSTREAM_REMOTE for 
$drm_upstream_git with:"
-   echo "git remote add $DIM_DRM_UPSTREAM_REMOTE 
$drm_upstream_git"
-   echo "or update your configuration."
-   exit 1
-   fi
-   cd ..
 
-   echo "Setting up maintainer-tools ..."
-   if [ ! -d maintainer-tools ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$drm_intel_ssh maintainer-tools
-   fi
-   cd maintainer-tools
-   git config remote.origin.url $drm_intel_ssh
-   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
-   git repack -a -d -l
-   if ! git branch | grep maintainer-tools > /dev/null ; then
-   git checkout -t origin/maintainer-tools
-   fi
-   cd ..
+   # check remote configuration
+   remote=`get_remote_name $linux_upstream_git`
+   remote=`get_remote_name $drm_intel_ssh`
+   remote=`get_remote_name $drm_upstream_git`
 
-   echo "Setting up drm-intel-rerere ..."
-   if [ ! -d drm-intel-rerere ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$drm_intel_ssh drm-intel-rerere
-   fi
-   cd drm-intel-rerere
-   git config remote.origin.url $drm_intel_ssh
-   echo "$DIM_PREFIX/$DIM_DRM_INTEL/.git/objects" > 
.git/objects/info/alternates
-   git repack -a -d -l
-   if ! git branch | grep rerere-cache > /dev/null ; then
-   git checkout -t origin/rerere-cache
-   fi
cd ..
 
-   echo "Setting up drm-intel-nightly ..."
-   if [ ! -d drm-intel-nightly ]; then
-   git clone --reference=$DIM_PREFIX/$DIM_DRM_INTEL/.git 
$drm_intel_ssh drm-intel-nightly
-   fi
+   setup_aux_checkout maintainer-tools $drm_intel_ssh 

[Intel-gfx] [PATCH 09/10] dim: Split out drm-nightly.git

[Daniel Vetter]

This is a prep step to eventually split out the drm-misc branches all
into their own repo. To get there we first need to split out the
integration tree mangling.

Since dim doesn't auto-update and since the transition is a good
reason to switch over to worktrees and it's tricky it's not scripted.
The following needs to be done when dim rebuild-nightly fails:

- Make sure you have the latest dim version.

- Good to also check you have a recent-ish git. Latest dim supports
  git worktree to save on disk space needed for .git metadata. It's
  much more robust than the git alternates storage trick we've used
  thus far. Note that git worktree is still optional (but that's not a
  recommended setup).

- Delete $DIM_PREFIX/{drm-intel-rerere,drm-intel-nightly,maintainer-tools}
  It's not strictly needed to kill the maintainer-tools checkout too,
  but might as well switch it over to git worktree too.

- Make sure you don't have any branches left over for drm-intel-rerere
  and drm-intel-nightly anywhere (since they need to switch their
  remotes).

- run dim setup and enjoy the new awesomeness.

If it breaks, I'm guilty ;-)

Signed-off-by: Daniel Vetter 
---
 dim | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/dim b/dim
index 20a3143a5c1e..de01f0addeaf 100755
--- a/dim
+++ b/dim
@@ -78,6 +78,7 @@ dim=$(basename $0)
 today=`date +%Y-%m-%d`
 
 drm_intel_ssh=ssh://git.freedesktop.org/git/drm-intel
+drm_nightly_ssh=ssh://git.freedesktop.org/git/drm-nightly
 drm_intel_git=git://anongit.freedesktop.org/drm-intel
 drm_upstream_git=git://people.freedesktop.org/~airlied/linux
 
linux_upstream_git=git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
@@ -511,6 +512,8 @@ function dim_apply_next_fixes
 
 function dim_cherry_pick
 {
+   local nightly_remote=`get_remote_name $drm_nightly_ssh`
+
if [[ "x$1" = "x" ]]; then
echo "usage: $dim $subcommand commit-ish"
exit 1
@@ -519,9 +522,9 @@ function dim_cherry_pick
sha_short=${sha:0:8}
 
# need latest -nightly
-   git fetch $DIM_DRM_INTEL_REMOTE
+   git fetch $nightly_remote
echo Possible fixup patches for your cherry-pick:
-   git log --grep=$sha_short --pretty=oneline 
$sha..$DIM_DRM_INTEL_REMOTE/drm-intel-nightly
+   git log --grep=$sha_short --pretty=oneline 
$sha..$nightly_remote/drm-intel-nightly
$DRY git cherry-pick -s -x -e $1
 }
 
@@ -890,15 +893,17 @@ function dim_for_each_workdirs
 
 function dim_update_next
 {
+   local nightly_remote=`get_remote_name $drm_nightly_ssh`
+
assert_branch drm-intel-next-queued
 
git pull --ff-only
 
-   if ! git branch --merged $DIM_DRM_INTEL_REMOTE/drm-intel-nightly | grep 
drm-intel-fixes &> /dev/null ; then
+   if ! git branch --merged $nightly_remote/drm-intel-nightly | grep 
drm-intel-fixes &> /dev/null ; then
echo "drm-intel-fixes not merged into -nigthly, please update!"
exit 2
fi
-   if ! git branch --merged $DIM_DRM_INTEL_REMOTE/drm-intel-nightly | grep 
drm-intel-next-queued &> /dev/null ; then
+   if ! git branch --merged $nightly_remote/drm-intel-nightly | grep 
drm-intel-next-queued &> /dev/null ; then
echo "drm-intel-next-queued not merged into -nigthly, please 
update!"
exit 2
fi
@@ -920,6 +925,8 @@ function dim_update_next
 
 function dim_update_next_continue
 {
+   local nightly_remote=`get_remote_name $drm_nightly_ssh`
+
assert_branch drm-intel-next-queued
 
git push $DRY_RUN -f $DIM_DRM_INTEL_REMOTE 
drm-intel-next-queued:drm-intel-next
@@ -928,7 +935,7 @@ function dim_update_next_continue
git push $DRY_RUN -f $DIM_DRM_INTEL_REMOTE $tag
 
echo "Updating -testing to latest -nightly"
-   git push $DRY_RUN $DIM_DRM_INTEL_REMOTE 
+$DIM_DRM_INTEL_REMOTE/drm-intel-nightly:drm-intel-testing
+   git push $DRY_RUN $DIM_DRM_INTEL_REMOTE 
+$nightly_remote/drm-intel-nightly:drm-intel-testing
$DRY git tag -f drm-intel-testing-$today 
$DIM_DRM_INTEL_REMOTE/drm-intel-testing
$DRY git push -f $DIM_DRM_INTEL_REMOTE drm-intel-testing-$today
 
@@ -1134,15 +1141,16 @@ function dim_setup
# check remote configuration
remote=`get_remote_name $linux_upstream_git`
remote=`get_remote_name $drm_intel_ssh`
+   remote=`get_remote_name $drm_nightly_ssh`
remote=`get_remote_name $drm_upstream_git`
 
cd ..
 
setup_aux_checkout maintainer-tools $drm_intel_ssh maintainer-tools
 
-   setup_aux_checkout rerere-cache $drm_intel_ssh drm-intel-rerere
+   setup_aux_checkout rerere-cache $drm_nightly_ssh drm-intel-rerere
 
-   setup_aux_checkout drm-intel-nightly $drm_intel_ssh drm-intel-nightly
+   setup_aux_checkout drm-intel-nightly $drm_nightly_ssh drm-intel-nightly
cd drm-intel-nightly
if git remote | grep drm-upstream > /dev/null 

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

[Mika Kuoppala]

Arkadiusz Hiler  writes:

> Dropping WA because it was for early steppings.
>
> It is fixed in newer preproduction and all production revisions.
>

We have used References tag to point to a relevant document
that has more information. Like for this, it should be:

References: HSD#2126385

From there I did figure out that this should be from skl:C0 onwards.

So based on that, we need this wa still.

-Mika


> Cc: Michal Winiarski 
> Signed-off-by: Arkadiusz Hiler 
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index e107455..32786ba 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -849,10 +849,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *engine)
>*/
>   }
>  
> - /* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt,kbl */
>   /* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt,kbl */
>   WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
> -   GEN9_ENABLE_YV12_BUGFIX |
> GEN9_ENABLE_GPGPU_PREEMPTION);
>  
>   /* Wa4x4STCOptimizationDisable:skl,bxt,kbl */
> -- 
> 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 v4 2/2] drm/i915: Make GPU pages movable

[Joonas Lahtinen]

On ma, 2016-04-04 at 14:18 +0100, Chris Wilson wrote:
> From: Akash Goel 
> 
> On a long run of more than 2-3 days, physical memory tends to get
> fragmented severely, which considerably slows down the system. In such a
> scenario, the shrinker is also unable to help as lack of memory is not
> the actual problem, since it has been observed that there are enough free
> pages of 0 order. This also manifests itself when an indiviual zone in
> the mm runs out of pages and if we cannot migrate pages between zones,
> the kernel hits an out-of-memory even though there are free pages (and
> often all of swap) available.
> 
> To address the issue of external fragementation, kernel does a compaction
> (which involves migration of pages) but it's efficacy depends upon how
> many pages are marked as MOVABLE, as only those pages can be migrated.
> 
> Currently the backing pages for GFX buffers are allocated from shmemfs
> with GFP_RECLAIMABLE flag, in units of 4KB pages.  In the case of limited
> swap space, it may not be possible always to reclaim or swap-out pages of
> all the inactive objects, to make way for free space allowing formation
> of higher order groups of physically-contiguous pages on compaction.
> 
> Just marking the GPU pages as MOVABLE will not suffice, as i915.ko has to
> pin the pages if they are in use by GPU, which will prevent their
> migration. So the migratepage callback in shmem is also hooked up to get
> a notification when kernel initiates the page migration. On the
> notification, i915.ko appropriately unpin the pages.  With this we can
> effectively mark the GPU pages as MOVABLE and hence mitigate the
> fragmentation problem.
> 
> v2:
>  - Rename the migration routine to gem_shrink_migratepage, move it to the
>    shrinker file, and use the existing constructs (Chris)
>  - To cleanup, add a new helper function to encapsulate all page migration
>    skip conditions (Chris)
>  - Add a new local helper function in shrinker file, for dropping the
>    backing pages, and call the same from gem_shrink() also (Chris)
> 
> v3:
>  - Fix/invert the check on the return value of unsafe_drop_pages (Chris)
> 
> v4:
>  - Minor tidy
> 
> Testcase: igt/gem_shrink
> Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
> Cc: Hugh Dickins 
> Cc: linux...@kvack.org
> Signed-off-by: Sourab Gupta 
> Signed-off-by: Akash Goel 
> Reviewed-by: Chris Wilson 

Could this patch be re-spinned on top of current nightly?

After removing;

> WARN(page_count(newpage) != 1, "Unexpected ref count for newpage\n")

and

>   if (ret)
>   DRM_DEBUG_DRIVER("page=%p migration returned %d\n", page, ret);

This is;

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

[Intel-gfx] [CI 3/4] drm/i915: Limit the scattergather coalescing to 32bits

[Chris Wilson]

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

v2: Also we should use unsigned int to match sg->length.

Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size")
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e13c9a6f484..8ed8e24025ac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2205,7 +2205,7 @@ i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
return 0;
 }
 
-static unsigned long swiotlb_max_size(void)
+static unsigned int swiotlb_max_size(void)
 {
 #if IS_ENABLED(CONFIG_SWIOTLB)
return rounddown(swiotlb_nr_tbl() << IO_TLB_SHIFT, PAGE_SIZE);
@@ -2225,7 +2225,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
struct sgt_iter sgt_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
-   unsigned long max_segment;
+   unsigned int max_segment;
int ret;
gfp_t gfp;
 
@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 
max_segment = swiotlb_max_size();
if (!max_segment)
-   max_segment = obj->base.size;
+   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (st == NULL)
-- 
2.9.3

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

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

[Chris Wilson]

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

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cabcd06c84bd..33c44c631bab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3107,7 +3107,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
*obj);
 void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
 struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size);
+  u64 size);
 struct drm_i915_gem_object *i915_gem_object_create_from_data(
struct drm_device *dev, const void *data, size_t size);
 void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 723a4b0b7f63..0e13c9a6f484 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4131,14 +4131,29 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
 };
 
-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size)
+/* Note we don't consider signbits :| */
+#define overflows_type(x, T) \
+   (sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
+
+struct drm_i915_gem_object *
+i915_gem_object_create(struct drm_device *dev, u64 size)
 {
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
int ret;
 
+   /* There is a prevalence of the assumption that we fit the object's
+* page count inside a 32bit _signed_ variable. Let's document this and
+* catch if we ever need to fix it. In the meantime, if you do spot
+* such a local variable, please consider fixing!
+*/
+   if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
+   return ERR_PTR(-E2BIG);
+
+   if (overflows_type(size, obj->base.size))
+   return ERR_PTR(-E2BIG);
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
return ERR_PTR(-ENOMEM);
-- 
2.9.3

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

[Intel-gfx] [CI 4/4] drm/i915: Restrict pagefault disabling to just around copy_from_user()

[Chris Wilson]

When handling execbuf relocations, we play a delicate dance with
pagefault. We first try to access the user pages underneath our
struct_mutex. However, if those pages were inside a GEM object, we may
trigger a pagefault and deadlock as i915_gem_fault() tries to
recursively acquire struct_mutex. Instead, we choose to disable
pagefaulting around the copy_from_user whilst inside the struct_mutex
and handle the EFAULT by falling back to a copy outside the
struct_mutex.

We however presumed that disabling pagefaults would be expensive. It is
just an operation on the local current task. Cheap enough that we can
restrict the disable/enable to the critical section around the copy, and
so avoid having to handle the atomic sections within the relocation
handling itself.

v2: Just illustrate the broken error handling rather than argue why it
is safer to ignore it, for now.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 71 +++---
 1 file changed, 35 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 204536a3087e..e52affdcc125 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -551,20 +551,6 @@ relocate_entry(struct drm_i915_gem_object *obj,
return 0;
 }
 
-static bool object_is_idle(struct drm_i915_gem_object *obj)
-{
-   unsigned long active = i915_gem_object_get_active(obj);
-   int idx;
-
-   for_each_active(active, idx) {
-   if (!i915_gem_active_is_idle(>last_read[idx],
->base.dev->struct_mutex))
-   return false;
-   }
-
-   return true;
-}
-
 static int
 i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
   struct eb_vmas *eb,
@@ -648,10 +634,6 @@ i915_gem_execbuffer_relocate_entry(struct 
drm_i915_gem_object *obj,
return -EINVAL;
}
 
-   /* We can't wait for rendering with pagefaults disabled */
-   if (pagefault_disabled() && !object_is_idle(obj))
-   return -EFAULT;
-
ret = relocate_entry(obj, reloc, cache, target_offset);
if (ret)
return ret;
@@ -678,12 +660,23 @@ i915_gem_execbuffer_relocate_vma(struct i915_vma *vma,
remain = entry->relocation_count;
while (remain) {
struct drm_i915_gem_relocation_entry *r = stack_reloc;
-   int count = remain;
-   if (count > ARRAY_SIZE(stack_reloc))
-   count = ARRAY_SIZE(stack_reloc);
+   unsigned long unwritten;
+   unsigned int count;
+
+   count = min_t(unsigned int, remain, ARRAY_SIZE(stack_reloc));
remain -= count;
 
-   if (__copy_from_user_inatomic(r, user_relocs, 
count*sizeof(r[0]))) {
+   /* This is the fast path and we cannot handle a pagefault
+* whilst holding the struct mutex lest the user pass in the
+* relocations contained within a mmaped bo. For in such a case
+* we, the page fault handler would call i915_gem_fault() and
+* we would try to acquire the struct mutex again. Obviously
+* this is bad and so lockdep complains vehemently.
+*/
+   pagefault_disable();
+   unwritten = __copy_from_user_inatomic(r, user_relocs, 
count*sizeof(r[0]));
+   pagefault_enable();
+   if (unlikely(unwritten)) {
ret = -EFAULT;
goto out;
}
@@ -695,11 +688,26 @@ i915_gem_execbuffer_relocate_vma(struct i915_vma *vma,
if (ret)
goto out;
 
-   if (r->presumed_offset != offset &&
-   __put_user(r->presumed_offset,
-  _relocs->presumed_offset)) {
-   ret = -EFAULT;
-   goto out;
+   if (r->presumed_offset != offset) {
+   pagefault_disable();
+   unwritten = __put_user(r->presumed_offset,
+  
_relocs->presumed_offset);
+   pagefault_enable();
+   if (unlikely(unwritten)) {
+   /* Note that reporting an error now
+* leaves everything in an inconsistent
+* state as we have *already* changed
+* the 

[Intel-gfx] [CI 1/4] drm/i915: Bump object bookkeeping to u64 from size_t

[Chris Wilson]

Internally we allow for using more objects than a single process can
allocate, i.e. we allow for a 64bit GPU address space even on a 32bit
system. Using size_t may oveerflow.

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7a41bb9aca6e..20638d22bbad 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -392,7 +392,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
if (ret)
return ret;
 
-   seq_printf(m, "%u objects, %zu bytes\n",
+   seq_printf(m, "%u objects, %llu bytes\n",
   dev_priv->mm.object_count,
   dev_priv->mm.object_memory);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8a1020f6c9cc..cabcd06c84bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1389,7 +1389,7 @@ struct i915_gem_mm {
 
/* accounting, useful for userland debugging */
spinlock_t object_stat_lock;
-   size_t object_memory;
+   u64 object_memory;
u32 object_count;
 };
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d53439769a4a..723a4b0b7f63 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -82,7 +82,7 @@ remove_mappable_node(struct drm_mm_node *node)
 
 /* some bookkeeping */
 static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
- size_t size)
+ u64 size)
 {
spin_lock(_priv->mm.object_stat_lock);
dev_priv->mm.object_count++;
@@ -91,7 +91,7 @@ static void i915_gem_info_add_obj(struct drm_i915_private 
*dev_priv,
 }
 
 static void i915_gem_info_remove_obj(struct drm_i915_private *dev_priv,
-size_t size)
+u64 size)
 {
spin_lock(_priv->mm.object_stat_lock);
dev_priv->mm.object_count--;
-- 
2.9.3

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

Re: [Intel-gfx] [PULL] GVT-g device model core

[Jani Nikula]

On Mon, 17 Oct 2016, Jani Nikula  wrote:
> On Mon, 17 Oct 2016, Daniel Vetter  wrote:
>> Ok applied, but a few things to keep in mind before your next pull
>> request:
>>
>> - Dont rebase everything 5 seconds before sending out the pull request.
>>   That just invalidates all the testing you've done, so not a good idea.
>>   In general try to avoid rebases as much as possible, and only rebase to
>>   take out a truly embarassing mistake. And then only rebase up to the
>>   patch that needs a hotfix, not your entire tree.
>
> CONFIG_DRM_I915_GVT=y
>
> drivers/gpu/drm/i915/gvt/handlers.c: In function ‘render_mmio_to_ring_id’:
> drivers/gpu/drm/i915/gvt/handlers.c:137:31: error: request for member 
> ‘mmio_base’ in something not a structure or union
>if (gvt->dev_priv->engine[i].mmio_base == reg)

This is now fixed, thanks, but there's still a load of sparse warnings
coming from gvt. Please install sparse, and run e.g.

$ make
$ rm drivers/gpu/drm/i915/gvt/*.o
$ make C=1

Below is a list of current warnings.

BR,
Jani.


  CHECK   drivers/gpu/drm/i915/gvt/firmware.c
drivers/gpu/drm/i915/gvt/firmware.c:54:9: warning: incorrect type in argument 2 
(different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:54:9:expected void volatile [noderef] 
*addr
drivers/gpu/drm/i915/gvt/firmware.c:54:9:got void *
drivers/gpu/drm/i915/gvt/firmware.c:56:9: warning: incorrect type in argument 1 
(different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:56:9:expected void const volatile 
[noderef] *addr
drivers/gpu/drm/i915/gvt/firmware.c:56:9:got void *
drivers/gpu/drm/i915/gvt/firmware.c:58:13: warning: incorrect type in argument 
1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:58:13:expected void const volatile 
[noderef] *addr
drivers/gpu/drm/i915/gvt/firmware.c:58:13:got void *
drivers/gpu/drm/i915/gvt/firmware.c:61:9: warning: incorrect type in argument 2 
(different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:61:9:expected void volatile [noderef] 
*addr
drivers/gpu/drm/i915/gvt/firmware.c:61:9:got void *
drivers/gpu/drm/i915/gvt/firmware.c:63:13: warning: incorrect type in argument 
1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:63:13:expected void const volatile 
[noderef] *addr
drivers/gpu/drm/i915/gvt/firmware.c:63:13:got void *
drivers/gpu/drm/i915/gvt/firmware.c:66:13: warning: incorrect type in argument 
1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:66:13:expected void const volatile 
[noderef] *addr
drivers/gpu/drm/i915/gvt/firmware.c:66:13:got void *
drivers/gpu/drm/i915/gvt/firmware.c:132:56: warning: incorrect type in argument 
1 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:132:56:expected void const volatile 
[noderef] *addr
drivers/gpu/drm/i915/gvt/firmware.c:132:56:got void *
drivers/gpu/drm/i915/gvt/firmware.c:259:14: warning: incorrect type in 
assignment (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:259:14:expected void *mmio
drivers/gpu/drm/i915/gvt/firmware.c:259:14:got void [noderef] *
drivers/gpu/drm/i915/gvt/firmware.c:299:27: warning: incorrect type in argument 
2 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:299:27:expected void [noderef] 
*
drivers/gpu/drm/i915/gvt/firmware.c:299:27:got void *mmio
drivers/gpu/drm/i915/gvt/firmware.c:306:27: warning: incorrect type in argument 
2 (different address spaces)
drivers/gpu/drm/i915/gvt/firmware.c:306:27:expected void [noderef] 
*
drivers/gpu/drm/i915/gvt/firmware.c:306:27:got void *mmio
  CC [M]  drivers/gpu/drm/i915/gvt/firmware.o
  CHECK   drivers/gpu/drm/i915/gvt/interrupt.c
drivers/gpu/drm/i915/gvt/interrupt.c:52:12: warning: symbol 'irq_name' was not 
declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/gvt/interrupt.o
  CHECK   drivers/gpu/drm/i915/gvt/gtt.c
drivers/gpu/drm/i915/gvt/gtt.c:270:23: warning: cast removes address space of 
expression
drivers/gpu/drm/i915/gvt/gtt.c:274:21: warning: incorrect type in argument 1 
(different address spaces)
drivers/gpu/drm/i915/gvt/gtt.c:274:21:expected void const volatile 
[noderef] *addr
drivers/gpu/drm/i915/gvt/gtt.c:274:21:got void *addr
drivers/gpu/drm/i915/gvt/gtt.c:285:23: warning: cast removes address space of 
expression
drivers/gpu/drm/i915/gvt/gtt.c:288:21: warning: incorrect type in argument 2 
(different address spaces)
drivers/gpu/drm/i915/gvt/gtt.c:288:21:expected void volatile [noderef] 
*addr
drivers/gpu/drm/i915/gvt/gtt.c:288:21:got void *addr
drivers/gpu/drm/i915/gvt/gtt.c:1922:6: warning: symbol 
'intel_gvt_create_scratch_page' was not declared. Should it be static?
drivers/gpu/drm/i915/gvt/gtt.c:1956:6: warning: symbol 
'intel_gvt_release_scratch_page' was not declared. Should it be static?
drivers/gpu/drm/i915/gvt/gtt.c:1932:24: warning: odd constant _Bool cast 
(fff4 becomes 1)

Re: [Intel-gfx] [PATCH 1/2] drm: make is_lspcon_adaptor static

[Sharma, Shashank]

Reviewed-by: Shashank Sharma

Regards
Shashank
-Original Message-
From: Nikula, Jani 
Sent: Tuesday, October 18, 2016 4:52 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani ; Vivi, Rodrigo 
; Sharma, Shashank ; 
dri-de...@lists.freedesktop.org
Subject: [PATCH 1/2] drm: make is_lspcon_adaptor static

Fixes sparse warning:

drivers/gpu/drm/drm_dp_dual_mode_helper.c:151:6: warning: symbol 
'is_lspcon_adaptor' was not declared. Should it be static?

Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Cc: 
Signed-off-by: Jani Nikula 

---

n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has been 
merged via drm-intel tree
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a7aeb1ec852c..2624e266abbd 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -148,8 +148,8 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
  DP_DUAL_MODE_REV_TYPE2);
 }
 
-bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
-   const uint8_t adaptor_id)
+static bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
+ const uint8_t adaptor_id)
 {
return is_hdmi_adaptor(hdmi_id) &&
(adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
--
2.1.4

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: make lspcon_get_current_mode static

[Sharma, Shashank]

Reviewed-by: Shashank Sharma

Regards
Shashank
-Original Message-
From: Nikula, Jani 
Sent: Tuesday, October 18, 2016 4:52 PM
To: intel-gfx@lists.freedesktop.org
Cc: Nikula, Jani ; Vivi, Rodrigo 
; Sharma, Shashank 
Subject: [PATCH 2/2] drm/i915: make lspcon_get_current_mode static

Fixes sparse warning:

drivers/gpu/drm/i915/intel_lspcon.c:30:22: warning: symbol 
'lspcon_get_current_mode' was not declared. Should it be static?

Fixes: dbe9e61b8e43 ("drm/i915: Add lspcon support for I915 driver")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index d606f1a8f3b6..632149c6b3ad 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -27,7 +27,7 @@
 #include   #include "intel_drv.h"
 
-enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
+static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon 
+*lspcon)
 {
enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
struct i2c_adapter *adapter = >aux->ddc;
--
2.1.4

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

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

[Chris Wilson]

On Tue, Oct 18, 2016 at 02:25:21PM +0300, Petri Latvala wrote:
> If executed too soon after prime_vgem tests, the vgem unload test
> fails due to its execbuffers still being handled in the kernel. Retry
> the unload three times with sleeps before reporting a skip.

What happened to igt ensuring that the driver was idle before closing a
test? I guess that is complicated by the use of multiple drivers in
vgem.

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 40bbff6..5d3aaa8 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -344,14 +344,18 @@ int drm_open_driver(int chipset)
fd = __drm_open_driver(chipset);
igt_skip_on_f(fd<0, "No known gpu found\n");
 
-   if (__sync_fetch_and_add(_count, 1))
-   return fd;
-
+   /* For i915, at least, we ensure that the driver is idle before
+* starting a test and we install an exit handler to wait until
+* idle before quitting.
+*/
if (is_i915_device(fd)) {
-   gem_quiescent_gpu(fd);
-   igt_install_exit_handler(quiescent_gpu_at_exit);
+   if (__sync_fetch_and_add(_count, 1) == 0) {
+   gem_quiescent_gpu(fd);
+
+   at_exit_drm_fd = __drm_open_driver(chipset);
+   igt_install_exit_handler(quiescent_gpu_at_exit);
+   }
}
-   at_exit_drm_fd = __drm_open_driver(chipset);
 
return fd;
 }


-- 
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] drm: fix sparse warnings on undeclared symbols in crc debugfs

[Chris Wilson]

On Tue, Oct 18, 2016 at 02:28:35PM +0300, Jani Nikula wrote:
> Fixes sparse warnings:
> 
> drivers/gpu/drm/drm_debugfs_crc.c:118:30: warning: symbol
> 'drm_crtc_crc_control_fops' was not declared. Should it be static?
> 
> drivers/gpu/drm/drm_debugfs_crc.c:264:30: warning: symbol
> 'drm_crtc_crc_data_fops' was not declared. Should it be static?
> 
> drivers/gpu/drm/drm_debugfs_crc.c:281:5: warning: symbol
> 'drm_debugfs_crtc_crc_add' was not declared. Should it be static?
> 
> Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
> Cc: Benjamin Gaignard 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Tomeu Vizoso 
> Signed-off-by: Jani Nikula 
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

[Intel-gfx] [PATCH] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

[Arkadiusz Hiler]

Dropping WA because it was for early steppings.

It is fixed in newer preproduction and all production revisions.

Cc: Michal Winiarski 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e107455..32786ba 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -849,10 +849,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
 */
}
 
-   /* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt,kbl */
/* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt,kbl */
WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
- GEN9_ENABLE_YV12_BUGFIX |
  GEN9_ENABLE_GPGPU_PREEMPTION);
 
/* Wa4x4STCOptimizationDisable:skl,bxt,kbl */
-- 
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: fix sparse warnings on undeclared symbols in crc debugfs

[Jani Nikula]

Fixes sparse warnings:

drivers/gpu/drm/drm_debugfs_crc.c:118:30: warning: symbol
'drm_crtc_crc_control_fops' was not declared. Should it be static?

drivers/gpu/drm/drm_debugfs_crc.c:264:30: warning: symbol
'drm_crtc_crc_data_fops' was not declared. Should it be static?

drivers/gpu/drm/drm_debugfs_crc.c:281:5: warning: symbol
'drm_debugfs_crtc_crc_add' was not declared. Should it be static?

Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
Cc: Benjamin Gaignard 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Tomeu Vizoso 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_debugfs_crc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index 4129405d17c0..00e771fb7df2 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include "drm_internal.h"
 
 /**
  * DOC: CRC ABI
@@ -115,7 +116,7 @@ static ssize_t crc_control_write(struct file *file, const 
char __user *ubuf,
return len;
 }
 
-const struct file_operations drm_crtc_crc_control_fops = {
+static const struct file_operations drm_crtc_crc_control_fops = {
.owner = THIS_MODULE,
.open = crc_control_open,
.read = seq_read,
@@ -261,7 +262,7 @@ static ssize_t crtc_crc_read(struct file *filep, char 
__user *user_buf,
return LINE_LEN(crc->values_cnt);
 }
 
-const struct file_operations drm_crtc_crc_data_fops = {
+static const struct file_operations drm_crtc_crc_data_fops = {
.owner = THIS_MODULE,
.open = crtc_crc_open,
.read = crtc_crc_read,
-- 
2.1.4

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

[Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

[Petri Latvala]

If executed too soon after prime_vgem tests, the vgem unload test
fails due to its execbuffers still being handled in the kernel. Retry
the unload three times with sleeps before reporting a skip.

When tested on HSW, one 1s sleep wasn't enough, 3s was.

Signed-off-by: Petri Latvala 
CC: Chris Wilson 
CC: Jari Tahvanainen 
CC: Daniel Vetter 
---

With this change, we can leave vgem_basic@unload last in the CI
testlist, and thus still catch actual unload problems.

tests/vgem_basic.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tests/vgem_basic.c b/tests/vgem_basic.c
index 5b54a4a..7f0750d 100644
--- a/tests/vgem_basic.c
+++ b/tests/vgem_basic.c
@@ -296,10 +296,15 @@ static int module_unload(void)
 static void test_unload(void)
 {
struct vgem_bo bo;
-   int vgem, dmabuf;
+   int vgem, dmabuf, unloaded, retry = 3;
uint32_t *ptr;
 
-   igt_require(module_unload() == 0);
+   while ((unloaded = module_unload()) && retry-- > 0) {
+   /* Sleep for a moment to let previous users finish */
+   sleep(1);
+   }
+
+   igt_require(unloaded == 0);
 
vgem = __drm_open_driver(DRIVER_VGEM);
igt_assert(vgem != -1);
-- 
2.9.3

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

[Intel-gfx] [PATCH 2/2] drm/i915: make lspcon_get_current_mode static

[Jani Nikula]

Fixes sparse warning:

drivers/gpu/drm/i915/intel_lspcon.c:30:22: warning: symbol
'lspcon_get_current_mode' was not declared. Should it be static?

Fixes: dbe9e61b8e43 ("drm/i915: Add lspcon support for I915 driver")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index d606f1a8f3b6..632149c6b3ad 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -27,7 +27,7 @@
 #include 
 #include "intel_drv.h"
 
-enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
+static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon 
*lspcon)
 {
enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
struct i2c_adapter *adapter = >aux->ddc;
-- 
2.1.4

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

[Intel-gfx] [PATCH 1/2] drm: make is_lspcon_adaptor static

[Jani Nikula]

Fixes sparse warning:

drivers/gpu/drm/drm_dp_dual_mode_helper.c:151:6: warning: symbol
'is_lspcon_adaptor' was not declared. Should it be static?

Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi 
Cc: Shashank Sharma 
Cc: 
Signed-off-by: Jani Nikula 

---

n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
been merged via drm-intel tree
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a7aeb1ec852c..2624e266abbd 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -148,8 +148,8 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
  DP_DUAL_MODE_REV_TYPE2);
 }
 
-bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
-   const uint8_t adaptor_id)
+static bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
+ const uint8_t adaptor_id)
 {
return is_hdmi_adaptor(hdmi_id) &&
(adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
-- 
2.1.4

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

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

[Chris Wilson]

On Tue, Oct 18, 2016 at 10:33:11AM +0100, Tvrtko Ursulin wrote:
> 
> On 17/10/2016 09:00, Chris Wilson wrote:
> >The scattergather list uses a 32bit size counter, we should avoid
> >exceeding it.
> >
> >v2: Also we should use unsigned int to match sg->length.
> >
> >Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment 
> >size")
> >Signed-off-by: Chris Wilson 
> >Reviewed-by: Tvrtko Ursulin  # v1
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 181bda2db587..a74ec10a5370 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2205,7 +2205,7 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
> >*obj)
> > return 0;
> >  }
> >-static unsigned long swiotlb_max_size(void)
> >+static unsigned int swiotlb_max_size(void)
> >  {
> >  #if IS_ENABLED(CONFIG_SWIOTLB)
> > return rounddown(swiotlb_nr_tbl() << IO_TLB_SHIFT, PAGE_SIZE);
> >@@ -2225,7 +2225,7 @@ i915_gem_object_get_pages_gtt(struct 
> >drm_i915_gem_object *obj)
> > struct sgt_iter sgt_iter;
> > struct page *page;
> > unsigned long last_pfn = 0; /* suppress gcc warning */
> >-unsigned long max_segment;
> >+unsigned int max_segment;
> > int ret;
> > gfp_t gfp;
> >@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct 
> >drm_i915_gem_object *obj)
> > max_segment = swiotlb_max_size();
> > if (!max_segment)
> >-max_segment = obj->base.size;
> >+max_segment = rounddown(UINT_MAX, PAGE_SIZE);
> 
> rounddown looks like an overkill vs just UINT_MAX, no?

I think there is a subtle difference becuase we are couting in pages and
compare sg->length >= max_segment. If we left it at UINT_MAX, sg->length
would wrap to zero rather than start a new sg.
-Chris

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Restrict pagefault disabling to just around copy_from_user() (rev2)

[Chris Wilson]

On Tue, Oct 18, 2016 at 09:35:12AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Restrict pagefault disabling to just around 
> copy_from_user() (rev2)
> URL   : https://patchwork.freedesktop.org/series/13880/
> State : failure
> 
> == Summary ==
> 
> Series 13880v2 drm/i915: Restrict pagefault disabling to just around 
> copy_from_user()
> https://patchwork.freedesktop.org/api/1.0/series/13880/revisions/2/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> incomplete -> DMESG-WARN (fi-byt-n2820)
> dmesg-warn -> INCOMPLETE (fi-byt-j1900)

These are fluctuating results because we now are seeing bugs from ACPI.

> Test gem_ringfill:
> Subgroup basic-default-hang:
> pass   -> TIMEOUT(fi-ivb-3770)

The unrelated case of ivb not being able to recover from a hang. :|
Still looking for that locally on an i7-3720QM
-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 23/41] drm/i915: Move object release to a freelist + worker

[John Harrison]

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

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

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

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

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 118bd35f750c..27fd5370f0cc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4873,10 +4873,12 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_ring_test_irq_fops,
  #define DROP_BOUND 0x2
  #define DROP_RETIRE 0x4
  #define DROP_ACTIVE 0x8
-#define DROP_ALL (DROP_UNBOUND | \
- DROP_BOUND | \
- DROP_RETIRE | \
- DROP_ACTIVE)
+#define DROP_FREED 0x10
+#define DROP_ALL (DROP_UNBOUND | \
+ DROP_BOUND| \
+ DROP_RETIRE   | \
+ DROP_ACTIVE   | \
+ DROP_FREED)
  static int
  i915_drop_caches_get(void *data, u64 *val)
  {
@@ -4920,6 +4922,11 @@ i915_drop_caches_set(void *data, u64 val)
  unlock:
mutex_unlock(>struct_mutex);
  
+	if (val & DROP_FREED) {

+   synchronize_rcu();
+   flush_work(_priv->mm.free_work);
+   }
+
return ret;
  }
  
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c

index 5b72da6d45a2..c46f96d8bb38 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -537,14 +537,17 @@ static const struct vga_switcheroo_client_ops 
i915_switcheroo_ops = {
.can_switch = i915_switcheroo_can_switch,
  };
  
-static void i915_gem_fini(struct drm_device *dev)

+static void i915_gem_fini(struct drm_i915_private *dev_priv)
  {
-   mutex_lock(>struct_mutex);
-   i915_gem_cleanup_engines(dev);
-   i915_gem_context_fini(dev);
-   mutex_unlock(>struct_mutex);
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_gem_cleanup_engines(_priv->drm);
+   i915_gem_context_fini(_priv->drm);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   synchronize_rcu();
+   flush_work(_priv->mm.free_work);
  
-	WARN_ON(!list_empty(_i915(dev)->context_list));

+   WARN_ON(!list_empty(_priv->context_list));
  }
  
  static int i915_load_modeset_init(struct drm_device *dev)

@@ -619,7 +622,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
  cleanup_gem:
if (i915_gem_suspend(dev))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
-   i915_gem_fini(dev);
+   i915_gem_fini(dev_priv);
  cleanup_irq:
intel_guc_fini(dev);
drm_irq_uninstall(dev);
@@ -1299,7 +1302,7 @@ void i915_driver_unload(struct drm_device *dev)
drain_workqueue(dev_priv->wq);
  
  	intel_guc_fini(dev);

-   i915_gem_fini(dev);
+   i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
  
  	intel_power_domains_fini(dev_priv);

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e066284aace9..e2fe50b6b493 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1355,8 +1355,8 @@ struct i915_gem_mm {
struct list_head bound_list;
/**
 * List of objects which are not bound to the GTT (thus
-* are idle and not used by the GPU) but still have
-* (presumably uncached) pages still attached.
+* are idle and not used by the GPU). These objects may or may
+* not actually have any pages attached.
 */
struct list_head unbound_list;
  
@@ -1365,6 +1365,12 @@ struct i915_gem_mm {

 */
struct list_head userfault_list;
  
+	/**

+* List of objects which are pending destruction.
+*/
+   struct llist_head free_list;
+   struct work_struct free_work;
+
/** Usable portion of 

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

[Chris Wilson]

On Tue, Oct 18, 2016 at 10:27:58AM +0100, Tvrtko Ursulin wrote:
> 
> On 17/10/2016 09:00, Chris Wilson wrote:
> >In many places, we try to count pages using a 32 bit integer. That
> >implies if we are asked to create an object larger than 43bits, we will
> >subtly crash much later. Catch this on the boundary, and add a warning
> >to remind ourselves later on our exabyte systems.
> >
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_drv.h |  2 +-
> >  drivers/gpu/drm/i915/i915_gem.c | 17 +++--
> >  2 files changed, 16 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index 092c5a0a44f0..a2b5fc72fdd9 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -3105,7 +3105,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
> >*obj);
> >  void i915_gem_object_init(struct drm_i915_gem_object *obj,
> >  const struct drm_i915_gem_object_ops *ops);
> >  struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> >-  size_t size);
> >+   u64 size);
> >  struct drm_i915_gem_object *i915_gem_object_create_from_data(
> > struct drm_device *dev, const void *data, size_t size);
> >  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
> > *file);
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 838dc159a2d1..181bda2db587 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -4131,14 +4131,27 @@ static const struct drm_i915_gem_object_ops 
> >i915_gem_object_ops = {
> > .put_pages = i915_gem_object_put_pages_gtt,
> >  };
> >-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
> >-  size_t size)
> >+#define overflows_type(x, T) \
> >+(sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
> >+
> 
> Looks like it wouldn't detect storing unsigned int in a signed int
> but I guess we don't care that much as long as this is local use
> only. Just slightly relevant because of the int page_count situation
> we mention below.

Hmm. Yeah, definitely worth improving. Quick googling shows that you are
the first to notice! :-p

I was thinking of trying gcc's __builtin_add_overflowp(x, 0, T) or
something like that.

But I also wonder if we can use signed T *var vs unsigned T *var in any
way to generalise the number of positive bits in a type.
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Restrict pagefault disabling to just around copy_from_user() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Restrict pagefault disabling to just around copy_from_user() 
(rev2)
URL   : https://patchwork.freedesktop.org/series/13880/
State : failure

== Summary ==

Series 13880v2 drm/i915: Restrict pagefault disabling to just around 
copy_from_user()
https://patchwork.freedesktop.org/api/1.0/series/13880/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-byt-n2820)
dmesg-warn -> INCOMPLETE (fi-byt-j1900)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> TIMEOUT(fi-ivb-3770)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-ivb-3520m)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-kbl-7200u)
pass   -> SKIP   (fi-hsw-4770)
skip   -> PASS   (fi-hsw-4770r)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:220  dwarn:1   dfail:0   fail:1   skip:24 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u failed to connect after reboot
fi-skl-6770hq failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2741/

7ec75289774dec48c46c37271fb334b7caed3d32 drm-intel-nightly: 
2016y-10m-17d-14h-07m-32s UTC integration manifest
0dbfd20 drm/i915: Restrict pagefault disabling to just around copy_from_user()

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

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

[Tvrtko Ursulin]

On 17/10/2016 09:00, Chris Wilson wrote:

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

v2: Also we should use unsigned int to match sg->length.

Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size")
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin  # v1
---
  drivers/gpu/drm/i915/i915_gem.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 181bda2db587..a74ec10a5370 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2205,7 +2205,7 @@ i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
return 0;
  }
  
-static unsigned long swiotlb_max_size(void)

+static unsigned int swiotlb_max_size(void)
  {
  #if IS_ENABLED(CONFIG_SWIOTLB)
return rounddown(swiotlb_nr_tbl() << IO_TLB_SHIFT, PAGE_SIZE);
@@ -2225,7 +2225,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
struct sgt_iter sgt_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
-   unsigned long max_segment;
+   unsigned int max_segment;
int ret;
gfp_t gfp;
  
@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
  
  	max_segment = swiotlb_max_size();

if (!max_segment)
-   max_segment = obj->base.size;
+   max_segment = rounddown(UINT_MAX, PAGE_SIZE);


rounddown looks like an overkill vs just UINT_MAX, no?

  
  	st = kmalloc(sizeof(*st), GFP_KERNEL);

if (st == NULL)


Anyway,

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

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

[Tvrtko Ursulin]

On 17/10/2016 09:00, Chris Wilson wrote:

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

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 092c5a0a44f0..a2b5fc72fdd9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3105,7 +3105,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
*obj);
  void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
  struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size);
+  u64 size);
  struct drm_i915_gem_object *i915_gem_object_create_from_data(
struct drm_device *dev, const void *data, size_t size);
  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 838dc159a2d1..181bda2db587 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4131,14 +4131,27 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
  };
  
-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,

- size_t size)
+#define overflows_type(x, T) \
+   (sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
+


Looks like it wouldn't detect storing unsigned int in a signed int but I 
guess we don't care that much as long as this is local use only. Just 
slightly relevant because of the int page_count situation we mention below.



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

+* page count inside a 32bit variable. Let's document this and catch


_Signed_ 32-bit integer as you have explained to justify the INT_MAX below.


+* if we ever need to fix it.
+*/
+   if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
+   return ERR_PTR(-E2BIG);
+
+   if (overflows_type(size, obj->base.size))
+   return ERR_PTR(-E2BIG);
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
return ERR_PTR(-ENOMEM);


With the comment clarification,

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

[Ville Syrjälä]

On Tue, Oct 18, 2016 at 12:03:12PM +0300, Petri Latvala wrote:
> On Tue, Oct 18, 2016 at 09:34:49AM +0200, Daniel Vetter wrote:
> > Re S4: If it indeed improves coverage (i.e. calls our shutdown hooks and
> > all these S4-only callbacks) then adding it to BAT sounds reasonable.
> > Still there's the issue of where to get the machine time from. I really do
> > think you need to first trade in some speed-up here (or throw out some
> > other tests) before you can add more tests.
> 
> For the record, the runtimes of all tests in CI can be found in the
> result-runtimes.log file, within the test log directory.
> 
> Over 10s runtimes on a randomly selected machine are:
> 
> 31.92 igt@gem_ctx_switch@basic-default-heavy
> 22.91 igt@gem_busy@basic-hang-default
> 21.03 igt@kms_flip@basic-flip-vs-dpms
> 20.96 igt@kms_flip@basic-flip-vs-modeset
> 20.39 igt@gem_ctx_switch@basic-default
> 20.30 igt@gem_exec_create@basic
> 20.11 igt@gem_ctx_create@basic-files
> 19.64 igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a
> 18.93 igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b
> 18.91 igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c
> 18.76 igt@gem_exec_suspend@basic-s3
> 17.98 igt@kms_pipe_crc_basic@hang-read-crc-pipe-c
> 16.70 igt@kms_flip@basic-flip-vs-wf_vblank
> 14.17 igt@kms_pipe_crc_basic@hang-read-crc-pipe-a
> 14.14 igt@gem_exec_nop@basic-parallel
> 14.12 igt@gem_exec_nop@basic-series
> 13.76 igt@kms_pipe_crc_basic@hang-read-crc-pipe-b
> 12.70 igt@gem_ringfill@basic-default-hang
> 11.34 igt@drv_hangman@error-state-basic
> 10.91 igt@gem_sync@basic-many-each
> 10.81 igt@gem_close_race@basic-threads
> 10.73 igt@kms_flip@basic-plain-flip
> 10.33 igt@gem_sync@basic-store-each
> 10.29 igt@gem_sync@basic-store-all
> 10.11 igt@gem_sync@basic-each
> 10.08 igt@gem_sync@basic-all
> 
> Does any of these strike as a low-hanging fruit?

s/15/5/ for the S3 delay I'd say. If there's a machine that won't work
with 5 seconds, then we find out what's the lowest safe value and use
that instead. 15 seconds is excessive on all the machines I've seen.
And maybe make these delays configurabe via env variables so that I
don't have to keep patching igt when I want to test suspendy stuff ;)

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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Bump object bookkeeping to u64 from size_t

[Tvrtko Ursulin]

On 17/10/2016 09:00, Chris Wilson wrote:

Internally we allow for using more objects than a single process can
allocate, i.e. we allow for a 64bit GPU address space even on a 32bit
system. Using size_t may oveerflow.

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 515c206ba653..dc057c770146 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -392,7 +392,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
if (ret)
return ret;
  
-	seq_printf(m, "%u objects, %zu bytes\n",

+   seq_printf(m, "%u objects, %llu bytes\n",
   dev_priv->mm.object_count,
   dev_priv->mm.object_memory);
  
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

index 4d1133ffe093..092c5a0a44f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1389,7 +1389,7 @@ struct i915_gem_mm {
  
  	/* accounting, useful for userland debugging */

spinlock_t object_stat_lock;
-   size_t object_memory;
+   u64 object_memory;
u32 object_count;
  };
  
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c

index fe92e28ea0a8..838dc159a2d1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -82,7 +82,7 @@ remove_mappable_node(struct drm_mm_node *node)
  
  /* some bookkeeping */

  static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
- size_t size)
+ u64 size)
  {
spin_lock(_priv->mm.object_stat_lock);
dev_priv->mm.object_count++;
@@ -91,7 +91,7 @@ static void i915_gem_info_add_obj(struct drm_i915_private 
*dev_priv,
  }
  
  static void i915_gem_info_remove_obj(struct drm_i915_private *dev_priv,

-size_t size)
+u64 size)
  {
spin_lock(_priv->mm.object_stat_lock);
dev_priv->mm.object_count--;


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

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

[Joonas Lahtinen]

On ti, 2016-10-18 at 12:19 +0300, Joonas Lahtinen wrote:
> With the change from John,
> 

"Now that the change from John was done" would have been better
wording.

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 23/41] drm/i915: Move object release to a freelist + worker

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> We want to hide the latency of releasing objects and their backing
> storage from the submission, so we move the actual free to a worker.
> This allows us to switch to struct_mutex freeing of the object in the
> next patch.
> 
> Furthermore, if we know that the object we are dereferencing remains valid
> for the duration of our access, we can forgo the usual synchronisation
> barriers and atomic reference counting. To ensure this we defer freeing
> an object til after an RCU grace period, such that any lookup of the
> object within an RCU read critical section will remain valid until
> after we exit that critical section. We also employ this delay for
> rate-limiting the serialisation on reallocation - we have to slow down
> object creation in order to prevent resource starvation (in particular,
> files).
> 
> v2: Return early in i915_gem_tiling() ioctl to skip over superfluous
> work on error.
> 
> Signed-off-by: Chris Wilson 

With the change from John,

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 12/15] drm: RIP mode_config->rotation_property

[Ville Syrjälä]

On Tue, Oct 18, 2016 at 11:13:53AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Tuesday 18 Oct 2016 09:36:23 Daniel Vetter wrote:
> > On Tue, Oct 18, 2016 at 01:38:05AM +0300, Laurent Pinchart wrote:
> > > On Friday 22 Jul 2016 16:43:13 ville.syrj...@linux.intel.com wrote:
> > >> From: Ville Syrjälä 
> > >> 
> > >> Now that all drivers have been converted over to the per-plane rotation
> > >> property, we can just nuke the global rotation property.
> > >> 
> > >> Signed-off-by: Ville Syrjälä 
> > > 
> > > Stupid question, but how does this work when the hardware supports global
> > > rotation only, not per-plane rotation ?
> > 
> > Does that exist? If so I guess we get to add a rotation property to CRTCS
> > (and update docs and all that).
> 
> I have a hardware composer that performs rotation on the output side. At the 
> moment it doesn't support rotation when used with the display, but I wouldn't 
> rule that out in future SoC versions. So I'm not aware of any use case for a 
> rotation property on the CRTC at the moment, I just wanted to make sure we 
> have a path forward.

I even implemented that for i915 long ago by having it rotate all the
planes (+ adjust their coordinates appropriately). But people weren't
too keen on putting that in, so I dropped it.

https://lists.freedesktop.org/archives/intel-gfx/2014-February/040053.html

The only bigger snafu here is omap, which already has a rotation property
on the crtc, except it actually only rotates the primary plane. So
when/if someone adds a real crtc rotation property it has to be called
something else that "rotation". I think I settled on "crtc-rotation"
judging what I have in my last branch on that topic.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Restrict pagefault disabling to just around copy_from_user()

[Tvrtko Ursulin]

On 18/10/2016 10:07, Chris Wilson wrote:

When handling execbuf relocations, we play a delicate dance with
pagefault. We first try to access the user pages underneath our
struct_mutex. However, if those pages were inside a GEM object, we may
trigger a pagefault and deadlock as i915_gem_fault() tries to
recursively acquire struct_mutex. Instead, we choose to disable
pagefaulting around the copy_from_user whilst inside the struct_mutex
and handle the EFAULT by falling back to a copy outside the
struct_mutex.

We however presumed that disabling pagefaults would be expensive. It is
just an operation on the local current task. Cheap enough that we can
restrict the disable/enable to the critical section around the copy, and
so avoid having to handle the atomic sections within the relocation
handling itself.

v2: Just illustrate the broken error handling rather than argue why it
is safer to ignore it, for now.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 71 +++---
  1 file changed, 35 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 204536a3087e..e52affdcc125 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -551,20 +551,6 @@ relocate_entry(struct drm_i915_gem_object *obj,
return 0;
  }
  
-static bool object_is_idle(struct drm_i915_gem_object *obj)

-{
-   unsigned long active = i915_gem_object_get_active(obj);
-   int idx;
-
-   for_each_active(active, idx) {
-   if (!i915_gem_active_is_idle(>last_read[idx],
->base.dev->struct_mutex))
-   return false;
-   }
-
-   return true;
-}
-
  static int
  i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
   struct eb_vmas *eb,
@@ -648,10 +634,6 @@ i915_gem_execbuffer_relocate_entry(struct 
drm_i915_gem_object *obj,
return -EINVAL;
}
  
-	/* We can't wait for rendering with pagefaults disabled */

-   if (pagefault_disabled() && !object_is_idle(obj))
-   return -EFAULT;
-
ret = relocate_entry(obj, reloc, cache, target_offset);
if (ret)
return ret;
@@ -678,12 +660,23 @@ i915_gem_execbuffer_relocate_vma(struct i915_vma *vma,
remain = entry->relocation_count;
while (remain) {
struct drm_i915_gem_relocation_entry *r = stack_reloc;
-   int count = remain;
-   if (count > ARRAY_SIZE(stack_reloc))
-   count = ARRAY_SIZE(stack_reloc);
+   unsigned long unwritten;
+   unsigned int count;
+
+   count = min_t(unsigned int, remain, ARRAY_SIZE(stack_reloc));
remain -= count;
  
-		if (__copy_from_user_inatomic(r, user_relocs, count*sizeof(r[0]))) {

+   /* This is the fast path and we cannot handle a pagefault
+* whilst holding the struct mutex lest the user pass in the
+* relocations contained within a mmaped bo. For in such a case
+* we, the page fault handler would call i915_gem_fault() and
+* we would try to acquire the struct mutex again. Obviously
+* this is bad and so lockdep complains vehemently.
+*/
+   pagefault_disable();
+   unwritten = __copy_from_user_inatomic(r, user_relocs, 
count*sizeof(r[0]));
+   pagefault_enable();
+   if (unlikely(unwritten)) {
ret = -EFAULT;
goto out;
}
@@ -695,11 +688,26 @@ i915_gem_execbuffer_relocate_vma(struct i915_vma *vma,
if (ret)
goto out;
  
-			if (r->presumed_offset != offset &&

-   __put_user(r->presumed_offset,
-  _relocs->presumed_offset)) {
-   ret = -EFAULT;
-   goto out;
+   if (r->presumed_offset != offset) {
+   pagefault_disable();
+   unwritten = __put_user(r->presumed_offset,
+  
_relocs->presumed_offset);
+   pagefault_enable();
+   if (unlikely(unwritten)) {
+   /* Note that reporting an error now
+* leaves everything in an inconsistent
+* state as we have *already* changed
+* the relocation value inside the
+ 

Re: [Intel-gfx] [i-g-t PATCH] igt/tools: Update intel_watermark with SKL support

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 10:19:35PM -0700, Dhinakaran Pandiyan wrote:
> Added support to print SKL watermark and DDB registers.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  tools/intel_watermark.c | 104 
> +++-
>  1 file changed, 103 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
> index e9a2b05..903a0b2 100644
> --- a/tools/intel_watermark.c
> +++ b/tools/intel_watermark.c
> @@ -120,6 +120,11 @@ static const char *endis(bool enabled)
>   return enabled ? "enabled" : "disabled";
>  }
>  
> +static const char endis_ast(bool enabled)
> +{
> + return enabled ? '*' : ' ';
> +}
> +
>  static int is_gen7_plus(uint32_t d)
>  {
>   return !(IS_GEN5(d) || IS_GEN6(d));
> @@ -130,6 +135,101 @@ static int is_hsw_plus(uint32_t d)
>   return !(IS_GEN5(d) || IS_GEN6(d) || IS_IVYBRIDGE(d));
>  }
>  
> +
> +static void skl_wm_dump(void)
> +{
> + int pipe, plane, level;
> + int num_pipes = 3;
> + int num_planes = 5;
> + int num_levels = 8;
> + uint32_t base_addr = 0x7, addr, wm_offset;
> +
> + uint32_t wm[num_levels][num_pipes][num_planes];
> + uint32_t wm_trans[num_pipes][num_planes];
> + uint32_t buf_cfg[num_pipes][num_planes];
> +
> + intel_register_access_init(intel_get_pci_device(), 0);
> +
> + for (pipe = 0; pipe < num_pipes; pipe++) {
> + for (plane = 0; plane < num_planes; plane++) {
> + addr =  base_addr +  pipe * 0x1000 + plane * 0x100;
> +
> + wm_trans[pipe][plane] = read_reg(addr + 0x00168);
> + buf_cfg[pipe][plane] = read_reg(addr + 0x0017C);
> + for (level = 0; level < num_levels; level++) {
> + wm_offset = addr + 0x00140 + level * 0x4;
> + wm[level][pipe][plane] = read_reg(wm_offset);
> + }
> + }
> + }
> +

Please dump out the all the raw register values first. Then proceed to
print out the decoded output. That's what I've been doing for all the
other platforms.

> + for (pipe = 0; pipe < num_pipes; pipe++) {
> + uint32_t start, end, size;
> + uint32_t lines, blocks, enable;
> +
> + printf("PIPE_%c\n", pipe_name(pipe));
> + printf("LEVEL   CURSOR   PLANE_A   PLANE_B   PLANE_C   
> PLANE_D\n");

Planes are labelled 1,2,3,... not A,B,C,...

> + for (level = 0; level < num_levels; level++) {
> + printf("%5d  ", level);
> + for (plane = 0; plane < num_planes; plane++) {
> + blocks = REG_DECODE1(wm[level][pipe][plane], 0, 
> 9);
> + lines = REG_DECODE1(wm[level][pipe][plane], 14, 
> 5);
> + enable = REG_DECODE1(wm[level][pipe][plane], 
> 31, 1);
> +
> + printf("%3d", blocks);
> + printf("%c", endis_ast(enable));

One printf() will do.

> + if (!REG_DECODE1(wm[level][pipe][plane], 30, 1))
> + printf("(%2d)  ", lines);
> + else
> + printf("(--)  ");
> + }
> + printf("\n");
> + }
> +
> + printf("TRANS: ");
> + for (plane = 0; plane < num_planes; plane++) {
> + blocks = REG_DECODE1(wm_trans[pipe][plane], 0, 9);
> + lines = REG_DECODE1(wm_trans[pipe][plane], 14, 5);
> + enable = REG_DECODE1(wm_trans[pipe][plane], 31, 1);
> +
> + printf("%3d", blocks);
> + printf("%c", endis_ast(enable));
> + if (!REG_DECODE1(wm_trans[pipe][plane], 30, 1))
> + printf("(%2d)  ", lines);
> + else
> + printf("(--)  ");
> + }
> +
> + printf("\nDDB allocation:");
> +
> + printf("\nstart ");
> + for (plane = 0; plane < num_planes; plane++) {
> + start = REG_DECODE1(buf_cfg[pipe][plane], 0, 10);
> + printf("%7d   ", start);
> + }
> +
> + printf("\nend   ");
> + for (plane = 0; plane < num_planes; plane++) {
> + end = REG_DECODE1(buf_cfg[pipe][plane], 16, 10);
> + printf("%7d   ", end);
> + }
> +
> + printf("\nsize  ");
> + for (plane = 0; plane < num_planes; plane++) {
> + start = REG_DECODE1(buf_cfg[pipe][plane], 0, 10);
> + end =  REG_DECODE1(buf_cfg[pipe][plane], 16, 10);
> + size = end - start + 1;
> + printf("%7d   ", (end == 0 && size == 1) ? 0 : size);
> +