Re: [Intel-gfx] [PATCH 0/2] extend page_track for external usage

2016-11-08 Thread Zhenyu Wang
On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote:
> >> Paolo, for this case, do you think it's feasible we pick them through
> >> drm/i915 merge path? As currently initial KVMGT patch sets require these
> >> exported symbols, that's why I ask how we should handle this dependency.
> >
> > Then it's actually a good thing that I dropped from kvm/queue!  You can
> > certainly include these patches, but please do that through a topic branch.
> >
> > I've prepared a branch for you
> > (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
> > Linus processes my outstanding pull request, the branch will only
> > include the three page-tracking patches.  Please pull that topic branch
> > into your own branch, and ensure you have a merge commit when you send
> > the pull request to Daniel.  The merge commit ensures that the workflow
> > was correct; use --no-ff if necessary.
> >
> > You can do the same for Jike's patches for the KVM-VFIO device, when
> > Alex reviews them, and I suppose you'll need a topic branch for mdev
> > too?  I didn't know that KVMGT was planned for 4.10.  In the future,
> > let's synchronize ahead so that we can prepare topic branches for you.
> 
> Ok, back from the useless wifi at plumbers, I can mail again. Zhenyu
> confirmed on irc that the initial code pile only needs this. For the
> cross-maintainer topic tree I prefer a formal pull request with stable
> tag. Please also cc: intel-gfx on that, since I plan to merge that one
> directly into i915.
> 

Paolo, could you help to do this for Daniel? Daniel would like to merge
current KVMGT required change for KVM directly, then I'd base KVMGT change
on that.

p.s, Daniel gave me this example 
https://lists.freedesktop.org/archives/intel-gfx/2015-December/082600.html,
which was for audio change merge.

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


Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

2016-11-08 Thread Matt Roper
On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> The previous spec version said "double Ytile planes minimum lines",
> and I interpreted this as referring to what the spec calls "Y tile
> minimum", but in fact it was referring to what the spec calls "Minimum
> Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> interpretation, so I sent and email to the spec authors and got
> clarification on the correct meaning. Also, BSpec was updated and
> should be clear now.
> 
> Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the memory 
> bandwidth WA")
> Cc: sta...@vger.kernel.org
> Cc: Mahesh Kumar 
> Signed-off-by: Paulo Zanoni 

This seems to match my reading of the spec update from Nov 4th, so:

Reviewed-by: Matt Roper 


> ---
>  drivers/gpu/drm/i915/intel_pm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index cc9e0c0..653525f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   y_min_scanlines = 4;
>   }
>  
> + if (apply_memory_bw_wa)
> + y_min_scanlines *= 2;
> +
>   plane_bytes_per_line = width * cpp;
>   if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
>   fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>plane_blocks_per_line);
>  
>   y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> - if (apply_memory_bw_wa)
> - y_tile_minimum *= 2;
>  
>   if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
>   fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

2016-11-08 Thread Matt Roper
On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote:
> One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
> partitioning for multi-screen cases"), and the other was added by
> 01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen
> cases"). I'm confused and I'll let the maintainers find out what went
> wrong here.
> 
> Cc: Jani Nikula 
> Signed-off-by: Paulo Zanoni 

I think this is just an artifact of having the patch in both -next and
-fixes.  The context probably changed later in -next causing a conflict
when the two were merged, and then the merge resolution accidentally
duplicated this hunk.  The merge commit ac4139ed7 is where we wound up
with the two copies:

diff --cc drivers/gpu/drm/i915/intel_pm.c
index db24f89,cc9e0c0..88e28c9
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@@ -3361,11 -3404,13 +3404,17 @@@ skl_allocate_pipe_ddb(struct 
intel_crtc
unsigned int total_data_rate;
int num_active;
int id, i;
+   unsigned plane_data_rate[I915_MAX_PLANES] = {};
+   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
+ 
+   /* Clear the partitioning for disabled planes. */
+   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
+   memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
  
 +  /* Clear the partitioning for disabled planes. */
 +  memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
 +  memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
 +
if (WARN_ON(!state))
return 0;
  
Dropping one looks good to me.

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 88e28c9..cc9e0c0 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3411,10 +3411,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
>   memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
>  
> - /* Clear the partitioning for disabled planes. */
> - memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> - memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> -
>   if (WARN_ON(!state))
>   return 0;
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-08 Thread Daniel Vetter
On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote:
> > The function's behaviour was changed in 90844f00049e, without changing
> > its signature, causing people to keep using it the old way without
> > realising they were now leaking memory.
> > Rob Clark also noticed it was also allocating GFP_KERNEL memory in
> > atomic contexts, breaking them.
> > 
> > Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> > to make them cleanup the memory afterwards, let's change the function's
> > signature by having the caller take care of the memory and passing it to
> > the function.
> > The new parameter is a single-field struct in order to enforce the size
> > of its buffer and help callers to correctly manage their memory.
> > 
> > Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> > Cc: Rob Clark 
> > Cc: Christian König 
> > Acked-by: Christian König 
> > Acked-by: Rob Clark 
> > Acked-by: Sinclair Yeh  (vmwgfx)
> > Reviewed-by: Jani Nikula 
> > Suggested-by: Ville Syrjälä 
> > Signed-off-by: Eric Engestrom 
> > ---
> > v3 - fix "Fixes" tag, replace it with an actual commit message
> >- collect ack & r-b
> > 
> > v2 - use single-field struct instead of typedef to let the compiler
> >  enforce the type (Christian König)
> 
> Applied to drm-misc, thanks.

Well, had to drop it again since it didn't compile:


  CC [M]  drivers/gpu/drm/drm_blend.o
drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’:
drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function 
‘drm_get_format_name’
 drm_get_format_name(fb->pixel_format));
 ^~~
In file included from ./include/drm/drmP.h:71:0,
 from drivers/gpu/drm/drm_atomic.c:29:
./include/drm/drm_fourcc.h:65:7: note: declared here
 char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
   ^~~

Can you pls rebase onto drm-misc or linux-next or something?

Thanks, 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 v3] drm: move allocation out of drm_get_format_name()

2016-11-08 Thread Daniel Vetter
On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote:
> The function's behaviour was changed in 90844f00049e, without changing
> its signature, causing people to keep using it the old way without
> realising they were now leaking memory.
> Rob Clark also noticed it was also allocating GFP_KERNEL memory in
> atomic contexts, breaking them.
> 
> Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> to make them cleanup the memory afterwards, let's change the function's
> signature by having the caller take care of the memory and passing it to
> the function.
> The new parameter is a single-field struct in order to enforce the size
> of its buffer and help callers to correctly manage their memory.
> 
> Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> Cc: Rob Clark 
> Cc: Christian König 
> Acked-by: Christian König 
> Acked-by: Rob Clark 
> Acked-by: Sinclair Yeh  (vmwgfx)
> Reviewed-by: Jani Nikula 
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Eric Engestrom 
> ---
> v3 - fix "Fixes" tag, replace it with an actual commit message
>- collect ack & r-b
> 
> v2 - use single-field struct instead of typedef to let the compiler
>  enforce the type (Christian König)

Applied to drm-misc, thanks.
-Daniel

> ---
>  include/drm/drm_fourcc.h| 10 +-
>  drivers/gpu/drm/drm_fourcc.c| 14 +++--
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
>  drivers/gpu/drm/drm_atomic.c|  7 +++--
>  drivers/gpu/drm/drm_crtc.c  |  7 +++--
>  drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
>  drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
>  drivers/gpu/drm/drm_plane.c |  7 +++--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
>  drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
>  drivers/gpu/drm/i915/intel_display.c| 41 
> ++---
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
>  17 files changed, 80 insertions(+), 86 deletions(-)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index dc0aafa..4b03ca0 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -45,6 +45,14 @@ struct drm_format_info {
>   u8 vsub;
>  };
>  
> +/**
> + * struct drm_format_name_buf - name of a DRM format
> + * @str: string buffer containing the format name
> + */
> +struct drm_format_name_buf {
> + char str[32];
> +};
> +
>  const struct drm_format_info *__drm_format_info(u32 format);
>  const struct drm_format_info *drm_format_info(u32 format);
>  uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> @@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
>  int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
> -char *drm_get_format_name(uint32_t format) __malloc;
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>  
>  #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..99b0b60 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
> depth)
>  EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>  
>  /**
> - * drm_get_format_name - return a string for drm fourcc format
> + * drm_get_format_name - fill a string with a drm fourcc format's name
>   * @format: format to compute name of
> + * @buf: caller-supplied buffer
> - *
> - * Note that the buffer returned by this function is owned by the caller
> - * and will need to be freed using kfree().
>   */
> -char *drm_get_format_name(uint32_t format)
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
>  {
> - char *buf = kmalloc(32, GFP_KERNEL);
> -
> - snprintf(buf, 32,
> + snprintf(buf->str, sizeof(buf->str),
>"%c%c%c%c %s-endian (0x%08x)",
>printable_char(format & 0xff),
>printable_char((format >> 8) & 0xff),
> @@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
>format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
>format);
>  
> - return buf;
> + return buf->str;
>  }
>  

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

2016-11-08 Thread Matt Roper
On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> As I told people in [1] we really should not be confusing enum plane
> as a per-pipe plane identifier. Looks like that happened nonetheless, so
> let's fix it up by splitting the two into two enums.
> 
> We'll also want something we just directly pass to various register
> offset macros and whatnot on SKL+. So let's make this new thing work for that.
> Currently we pass intel_plane->plane for the "sprites" and just a
> hardcoded zero for the "primary" planes. We want to get rid of that
> hardocoding so that we can share the same code for all planes (apart
> from the legacy cursor of course).
> 
> [1] 
> https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html
> 
> Cc: Matt Roper 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 

So the goal here is to make intel_plane->plane represent which of the
system's primary planes (A, B, or C) the plane structure refers to?
From a quick Cocci test, it looks like there's only a single use of the
value for that purpose in our driver (in primary_get_hw_state).  I think
all of the other calls to DSPCNTR are actually using crtc->plane as
their index, which should have the same value.  Would it make more sense
to just drop intel_plane->plane entirely and switch the last user over
to crtc->plane so that we're not carrying around a structure field that
is either bogus or empty on the majority of the platform's planes?

While we're at it, we could rename 'enum plane' to something like 'enum
primary_plane' to make it extra clear what its purpose is and avoid
future confusion.  And maybe a similar rename to crtc->plane as well.
We use the standalone term 'plane' in a generic manner in too many
places in our driver and it means something slightly different
everywhere...


Matt

> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 28 +---
>  drivers/gpu/drm/i915/intel_display.c |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
>  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
>  4 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 30777dee3f9c..2451b88b1e82 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum transcoder 
> transcoder)
>  }
>  
>  /*
> - * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> - * number of planes per CRTC.  Not all platforms really have this many 
> planes,
> - * which means some arrays of size I915_MAX_PLANES may have unused entries
> - * between the topmost sprite plane and the cursor plane.
> + * Global legacy plane identifier. Valid only for primary/sprite
> + * planes on pre-g4x, and only for primary planes on g4x+.
>   */
>  enum plane {
> - PLANE_A = 0,
> + PLANE_A,
>   PLANE_B,
>   PLANE_C,
> - PLANE_CURSOR,
> - I915_MAX_PLANES,
>  };
>  #define plane_name(p) ((p) + 'A')
>  
>  #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + 
> (s) + 'A')
>  
> +/*
> + * Per-pipe plane identifier.
> + * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> + * number of planes per CRTC.  Not all platforms really have this many 
> planes,
> + * which means some arrays of size I915_MAX_PLANES may have unused entries
> + * between the topmost sprite plane and the cursor plane.
> + *
> + * This is expected to be passed to various register macros
> + * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
> + */
> +enum plane_id {
> + PLANE_PRIMARY,
> + PLANE_SPRITE0,
> + PLANE_SPRITE1,
> + PLANE_CURSOR,
> + I915_MAX_PLANES,
> +};
> +
>  enum port {
>   PORT_NONE = -1,
>   PORT_A = 0,
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 10869360cfdc..b318119330e8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15008,6 +15008,7 @@ intel_primary_plane_create(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>   primary->plane = (enum plane) !pipe;
>   else
>   primary->plane = (enum plane) pipe;
> + primary->id = PLANE_PRIMARY;
>   primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
>   primary->check_plane = intel_check_primary_plane;
>  
> @@ -15203,6 +15204,7 @@ intel_cursor_plane_create(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>   cursor->max_downscale = 1;
>   cursor->pipe = pipe;
>   cursor->plane = pipe;
> + cursor->id = PLANE_CURSOR;
>   cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
>   cursor->check_plane = intel_check_cursor_plane;
>   cursor->update_plane = intel_update_cursor_plane;

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: move allocation out of drm_get_format_name() (rev3)

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

Series: drm: move allocation out of drm_get_format_name() (rev3)
URL   : https://patchwork.freedesktop.org/series/14873/
State : failure

== Summary ==

  CC [M]  drivers/gpu/drm/i915/dvo_ns2501.o
  CC [M]  drivers/gpu/drm/i915/dvo_sil164.o
  CC [M]  drivers/gpu/drm/i915/dvo_tfp410.o
  CC [M]  drivers/gpu/drm/i915/intel_ddi.o
  CC [M]  drivers/gpu/drm/i915/intel_crt.o
  CC [M]  drivers/gpu/drm/i915/intel_dp_aux_backlight.o
  LD  drivers/tty/serial/8250/8250.o
  CC [M]  drivers/gpu/drm/i915/intel_dp_link_training.o
  CC [M]  drivers/gpu/drm/i915/intel_dp.o
  CC [M]  drivers/gpu/drm/i915/intel_dsi.o
  CC [M]  drivers/gpu/drm/i915/intel_dsi_dcs_backlight.o
  CC [M]  drivers/gpu/drm/i915/intel_dp_mst.o
  CC [M]  drivers/gpu/drm/i915/intel_dsi_panel_vbt.o
  CC [M]  drivers/gpu/drm/i915/intel_dsi_pll.o
  CC [M]  drivers/gpu/drm/i915/intel_dvo.o
  CC [M]  drivers/gpu/drm/i915/intel_i2c.o
  CC [M]  drivers/gpu/drm/i915/intel_hdmi.o
  CC [M]  drivers/gpu/drm/i915/intel_lspcon.o
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
  CC [M]  drivers/gpu/drm/i915/intel_tv.o
  CC [M]  drivers/gpu/drm/i915/intel_sdvo.o
  CC [M]  drivers/gpu/drm/i915/i915_vgpu.o
  CC [M]  drivers/gpu/drm/i915/i915_gpu_error.o
  LD  drivers/acpi/acpica/acpi.o
  LD  lib/zlib_deflate/zlib_deflate.o
  LD  lib/zlib_deflate/built-in.o
  LD  drivers/pci/pcie/aer/aerdriver.o
  LD  drivers/scsi/scsi_mod.o
  LD  drivers/pci/pcie/aer/built-in.o
  LD  drivers/pci/pcie/built-in.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD  lib/lz4/built-in.o
  LD  drivers/acpi/acpica/built-in.o
  LD  lib/zlib_inflate/zlib_inflate.o
  LD  lib/zlib_inflate/built-in.o
  LD [M]  drivers/gpu/drm/vgem/vgem.o
  LD  net/netlink/built-in.o
  LD  drivers/acpi/built-in.o
  LD  lib/xz/xz_dec.o
  LD  lib/xz/built-in.o
  LD  net/unix/unix.o
  LD  net/unix/built-in.o
  LD  drivers/usb/gadget/libcomposite.o
  LD  drivers/pci/built-in.o
  LD  lib/raid6/raid6_pq.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  lib/raid6/built-in.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD  drivers/usb/gadget/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD [M]  drivers/misc/mei/mei-me.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/misc/built-in.o
  LD  drivers/scsi/built-in.o
  LD  net/packet/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/tty/serial/built-in.o
  LD  drivers/usb/core/built-in.o
  LD  net/ipv6/ipv6.o
  LD  net/ipv6/built-in.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/tty/built-in.o
  LD  net/xfrm/built-in.o
  LD  drivers/video/console/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  fs/btrfs/btrfs.o
  LD  drivers/md/md-mod.o
  LD  drivers/md/built-in.o
  LD  drivers/usb/host/built-in.o
  CC  arch/x86/kernel/cpu/capflags.o
  LD  fs/btrfs/built-in.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  drivers/usb/built-in.o
  LD  arch/x86/kernel/built-in.o
  AR  lib/lib.a
  EXPORTS lib/lib-ksyms.o
  LD  lib/built-in.o
  LD  arch/x86/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  fs/ext4/ext4.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  LD  net/core/built-in.o
  LD  net/ipv4/built-in.o
  LD  net/built-in.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
  LD [M]  drivers/gpu/drm/i915/i915.o
scripts/Makefile.build:475: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:475: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:983: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/Patchwork_2938

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


[Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

2016-11-08 Thread Eric Engestrom
The function's behaviour was changed in 90844f00049e, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.

Instead of having to allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory.

Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 
Acked-by: Rob Clark 
Acked-by: Sinclair Yeh  (vmwgfx)
Reviewed-by: Jani Nikula 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 
---
v3 - fix "Fixes" tag, replace it with an actual commit message
   - collect ack & r-b

v2 - use single-field struct instead of typedef to let the compiler
 enforce the type (Christian König)
---
 include/drm/drm_fourcc.h| 10 +-
 drivers/gpu/drm/drm_fourcc.c| 14 +++--
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  7 ++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  7 ++---
 drivers/gpu/drm/drm_atomic.c|  7 +++--
 drivers/gpu/drm/drm_crtc.c  |  7 +++--
 drivers/gpu/drm/drm_framebuffer.c   |  7 +++--
 drivers/gpu/drm/drm_modeset_helper.c|  7 +++--
 drivers/gpu/drm/drm_plane.c |  7 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  7 ++---
 drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
 drivers/gpu/drm/i915/intel_atomic_plane.c   |  8 ++---
 drivers/gpu/drm/i915/intel_display.c| 41 ++---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 14 -
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  3 +-
 17 files changed, 80 insertions(+), 86 deletions(-)

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index dc0aafa..4b03ca0 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -45,6 +45,14 @@ struct drm_format_info {
u8 vsub;
 };
 
+/**
+ * struct drm_format_name_buf - name of a DRM format
+ * @str: string buffer containing the format name
+ */
+struct drm_format_name_buf {
+   char str[32];
+};
+
 const struct drm_format_info *__drm_format_info(u32 format);
 const struct drm_format_info *drm_format_info(u32 format);
 uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
@@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
 int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
-char *drm_get_format_name(uint32_t format) __malloc;
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
 
 #endif /* __DRM_FOURCC_H__ */
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index cbb8b77..99b0b60 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth)
 EXPORT_SYMBOL(drm_mode_legacy_fb_format);
 
 /**
- * drm_get_format_name - return a string for drm fourcc format
+ * drm_get_format_name - fill a string with a drm fourcc format's name
  * @format: format to compute name of
+ * @buf: caller-supplied buffer
- *
- * Note that the buffer returned by this function is owned by the caller
- * and will need to be freed using kfree().
  */
-char *drm_get_format_name(uint32_t format)
+char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
 {
-   char *buf = kmalloc(32, GFP_KERNEL);
-
-   snprintf(buf, 32,
+   snprintf(buf->str, sizeof(buf->str),
 "%c%c%c%c %s-endian (0x%08x)",
 printable_char(format & 0xff),
 printable_char((format >> 8) & 0xff),
@@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
 format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
 format);
 
-   return buf;
+   return buf->str;
 }
 EXPORT_SYMBOL(drm_get_format_name);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 199d3f7..2924cdd 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

2016-11-08 Thread Stephen Rothwell
Hi all,

After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "depot_save_stack" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "depot_fetch_stack" [drivers/gpu/drm/drm.ko] undefined!

Caused by commit

  5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")

I hate used the drm-misc tree from next-20161108 for today.

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

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

Series: drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
URL   : https://patchwork.freedesktop.org/series/14990/
State : success

== Summary ==

Series 14990v1 drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
https://patchwork.freedesktop.org/api/1.0/series/14990/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

0fa5820fd3cbd43e750ef57d8b272a731a04875c drm-intel-nightly: 
2016y-11m-08d-19h-30m-38s UTC integration manifest
92970b0 drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

2016-11-08 Thread Paulo Zanoni
The previous spec version said "double Ytile planes minimum lines",
and I interpreted this as referring to what the spec calls "Y tile
minimum", but in fact it was referring to what the spec calls "Minimum
Scanlines for Y tile". I noticed that Mahesh Kumar had a different
interpretation, so I sent and email to the spec authors and got
clarification on the correct meaning. Also, BSpec was updated and
should be clear now.

Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the memory bandwidth 
WA")
Cc: sta...@vger.kernel.org
Cc: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cc9e0c0..653525f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
y_min_scanlines = 4;
}
 
+   if (apply_memory_bw_wa)
+   y_min_scanlines *= 2;
+
plane_bytes_per_line = width * cpp;
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
@@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 plane_blocks_per_line);
 
y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
-   if (apply_memory_bw_wa)
-   y_tile_minimum *= 2;
 
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
-- 
2.7.4

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

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

Series: drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()
URL   : https://patchwork.freedesktop.org/series/14984/
State : success

== Summary ==

Series 14984v1 drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()
https://patchwork.freedesktop.org/api/1.0/series/14984/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

9435ffb9ffbfecfa5a429a46af96b1b3fda41d6c drm-intel-nightly: 
2016y-11m-08d-13h-53m-48s UTC integration manifest
af272ef drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2936/
___
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: Add a per-pipe plane identifier enum (rev3)

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

Series: drm/i915: Add a per-pipe plane identifier enum (rev3)
URL   : https://patchwork.freedesktop.org/series/14978/
State : warning

== Summary ==

Series 14978v3 drm/i915: Add a per-pipe plane identifier enum
https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/3/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-kbl-7200u)
Test kms_busy:
Subgroup basic-flip-default-c:
pass   -> DMESG-WARN (fi-bxt-t5700)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:244  pass:215  dwarn:1   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:229  dwarn:1   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:221  dwarn:2   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:223  dwarn:7   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

9435ffb9ffbfecfa5a429a46af96b1b3fda41d6c drm-intel-nightly: 
2016y-11m-08d-13h-53m-48s UTC integration manifest
ee2cdee drm/i915: Don't populate plane->plane for cursors and sprites
f43966f drm/i915: Rename the local 'plane' variable to 'plane_id' in primary 
plane code
04a0e37 drm/i915: Use enum plane_id in VLV/CHV wm code
db5553c drm/i915: Use enum plane_id in VLV/CHV sprite code
6a71330 drm/i915: Use enum plane_id in SKL plane code
e88c3fb drm/i915: Use enum plane_id in SKL wm code
cc004ca drm/i915: Add crtc->plane_ids_mask
616c141 drm/i915: Add per-pipe plane identifier
49d3701 drm/i915: Remove some duplicated plane swapping logic

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

2016-11-08 Thread Paulo Zanoni
One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
partitioning for multi-screen cases"), and the other was added by
01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen
cases"). I'm confused and I'll let the maintainers find out what went
wrong here.

Cc: Jani Nikula 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 88e28c9..cc9e0c0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3411,10 +3411,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
 
-   /* Clear the partitioning for disabled planes. */
-   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
-   memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
-
if (WARN_ON(!state))
return 0;
 
-- 
2.7.4

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


Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

2016-11-08 Thread Daniel Vetter
On Tue, Nov 08, 2016 at 06:04:15PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > > Now, I know you're working on getting rid of this entirely for i915, but
> > > what about that MSM driver? Will we continue to need it there, is
> > > anybody actually maintaining that thing?
> > 
> > Rob Clark is, and since he's a one-man gpu driver team with other
> > responsibilities it might take even longer than for i915 :(
> 
> Fair enough. For my information, how much a of copy/paste job from i915
> was that? Could he, in principle, copy/paste your changes to get rid of
> this back into MSM without too much effort, or have things diverged
> greatly since the initial copy/paste?

Probably diverged too much already, and on top the big part is the command
submission, and that's entirely driver/hw specific. But etnaviv is a plain
gem driver which uses per-bo locking, and there's all the ttm drivers with
similar designs, so there's plenty of templates. But it's not just
copypasta for sure.
-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


[Intel-gfx] [PATCH v2 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Use intel_plane->id to derive the VLV/CHV sprite register offsets
instead of abusing plane->plane which is really meant to for
primary planes only.

v2: Convert assert_sprites_disabled() over as well

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  | 58 +++-
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_sprite.c  | 74 ++--
 3 files changed, 70 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3361d7ffc63e..9739e97c6263 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5374,18 +5374,21 @@ enum {
 #define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
 #define _SPBGAMC   (VLV_DISPLAY_BASE + 0x722f4)
 
-#define SPCNTR(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPACNTR, 
_SPBCNTR)
-#define SPLINOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPALINOFF, 
_SPBLINOFF)
-#define SPSTRIDE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASTRIDE, 
_SPBSTRIDE)
-#define SPPOS(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAPOS, _SPBPOS)
-#define SPSIZE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASIZE, 
_SPBSIZE)
-#define SPKEYMINVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
_SPAKEYMINVAL, _SPBKEYMINVAL)
-#define SPKEYMSK(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAKEYMSK, 
_SPBKEYMSK)
-#define SPSURF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASURF, 
_SPBSURF)
-#define SPKEYMAXVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
_SPAKEYMAXVAL, _SPBKEYMAXVAL)
-#define SPTILEOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPATILEOFF, 
_SPBTILEOFF)
-#define SPCONSTALPHA(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
_SPACONSTALPHA, _SPBCONSTALPHA)
-#define SPGAMC(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAGAMC, 
_SPBGAMC)
+#define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) \
+   _MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a), (reg_b))
+
+#define SPCNTR(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPACNTR, _SPBCNTR)
+#define SPLINOFF(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPALINOFF, _SPBLINOFF)
+#define SPSTRIDE(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPASTRIDE, _SPBSTRIDE)
+#define SPPOS(pipe, plane) _MMIO_VLV_SPR((pipe), (plane), _SPAPOS, 
_SPBPOS)
+#define SPSIZE(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPASIZE, _SPBSIZE)
+#define SPKEYMINVAL(pipe, plane)   _MMIO_VLV_SPR((pipe), (plane), 
_SPAKEYMINVAL, _SPBKEYMINVAL)
+#define SPKEYMSK(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPAKEYMSK, _SPBKEYMSK)
+#define SPSURF(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPASURF, _SPBSURF)
+#define SPKEYMAXVAL(pipe, plane)   _MMIO_VLV_SPR((pipe), (plane), 
_SPAKEYMAXVAL, _SPBKEYMAXVAL)
+#define SPTILEOFF(pipe, plane) _MMIO_VLV_SPR((pipe), (plane), 
_SPATILEOFF, _SPBTILEOFF)
+#define SPCONSTALPHA(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPACONSTALPHA, _SPBCONSTALPHA)
+#define SPGAMC(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPAGAMC, _SPBGAMC)
 
 /*
  * CHV pipe B sprite CSC
@@ -5394,29 +5397,32 @@ enum {
  * |yg| = |c3 c4 c5| x |yg + yg_ioff| + |yg_ooff|
  * |cb|   |c6 c7 c8|   |cb + cr_ioff|   |cb_ooff|
  */
-#define SPCSCYGOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d900 + (sprite) * 
0x1000)
-#define SPCSCCBOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d904 + (sprite) * 
0x1000)
-#define SPCSCCROFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d908 + (sprite) * 
0x1000)
+#define _MMIO_CHV_SPCSC(plane, reg) \
+   _MMIO(VLV_DISPLAY_BASE + ((plane) - PLANE_SPRITE0) * 0x1000 + (reg))
+
+#define SPCSCYGOFF(plane)  _MMIO_CHV_SPCSC(plane, 0x6d900)
+#define SPCSCCBOFF(plane)  _MMIO_CHV_SPCSC(plane, 0x6d904)
+#define SPCSCCROFF(plane)  _MMIO_CHV_SPCSC(plane, 0x6d908)
 #define  SPCSC_OOFF(x) (((x) & 0x7ff) << 16) /* s11 */
 #define  SPCSC_IOFF(x) (((x) & 0x7ff) << 0) /* s11 */
 
-#define SPCSCC01(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d90c + (sprite) * 
0x1000)
-#define SPCSCC23(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d910 + (sprite) * 
0x1000)
-#define SPCSCC45(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d914 + (sprite) * 
0x1000)
-#define SPCSCC67(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d918 + (sprite) * 
0x1000)
-#define SPCSCC8(sprite)_MMIO(VLV_DISPLAY_BASE + 0x6d91c + 
(sprite) * 0x1000)
+#define SPCSCC01(plane)_MMIO_CHV_SPCSC(plane, 0x6d90c)
+#define SPCSCC23(plane)_MMIO_CHV_SPCSC(plane, 0x6d910)
+#define SPCSCC45(plane)_MMIO_CHV_SPCSC(plane, 0x6d914)
+#define SPCSCC67(plane)_MMIO_CHV_SPCSC(plane, 0x6d918)
+#define SPCSCC8(plane) _MMIO_CHV_SPCSC(plane, 0x6d91c)
 #define  SPCSC_C1(x)   (((x) & 0x7fff) << 16) /* s3.12 

[Intel-gfx] [PATCH v2 4/9] drm/i915: Use enum plane_id in SKL wm code

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Nuke skl_wm_plane_id() and just use the new intel_plane->id.

v2: Convert skl_write_plane_wm() as well

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

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a3c696d8bf93..6a4cd6edafa5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1751,7 +1751,7 @@ void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
 void skl_write_plane_wm(struct intel_crtc *intel_crtc,
const struct skl_plane_wm *wm,
const struct skl_ddb_allocation *ddb,
-   int plane);
+   enum plane_id plane_id);
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 88e28c989b9c..93595ce64cb7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2863,28 +2863,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
 #define SKL_SAGV_BLOCK_TIME30 /* µs */
 
 /*
- * Return the index of a plane in the SKL DDB and wm result arrays.  Primary
- * plane is always in slot 0, cursor is always in slot I915_MAX_PLANES-1, and
- * other universal planes are in indices 1..n.  Note that this may leave unused
- * indices between the top "sprite" plane and the cursor.
- */
-static int
-skl_wm_plane_id(const struct intel_plane *plane)
-{
-   switch (plane->base.type) {
-   case DRM_PLANE_TYPE_PRIMARY:
-   return 0;
-   case DRM_PLANE_TYPE_CURSOR:
-   return PLANE_CURSOR;
-   case DRM_PLANE_TYPE_OVERLAY:
-   return plane->plane + 1;
-   default:
-   MISSING_CASE(plane->base.type);
-   return plane->plane;
-   }
-}
-
-/*
  * FIXME: We still don't have the proper code detect if we need to apply the 
WA,
  * so assume we'll always need it in order to avoid underruns.
  */
@@ -3022,7 +3000,6 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
struct intel_crtc *crtc;
struct intel_plane *plane;
struct intel_crtc_state *cstate;
-   struct skl_plane_wm *wm;
enum pipe pipe;
int level, latency;
 
@@ -3049,7 +3026,8 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
return false;
 
for_each_intel_plane_on_crtc(dev, crtc, plane) {
-   wm = >wm.skl.optimal.planes[skl_wm_plane_id(plane)];
+   struct skl_plane_wm *wm =
+   >wm.skl.optimal.planes[plane->id];
 
/* Skip this plane if it's not enabled */
if (!wm->wm[0].plane_en)
@@ -3148,28 +3126,28 @@ static void skl_ddb_entry_init_from_hw(struct 
skl_ddb_entry *entry, u32 reg)
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */)
 {
-   enum pipe pipe;
-   int plane;
+   struct intel_crtc *crtc;
u32 val;
 
memset(ddb, 0, sizeof(*ddb));
 
-   for_each_pipe(dev_priv, pipe) {
+   for_each_intel_crtc(_priv->drm, crtc) {
enum intel_display_power_domain power_domain;
+   enum plane_id plane_id;
+   enum pipe pipe = crtc->pipe;
 
power_domain = POWER_DOMAIN_PIPE(pipe);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
-   for_each_universal_plane(dev_priv, pipe, plane) {
-   val = I915_READ(PLANE_BUF_CFG(pipe, plane));
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane],
-  val);
-   }
+   for_each_plane_id_on_crtc(crtc, plane_id) {
+   if (plane_id != PLANE_CURSOR)
+   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+   else
+   val = I915_READ(CUR_BUF_CFG(pipe));
 
-   val = I915_READ(CUR_BUF_CFG(pipe));
-   skl_ddb_entry_init_from_hw(>plane[pipe][PLANE_CURSOR],
-  val);
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], 
val);
+   }
 
intel_display_power_put(dev_priv, power_domain);
}
@@ -3270,30 +3248,30 @@ 

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

2016-11-08 Thread Peter Zijlstra
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > Now, I know you're working on getting rid of this entirely for i915, but
> > what about that MSM driver? Will we continue to need it there, is
> > anybody actually maintaining that thing?
> 
> Rob Clark is, and since he's a one-man gpu driver team with other
> responsibilities it might take even longer than for i915 :(

Fair enough. For my information, how much a of copy/paste job from i915
was that? Could he, in principle, copy/paste your changes to get rid of
this back into MSM without too much effort, or have things diverged
greatly since the initial copy/paste?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

2016-11-08 Thread Peter Zijlstra
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > You're talking about:
> > 
> >   lkml.kernel.org/r/20161007154351.gl3...@twins.programming.kicks-ass.net
> > 
> > ? I got no feedback from you DRM guys on that so I kinda forgot about
> > that in the hope we'd not have to do this at all.
> 
> Yes. Chris/Joonas, pls give this is a spin and review.

OK, I'll respin that thing with Linus' feedback etc. Might not be until
tomorrow though, so any additional feedback would be good.

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


Re: [Intel-gfx] [PATCH 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 04:04:23PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:16PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Use intel_plane->id to derive the VLV/CHV sprite register offsets
> > instead of abusing plane->plane which is really meant to for
> > primary planes only.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 58 -
> >  drivers/gpu/drm/i915/intel_sprite.c | 74 
> > ++---
> >  2 files changed, 69 insertions(+), 63 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 3361d7ffc63e..9739e97c6263 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5374,18 +5374,21 @@ enum {
> >  #define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
> >  #define _SPBGAMC   (VLV_DISPLAY_BASE + 0x722f4)
> >  
> > -#define SPCNTR(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPACNTR, 
> > _SPBCNTR)
> > -#define SPLINOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPALINOFF, 
> > _SPBLINOFF)
> > -#define SPSTRIDE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASTRIDE, 
> > _SPBSTRIDE)
> > -#define SPPOS(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAPOS, 
> > _SPBPOS)
> > -#define SPSIZE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASIZE, 
> > _SPBSIZE)
> > -#define SPKEYMINVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
> > _SPAKEYMINVAL, _SPBKEYMINVAL)
> > -#define SPKEYMSK(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAKEYMSK, 
> > _SPBKEYMSK)
> > -#define SPSURF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASURF, 
> > _SPBSURF)
> > -#define SPKEYMAXVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
> > _SPAKEYMAXVAL, _SPBKEYMAXVAL)
> > -#define SPTILEOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
> > _SPATILEOFF, _SPBTILEOFF)
> > -#define SPCONSTALPHA(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
> > _SPACONSTALPHA, _SPBCONSTALPHA)
> > -#define SPGAMC(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAGAMC, 
> > _SPBGAMC)
> > +#define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) \
> > +   _MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a), (reg_b))
> 
> #define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) ({
>   typecheck(enum pipe, pipe);
>   typecheck(enum plane_id, plane);
>   _MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a), (reg_b))
> )}
> 
> Does that work?

Not really. The enum gets turned into a signed or unsigned int
it seems. Which one depends on whether it has negative values or not.

But while playing with this I did notice that I forgot to convert
assert_sprites_disabled() at least. So this wasn't a totally wasted
exercise :)

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


Re: [Intel-gfx] [PATCH] drm/i915: avoid harmless empty-body warning

2016-11-08 Thread Daniel Vetter
On Tue, Nov 08, 2016 at 02:49:05PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote:
> > The newly added assert_kernel_context_is_current introduces a warning
> > when built with W=1:
> > 
> > drivers/gpu/drm/i915/i915_gem.c: In function 
> > ‘assert_kernel_context_is_current’:
> > drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty 
> > body in an ‘else’ statement [-Werror=empty-body]
> > 
> > Changing the GEM_BUG_ON() macro from an empty definition to "do { } while 
> > (0)"
> > makes the macro more robust to use and avoids the warning.
> > 
> > Fixes: 3033acab07f9 ("drm/i915: Queue the idling context switch after all 
> > other timelines")
> > Signed-off-by: Arnd Bergmann 
> Reviewed-by: Chris Wilson 

Queued for -next, thanks for the patch.
-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] [PULL] GVT-g device model fixes

2016-11-08 Thread Daniel Vetter
On Mon, Nov 07, 2016 at 05:18:21PM +0800, Zhenyu Wang wrote:
> 
> Hi,
> 
> This is current fixes for GVT-g device model part. Most notable is to
> fix a regression from e95433c73a11 ("drm/i915: Rearrange
> i915_wait_request() accounting with callers") which has stopped our
> testing.
> 
> As for that regression fix, I have to base this series on top of it
> as lacking a tag on dinq for that.
> 
> Thanks.
> 
> The following changes since commit e95433c73a11759203af1cae5958f998c9673370:
> 
>   drm/i915: Rearrange i915_wait_request() accounting with callers (2016-10-28 
> 20:53:43 +0100)
> 
> are available in the git repository at:
> 
>   https://github.com/01org/gvt-linux tags/gvt-next-2016-11-07
> 
> for you to fetch changes up to 3b6411c2c20525f98b8541b3060c9ed95e31a762:
> 
>   drm/i915/gvt: implement scratch page table tree for shadow PPGTT 
> (2016-11-07 14:17:02 +0800)
> 
> 
> gvt-next-2016-11-07
> 
> - Fix regression from e95433c73a11
> - Some MMIO handler fixes
> - Add better handling for guest reset control
> - stratch page table tree for shadow ppgtt

Pulled, thanks.
-Daniel

> 
> 
> Du, Changbin (1):
>   drm/i915/gvt: emulate vgpu engine reset control behavior
> 
> Ping Gao (5):
>   drm/i915/gvt: remove unused variable 'execlist'
>   drm/i915/gvt: add write vreg in MMIO DMA_CTRL handler
>   drm/i915/gvt: correct the emulation in TLB control handler
>   drm/i915/gvt: update misc ctl regs base on stepping info
>   drm/i915/gvt: implement scratch page table tree for shadow PPGTT
> 
> Zhenyu Wang (2):
>   drm/i915/gvt: Fix shift for cmd data size
>   drm/i915/gvt: Fix workload status after wait
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c   |   4 +-
>  drivers/gpu/drm/i915/gvt/gtt.c  | 151 
> +++-
>  drivers/gpu/drm/i915/gvt/gtt.h  |  40 -
>  drivers/gpu/drm/i915/gvt/handlers.c |  44 --
>  drivers/gpu/drm/i915/gvt/render.c   |   2 +
>  drivers/gpu/drm/i915/gvt/sched_policy.c |   2 -
>  drivers/gpu/drm/i915/gvt/scheduler.c|   2 +
>  7 files changed, 172 insertions(+), 73 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827



-- 
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] linux-next: manual merge of the tip tree with the drm-intel tree

2016-11-08 Thread Daniel Vetter
On Tue, Nov 08, 2016 at 02:24:48PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > FIXME: Add owner of second tree to To:
> > >Add author(s)/SOB of conflicting commits.
> > > 
> > > Today's linux-next merge of the tip tree got a conflict in:
> > > 
> > >   drivers/gpu/drm/i915/i915_gem_shrinker.c
> > > 
> > > between commits:
> > > 
> > >   1233e2db199d ("drm/i915: Move object backing storage manipulation to 
> > > its own locking")
> > > 
> > > from the drm-intel tree and commit:
> > > 
> > >   3ab7c086d5ec ("locking/drm: Kill mutex trickery")
> > >   c7faee2109f9 ("locking/drm: Fix i915_gem_shrinker_lock() locking")
> > 
> > Hm, this seems to be the older versions that nuke the recursive locking
> > trickery entirely, I thought we had version in-flight that kept that? I
> > know that the i915 (and msm locking fwiw) is horrible since essentially
> > it's a recursive BKL, and we're working (slowly, after all getting rid of
> > the BKL wasn't simple either) to fix this. But meanwhile I'm assuming that
> > we'll still need this to be able to get out of low memory situations in
> > i915. Has that part simply not yet landed?
> 
> You're talking about:
> 
>   lkml.kernel.org/r/20161007154351.gl3...@twins.programming.kicks-ass.net
> 
> ? I got no feedback from you DRM guys on that so I kinda forgot about
> that in the hope we'd not have to do this at all.

Yes. Chris/Joonas, pls give this is a spin and review.
> 
> I can try and resurrect, that I suppose.
> 
> Now, I know you're working on getting rid of this entirely for i915, but
> what about that MSM driver? Will we continue to need it there, is
> anybody actually maintaining that thing?

Rob Clark is, and since he's a one-man gpu driver team with other
responsibilities it might take even longer than for i915 :(
-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 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 04:47:16PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Use intel_plane->id to derive the VLV/CHV sprite register offsets
> instead of abusing plane->plane which is really meant to for
> primary planes only.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 58 -
>  drivers/gpu/drm/i915/intel_sprite.c | 74 
> ++---
>  2 files changed, 69 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3361d7ffc63e..9739e97c6263 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5374,18 +5374,21 @@ enum {
>  #define _SPBCONSTALPHA   (VLV_DISPLAY_BASE + 0x722a8)
>  #define _SPBGAMC (VLV_DISPLAY_BASE + 0x722f4)
>  
> -#define SPCNTR(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPACNTR, 
> _SPBCNTR)
> -#define SPLINOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPALINOFF, 
> _SPBLINOFF)
> -#define SPSTRIDE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASTRIDE, 
> _SPBSTRIDE)
> -#define SPPOS(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAPOS, _SPBPOS)
> -#define SPSIZE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASIZE, 
> _SPBSIZE)
> -#define SPKEYMINVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
> _SPAKEYMINVAL, _SPBKEYMINVAL)
> -#define SPKEYMSK(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAKEYMSK, 
> _SPBKEYMSK)
> -#define SPSURF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASURF, 
> _SPBSURF)
> -#define SPKEYMAXVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
> _SPAKEYMAXVAL, _SPBKEYMAXVAL)
> -#define SPTILEOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPATILEOFF, 
> _SPBTILEOFF)
> -#define SPCONSTALPHA(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
> _SPACONSTALPHA, _SPBCONSTALPHA)
> -#define SPGAMC(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAGAMC, 
> _SPBGAMC)
> +#define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) \
> + _MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a), (reg_b))

#define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) ({
typecheck(enum pipe, pipe);
typecheck(enum plane_id, plane);
_MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a), (reg_b))
)}

Does that work?

-- 
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: success for drm/i915: Spin until breadcrumb threads are complete

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 03:16:13PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Spin until breadcrumb threads are complete
> URL   : https://patchwork.freedesktop.org/series/14977/
> State : success
> 
> == Summary ==
> 
> Series 14977v1 drm/i915: Spin until breadcrumb threads are complete
> https://patchwork.freedesktop.org/api/1.0/series/14977/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (fi-skl-6770hq)

I don't think there is a single BAT test that exercises this code.
gem_exec_whisper is may favourite here.
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Add a per-pipe plane identifier enum

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

Series: drm/i915: Add a per-pipe plane identifier enum
URL   : https://patchwork.freedesktop.org/series/14978/
State : warning

== Summary ==

Series 14978v1 drm/i915: Add a per-pipe plane identifier enum
https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-kbl-7200u)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_busy:
Subgroup basic-flip-default-c:
pass   -> DMESG-WARN (fi-bxt-t5700)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
pass   -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-snb-2520m)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:215  dwarn:1   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:229  dwarn:1   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:221  dwarn:2   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:223  dwarn:7   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

9435ffb9ffbfecfa5a429a46af96b1b3fda41d6c drm-intel-nightly: 
2016y-11m-08d-13h-53m-48s UTC integration manifest
7631b0d drm/i915: Don't populate plane->plane for cursors and sprites
8584dd5 drm/i915: Rename the local 'plane' variable to 'plane_id' in primary 
plane code
addbd43 drm/i915: Use enum plane_id in VLV/CHV wm code
c3354df drm/i915: Use enum plane_id in VLV/CHV sprite code
5dd9250 drm/i915: Use enum plane_id in SKL plane code
ce4f6dd drm/i915: Use enum plane_id in SKL wm code
b325442 drm/i915: Add crtc->plane_ids_mask
69c4249 drm/i915: Add per-pipe plane identifier
cf7f939 drm/i915: Remove some duplicated plane swapping logic

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 03:26:31PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > As I told people in [1] we really should not be confusing enum plane
> > as a per-pipe plane identifier. Looks like that happened nonetheless, so
> > let's fix it up by splitting the two into two enums.
> > 
> > We'll also want something we just directly pass to various register
> > offset macros and whatnot on SKL+. So let's make this new thing work for 
> > that.
> > Currently we pass intel_plane->plane for the "sprites" and just a
> > hardcoded zero for the "primary" planes. We want to get rid of that
> > hardocoding so that we can share the same code for all planes (apart
> > from the legacy cursor of course).
> > 
> > [1] 
> > https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html
> > 
> > Cc: Matt Roper 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 28 +---
> >  drivers/gpu/drm/i915/intel_display.c |  2 ++
> >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> >  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
> >  4 files changed, 26 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 30777dee3f9c..2451b88b1e82 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum transcoder 
> > transcoder)
> >  }
> >  
> >  /*
> > - * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> > - * number of planes per CRTC.  Not all platforms really have this many 
> > planes,
> > - * which means some arrays of size I915_MAX_PLANES may have unused entries
> > - * between the topmost sprite plane and the cursor plane.
> > + * Global legacy plane identifier. Valid only for primary/sprite
> > + * planes on pre-g4x, and only for primary planes on g4x+.
> >   */
> >  enum plane {
> > -   PLANE_A = 0,
> > +   PLANE_A,
> > PLANE_B,
> > PLANE_C,
> > -   PLANE_CURSOR,
> > -   I915_MAX_PLANES,
> >  };
> >  #define plane_name(p) ((p) + 'A')
> 
> And make then non-interchangeable with PLANE_A = 'A', PLANE_B = 'B' etc?
> 
> >  #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + 
> > (s) + 'A')
> 
> But that makes that macro even worse. It was an idea.

Yeah, would be nice to make it harder to mix things up somehow. But I
must admit I didn't spend much time thinking what would be the best way
to achieve that.

> 
> >  struct intel_plane {
> > struct drm_plane base;
> > -   int plane;
> > +   u8 plane;
> 
> enum plane plane ?

A bit later ;)

-- 
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 1/9] drm/i915: Remove some duplicated plane swapping logic

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 03:23:14PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC
> > capable plane feeding the LVDS port by default. We have the logic for
> > the plane swapping duplicated in many places. Let's remove a bit of the
> > duplication by having the crtc look up the thing from the primary plane.
> 
> And intel_crtc->plane is just a left over to be removed when we go full
> atomic.

Yeah, that should die. Just need to sort out the few remaning users
somehow, assuming they won't just disappear magically.

>  
> > Signed-off-by: Ville Syrjälä 
> Reviewed-by: Chris Wilson 
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
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 9/9] drm/i915: Don't populate plane->plane for cursors and sprites

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 03:30:33PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:19PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > With plane->plane now purely reserved for the primary planes, let's
> > not even populate it for cursors and sprites. Let's switch the type
> > to enum plane as well since it's no longer being abused for anything
> > else.
> 
> Also suggests not starting enum plane from zero.

That would complicate the DSPCNTR() etc. macros a bit. Also I think for
gen2/3 I'll be wanting to index watermark related structs and whatnot
with enum plane rather than enum plane_id since the planes<->pipe
mapping isn't fixed. So a non-zero base might make life a bit more
difficult.

-- 
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 9/9] drm/i915: Don't populate plane->plane for cursors and sprites

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 04:47:19PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> With plane->plane now purely reserved for the primary planes, let's
> not even populate it for cursors and sprites. Let's switch the type
> to enum plane as well since it's no longer being abused for anything
> else.

Also suggests not starting enum plane from zero.
-Chris

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


Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> As I told people in [1] we really should not be confusing enum plane
> as a per-pipe plane identifier. Looks like that happened nonetheless, so
> let's fix it up by splitting the two into two enums.
> 
> We'll also want something we just directly pass to various register
> offset macros and whatnot on SKL+. So let's make this new thing work for that.
> Currently we pass intel_plane->plane for the "sprites" and just a
> hardcoded zero for the "primary" planes. We want to get rid of that
> hardocoding so that we can share the same code for all planes (apart
> from the legacy cursor of course).
> 
> [1] 
> https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html
> 
> Cc: Matt Roper 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 28 +---
>  drivers/gpu/drm/i915/intel_display.c |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
>  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
>  4 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 30777dee3f9c..2451b88b1e82 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum transcoder 
> transcoder)
>  }
>  
>  /*
> - * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> - * number of planes per CRTC.  Not all platforms really have this many 
> planes,
> - * which means some arrays of size I915_MAX_PLANES may have unused entries
> - * between the topmost sprite plane and the cursor plane.
> + * Global legacy plane identifier. Valid only for primary/sprite
> + * planes on pre-g4x, and only for primary planes on g4x+.
>   */
>  enum plane {
> - PLANE_A = 0,
> + PLANE_A,
>   PLANE_B,
>   PLANE_C,
> - PLANE_CURSOR,
> - I915_MAX_PLANES,
>  };
>  #define plane_name(p) ((p) + 'A')

And make then non-interchangeable with PLANE_A = 'A', PLANE_B = 'B' etc?

>  #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + 
> (s) + 'A')

But that makes that macro even worse. It was an idea.

>  struct intel_plane {
>   struct drm_plane base;
> - int plane;
> + u8 plane;

enum plane plane ?

-- 
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/9] drm/i915: Remove some duplicated plane swapping logic

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC
> capable plane feeding the LVDS port by default. We have the logic for
> the plane swapping duplicated in many places. Let's remove a bit of the
> duplication by having the crtc look up the thing from the primary plane.

And intel_crtc->plane is just a left over to be removed when we go full
atomic.
 
> Signed-off-by: Ville Syrjälä 
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] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

2016-11-08 Thread Martin Steigerwald
Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > On Mon, 07 Nov 2016, Martin Steigerwald  wrote:
> > > It is also the same kind of corruptions as shown in
> > > 
> > > [Bug 177701] warning in intel_dp_aux_transfer
> > > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > > 
> > > Just compare
> > > 
> > > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > > 
> > > with
> > > 
> > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > > 
> > > 
> > > However that bug report links to
> > > 
> > > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > > 
> > > yet the patch mentioned in there does not fix the issue. So I wonder
> > > whether bug #97344 and bug #177701 are really the same.
> > 
> > They are the same, it's just that #177701 conflates two issues, a
> > warning (tracked at fdo #973449) and a graphics corruption. The latter
> > appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> > 
> > The fix has now been pushed to drm-intel-fixes branch of
> > http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> > latest fixes. Please try that and report back.
> 
> For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes

I ment not exactly this commit, but this is the last commit in the branch as I 
compiled the kernel.

> branch seems to work okay. I can only test with laptop display at the
> moment. But I will test with external display this evening – in case the
> issue at hand is DisplayPort related.
> 
> I will add this information to fdo bug 98402 as well.
> 
> Thanks,
> Martin
> 
> > > Of course I can report a bug at fdo as well, but I am a bit confused
> > > whether it may not already have been reported. Well I hope I get a
> > > chance to report it there as well and you get to decide.
> > 
> > If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> > bug over at the freedesktop.org bugzilla.
> > 
> > BR,
> > Jani.


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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Spin until breadcrumb threads are complete

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

Series: drm/i915: Spin until breadcrumb threads are complete
URL   : https://patchwork.freedesktop.org/series/14977/
State : success

== Summary ==

Series 14977v1 drm/i915: Spin until breadcrumb threads are complete
https://patchwork.freedesktop.org/api/1.0/series/14977/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

9435ffb9ffbfecfa5a429a46af96b1b3fda41d6c drm-intel-nightly: 
2016y-11m-08d-13h-53m-48s UTC integration manifest
bf87b78 drm/i915: Spin until breadcrumb threads are complete

== Logs ==

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


Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

2016-11-08 Thread Martin Steigerwald
Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Steigerwald  wrote:
> > It is also the same kind of corruptions as shown in
> > 
> > [Bug 177701] warning in intel_dp_aux_transfer
> > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > 
> > Just compare
> > 
> > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > 
> > with
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > 
> > However that bug report links to
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > 
> > yet the patch mentioned in there does not fix the issue. So I wonder
> > whether bug #97344 and bug #177701 are really the same.
> 
> They are the same, it's just that #177701 conflates two issues, a
> warning (tracked at fdo #973449) and a graphics corruption. The latter
> appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> 
> The fix has now been pushed to drm-intel-fixes branch of
> http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> latest fixes. Please try that and report back.

For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes 
branch seems to work okay. I can only test with laptop display at the moment. 
But I will test with external display this evening – in case the issue at hand 
is DisplayPort related.

I will add this information to fdo bug 98402 as well.

Thanks,
Martin

> > Of course I can report a bug at fdo as well, but I am a bit confused
> > whether it may not already have been reported. Well I hope I get a
> > chance to report it there as well and you get to decide.
> 
> If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> bug over at the freedesktop.org bugzilla.
> 
> BR,
> Jani.


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


[Intel-gfx] [drm-intel:topic/drm-misc 1/14] warning: (KMEMCHECK && ..) selects STACKTRACE which has unmet direct dependencies (STACKTRACE_SUPPORT)

2016-11-08 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   93ce75fa3dba8781c5c042bd7a61d438662ed73c
commit: 5705670d0463423337c82d00877989e7df8b169d [1/14] drm: Track drm_mm 
allocators and show leaks on shutdown
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5705670d0463423337c82d00877989e7df8b169d
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All warnings (new ones prefixed by >>):

warning: (KMEMCHECK && STACK_TRACER && BLK_DEV_IO_TRACE && STACKDEPOT) selects 
STACKTRACE which has unmet direct dependencies (STACKTRACE_SUPPORT)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/9] drm/i915: Remove some duplicated plane swapping logic

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC
capable plane feeding the LVDS port by default. We have the logic for
the plane swapping duplicated in many places. Let's remove a bit of the
duplication by having the crtc look up the thing from the primary plane.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0bb24b4e8815..10869360cfdc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15000,11 +15000,16 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
state->scaler_id = -1;
}
primary->pipe = pipe;
-   primary->plane = pipe;
+   /*
+* On gen2/3 only plane A can do FBC, but the panel fitter and LVDS
+* port is hooked to pipe B. Hence we want plane A feeding pipe B.
+*/
+   if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4)
+   primary->plane = (enum plane) !pipe;
+   else
+   primary->plane = (enum plane) pipe;
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
primary->check_plane = intel_check_primary_plane;
-   if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4)
-   primary->plane = !pipe;
 
if (INTEL_GEN(dev_priv) >= 9) {
intel_primary_formats = skl_primary_formats;
@@ -15310,16 +15315,8 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
if (ret)
goto fail;
 
-   /*
-* On gen2/3 only plane A can do fbc, but the panel fitter and lvds port
-* is hooked to pipe B. Hence we want plane A feeding pipe B.
-*/
intel_crtc->pipe = pipe;
-   intel_crtc->plane = (enum plane) pipe;
-   if (HAS_FBC(dev_priv) && INTEL_GEN(dev_priv) < 4) {
-   DRM_DEBUG_KMS("swapping pipes & planes for FBC\n");
-   intel_crtc->plane = !pipe;
-   }
+   intel_crtc->plane = primary->plane;
 
intel_crtc->cursor_base = ~0;
intel_crtc->cursor_cntl = ~0;
-- 
2.7.4

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


[Intel-gfx] [PATCH 4/9] drm/i915: Use enum plane_id in SKL wm code

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Nuke skl_wm_plane_id() and just use the new intel_plane->id.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 88e28c989b9c..fd8cbc224b07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2863,28 +2863,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
 #define SKL_SAGV_BLOCK_TIME30 /* µs */
 
 /*
- * Return the index of a plane in the SKL DDB and wm result arrays.  Primary
- * plane is always in slot 0, cursor is always in slot I915_MAX_PLANES-1, and
- * other universal planes are in indices 1..n.  Note that this may leave unused
- * indices between the top "sprite" plane and the cursor.
- */
-static int
-skl_wm_plane_id(const struct intel_plane *plane)
-{
-   switch (plane->base.type) {
-   case DRM_PLANE_TYPE_PRIMARY:
-   return 0;
-   case DRM_PLANE_TYPE_CURSOR:
-   return PLANE_CURSOR;
-   case DRM_PLANE_TYPE_OVERLAY:
-   return plane->plane + 1;
-   default:
-   MISSING_CASE(plane->base.type);
-   return plane->plane;
-   }
-}
-
-/*
  * FIXME: We still don't have the proper code detect if we need to apply the 
WA,
  * so assume we'll always need it in order to avoid underruns.
  */
@@ -3022,7 +3000,6 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
struct intel_crtc *crtc;
struct intel_plane *plane;
struct intel_crtc_state *cstate;
-   struct skl_plane_wm *wm;
enum pipe pipe;
int level, latency;
 
@@ -3049,7 +3026,8 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
return false;
 
for_each_intel_plane_on_crtc(dev, crtc, plane) {
-   wm = >wm.skl.optimal.planes[skl_wm_plane_id(plane)];
+   struct skl_plane_wm *wm =
+   >wm.skl.optimal.planes[plane->id];
 
/* Skip this plane if it's not enabled */
if (!wm->wm[0].plane_en)
@@ -3148,28 +3126,28 @@ static void skl_ddb_entry_init_from_hw(struct 
skl_ddb_entry *entry, u32 reg)
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */)
 {
-   enum pipe pipe;
-   int plane;
+   struct intel_crtc *crtc;
u32 val;
 
memset(ddb, 0, sizeof(*ddb));
 
-   for_each_pipe(dev_priv, pipe) {
+   for_each_intel_crtc(_priv->drm, crtc) {
enum intel_display_power_domain power_domain;
+   enum plane_id plane_id;
+   enum pipe pipe = crtc->pipe;
 
power_domain = POWER_DOMAIN_PIPE(pipe);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
 
-   for_each_universal_plane(dev_priv, pipe, plane) {
-   val = I915_READ(PLANE_BUF_CFG(pipe, plane));
-   skl_ddb_entry_init_from_hw(>plane[pipe][plane],
-  val);
-   }
+   for_each_plane_id_on_crtc(crtc, plane_id) {
+   if (plane_id != PLANE_CURSOR)
+   val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+   else
+   val = I915_READ(CUR_BUF_CFG(pipe));
 
-   val = I915_READ(CUR_BUF_CFG(pipe));
-   skl_ddb_entry_init_from_hw(>plane[pipe][PLANE_CURSOR],
-  val);
+   skl_ddb_entry_init_from_hw(>plane[pipe][plane_id], 
val);
+   }
 
intel_display_power_put(dev_priv, power_domain);
}
@@ -3270,30 +3248,30 @@ skl_get_total_relative_data_rate(struct 
intel_crtc_state *intel_cstate,
struct drm_crtc_state *cstate = _cstate->base;
struct drm_atomic_state *state = cstate->state;
struct drm_plane *plane;
-   const struct intel_plane *intel_plane;
const struct drm_plane_state *pstate;
-   unsigned int rate, total_data_rate = 0;
-   int id;
+   unsigned int total_data_rate = 0;
 
if (WARN_ON(!state))
return 0;
 
/* Calculate and cache data rate for each plane */
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, cstate) {
-   id = skl_wm_plane_id(to_intel_plane(plane));
-   intel_plane = to_intel_plane(plane);
+   enum plane_id plane_id = to_intel_plane(plane)->id;
+   unsigned int rate;
+
+   /* FIXME cursor 

[Intel-gfx] [PATCH 0/9] drm/i915: Add a per-pipe plane identifier enum

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

This series aims to clean up the mess we have with intel_plane->plane
by adding a new intel_plane->id thing. Afterwards the two are clearly
separated so that intel_plane->id is the per-pipe plane identifier,
and intel_plane->plane is the legacy primary plane identifier
(ie. same as intel_plane->pipe everwhere except potentially gen2/3).

Ville Syrjälä (9):
  drm/i915: Remove some duplicated plane swapping logic
  drm/i915: Add per-pipe plane identifier
  drm/i915: Add crtc->plane_ids_mask
  drm/i915: Use enum plane_id in SKL wm code
  drm/i915: Use enum plane_id in SKL plane code
  drm/i915: Use enum plane_id in VLV/CHV sprite code
  drm/i915: Use enum plane_id in VLV/CHV wm code
  drm/i915: Rename the local 'plane' variable to 'plane_id' in primary
plane code
  drm/i915: Don't populate plane->plane for cursors and sprites

 drivers/gpu/drm/i915/i915_drv.h  |  30 -
 drivers/gpu/drm/i915/i915_reg.h  |  58 +
 drivers/gpu/drm/i915/intel_display.c | 118 +-
 drivers/gpu/drm/i915/intel_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 229 +++
 drivers/gpu/drm/i915/intel_sprite.c  | 126 +--
 6 files changed, 282 insertions(+), 285 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH 8/9] drm/i915: Rename the local 'plane' variable to 'plane_id' in primary plane code

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Now we've rename the local plane id variable as 'plane_id' everywhere
except the pre-SKL primary plane code. Let's do the rename there as well
so that we'll free up the name 'plane' for use with struct intel_plane*.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 95644c8cc568..bd084b085421 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3014,10 +3014,9 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
-   int plane = intel_crtc->plane;
+   enum plane plane_id = to_intel_plane(primary)->plane;
u32 linear_offset;
u32 dspcntr;
-   i915_reg_t reg = DSPCNTR(plane);
unsigned int rotation = plane_state->base.rotation;
int x = plane_state->base.src.x1 >> 16;
int y = plane_state->base.src.y1 >> 16;
@@ -3033,16 +3032,16 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
/* pipesrc and dspsize control the size that is scaled from,
 * which should always be the user's requested size.
 */
-   I915_WRITE(DSPSIZE(plane),
+   I915_WRITE(DSPSIZE(plane_id),
   ((crtc_state->pipe_src_h - 1) << 16) |
   (crtc_state->pipe_src_w - 1));
-   I915_WRITE(DSPPOS(plane), 0);
-   } else if (IS_CHERRYVIEW(dev_priv) && plane == PLANE_B) {
-   I915_WRITE(PRIMSIZE(plane),
+   I915_WRITE(DSPPOS(plane_id), 0);
+   } else if (IS_CHERRYVIEW(dev_priv) && plane_id == PLANE_B) {
+   I915_WRITE(PRIMSIZE(plane_id),
   ((crtc_state->pipe_src_h - 1) << 16) |
   (crtc_state->pipe_src_w - 1));
-   I915_WRITE(PRIMPOS(plane), 0);
-   I915_WRITE(PRIMCNSTALPHA(plane), 0);
+   I915_WRITE(PRIMPOS(plane_id), 0);
+   I915_WRITE(PRIMCNSTALPHA(plane_id), 0);
}
 
switch (fb->pixel_format) {
@@ -3099,21 +3098,21 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
intel_crtc->adjusted_x = x;
intel_crtc->adjusted_y = y;
 
-   I915_WRITE(reg, dspcntr);
+   I915_WRITE(DSPCNTR(plane_id), dspcntr);
 
-   I915_WRITE(DSPSTRIDE(plane), fb->pitches[0]);
+   I915_WRITE(DSPSTRIDE(plane_id), fb->pitches[0]);
if (INTEL_INFO(dev)->gen >= 4) {
-   I915_WRITE(DSPSURF(plane),
+   I915_WRITE(DSPSURF(plane_id),
   intel_fb_gtt_offset(fb, rotation) +
   intel_crtc->dspaddr_offset);
-   I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
-   I915_WRITE(DSPLINOFF(plane), linear_offset);
+   I915_WRITE(DSPTILEOFF(plane_id), (y << 16) | x);
+   I915_WRITE(DSPLINOFF(plane_id), linear_offset);
} else {
-   I915_WRITE(DSPADDR(plane),
+   I915_WRITE(DSPADDR(plane_id),
   intel_fb_gtt_offset(fb, rotation) +
   intel_crtc->dspaddr_offset);
}
-   POSTING_READ(reg);
+   POSTING_READ(DSPCNTR(plane_id));
 }
 
 static void i9xx_disable_primary_plane(struct drm_plane *primary,
@@ -3121,15 +3120,14 @@ static void i9xx_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);
-   int plane = intel_crtc->plane;
+   enum plane plane_id = to_intel_plane(primary)->plane;
 
-   I915_WRITE(DSPCNTR(plane), 0);
+   I915_WRITE(DSPCNTR(plane_id), 0);
if (INTEL_INFO(dev_priv)->gen >= 4)
-   I915_WRITE(DSPSURF(plane), 0);
+   I915_WRITE(DSPSURF(plane_id), 0);
else
-   I915_WRITE(DSPADDR(plane), 0);
-   POSTING_READ(DSPCNTR(plane));
+   I915_WRITE(DSPADDR(plane_id), 0);
+   POSTING_READ(DSPCNTR(plane_id));
 }
 
 static void ironlake_update_primary_plane(struct drm_plane *primary,
@@ -3140,10 +3138,9 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
-   int plane = intel_crtc->plane;
+   enum plane plane_id = to_intel_plane(primary)->plane;
u32 linear_offset;
u32 dspcntr;

[Intel-gfx] [PATCH 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Use intel_plane->id to derive the VLV/CHV sprite register offsets
instead of abusing plane->plane which is really meant to for
primary planes only.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h | 58 -
 drivers/gpu/drm/i915/intel_sprite.c | 74 ++---
 2 files changed, 69 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3361d7ffc63e..9739e97c6263 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5374,18 +5374,21 @@ enum {
 #define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
 #define _SPBGAMC   (VLV_DISPLAY_BASE + 0x722f4)
 
-#define SPCNTR(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPACNTR, 
_SPBCNTR)
-#define SPLINOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPALINOFF, 
_SPBLINOFF)
-#define SPSTRIDE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASTRIDE, 
_SPBSTRIDE)
-#define SPPOS(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAPOS, _SPBPOS)
-#define SPSIZE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASIZE, 
_SPBSIZE)
-#define SPKEYMINVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
_SPAKEYMINVAL, _SPBKEYMINVAL)
-#define SPKEYMSK(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAKEYMSK, 
_SPBKEYMSK)
-#define SPSURF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPASURF, 
_SPBSURF)
-#define SPKEYMAXVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
_SPAKEYMAXVAL, _SPBKEYMAXVAL)
-#define SPTILEOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPATILEOFF, 
_SPBTILEOFF)
-#define SPCONSTALPHA(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), 
_SPACONSTALPHA, _SPBCONSTALPHA)
-#define SPGAMC(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAGAMC, 
_SPBGAMC)
+#define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) \
+   _MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a), (reg_b))
+
+#define SPCNTR(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPACNTR, _SPBCNTR)
+#define SPLINOFF(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPALINOFF, _SPBLINOFF)
+#define SPSTRIDE(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPASTRIDE, _SPBSTRIDE)
+#define SPPOS(pipe, plane) _MMIO_VLV_SPR((pipe), (plane), _SPAPOS, 
_SPBPOS)
+#define SPSIZE(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPASIZE, _SPBSIZE)
+#define SPKEYMINVAL(pipe, plane)   _MMIO_VLV_SPR((pipe), (plane), 
_SPAKEYMINVAL, _SPBKEYMINVAL)
+#define SPKEYMSK(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPAKEYMSK, _SPBKEYMSK)
+#define SPSURF(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPASURF, _SPBSURF)
+#define SPKEYMAXVAL(pipe, plane)   _MMIO_VLV_SPR((pipe), (plane), 
_SPAKEYMAXVAL, _SPBKEYMAXVAL)
+#define SPTILEOFF(pipe, plane) _MMIO_VLV_SPR((pipe), (plane), 
_SPATILEOFF, _SPBTILEOFF)
+#define SPCONSTALPHA(pipe, plane)  _MMIO_VLV_SPR((pipe), (plane), 
_SPACONSTALPHA, _SPBCONSTALPHA)
+#define SPGAMC(pipe, plane)_MMIO_VLV_SPR((pipe), (plane), 
_SPAGAMC, _SPBGAMC)
 
 /*
  * CHV pipe B sprite CSC
@@ -5394,29 +5397,32 @@ enum {
  * |yg| = |c3 c4 c5| x |yg + yg_ioff| + |yg_ooff|
  * |cb|   |c6 c7 c8|   |cb + cr_ioff|   |cb_ooff|
  */
-#define SPCSCYGOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d900 + (sprite) * 
0x1000)
-#define SPCSCCBOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d904 + (sprite) * 
0x1000)
-#define SPCSCCROFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d908 + (sprite) * 
0x1000)
+#define _MMIO_CHV_SPCSC(plane, reg) \
+   _MMIO(VLV_DISPLAY_BASE + ((plane) - PLANE_SPRITE0) * 0x1000 + (reg))
+
+#define SPCSCYGOFF(plane)  _MMIO_CHV_SPCSC(plane, 0x6d900)
+#define SPCSCCBOFF(plane)  _MMIO_CHV_SPCSC(plane, 0x6d904)
+#define SPCSCCROFF(plane)  _MMIO_CHV_SPCSC(plane, 0x6d908)
 #define  SPCSC_OOFF(x) (((x) & 0x7ff) << 16) /* s11 */
 #define  SPCSC_IOFF(x) (((x) & 0x7ff) << 0) /* s11 */
 
-#define SPCSCC01(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d90c + (sprite) * 
0x1000)
-#define SPCSCC23(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d910 + (sprite) * 
0x1000)
-#define SPCSCC45(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d914 + (sprite) * 
0x1000)
-#define SPCSCC67(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d918 + (sprite) * 
0x1000)
-#define SPCSCC8(sprite)_MMIO(VLV_DISPLAY_BASE + 0x6d91c + 
(sprite) * 0x1000)
+#define SPCSCC01(plane)_MMIO_CHV_SPCSC(plane, 0x6d90c)
+#define SPCSCC23(plane)_MMIO_CHV_SPCSC(plane, 0x6d910)
+#define SPCSCC45(plane)_MMIO_CHV_SPCSC(plane, 0x6d914)
+#define SPCSCC67(plane)_MMIO_CHV_SPCSC(plane, 0x6d918)
+#define SPCSCC8(plane) _MMIO_CHV_SPCSC(plane, 0x6d91c)
 #define  SPCSC_C1(x)   (((x) & 0x7fff) << 16) /* s3.12 */
 #define  SPCSC_C0(x)   (((x) & 0x7fff) << 0) /* s3.12 */
 
-#define 

Re: [Intel-gfx] [PATCH] drm/i915: avoid harmless empty-body warning

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote:
> The newly added assert_kernel_context_is_current introduces a warning
> when built with W=1:
> 
> drivers/gpu/drm/i915/i915_gem.c: In function 
> ‘assert_kernel_context_is_current’:
> drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty 
> body in an ‘else’ statement [-Werror=empty-body]
> 
> Changing the GEM_BUG_ON() macro from an empty definition to "do { } while (0)"
> makes the macro more robust to use and avoids the warning.
> 
> Fixes: 3033acab07f9 ("drm/i915: Queue the idling context switch after all 
> other timelines")
> Signed-off-by: Arnd Bergmann 
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 9/9] drm/i915: Don't populate plane->plane for cursors and sprites

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

With plane->plane now purely reserved for the primary planes, let's
not even populate it for cursors and sprites. Let's switch the type
to enum plane as well since it's no longer being abused for anything
else.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bd084b085421..2174593e5ef5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15202,7 +15202,6 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
cursor->can_scale = false;
cursor->max_downscale = 1;
cursor->pipe = pipe;
-   cursor->plane = pipe;
cursor->id = PLANE_CURSOR;
cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
cursor->check_plane = intel_check_cursor_plane;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a3c696d8bf93..aaef98fed79f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -768,7 +768,7 @@ struct intel_plane_wm_parameters {
 
 struct intel_plane {
struct drm_plane base;
-   u8 plane;
+   enum plane plane;
enum plane_id id;
enum pipe pipe;
bool can_scale;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index a922c6382fc7..22489c11c86e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1125,7 +1125,6 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
}
 
intel_plane->pipe = pipe;
-   intel_plane->plane = plane;
intel_plane->id = PLANE_SPRITE0 + plane;
intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER_SPRITE(pipe, plane);
intel_plane->check_plane = intel_check_sprite_plane;
-- 
2.7.4

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


[Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Let's try not to abuse plane->plane for sprites on VLV/CHV and instead
use plane->id. Since out watermark structures aren't entirely plane type
agnostic (for now) and start indexing sprites from 0  we'll add a small
helper to convert between the two bases.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 73 -
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fd8cbc224b07..b1ad09e458ca 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -371,12 +371,15 @@ static const int pessimal_latency_ns = 5000;
 #define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
dsparb) >> (lo_shift)) & 0xff) | dsparb2) >> (hi_shift)) & 0x1) 
<< 8))
 
-static int vlv_get_fifo_size(struct drm_i915_private *dev_priv,
- enum pipe pipe, int plane)
+static int vlv_get_fifo_size(struct intel_plane *plane)
 {
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
int sprite0_start, sprite1_start, size;
 
-   switch (pipe) {
+   if (plane->id == PLANE_CURSOR)
+   return 63;
+
+   switch (plane->pipe) {
uint32_t dsparb, dsparb2, dsparb3;
case PIPE_A:
dsparb = I915_READ(DSPARB);
@@ -400,24 +403,21 @@ static int vlv_get_fifo_size(struct drm_i915_private 
*dev_priv,
return 0;
}
 
-   switch (plane) {
-   case 0:
+   switch (plane->id) {
+   case PLANE_PRIMARY:
size = sprite0_start;
break;
-   case 1:
+   case PLANE_SPRITE0:
size = sprite1_start - sprite0_start;
break;
-   case 2:
+   case PLANE_SPRITE1:
size = 512 - 1 - sprite1_start;
break;
default:
return 0;
}
 
-   DRM_DEBUG_KMS("Pipe %c %s %c FIFO size: %d\n",
- pipe_name(pipe), plane == 0 ? "primary" : "sprite",
- plane == 0 ? plane_name(pipe) : sprite_name(pipe, plane - 
1),
- size);
+   DRM_DEBUG_KMS("%s FIFO size: %d\n", plane->base.name, size);
 
return size;
 }
@@ -1054,6 +1054,12 @@ static void vlv_compute_fifo(struct intel_crtc *crtc)
WARN_ON(fifo_left != 0);
 }
 
+/* FIXME kill me */
+static inline int vlv_sprite_id(enum plane_id plane_id)
+{
+   return plane_id - PLANE_SPRITE0;
+}
+
 static void vlv_invert_wms(struct intel_crtc *crtc)
 {
struct vlv_wm_state *wm_state = >wm_state;
@@ -1079,7 +1085,7 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
wm_state->wm[level].primary;
break;
case DRM_PLANE_TYPE_OVERLAY:
-   sprite = plane->plane;
+   sprite = vlv_sprite_id(plane->id);
wm_state->wm[level].sprite[sprite] = 
plane->wm.fifo_size -
wm_state->wm[level].sprite[sprite];
break;
@@ -1143,7 +1149,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
wm_state->wm[level].primary = wm;
break;
case DRM_PLANE_TYPE_OVERLAY:
-   sprite = plane->plane;
+   sprite = vlv_sprite_id(plane->id);
wm_state->wm[level].sprite[sprite] = wm;
break;
}
@@ -1169,7 +1175,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
wm_state->wm[level].primary);
break;
case DRM_PLANE_TYPE_OVERLAY:
-   sprite = plane->plane;
+   sprite = vlv_sprite_id(plane->id);
for (level = 0; level < wm_state->num_levels; level++)
wm_state->sr[level].plane =
min(wm_state->sr[level].plane,
@@ -1198,17 +1204,23 @@ static void vlv_pipe_set_fifo_size(struct intel_crtc 
*crtc)
int sprite0_start = 0, sprite1_start = 0, fifo_size = 0;
 
for_each_intel_plane_on_crtc(dev, crtc, plane) {
-   if (plane->base.type == DRM_PLANE_TYPE_CURSOR) {
-   WARN_ON(plane->wm.fifo_size != 63);
-   continue;
-   }
-
-   if (plane->base.type == DRM_PLANE_TYPE_PRIMARY)
+   switch (plane->id) {
+   case PLANE_PRIMARY:
sprite0_start = plane->wm.fifo_size;
-   else if (plane->plane == 0)
+   break;
+   

[Intel-gfx] [PATCH 5/9] drm/i915: Use enum plane_id in SKL plane code

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane
code with intel_plane->id.

This should make the SKL "primary" and "sprite" code virtually
identical, so the next logical step would likely be dropping one
of the copies.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 34 
 drivers/gpu/drm/i915/intel_sprite.c  | 50 ++--
 2 files changed, 43 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e3ed5d1fcf0d..95644c8cc568 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3384,9 +3384,10 @@ static void skylake_update_primary_plane(struct 
drm_plane *plane,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
+   enum plane_id plane_id = to_intel_plane(plane)->id;
const struct skl_wm_values *wm = _priv->wm.skl_results;
const struct skl_plane_wm *p_wm =
-   _state->wm.skl.optimal.planes[0];
+   _state->wm.skl.optimal.planes[plane_id];
int pipe = intel_crtc->pipe;
u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
@@ -3423,32 +3424,32 @@ 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, p_wm, >ddb, 0);
+   skl_write_plane_wm(intel_crtc, p_wm, >ddb, plane_id);
 
-   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
-   I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
-   I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
-   I915_WRITE(PLANE_SIZE(pipe, 0), (src_h << 16) | src_w);
+   I915_WRITE(PLANE_CTL(pipe, plane_id), plane_ctl);
+   I915_WRITE(PLANE_OFFSET(pipe, plane_id), (src_y << 16) | src_x);
+   I915_WRITE(PLANE_STRIDE(pipe, plane_id), stride);
+   I915_WRITE(PLANE_SIZE(pipe, plane_id), (src_h << 16) | src_w);
 
if (scaler_id >= 0) {
uint32_t ps_ctrl = 0;
 
WARN_ON(!dst_w || !dst_h);
-   ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(0) |
+   ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
crtc_state->scaler_state.scalers[scaler_id].mode;
I915_WRITE(SKL_PS_CTRL(pipe, scaler_id), ps_ctrl);
I915_WRITE(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
I915_WRITE(SKL_PS_WIN_POS(pipe, scaler_id), (dst_x << 16) | 
dst_y);
I915_WRITE(SKL_PS_WIN_SZ(pipe, scaler_id), (dst_w << 16) | 
dst_h);
-   I915_WRITE(PLANE_POS(pipe, 0), 0);
+   I915_WRITE(PLANE_POS(pipe, plane_id), 0);
} else {
-   I915_WRITE(PLANE_POS(pipe, 0), (dst_y << 16) | dst_x);
+   I915_WRITE(PLANE_POS(pipe, plane_id), (dst_y << 16) | dst_x);
}
 
-   I915_WRITE(PLANE_SURF(pipe, 0),
+   I915_WRITE(PLANE_SURF(pipe, plane_id),
   intel_fb_gtt_offset(fb, rotation) + surf_addr);
 
-   POSTING_READ(PLANE_SURF(pipe, 0));
+   POSTING_READ(PLANE_SURF(pipe, plane_id));
 }
 
 static void skylake_disable_primary_plane(struct drm_plane *primary,
@@ -3458,7 +3459,8 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
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];
+   enum plane_id plane_id = to_intel_plane(primary)->id;
+   const struct skl_plane_wm *p_wm = 
>wm.skl.optimal.planes[plane_id];
int pipe = intel_crtc->pipe;
 
/*
@@ -3467,11 +3469,11 @@ static void skylake_disable_primary_plane(struct 
drm_plane *primary,
 */
if (!crtc->primary->state->visible)
skl_write_plane_wm(intel_crtc, p_wm,
-  _priv->wm.skl_results.ddb, 0);
+  _priv->wm.skl_results.ddb, plane_id);
 
-   I915_WRITE(PLANE_CTL(pipe, 0), 0);
-   I915_WRITE(PLANE_SURF(pipe, 0), 0);
-   POSTING_READ(PLANE_SURF(pipe, 0));
+   I915_WRITE(PLANE_CTL(pipe, plane_id), 0);
+   I915_WRITE(PLANE_SURF(pipe, plane_id), 0);
+   POSTING_READ(PLANE_SURF(pipe, plane_id));
 }
 
 /* Assume fb object is pinned & idle & fenced and just update base pointers */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 4b44863a07c2..91d47d19f4a9 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -203,13 +203,13 @@ 

[Intel-gfx] [PATCH 3/9] drm/i915: Add crtc->plane_ids_mask

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

Add a mask of which planes are available for each pipe. This doesn't
quite work for old platforms with dynamic plane<->pipe assignment, but
as we don't support that sort of stuff (yet) we can get away with it.

The main use I have for this is the for_each_plane_id_on_crtc() macro
for iterating over all possible planes on the crtc. I suppose we could
not add the mask, and instead iterate by comparing intel_plane->pipe
but then we'd need a local intel_plane variable which is just
unnecessary clutter in some cases. But I'm not hung up on this, so if
people prefer the other option I could be convinced to use it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  | 4 
 drivers/gpu/drm/i915/intel_display.c | 3 +++
 drivers/gpu/drm/i915/intel_drv.h | 3 ++-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2451b88b1e82..2325efacbd5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -201,6 +201,10 @@ enum plane_id {
I915_MAX_PLANES,
 };
 
+#define for_each_plane_id_on_crtc(__crtc, __p) \
+   for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
+   for_each_if ((__crtc)->plane_ids_mask & (1 << (__p)))
+
 enum port {
PORT_NONE = -1,
PORT_A = 0,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b318119330e8..e3ed5d1fcf0d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15293,6 +15293,7 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
ret = PTR_ERR(primary);
goto fail;
}
+   intel_crtc->plane_ids_mask |= BIT(primary->id);
 
for_each_sprite(dev_priv, pipe, sprite) {
struct intel_plane *plane;
@@ -15302,6 +15303,7 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
ret = PTR_ERR(plane);
goto fail;
}
+   intel_crtc->plane_ids_mask |= BIT(plane->id);
}
 
cursor = intel_cursor_plane_create(dev_priv, pipe);
@@ -15309,6 +15311,7 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
ret = PTR_ERR(cursor);
goto fail;
}
+   intel_crtc->plane_ids_mask |= BIT(cursor->id);
 
ret = drm_crtc_init_with_planes(_priv->drm, _crtc->base,
>base, >base,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 58fc8e1d2aa8..a3c696d8bf93 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -689,8 +689,9 @@ struct intel_crtc {
 * some outputs connected to this crtc.
 */
bool active;
-   unsigned long enabled_power_domains;
bool lowfreq_avail;
+   u8 plane_ids_mask;
+   unsigned long enabled_power_domains;
struct intel_overlay *overlay;
struct intel_flip_work *flip_work;
 
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

2016-11-08 Thread ville . syrjala
From: Ville Syrjälä 

As I told people in [1] we really should not be confusing enum plane
as a per-pipe plane identifier. Looks like that happened nonetheless, so
let's fix it up by splitting the two into two enums.

We'll also want something we just directly pass to various register
offset macros and whatnot on SKL+. So let's make this new thing work for that.
Currently we pass intel_plane->plane for the "sprites" and just a
hardcoded zero for the "primary" planes. We want to get rid of that
hardocoding so that we can share the same code for all planes (apart
from the legacy cursor of course).

[1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html

Cc: Matt Roper 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  | 28 +---
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  1 +
 4 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30777dee3f9c..2451b88b1e82 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum transcoder 
transcoder)
 }
 
 /*
- * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
- * number of planes per CRTC.  Not all platforms really have this many planes,
- * which means some arrays of size I915_MAX_PLANES may have unused entries
- * between the topmost sprite plane and the cursor plane.
+ * Global legacy plane identifier. Valid only for primary/sprite
+ * planes on pre-g4x, and only for primary planes on g4x+.
  */
 enum plane {
-   PLANE_A = 0,
+   PLANE_A,
PLANE_B,
PLANE_C,
-   PLANE_CURSOR,
-   I915_MAX_PLANES,
 };
 #define plane_name(p) ((p) + 'A')
 
 #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] + (s) 
+ 'A')
 
+/*
+ * Per-pipe plane identifier.
+ * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
+ * number of planes per CRTC.  Not all platforms really have this many planes,
+ * which means some arrays of size I915_MAX_PLANES may have unused entries
+ * between the topmost sprite plane and the cursor plane.
+ *
+ * This is expected to be passed to various register macros
+ * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
+ */
+enum plane_id {
+   PLANE_PRIMARY,
+   PLANE_SPRITE0,
+   PLANE_SPRITE1,
+   PLANE_CURSOR,
+   I915_MAX_PLANES,
+};
+
 enum port {
PORT_NONE = -1,
PORT_A = 0,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 10869360cfdc..b318119330e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15008,6 +15008,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
primary->plane = (enum plane) !pipe;
else
primary->plane = (enum plane) pipe;
+   primary->id = PLANE_PRIMARY;
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
primary->check_plane = intel_check_primary_plane;
 
@@ -15203,6 +15204,7 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
cursor->max_downscale = 1;
cursor->pipe = pipe;
cursor->plane = pipe;
+   cursor->id = PLANE_CURSOR;
cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
cursor->check_plane = intel_check_cursor_plane;
cursor->update_plane = intel_update_cursor_plane;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 398195bf6dd1..58fc8e1d2aa8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -767,7 +767,8 @@ struct intel_plane_wm_parameters {
 
 struct intel_plane {
struct drm_plane base;
-   int plane;
+   u8 plane;
+   enum plane_id id;
enum pipe pipe;
bool can_scale;
int max_downscale;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 5e4eb7cafef0..4b44863a07c2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1126,6 +1126,7 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
 
intel_plane->pipe = pipe;
intel_plane->plane = plane;
+   intel_plane->id = PLANE_SPRITE0 + plane;
intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER_SPRITE(pipe, plane);
intel_plane->check_plane = intel_check_sprite_plane;
 
-- 
2.7.4

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


[Intel-gfx] [PATCH] drm/i915: Spin until breadcrumb threads are complete

2016-11-08 Thread Chris Wilson
When we need to reset the global seqno on wraparound, we have to wait
until the current rbtrees are drained (or otherwise the next waiter will
be out of sequence). The current mechanism to kick and spin until
complete, may exit too early as it would break if the target thread was
currently running. Instead, we must wake up the threads, but keep
spinning until the trees have been deleted.

In order to appease Tvrtko, busy spin rather than yield().

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c  |  5 ++---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 31 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  3 +--
 3 files changed, 15 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index d866069c1767..6c71637d4be1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -319,9 +319,8 @@ static int i915_gem_init_global_seqno(struct 
drm_i915_private *i915, u32 seqno)
 
/* If the seqno wraps around, we need to clear the breadcrumb rbtree */
if (!i915_seqno_passed(seqno, atomic_read(>next_seqno))) {
-   while (intel_kick_waiters(i915) || intel_kick_signalers(i915))
-   yield();
-   yield();
+   while (intel_breadcrumbs_busy(i915))
+   cond_resched(); /* spin until threads are complete */
}
atomic_set(>next_seqno, seqno);
 
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index c410d3d6465f..c9c46a538edb 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -629,35 +629,28 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs 
*engine)
cancel_fake_irq(engine);
 }
 
-unsigned int intel_kick_waiters(struct drm_i915_private *i915)
+unsigned int intel_breadcrumbs_busy(struct drm_i915_private *i915)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
unsigned int mask = 0;
 
-   /* To avoid the task_struct disappearing beneath us as we wake up
-* the process, we must first inspect the task_struct->state under the
-* RCU lock, i.e. as we call wake_up_process() we must be holding the
-* rcu_read_lock().
-*/
-   for_each_engine(engine, i915, id)
-   if (unlikely(intel_engine_wakeup(engine)))
-   mask |= intel_engine_flag(engine);
+   for_each_engine(engine, i915, id) {
+   struct intel_breadcrumbs *b = >breadcrumbs;
 
-   return mask;
-}
+   spin_lock_irq(>lock);
 
-unsigned int intel_kick_signalers(struct drm_i915_private *i915)
-{
-   struct intel_engine_cs *engine;
-   enum intel_engine_id id;
-   unsigned int mask = 0;
+   if (b->first_wait) {
+   wake_up_process(b->first_wait->tsk);
+   mask |= intel_engine_flag(engine);
+   }
 
-   for_each_engine(engine, i915, id) {
-   if (unlikely(READ_ONCE(engine->breadcrumbs.first_signal))) {
-   wake_up_process(engine->breadcrumbs.signaler);
+   if (b->first_signal) {
+   wake_up_process(b->signaler);
mask |= intel_engine_flag(engine);
}
+
+   spin_unlock_irq(>lock);
}
 
return mask;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index cbc148863a03..3466b4e77e7c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -587,7 +587,6 @@ static inline bool intel_engine_wakeup(const struct 
intel_engine_cs *engine)
 
 void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-unsigned int intel_kick_waiters(struct drm_i915_private *i915);
-unsigned int intel_kick_signalers(struct drm_i915_private *i915);
+unsigned int intel_breadcrumbs_busy(struct drm_i915_private *i915);
 
 #endif /* _INTEL_RINGBUFFER_H_ */
-- 
2.10.2

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


Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

2016-11-08 Thread Peter Zijlstra
On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > FIXME: Add owner of second tree to To:
> >Add author(s)/SOB of conflicting commits.
> > 
> > Today's linux-next merge of the tip tree got a conflict in:
> > 
> >   drivers/gpu/drm/i915/i915_gem_shrinker.c
> > 
> > between commits:
> > 
> >   1233e2db199d ("drm/i915: Move object backing storage manipulation to its 
> > own locking")
> > 
> > from the drm-intel tree and commit:
> > 
> >   3ab7c086d5ec ("locking/drm: Kill mutex trickery")
> >   c7faee2109f9 ("locking/drm: Fix i915_gem_shrinker_lock() locking")
> 
> Hm, this seems to be the older versions that nuke the recursive locking
> trickery entirely, I thought we had version in-flight that kept that? I
> know that the i915 (and msm locking fwiw) is horrible since essentially
> it's a recursive BKL, and we're working (slowly, after all getting rid of
> the BKL wasn't simple either) to fix this. But meanwhile I'm assuming that
> we'll still need this to be able to get out of low memory situations in
> i915. Has that part simply not yet landed?

You're talking about:

  lkml.kernel.org/r/20161007154351.gl3...@twins.programming.kicks-ass.net

? I got no feedback from you DRM guys on that so I kinda forgot about
that in the hope we'd not have to do this at all.

I can try and resurrect, that I suppose.

Now, I know you're working on getting rid of this entirely for i915, but
what about that MSM driver? Will we continue to need it there, is
anybody actually maintaining that thing?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote:
> This is a hack and not needed. Use the right mask by checking
> intel_state->modeset. This works for watermark sanitization too.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 38 +++---
>  1 file changed, 15 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 02f52b52a03d..d38a46efcfed 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3089,26 +3089,22 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct drm_crtc *for_crtc = cstate->base.crtc;
> - unsigned int pipe_size, ddb_size;
> + unsigned int pipe_size, ddb_size, active_crtcs;
>   int nth_active_pipe;
>  
> + if (intel_state->modeset)
> + active_crtcs = intel_state->active_crtcs;
> + else
> + active_crtcs = dev_priv->active_crtcs;

What's the story with the locking here?

> +
> + *num_active = hweight32(active_crtcs);
> +
>   if (WARN_ON(!state) || !cstate->base.active) {
>   alloc->start = 0;
>   alloc->end = 0;
> - *num_active = hweight32(dev_priv->active_crtcs);
>   return;
>   }
>  
> - if (intel_state->active_pipe_changes)
> - *num_active = hweight32(intel_state->active_crtcs);
> - else
> - *num_active = hweight32(dev_priv->active_crtcs);
> -
> - ddb_size = INTEL_INFO(dev_priv)->ddb_size;
> - WARN_ON(ddb_size == 0);
> -
> - ddb_size -= 4; /* 4 blocks for bypass path allocation */
> -
>   /*
>* If the state doesn't change the active CRTC's, then there's
>* no need to recalculate; the existing pipe allocation limits
> @@ -3126,9 +3122,14 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
> *dev,
>   return;
>   }
>  
> - nth_active_pipe = hweight32(intel_state->active_crtcs &
> + ddb_size = INTEL_INFO(dev_priv)->ddb_size;
> + WARN_ON(ddb_size == 0);
> +
> + ddb_size -= 4; /* 4 blocks for bypass path allocation */
> +
> + nth_active_pipe = hweight32(active_crtcs &
>   (drm_crtc_mask(for_crtc) - 1));
> - pipe_size = ddb_size / hweight32(intel_state->active_crtcs);
> + pipe_size = ddb_size / *num_active;
>   alloc->start = nth_active_pipe * ddb_size / *num_active;
>   alloc->end = alloc->start + pipe_size;
>  }
> @@ -4021,15 +4022,6 @@ skl_compute_ddb(struct drm_atomic_state *state)
>   return ret;
>  
>   intel_state->active_pipe_changes = ~0;
> -
> - /*
> -  * We usually only initialize intel_state->active_crtcs if we
> -  * we're doing a modeset; make sure this field is always
> -  * initialized during the sanitization process that happens
> -  * on the first commit too.
> -  */
> - if (!intel_state->modeset)
> - intel_state->active_crtcs = dev_priv->active_crtcs;
>   }
>  
>   /*
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 v3 09/11] drm/i915: Update atomic modeset state synchronously, v2.

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 01:55:40PM +0100, Maarten Lankhorst wrote:
> All of this state should be updated as soon as possible. It shouldn't be
> done later because then future updates may not depend on it.
> 
> Changes since v1:
> - Move the modeset update to before drm_atomic_state_get. (Ville)
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e59adb03933e..d368afa199e3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14353,14 +14353,8 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   drm_atomic_helper_wait_for_dependencies(state);
>  
> - if (intel_state->modeset) {
> - memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
> -sizeof(intel_state->min_pixclk));
> - dev_priv->active_crtcs = intel_state->active_crtcs;
> - dev_priv->atomic_cdclk_freq = intel_state->cdclk;
> -
> + if (intel_state->modeset)
>   intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
> - }
>  
>   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> @@ -14601,6 +14595,13 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>   intel_shared_dpll_commit(state);
>   intel_atomic_track_fbs(state);
>  
> + if (intel_state->modeset) {
> + memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
> +sizeof(intel_state->min_pixclk));
> + dev_priv->active_crtcs = intel_state->active_crtcs;
> + dev_priv->atomic_cdclk_freq = intel_state->cdclk;
> + }
> +
>   drm_atomic_state_get(state);
>   INIT_WORK(>commit_work,
> nonblock ? intel_atomic_commit_work : NULL);
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 v3 07/11] drm/i915: Pass atomic state to intel_audio_codec_enable, v2.

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 01:55:38PM +0100, Maarten Lankhorst wrote:
> drm_select_eld requires mode_config.mutex and connection_mutex
> because it looks at the connector list and at the legacy encoders.
> 
> This is not required, because when we call audio_codec_enable we know
> which connector it was called for, so pass the state.
> 
> This also removes having to look at crtc->config.
> 
> Changes since v1:
> - Use intel_crtc->pipe instead of drm_crtc_index. (Ville)
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_audio.c | 17 ++---
>  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
>  drivers/gpu/drm/i915/intel_dp.c| 11 ++-
>  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
>  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
>  5 files changed, 21 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 813fd74d9c8d..1c509f7410f5 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -574,23 +574,26 @@ static void ilk_audio_codec_enable(struct drm_connector 
> *connector,
>  /**
>   * intel_audio_codec_enable - Enable the audio codec for HD audio
>   * @intel_encoder: encoder on which to enable audio
> + * @crtc_state: pointer to the current crtc state.
> + * @conn_state: pointer to the current connector state.
>   *
>   * The enable sequences may only be performed after enabling the transcoder 
> and
>   * port, and after completed link training.
>   */
> -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
> +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
> +   const struct intel_crtc_state *crtc_state,
> +   const struct drm_connector_state *conn_state)
>  {
>   struct drm_encoder *encoder = _encoder->base;
> - struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> - const struct drm_display_mode *adjusted_mode = 
> >config->base.adjusted_mode;
> + const struct drm_display_mode *adjusted_mode = 
> _state->base.adjusted_mode;
>   struct drm_connector *connector;
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   enum port port = intel_encoder->port;
> - enum pipe pipe = crtc->pipe;
> + enum pipe pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
>  
> - connector = drm_select_eld(encoder);
> - if (!connector)
> + connector = conn_state->connector;
> + if (!connector || !connector->eld[0])
>   return;
>  
>   DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> @@ -601,7 +604,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>  
>   /* ELD Conn_Type */
>   connector->eld[5] &= ~(3 << 2);
> - if (intel_crtc_has_dp_encoder(crtc->config))
> + if (intel_crtc_has_dp_encoder(crtc_state))
>   connector->eld[5] |= (1 << 2);
>  
>   connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 938ac4dbcb45..0ad4e16a639f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1866,7 +1866,7 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>  
>   if (intel_crtc->config->has_audio) {
>   intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
> - intel_audio_codec_enable(intel_encoder);
> + intel_audio_codec_enable(intel_encoder, pipe_config, 
> conn_state);
>   }
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9df331b3305b..117a71450ec2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2735,7 +2735,8 @@ static void intel_dp_enable_port(struct intel_dp 
> *intel_dp,
>  }
>  
>  static void intel_enable_dp(struct intel_encoder *encoder,
> - struct intel_crtc_state *pipe_config)
> + struct intel_crtc_state *pipe_config,
> + struct drm_connector_state *conn_state)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct drm_device *dev = encoder->base.dev;
> @@ -2777,7 +2778,7 @@ static void intel_enable_dp(struct intel_encoder 
> *encoder,
>   if (pipe_config->has_audio) {
>   DRM_DEBUG_DRIVER("Enabling DP audio on pipe %c\n",
>pipe_name(pipe));
> - intel_audio_codec_enable(encoder);
> + intel_audio_codec_enable(encoder, pipe_config, conn_state);
>   }
>  }
>  
> @@ -2787,7 +2788,7 @@ static void g4x_enable_dp(struct intel_encoder *encoder,
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);

[Intel-gfx] [PATCH] drm/i915: avoid harmless empty-body warning

2016-11-08 Thread Arnd Bergmann
The newly added assert_kernel_context_is_current introduces a warning
when built with W=1:

drivers/gpu/drm/i915/i915_gem.c: In function ‘assert_kernel_context_is_current’:
drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty 
body in an ‘else’ statement [-Werror=empty-body]

Changing the GEM_BUG_ON() macro from an empty definition to "do { } while (0)"
makes the macro more robust to use and avoids the warning.

Fixes: 3033acab07f9 ("drm/i915: Queue the idling context switch after all other 
timelines")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/i915_gem.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 735580d72eb1..51ec793f2e20 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -28,7 +28,7 @@
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(expr) BUG_ON(expr)
 #else
-#define GEM_BUG_ON(expr)
+#define GEM_BUG_ON(expr) do { } while (0)
 #endif
 
 #define I915_NUM_ENGINES 5
-- 
2.9.0

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


Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use intel_fb_gtt_offset() also for gen2/3 primary plane

2016-11-08 Thread Ville Syrjälä
On Mon, Nov 07, 2016 at 09:20:05PM +, Chris Wilson wrote:
> On Mon, Nov 07, 2016 at 10:20:57PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The code to determine the primary plane offset for gen2/3 looks
> > different than the code for gen4+, but in fact it's doing the same
> > thing. Let's make it uniform. Allows us to eliminate the 'obj' from
> > the list of local variables as well.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 817ed3f320f7..3d519d701e1c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3017,7 +3017,6 @@ static void i9xx_update_primary_plane(struct 
> > drm_plane *primary,
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
> > struct drm_framebuffer *fb = plane_state->base.fb;
> > -   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > int plane = intel_crtc->plane;
> > u32 linear_offset;
> > u32 dspcntr;
> > @@ -3112,8 +3111,11 @@ static void i9xx_update_primary_plane(struct 
> > drm_plane *primary,
> >intel_crtc->dspaddr_offset);
> > I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
> > I915_WRITE(DSPLINOFF(plane), linear_offset);
> > -   } else
> > -   I915_WRITE(DSPADDR(plane), i915_gem_object_ggtt_offset(obj, 
> > NULL) + linear_offset);
> > +   } else {
> > +   I915_WRITE(DSPADDR(plane),
> > +  intel_fb_gtt_offset(fb, rotation) +
> > +  intel_crtc->dspaddr_offset);
> 
> Reviewed-by: Chris Wilson 

Patches 3-5 pushed to dinq. Thanks for the review.

> 
> Though the reader might notice the same offset being passed to both gen4+
> DSPSURF and gen3- DSPADDR, and might reasonably ask if they should be
> sharing a variable.

Perhaps. I think I'll be merging the pre-ilk and ilk codepaths soon,
so I'll see if I can reorganize some of this offset stuff at the same
time a bit.

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


[Intel-gfx] [PATCH i-g-t v7] tests/kms_plane_multiple: CRC based atomic correctness test

2016-11-08 Thread Mika Kahola
This is a testcase with multiple planes. The idea here is the following

 - draw a uniform frame with blue color
 - grab crc for reference
 - put planes randomly on top with the same blue color
 - punch holes with black color into the primary framebuffer
 - ideally the planes should cover these holes so that the output is the
   identical to reference crc
 - composite all with one ioctl call
 - grab crc and verify that the reference crc is equal
 - repeat this for several iterations to maximize coverage

v7: Unify reference crc grabbing for atomic and legacy tests (Maarten)

v6: Rename test_planes() to prepare_planes() (Maarten)
When grabbing reference crc, keep framebuffer and crc enabled for
atomic mode setting. (Maarten)
Fix crc collection for legacy modesetting (Maarten)

v5: Remove limit for max number of iterations and add possibility to
loop forever (Daniel)
Remove IN_RANGE() macro (Maarten)
Remove log file and show random number seed on screen instead (Maarten)
Split legacy and atomic plane tests on own functions (Maarten)
remove test_atomic() function and pass test mode info as
parameter (Maarten)
Use bigger rectangle size (256x256) for non-cursor planes and
smaller (128x128) size for cursor plane (Maarten)

v4: For atomic test enable crc capturing before entering into a
iteration loop. After each iteration, check that page flip
didn't take no more than 1 vblank, fetch all crc's and check
the values.

Introduce new command line parameter for the number of iterations.
The test run from 1 to 256 iterations.

v3: Cleanup by removing separate plane array
For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
Grab crc by using igt_pipe_crc_get_crc instead of igt_pipe_crc_collect_crc
Rename nplanes variable to max_planes
To optimize test execution, run iterations after the modeset

v2: Keep a logfile on random number seeds per subtest that are not skipped
due to unmet test requirements

Signed-off-by: Mika Kahola 
---
 tests/Makefile.sources |   1 +
 tests/kms_plane_multiple.c | 494 +
 2 files changed, 495 insertions(+)
 create mode 100644 tests/kms_plane_multiple.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..ffd59c1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs_M = \
kms_pipe_color \
kms_pipe_crc_basic \
kms_plane \
+   kms_plane_multiple \
kms_properties \
kms_psr_sink_crc \
kms_render \
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
new file mode 100644
index 000..bedee16
--- /dev/null
+++ b/tests/kms_plane_multiple.c
@@ -0,0 +1,494 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple planes ");
+
+#define MAX_CRCS  1
+#define SIZE_PLANE  256
+#define SIZE_CURSOR 128
+#define LOOP_FOREVER -1
+
+typedef struct {
+   float red;
+   float green;
+   float blue;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   igt_pipe_crc_t *pipe_crc;
+   igt_plane_t *plane[IGT_MAX_PLANES];
+   struct igt_fb fb[IGT_MAX_PLANES];
+} data_t;
+
+typedef struct {
+   data_t *data;
+   igt_crc_t reference_crc;
+} test_position_t;
+
+/* Command line parameters. */
+struct {
+   int iterations;
+   bool user_seed;
+   int seed;
+} opt = {
+   .iterations = 64,
+   .user_seed = false,
+   .seed = 1,
+};
+
+static inline uint32_t pipe_select(int pipe)
+{
+   if (pipe > 1)
+   return pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
+   else if 

[Intel-gfx] ✓ Fi.CI.BAT: success for Skylake watermark fixes and nonblocking modeset.

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

Series: Skylake watermark fixes and nonblocking modeset.
URL   : https://patchwork.freedesktop.org/series/14966/
State : success

== Summary ==

Series 14966v1 Skylake watermark fixes and nonblocking modeset.
https://patchwork.freedesktop.org/api/1.0/series/14966/revisions/1/mbox/

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

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

aa74f4d7a58d239a7ff25c02eebf00c9ceb42c95 drm-intel-nightly: 
2016y-11m-08d-11h-05m-41s UTC integration manifest
dc6cbdd drm/i915: Enable support for nonblocking modeset
9d7426c drm/i915: Pass atomic state to verify_connector_state
4e7ab3e drm/i915: Update atomic modeset state synchronously, v2.
31b91b5 drm/edid: Remove drm_select_eld
e185dd9 drm/i915: Pass atomic state to intel_audio_codec_enable, v2.
dd9fe0d drm/i915: Convert intel_hdmi to use atomic state
e485020 drm/i915/gen9+: Do not initialise active_crtcs for !modeset
c2129a1 drm/i915/gen9+: Kill off hw_ddb from intel_crtc.
3f454fa drm/i915/gen9+: Preserve old allocation from crtc_state.
49193be drm/i915/gen9+: Program watermarks as a separate step during evasion, 
v3.
5bb427c drm/i915: Add a atomic evasion step to watermark programming, v3.

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Always flush the dirty CPU cache when pinning the scanout

2016-11-08 Thread Ville Syrjälä
On Tue, Nov 08, 2016 at 11:42:38AM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 01:33:41PM +0200, Ville Syrjälä wrote:
> > On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote:
> > > - i915_gem_object_flush_cpu_write_domain(obj);
> > > + if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> > > + i915_gem_clflush_object(obj, true);
> > > + intel_fb_obj_flush(obj, false, ORIGIN_CPU);
> > 
> > So one slight change in behaviour is that we won't clear the write domain
> > here, but that's fine since we'll clear it below anyway.
> > 
> > The other is that we now call intel_fb_obj_flush() unconditionally,
> > whereas before we only called if when the bo was in the CPU write
> > domain. Hmm. Should we keep it conditional?
> 
> I was thinking that we should call it in the case we deferred clflush,
> and I was wanting to make the preflip path closer to dirtyfb. Since to
> me they both demark the frame boundary and the preparatory flushing
> should be more or less the same.

All right. Seems sane enough to me.

Reviewed-by: Ville Syrjälä 

> 
> > >   old_write_domain = obj->base.write_domain;
> > >   old_read_domains = obj->base.read_domains;
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 92ab01f33208..47233b242c99 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -15698,6 +15698,8 @@ static int intel_user_framebuffer_dirty(struct 
> > > drm_framebuffer *fb,
> > >   struct drm_i915_gem_object *obj = intel_fb->obj;
> > >  
> > >   mutex_lock(>struct_mutex);
> > > + if (obj->pin_display && obj->cache_dirty)
> > > + i915_gem_clflush_object(obj, true);
> > >   intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
> > >   mutex_unlock(>struct_mutex);
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
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 i-g-t v6] tests/kms_plane_multiple: CRC based atomic correctness test

2016-11-08 Thread Mika Kahola
On Tue, 2016-11-08 at 14:14 +0100, Maarten Lankhorst wrote:
> Op 08-11-16 om 12:54 schreef Mika Kahola:
> > 
> > This is a testcase with multiple planes. The idea here is the
> > following
> > 
> >  - draw a uniform frame with blue color
> >  - grab crc for reference
> >  - put planes randomly on top with the same blue color
> >  - punch holes with black color into the primary framebuffer
> >  - ideally the planes should cover these holes so that the output
> > is the
> >    identical to reference crc
> >  - composite all with one ioctl call
> >  - grab crc and verify that the reference crc is equal
> >  - repeat this for several iterations to maximize coverage
> > 
> > v6: Rename test_planes() to prepare_planes() (Maarten)
> > When grabbing reference crc, keep framebuffer and crc enabled
> > for
> > atomic mode setting. (Maarten)
> > Fix crc collection for legacy modesetting (Maarten)
> > 
> > v5: Remove limit for max number of iterations and add possibility
> > to
> > loop forever (Daniel)
> > Remove IN_RANGE() macro (Maarten)
> > Remove log file and show random number seed on screen instead
> > (Maarten)
> > Split legacy and atomic plane tests on own functions (Maarten)
> > remove test_atomic() function and pass test mode info as
> > parameter (Maarten)
> > Use bigger rectangle size (256x256) for non-cursor planes and
> > smaller (128x128) size for cursor plane (Maarten)
> > 
> > v4: For atomic test enable crc capturing before entering into a
> > iteration loop. After each iteration, check that page flip
> > didn't take no more than 1 vblank, fetch all crc's and check
> > the values.
> > 
> > Introduce new command line parameter for the number of
> > iterations.
> > The test run from 1 to 256 iterations.
> > 
> > v3: Cleanup by removing separate plane array
> > For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
> > Grab crc by using igt_pipe_crc_get_crc instead of
> > igt_pipe_crc_collect_crc
> > Rename nplanes variable to max_planes
> > To optimize test execution, run iterations after the modeset
> > 
> > v2: Keep a logfile on random number seeds per subtest that are not
> > skipped
> > due to unmet test requirements
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  tests/Makefile.sources |   1 +
> >  tests/kms_plane_multiple.c | 501
> > +
> >  2 files changed, 502 insertions(+)
> >  create mode 100644 tests/kms_plane_multiple.c
> > 
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 6d081c3..ffd59c1 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -105,6 +105,7 @@ TESTS_progs_M = \
> >     kms_pipe_color \
> >     kms_pipe_crc_basic \
> >     kms_plane \
> > +   kms_plane_multiple \
> >     kms_properties \
> >     kms_psr_sink_crc \
> >     kms_render \
> > diff --git a/tests/kms_plane_multiple.c
> > b/tests/kms_plane_multiple.c
> > new file mode 100644
> > index 000..f316488
> > --- /dev/null
> > +++ b/tests/kms_plane_multiple.c
> > @@ -0,0 +1,501 @@
> > +/*
> > + * Copyright © 2016 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > + * and/or sell copies of the Software, and to permit persons to
> > whom the
> > + * Software is furnished to do so, subject to the following
> > conditions:
> > + *
> > + * The above copyright notice and this permission notice
> > (including the next
> > + * paragraph) shall be included in all copies or substantial
> > portions of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > OTHER DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + */
> > +
> > +#include "igt.h"
> > +#include "drmtest.h"
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple
> > planes ");
> > +
> > +#define MAX_CRCS  1
> > +#define SIZE_PLANE  256
> > +#define SIZE_CURSOR 128
> > +#define LOOP_FOREVER -1
> > +
> > +typedef struct {
> > +   float red;
> > +   float green;
> > +   float blue;
> > +} color_t;
> > +
> > +typedef struct {
> > +   int drm_fd;
> > +   igt_display_t display;
> > +   

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev2)

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

Series: Enable i915 perf stream for Haswell OA unit (rev2)
URL   : https://patchwork.freedesktop.org/series/14935/
State : failure

== Summary ==

Series 14935v2 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/14935/revisions/2/mbox/

Test gem_exec_parse:
Subgroup basic-rejected:
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-byt-n2820)
pass   -> FAIL   (fi-hsw-4770r)
pass   -> FAIL   (fi-hsw-4770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:215  dwarn:0   dfail:0   fail:1   skip:28 
fi-byt-n2820 total:244  pass:211  dwarn:0   dfail:0   fail:1   skip:32 
fi-hsw-4770  total:244  pass:223  dwarn:0   dfail:0   fail:1   skip:20 
fi-hsw-4770r total:244  pass:223  dwarn:0   dfail:0   fail:1   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-ivb-3770  total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

aa74f4d7a58d239a7ff25c02eebf00c9ceb42c95 drm-intel-nightly: 
2016y-11m-08d-11h-05m-41s UTC integration manifest
6bbae39 drm/i915: Add a kerneldoc summary for i915_perf.c
8b05137 drm/i915: Add more Haswell OA metric sets
f4c6eec drm/i915: add dev.i915.oa_max_sample_rate sysctl
9f486e7 drm/i915: Add dev.i915.perf_stream_paranoid sysctl option
576e12b drm/i915: advertise available metrics via sysfs
2fe39d2 drm/i915: Enable i915 perf stream for Haswell OA unit
b478f8e drm/i915: Add 'render basic' Haswell OA unit config
bcf0893 drm/i915: don't whitelist oacontrol in cmd parser
cf8aecb drm/i915: return EACCES for check_cmd() failures
676b8a2 drm/i915: rename OACONTROL GEN7_OACONTROL
289c71d drm/i915: Add i915 perf infrastructure

== Logs ==

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


Re: [Intel-gfx] [PATCH i-g-t v6] tests/kms_plane_multiple: CRC based atomic correctness test

2016-11-08 Thread Maarten Lankhorst
Op 08-11-16 om 12:54 schreef Mika Kahola:
> This is a testcase with multiple planes. The idea here is the following
>
>  - draw a uniform frame with blue color
>  - grab crc for reference
>  - put planes randomly on top with the same blue color
>  - punch holes with black color into the primary framebuffer
>  - ideally the planes should cover these holes so that the output is the
>identical to reference crc
>  - composite all with one ioctl call
>  - grab crc and verify that the reference crc is equal
>  - repeat this for several iterations to maximize coverage
>
> v6: Rename test_planes() to prepare_planes() (Maarten)
> When grabbing reference crc, keep framebuffer and crc enabled for
> atomic mode setting. (Maarten)
> Fix crc collection for legacy modesetting (Maarten)
>
> v5: Remove limit for max number of iterations and add possibility to
> loop forever (Daniel)
> Remove IN_RANGE() macro (Maarten)
> Remove log file and show random number seed on screen instead (Maarten)
> Split legacy and atomic plane tests on own functions (Maarten)
> remove test_atomic() function and pass test mode info as
> parameter (Maarten)
> Use bigger rectangle size (256x256) for non-cursor planes and
> smaller (128x128) size for cursor plane (Maarten)
>
> v4: For atomic test enable crc capturing before entering into a
> iteration loop. After each iteration, check that page flip
> didn't take no more than 1 vblank, fetch all crc's and check
> the values.
>
> Introduce new command line parameter for the number of iterations.
> The test run from 1 to 256 iterations.
>
> v3: Cleanup by removing separate plane array
> For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
> Grab crc by using igt_pipe_crc_get_crc instead of igt_pipe_crc_collect_crc
> Rename nplanes variable to max_planes
> To optimize test execution, run iterations after the modeset
>
> v2: Keep a logfile on random number seeds per subtest that are not skipped
> due to unmet test requirements
>
> Signed-off-by: Mika Kahola 
> ---
>  tests/Makefile.sources |   1 +
>  tests/kms_plane_multiple.c | 501 
> +
>  2 files changed, 502 insertions(+)
>  create mode 100644 tests/kms_plane_multiple.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 6d081c3..ffd59c1 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -105,6 +105,7 @@ TESTS_progs_M = \
>   kms_pipe_color \
>   kms_pipe_crc_basic \
>   kms_plane \
> + kms_plane_multiple \
>   kms_properties \
>   kms_psr_sink_crc \
>   kms_render \
> diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
> new file mode 100644
> index 000..f316488
> --- /dev/null
> +++ b/tests/kms_plane_multiple.c
> @@ -0,0 +1,501 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include "igt.h"
> +#include "drmtest.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple planes ");
> +
> +#define MAX_CRCS  1
> +#define SIZE_PLANE  256
> +#define SIZE_CURSOR 128
> +#define LOOP_FOREVER -1
> +
> +typedef struct {
> + float red;
> + float green;
> + float blue;
> +} color_t;
> +
> +typedef struct {
> + int drm_fd;
> + igt_display_t display;
> + igt_pipe_crc_t *pipe_crc;
> + igt_plane_t *plane[IGT_MAX_PLANES];
> + struct igt_fb fb[IGT_MAX_PLANES];
> +} data_t;
> +
> +typedef struct {
> + data_t *data;
> + igt_crc_t reference_crc;
> +} test_position_t;
> +
> +/* Command line parameters. */
> +struct {
> + int iterations;
> + bool user_seed;
> + int seed;
> +} opt = {
> + .iterations = 64,
> + 

[Intel-gfx] [PATCH v3 08/11] drm/edid: Remove drm_select_eld

2016-11-08 Thread Maarten Lankhorst
The only user was i915, which is now gone.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie  #irc
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/drm_edid.c | 26 --
 include/drm/drm_edid.h |  1 -
 2 files changed, 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933b41cd..1801e9c0e41b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3611,32 +3611,6 @@ int drm_av_sync_delay(struct drm_connector *connector,
 EXPORT_SYMBOL(drm_av_sync_delay);
 
 /**
- * drm_select_eld - select one ELD from multiple HDMI/DP sinks
- * @encoder: the encoder just changed display mode
- *
- * It's possible for one encoder to be associated with multiple HDMI/DP sinks.
- * The policy is now hard coded to simply use the first HDMI/DP sink's ELD.
- *
- * Return: The connector associated with the first HDMI/DP sink that has ELD
- * attached to it.
- */
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder)
-{
-   struct drm_connector *connector;
-   struct drm_device *dev = encoder->dev;
-
-   WARN_ON(!mutex_is_locked(>mode_config.mutex));
-   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
-
-   drm_for_each_connector(connector, dev)
-   if (connector->encoder == encoder && connector->eld[0])
-   return connector;
-
-   return NULL;
-}
-EXPORT_SYMBOL(drm_select_eld);
-
-/**
  * drm_detect_hdmi_monitor - detect whether monitor is HDMI
  * @edid: monitor EDID information
  *
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3a7d440bc11..38eabf65f19d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -330,7 +330,6 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
**sads);
 int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
 int drm_av_sync_delay(struct drm_connector *connector,
  const struct drm_display_mode *mode);
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
 
 #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
 int drm_load_edid_firmware(struct drm_connector *connector);
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 03/11] drm/i915/gen9+: Preserve old allocation from crtc_state.

2016-11-08 Thread Maarten Lankhorst
This is the last bit required for making nonblocking modesets work
correctly. The state in intel_crtc->hw_ddb is not updated until
somewhere in atomic commit, while the previous crtc state should be
accurate if the ddb hasn't changed.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index abfcaa07bbe3..69f9addb29b3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14313,7 +14313,7 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 * new ddb allocation to take effect.
 */
if (!skl_ddb_entry_equal(>wm.skl.ddb,
-_crtc->hw_ddb) &&
+
_intel_crtc_state(old_crtc_state)->wm.skl.ddb) &&
!crtc->state->active_changed &&
intel_state->wm_results.dirty_pipes != updated)
vbl_wait = true;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 93e261300ef0..bde6c68eb0db 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3118,7 +3118,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
*dev,
 * we currently hold.
 */
if (!intel_state->active_pipe_changes) {
-   *alloc = to_intel_crtc(for_crtc)->hw_ddb;
+   /*
+* alloc may be cleared by clear_intel_crtc_state,
+* copy from old state to be sure
+*/
+   *alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
return;
}
 
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 07/11] drm/i915: Pass atomic state to intel_audio_codec_enable, v2.

2016-11-08 Thread Maarten Lankhorst
drm_select_eld requires mode_config.mutex and connection_mutex
because it looks at the connector list and at the legacy encoders.

This is not required, because when we call audio_codec_enable we know
which connector it was called for, so pass the state.

This also removes having to look at crtc->config.

Changes since v1:
- Use intel_crtc->pipe instead of drm_crtc_index. (Ville)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_audio.c | 17 ++---
 drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
 drivers/gpu/drm/i915/intel_dp.c| 11 ++-
 drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
 drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
 5 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 813fd74d9c8d..1c509f7410f5 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -574,23 +574,26 @@ static void ilk_audio_codec_enable(struct drm_connector 
*connector,
 /**
  * intel_audio_codec_enable - Enable the audio codec for HD audio
  * @intel_encoder: encoder on which to enable audio
+ * @crtc_state: pointer to the current crtc state.
+ * @conn_state: pointer to the current connector state.
  *
  * The enable sequences may only be performed after enabling the transcoder and
  * port, and after completed link training.
  */
-void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
+void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
 {
struct drm_encoder *encoder = _encoder->base;
-   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
-   const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
+   const struct drm_display_mode *adjusted_mode = 
_state->base.adjusted_mode;
struct drm_connector *connector;
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
enum port port = intel_encoder->port;
-   enum pipe pipe = crtc->pipe;
+   enum pipe pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
 
-   connector = drm_select_eld(encoder);
-   if (!connector)
+   connector = conn_state->connector;
+   if (!connector || !connector->eld[0])
return;
 
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
@@ -601,7 +604,7 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
 
/* ELD Conn_Type */
connector->eld[5] &= ~(3 << 2);
-   if (intel_crtc_has_dp_encoder(crtc->config))
+   if (intel_crtc_has_dp_encoder(crtc_state))
connector->eld[5] |= (1 << 2);
 
connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 938ac4dbcb45..0ad4e16a639f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1866,7 +1866,7 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
 
if (intel_crtc->config->has_audio) {
intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
-   intel_audio_codec_enable(intel_encoder);
+   intel_audio_codec_enable(intel_encoder, pipe_config, 
conn_state);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9df331b3305b..117a71450ec2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2735,7 +2735,8 @@ static void intel_dp_enable_port(struct intel_dp 
*intel_dp,
 }
 
 static void intel_enable_dp(struct intel_encoder *encoder,
-   struct intel_crtc_state *pipe_config)
+   struct intel_crtc_state *pipe_config,
+   struct drm_connector_state *conn_state)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_device *dev = encoder->base.dev;
@@ -2777,7 +2778,7 @@ static void intel_enable_dp(struct intel_encoder *encoder,
if (pipe_config->has_audio) {
DRM_DEBUG_DRIVER("Enabling DP audio on pipe %c\n",
 pipe_name(pipe));
-   intel_audio_codec_enable(encoder);
+   intel_audio_codec_enable(encoder, pipe_config, conn_state);
}
 }
 
@@ -2787,7 +2788,7 @@ static void g4x_enable_dp(struct intel_encoder *encoder,
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
 
-   intel_enable_dp(encoder, pipe_config);
+   intel_enable_dp(encoder, pipe_config, conn_state);
intel_edp_backlight_on(intel_dp);
 }
 
@@ -2924,7 +2925,7 @@ static void vlv_pre_enable_dp(struct intel_encoder 
*encoder,
 {

[Intel-gfx] [PATCH v3 04/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.

2016-11-08 Thread Maarten Lankhorst
This member is only used in skl_update_crtcs now. It's easy to remove it
by keeping track of which ddb entries in an array, and update them after
we update the crtc. This removes the last bits of SKL-style watermarks
kept outside of crtc_state.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 drivers/gpu/drm/i915/intel_drv.h | 11 +++
 drivers/gpu/drm/i915/intel_pm.c  | 25 +++--
 3 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 69f9addb29b3..e59adb03933e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14280,6 +14280,14 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
unsigned int updated = 0;
bool progress;
enum pipe pipe;
+   int i;
+
+   const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
+
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i)
+   /* ignore allocations for crtc's that have been turned off. */
+   if (crtc->state->active)
+   entries[i] = 
_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
 
/*
 * Whenever the number of active pipes changes, we need to make sure we
@@ -14288,7 +14296,6 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
 * cause pipe underruns and other bad stuff.
 */
do {
-   int i;
progress = false;
 
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
@@ -14299,12 +14306,14 @@ static void skl_update_crtcs(struct drm_atomic_state 
*state,
cstate = to_intel_crtc_state(crtc->state);
pipe = intel_crtc->pipe;
 
-   if (updated & cmask || !crtc->state->active)
+   if (updated & cmask || !cstate->base.active)
continue;
-   if (skl_ddb_allocation_overlaps(state, intel_crtc))
+
+   if (skl_ddb_allocation_overlaps(entries, 
>wm.skl.ddb, i))
continue;
 
updated |= cmask;
+   entries[i] = >wm.skl.ddb;
 
/*
 * If this is an already active pipe, it's DDB changed,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d18444097e1c..815e8dae3904 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -728,9 +728,6 @@ struct intel_crtc {
bool cxsr_allowed;
} wm;
 
-   /* gen9+: ddb allocation currently being used */
-   struct skl_ddb_entry hw_ddb;
-
int scanline_offset;
 
struct {
@@ -1738,11 +1735,9 @@ int intel_enable_sagv(struct drm_i915_private *dev_priv);
 int intel_disable_sagv(struct drm_i915_private *dev_priv);
 bool skl_wm_level_equals(const struct skl_wm_level *l1,
 const struct skl_wm_level *l2);
-bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old,
-  const struct skl_ddb_allocation *new,
-  enum pipe pipe);
-bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
-struct intel_crtc *intel_crtc);
+bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry **entries,
+const struct skl_ddb_entry *ddb,
+int ignore);
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bde6c68eb0db..02f52b52a03d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3914,25 +3914,16 @@ static inline bool skl_ddb_entries_overlap(const struct 
skl_ddb_entry *a,
return a->start < b->end && b->start < a->end;
 }
 
-bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
-struct intel_crtc *intel_crtc)
-{
-   struct drm_crtc *other_crtc;
-   struct drm_crtc_state *other_cstate;
-   struct intel_crtc *other_intel_crtc;
-   const struct skl_ddb_entry *ddb =
-   _intel_crtc_state(intel_crtc->base.state)->wm.skl.ddb;
+bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry **entries,
+const struct skl_ddb_entry *ddb,
+int ignore)
+{
int i;
 
-   for_each_crtc_in_state(state, other_crtc, other_cstate, i) {
-   other_intel_crtc = to_intel_crtc(other_crtc);
-
-   if (other_intel_crtc == intel_crtc)
-  

[Intel-gfx] [PATCH v3 01/11] drm/i915: Add a atomic evasion step to watermark programming, v3.

2016-11-08 Thread Maarten Lankhorst
Allow the driver to write watermarks during atomic evasion.
This will make it possible to write the watermarks in a cleaner
way on gen9+.

intel_atomic_state is not used here yet, but will be used when
we program all watermarks as a separate step during evasion.

This also writes linetime all the time, while before it was only
done during plane updates. This looks like this could be a bugfix,
but I'm not sure what it affects.

Changes since v1:
- Add comment about atomic evasion to commit message.
- Unwrap I915_WRITE call. (Lyude)
Changes since v2:
- Rename atomic_evade_watermarks to atomic_update_watermarks. (Ville)
- Add line wraps where appropriate, fix grammar in commit message. (Matt)

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Matt Roper 
Cc: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  9 +++--
 drivers/gpu/drm/i915/intel_display.c | 26 +-
 drivers/gpu/drm/i915/intel_pm.c  | 18 --
 3 files changed, 36 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4735b4177100..00988d716d7e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -487,6 +487,7 @@ struct sdvo_device_mapping {
 
 struct intel_connector;
 struct intel_encoder;
+struct intel_atomic_state;
 struct intel_crtc_state;
 struct intel_initial_plane_config;
 struct intel_crtc;
@@ -500,8 +501,12 @@ struct drm_i915_display_funcs {
int (*compute_intermediate_wm)(struct drm_device *dev,
   struct intel_crtc *intel_crtc,
   struct intel_crtc_state *newstate);
-   void (*initial_watermarks)(struct intel_crtc_state *cstate);
-   void (*optimize_watermarks)(struct intel_crtc_state *cstate);
+   void (*initial_watermarks)(struct intel_atomic_state *state,
+  struct intel_crtc_state *cstate);
+   void (*atomic_update_watermarks)(struct intel_atomic_state *state,
+struct intel_crtc_state *cstate);
+   void (*optimize_watermarks)(struct intel_atomic_state *state,
+   struct intel_crtc_state *cstate);
int (*compute_global_watermarks)(struct drm_atomic_state *state);
void (*update_wm)(struct intel_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 92ab01f33208..66cf29ac9fe4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5169,7 +5169,7 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
 * us to.
 */
if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(pipe_config);
+   
dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
pipe_config);
else if (pipe_config->update_wm_pre)
intel_update_watermarks(crtc);
 }
@@ -5383,7 +5383,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_color_load_luts(_config->base);
 
if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(intel_crtc->config);
+   
dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
intel_crtc->config);
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
@@ -5489,7 +5489,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_ddi_enable_transcoder_func(crtc);
 
if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(pipe_config);
+   
dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state), 
pipe_config);
else
intel_update_watermarks(intel_crtc);
 
@@ -14474,7 +14474,7 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
intel_cstate = to_intel_crtc_state(crtc->state);
 
if (dev_priv->display.optimize_watermarks)
-   dev_priv->display.optimize_watermarks(intel_cstate);
+   dev_priv->display.optimize_watermarks(intel_state, 
intel_cstate);
}
 
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
@@ -14909,10 +14909,11 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *intel_cstate =
to_intel_crtc_state(crtc->state);
-   struct intel_crtc_state *old_intel_state =
+   struct intel_crtc_state *old_intel_cstate =
to_intel_crtc_state(old_crtc_state);
+   

[Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset

2016-11-08 Thread Maarten Lankhorst
This is a hack and not needed. Use the right mask by checking
intel_state->modeset. This works for watermark sanitization too.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 38 +++---
 1 file changed, 15 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 02f52b52a03d..d38a46efcfed 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3089,26 +3089,22 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
*dev,
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc *for_crtc = cstate->base.crtc;
-   unsigned int pipe_size, ddb_size;
+   unsigned int pipe_size, ddb_size, active_crtcs;
int nth_active_pipe;
 
+   if (intel_state->modeset)
+   active_crtcs = intel_state->active_crtcs;
+   else
+   active_crtcs = dev_priv->active_crtcs;
+
+   *num_active = hweight32(active_crtcs);
+
if (WARN_ON(!state) || !cstate->base.active) {
alloc->start = 0;
alloc->end = 0;
-   *num_active = hweight32(dev_priv->active_crtcs);
return;
}
 
-   if (intel_state->active_pipe_changes)
-   *num_active = hweight32(intel_state->active_crtcs);
-   else
-   *num_active = hweight32(dev_priv->active_crtcs);
-
-   ddb_size = INTEL_INFO(dev_priv)->ddb_size;
-   WARN_ON(ddb_size == 0);
-
-   ddb_size -= 4; /* 4 blocks for bypass path allocation */
-
/*
 * If the state doesn't change the active CRTC's, then there's
 * no need to recalculate; the existing pipe allocation limits
@@ -3126,9 +3122,14 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device 
*dev,
return;
}
 
-   nth_active_pipe = hweight32(intel_state->active_crtcs &
+   ddb_size = INTEL_INFO(dev_priv)->ddb_size;
+   WARN_ON(ddb_size == 0);
+
+   ddb_size -= 4; /* 4 blocks for bypass path allocation */
+
+   nth_active_pipe = hweight32(active_crtcs &
(drm_crtc_mask(for_crtc) - 1));
-   pipe_size = ddb_size / hweight32(intel_state->active_crtcs);
+   pipe_size = ddb_size / *num_active;
alloc->start = nth_active_pipe * ddb_size / *num_active;
alloc->end = alloc->start + pipe_size;
 }
@@ -4021,15 +4022,6 @@ skl_compute_ddb(struct drm_atomic_state *state)
return ret;
 
intel_state->active_pipe_changes = ~0;
-
-   /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
-   if (!intel_state->modeset)
-   intel_state->active_crtcs = dev_priv->active_crtcs;
}
 
/*
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 02/11] drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.

2016-11-08 Thread Maarten Lankhorst
The watermark updates for SKL style watermarks are no longer done
in the plane callbacks, but are now called in a separate watermark
update function that's called during the same vblank evasion,
before the plane updates.

This also gets rid of the global skl_results, which was required for
keeping track of the current atomic commit.

Changes since v1:
- Move line unwrap to correct patch. (Lyude)
- Make sure we don't regress ILK watermarks. (Matt)
- Rephrase commit message. (Matt)
Changes since v2:
- Fix disable watermark check to use the correct way to determine single
  step watermark support.

Reviewed-by: Matt Roper 
Reviewed-by: Lyude 
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |  7 ---
 drivers/gpu/drm/i915/intel_display.c | 40 
 drivers/gpu/drm/i915/intel_drv.h |  7 ---
 drivers/gpu/drm/i915/intel_pm.c  | 40 
 drivers/gpu/drm/i915/intel_sprite.c  | 18 
 5 files changed, 31 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00988d716d7e..547a1a4f0225 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,13 +2058,6 @@ struct drm_i915_private {
 */
uint16_t skl_latency[8];
 
-   /*
-* The skl_wm_values structure is a bit too big for stack
-* allocation, so we keep the staging struct where we store
-* intermediate results here instead.
-*/
-   struct skl_wm_values skl_results;
-
/* current hardware state */
union {
struct ilk_wm_values hw;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 66cf29ac9fe4..abfcaa07bbe3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3382,9 +3382,6 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct drm_i915_private *dev_priv = to_i915(dev);
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;
@@ -3420,9 +3417,6 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_x = src_x;
intel_crtc->adjusted_y = src_y;
 
-   if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
-   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);
I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
@@ -3455,18 +3449,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;
 
-   /*
-* We only populate skl_results on watermark updates, and if the
-* plane's visiblity isn't actually changing neither is its watermarks.
-*/
-   if (!crtc->primary->state->visible)
-   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);
POSTING_READ(PLANE_SURF(pipe, 0));
@@ -10848,16 +10832,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
-   const struct skl_wm_values *wm = _priv->wm.skl_results;
-   const struct skl_plane_wm *p_wm =
-   >wm.skl.optimal.planes[PLANE_CURSOR];
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
 
-   if (INTEL_GEN(dev_priv) >= 9 && wm->dirty_pipes & drm_crtc_mask(crtc))
-   skl_write_cursor_wm(intel_crtc, p_wm, >ddb);
-
if (plane_state && plane_state->base.visible) {
cntl = MCURSOR_GAMMA_ENABLE;
switch (plane_state->base.crtc_w) {
@@ -14407,8 +14384,17 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)

[Intel-gfx] [PATCH v3 06/11] drm/i915: Convert intel_hdmi to use atomic state

2016-11-08 Thread Maarten Lankhorst
This is the last connector still looking at crtc->config. Fix this.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 48 +--
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 35ada4e1c6cf..2218b10fa22a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -975,7 +975,9 @@ static void intel_hdmi_get_config(struct intel_encoder 
*encoder,
pipe_config->lane_count = 4;
 }
 
-static void intel_enable_hdmi_audio(struct intel_encoder *encoder)
+static void intel_enable_hdmi_audio(struct intel_encoder *encoder,
+   struct intel_crtc_state *pipe_config,
+   struct drm_connector_state *conn_state)
 {
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
 
@@ -991,21 +993,20 @@ static void g4x_enable_hdmi(struct intel_encoder *encoder,
 {
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(>base);
u32 temp;
 
temp = I915_READ(intel_hdmi->hdmi_reg);
 
temp |= SDVO_ENABLE;
-   if (crtc->config->has_audio)
+   if (pipe_config->has_audio)
temp |= SDVO_AUDIO_ENABLE;
 
I915_WRITE(intel_hdmi->hdmi_reg, temp);
POSTING_READ(intel_hdmi->hdmi_reg);
 
-   if (crtc->config->has_audio)
-   intel_enable_hdmi_audio(encoder);
+   if (pipe_config->has_audio)
+   intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
 }
 
 static void ibx_enable_hdmi(struct intel_encoder *encoder,
@@ -1040,8 +1041,8 @@ static void ibx_enable_hdmi(struct intel_encoder *encoder,
 * FIXME: BSpec says this should be done at the end of
 * of the modeset sequence, so not sure if this isn't too soon.
 */
-   if (crtc->config->pipe_bpp > 24 &&
-   crtc->config->pixel_multiplier > 1) {
+   if (pipe_config->pipe_bpp > 24 &&
+   pipe_config->pixel_multiplier > 1) {
I915_WRITE(intel_hdmi->hdmi_reg, temp & ~SDVO_ENABLE);
POSTING_READ(intel_hdmi->hdmi_reg);
 
@@ -1055,8 +1056,8 @@ static void ibx_enable_hdmi(struct intel_encoder *encoder,
POSTING_READ(intel_hdmi->hdmi_reg);
}
 
-   if (crtc->config->has_audio)
-   intel_enable_hdmi_audio(encoder);
+   if (pipe_config->has_audio)
+   intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
 }
 
 static void cpt_enable_hdmi(struct intel_encoder *encoder,
@@ -1073,7 +1074,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
temp = I915_READ(intel_hdmi->hdmi_reg);
 
temp |= SDVO_ENABLE;
-   if (crtc->config->has_audio)
+   if (pipe_config->has_audio)
temp |= SDVO_AUDIO_ENABLE;
 
/*
@@ -1086,7 +1087,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
 * 4. enable HDMI clock gating
 */
 
-   if (crtc->config->pipe_bpp > 24) {
+   if (pipe_config->pipe_bpp > 24) {
I915_WRITE(TRANS_CHICKEN1(pipe),
   I915_READ(TRANS_CHICKEN1(pipe)) |
   TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
@@ -1098,7 +1099,7 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
I915_WRITE(intel_hdmi->hdmi_reg, temp);
POSTING_READ(intel_hdmi->hdmi_reg);
 
-   if (crtc->config->pipe_bpp > 24) {
+   if (pipe_config->pipe_bpp > 24) {
temp &= ~SDVO_COLOR_FORMAT_MASK;
temp |= HDMI_COLOR_FORMAT_12bpc;
 
@@ -1110,8 +,8 @@ static void cpt_enable_hdmi(struct intel_encoder *encoder,
   ~TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
}
 
-   if (crtc->config->has_audio)
-   intel_enable_hdmi_audio(encoder);
+   if (pipe_config->has_audio)
+   intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
 }
 
 static void vlv_enable_hdmi(struct intel_encoder *encoder,
@@ -1178,9 +1179,7 @@ static void g4x_disable_hdmi(struct intel_encoder 
*encoder,
 struct intel_crtc_state *old_crtc_state,
 struct drm_connector_state *old_conn_state)
 {
-   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
-
-   if (crtc->config->has_audio)
+   if (old_crtc_state->has_audio)
intel_audio_codec_disable(encoder);
 
intel_disable_hdmi(encoder, old_crtc_state, old_conn_state);
@@ -1190,9 +1189,7 @@ static void pch_disable_hdmi(struct intel_encoder 
*encoder,
 struct intel_crtc_state *old_crtc_state,
   

[Intel-gfx] [PATCH v3 10/11] drm/i915: Pass atomic state to verify_connector_state

2016-11-08 Thread Maarten Lankhorst
This gets rid of a warning that the connectors are used without locking
when doing a nonblocking modeset.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d368afa199e3..ee8b6db0b425 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13543,11 +13543,15 @@ static void verify_wm_state(struct drm_crtc *crtc,
 }
 
 static void
-verify_connector_state(struct drm_device *dev, struct drm_crtc *crtc)
+verify_connector_state(struct drm_device *dev,
+  struct drm_atomic_state *state,
+  struct drm_crtc *crtc)
 {
struct drm_connector *connector;
+   struct drm_connector_state *old_conn_state;
+   int i;
 
-   drm_for_each_connector(connector, dev) {
+   for_each_connector_in_state(state, connector, old_conn_state, i) {
struct drm_encoder *encoder = connector->encoder;
struct drm_connector_state *state = connector->state;
 
@@ -13755,15 +13759,16 @@ verify_shared_dpll_state(struct drm_device *dev, 
struct drm_crtc *crtc,
 
 static void
 intel_modeset_verify_crtc(struct drm_crtc *crtc,
-struct drm_crtc_state *old_state,
-struct drm_crtc_state *new_state)
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_state,
+ struct drm_crtc_state *new_state)
 {
if (!needs_modeset(new_state) &&
!to_intel_crtc_state(new_state)->update_pipe)
return;
 
verify_wm_state(crtc, new_state);
-   verify_connector_state(crtc->dev, crtc);
+   verify_connector_state(crtc->dev, state, crtc);
verify_crtc_state(crtc, old_state, new_state);
verify_shared_dpll_state(crtc->dev, crtc, old_state, new_state);
 }
@@ -13779,10 +13784,11 @@ verify_disabled_dpll_state(struct drm_device *dev)
 }
 
 static void
-intel_modeset_verify_disabled(struct drm_device *dev)
+intel_modeset_verify_disabled(struct drm_device *dev,
+ struct drm_atomic_state *state)
 {
verify_encoder_state(dev);
-   verify_connector_state(dev, NULL);
+   verify_connector_state(dev, state, NULL);
verify_disabled_dpll_state(dev);
 }
 
@@ -14420,7 +14426,7 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
if (!intel_can_enable_sagv(state))
intel_disable_sagv(dev_priv);
 
-   intel_modeset_verify_disabled(dev);
+   intel_modeset_verify_disabled(dev, state);
}
 
/* Complete the events for pipes that have now been disabled */
@@ -14472,7 +14478,7 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
if (put_domains[i])
modeset_put_power_domains(dev_priv, put_domains[i]);
 
-   intel_modeset_verify_crtc(crtc, old_crtc_state, crtc->state);
+   intel_modeset_verify_crtc(crtc, state, old_crtc_state, 
crtc->state);
}
 
if (intel_state->modeset && intel_can_enable_sagv(state))
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 11/11] drm/i915: Enable support for nonblocking modeset

2016-11-08 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ee8b6db0b425..759b1fdbb009 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14561,10 +14561,6 @@ static void intel_atomic_track_fbs(struct 
drm_atomic_state *state)
  * This function commits a top-level state object that has been validated
  * with drm_atomic_helper_check().
  *
- * FIXME:  Atomic modeset support for i915 is not yet complete.  At the moment
- * nonblocking commits are only safe for pure plane updates. Everything else
- * should work though.
- *
  * RETURNS
  * Zero for success or -errno.
  */
@@ -14576,11 +14572,6 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
 
-   if (intel_state->modeset && nonblock) {
-   DRM_DEBUG_KMS("nonblocking commit for modeset not yet 
implemented.\n");
-   return -EINVAL;
-   }
-
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 09/11] drm/i915: Update atomic modeset state synchronously, v2.

2016-11-08 Thread Maarten Lankhorst
All of this state should be updated as soon as possible. It shouldn't be
done later because then future updates may not depend on it.

Changes since v1:
- Move the modeset update to before drm_atomic_state_get. (Ville)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e59adb03933e..d368afa199e3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14353,14 +14353,8 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
 
drm_atomic_helper_wait_for_dependencies(state);
 
-   if (intel_state->modeset) {
-   memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
-  sizeof(intel_state->min_pixclk));
-   dev_priv->active_crtcs = intel_state->active_crtcs;
-   dev_priv->atomic_cdclk_freq = intel_state->cdclk;
-
+   if (intel_state->modeset)
intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
-   }
 
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -14601,6 +14595,13 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_commit(state);
intel_atomic_track_fbs(state);
 
+   if (intel_state->modeset) {
+   memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
+  sizeof(intel_state->min_pixclk));
+   dev_priv->active_crtcs = intel_state->active_crtcs;
+   dev_priv->atomic_cdclk_freq = intel_state->cdclk;
+   }
+
drm_atomic_state_get(state);
INIT_WORK(>commit_work,
  nonblock ? intel_atomic_commit_work : NULL);
-- 
2.7.4

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


[Intel-gfx] [PATCH v3 00/11] Skylake watermark fixes and nonblocking modeset.

2016-11-08 Thread Maarten Lankhorst
These are the remaining watermark fixes required before nonblocking
modeset can be enabled, plus the patches required to enable
nonblocking modeset support in i915.

Maarten Lankhorst (11):
  drm/i915: Add a atomic evasion step to watermark programming, v3.
  drm/i915/gen9+: Program watermarks as a separate step during evasion,
v3.
  drm/i915/gen9+: Preserve old allocation from crtc_state.
  drm/i915/gen9+: Kill off hw_ddb from intel_crtc.
  drm/i915/gen9+: Do not initialise active_crtcs for !modeset
  drm/i915: Convert intel_hdmi to use atomic state
  drm/i915: Pass atomic state to intel_audio_codec_enable, v2.
  drm/edid: Remove drm_select_eld
  drm/i915: Update atomic modeset state synchronously, v2.
  drm/i915: Pass atomic state to verify_connector_state
  drm/i915: Enable support for nonblocking modeset

 drivers/gpu/drm/drm_edid.c   |  26 ---
 drivers/gpu/drm/i915/i915_drv.h  |  16 ++---
 drivers/gpu/drm/i915/intel_audio.c   |  17 +++--
 drivers/gpu/drm/i915/intel_ddi.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c | 131 +--
 drivers/gpu/drm/i915/intel_dp.c  |  11 +--
 drivers/gpu/drm/i915/intel_drv.h |  22 ++
 drivers/gpu/drm/i915/intel_hdmi.c|  50 ++---
 drivers/gpu/drm/i915/intel_pm.c  | 123 
 drivers/gpu/drm/i915/intel_sprite.c  |  18 -
 include/drm/drm_edid.h   |   1 -
 11 files changed, 173 insertions(+), 244 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH v2] drm/i915: don't whitelist oacontrol in cmd parser

2016-11-08 Thread Robert Bragg
This v2 patch bumps the command parser version so it can be referenced in
corresponding i-g-t gem_exec_parse changes.

--- >8 ---

Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

v2:
This bumps the command parser version from 8 to 9, as the change is
visible to userspace.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
Reviewed-by: Sourab Gupta 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 42 --
 1 file changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index c9d2ecd..f5762cd 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct intel_engine_cs 
*engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_SKIP)
return true;
@@ -1099,31 +1097,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}
 
/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_REG) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRR to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1214,7 +1187,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
u32 *cmd, *batch_end;
struct drm_i915_cmd_descriptor default_desc = noop_desc;
const struct drm_i915_cmd_descriptor *desc = _desc;
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
bool needs_clflush_after = false;
int ret = 0;
 
@@ -1270,8 +1242,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
break;
}
 
-   if (!check_cmd(engine, desc, cmd, length, 

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

2016-11-08 Thread Chris Wilson
On Mon, Nov 07, 2016 at 01:59:45PM +, Chris Wilson wrote:
> The scheduler needs to know the dependencies of each request for the
> lifetime of the request, as it may choose to reschedule the requests at
> any time and must ensure the dependency tree is not broken. This is in
> additional to using the fence to only allow execution after all
> dependencies have been completed.
> 
> One option was to extend the fence to support the bidirectional
> dependency tracking required by the scheduler. However the mismatch in
> lifetimes between the submit fence and the request essentially meant
> that we had to build a completely separate struct (and we could not
> simply reuse the existing waitqueue in the fence for one half of the
> dependency tracking). The extra dependency tracking simply did not mesh
> well with the fence, and keeping it separate both keeps the fence
> implementation simpler and allows us to extend the dependency tracking
> into a priority tree (whilst maintaining support for reordering the
> tree).
> 
> To avoid the additional allocations and list manipulations, the use of
> the priotree is disabled when there are no schedulers to use it.
> 
> v2: Create a dedicated slab for i915_dependency.
> Rename the lists.

Sod. I've squashed the priority sort into this as a rebase calamity.
-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 v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

2016-11-08 Thread sourab gupta
On Tue, 2016-11-08 at 03:47 -0800, Robert Bragg wrote:
> 
> 
> On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta 
> wrote:
> On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> > The maximum OA sampling frequency is now configurable via a
> > dev.i915.oa_max_sample_rate sysctl parameter.
> >
> > Following the precedent set by perf's similar
> > kernel.perf_event_max_sample_rate the default maximum rate
> is 10Hz
> >
> > Signed-off-by: Robert Bragg 
> > ---
> >  drivers/gpu/drm/i915/i915_perf.c | 61
> 
> >  1 file changed, 50 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> > index e51c1d8..1a87fe9 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -82,6 +82,21 @@ static u32 i915_perf_stream_paranoid =
> true;
> >  #define INVALID_CTX_ID 0x
> >
> >
> > +/* For sysctl proc_dointvec_minmax of
> i915_oa_max_sample_rate
> > + *
> > + * 160ns is the smallest sampling period we can
> theoretically program the OA
> > + * unit with on Haswell, corresponding to 6.25MHz.
> > + */
> > +static int oa_sample_rate_hard_limit = 625;
> There's no check for 'oa_sample_rate_hard_limit' anywhere
> below.
> 
> 
> It's in the struct ctl_table oa_table[] declaration of the
> "oa_max_sample_rate" paramater, assigned to .extra2 which is
> referenced by the proc_dointvec_minmax validation handler for the
> parameter.
> 
Ok. Seems fine then.
>  
> 
> > +
> > +/* Theoretically we can program the OA unit to sample every
> 160ns but don't
> > + * allow that by default unless root...
> > + *
> > + * The default threshold of 10Hz is based on perf's
> similar
> > + * kernel.perf_event_max_sample_rate sysctl parameter.
> > + */
> > +static u32 i915_oa_max_sample_rate = 10;
> > +
> >  /* XXX: beware if future OA HW adds new report formats that
> the current
> >   * code assumes all reports have a power-of-two size and
> ~(size - 1) can
> >   * be used as a mask to align the OA tail pointer.
> > @@ -1314,6 +1329,7 @@ static int
> read_properties_unlocked(struct drm_i915_private *dev_priv,
> >   }
> >
> >   for (i = 0; i < n_props; i++) {
> > + u64 oa_period, oa_freq_hz;
> >   u64 id, value;
> >   int ret;
> >
> > @@ -1359,21 +1375,35 @@ static int
> read_properties_unlocked(struct drm_i915_private *dev_priv,
> >   return -EINVAL;
> >   }
> >
> > - /* NB: The exponent represents a
> period as follows:
> > -  *
> > -  *   80ns * 2^(period_exponent + 1)
> > -  *
> > -  * Theoretically we can program the OA
> unit to sample
> > + /* Theoretically we can program the OA
> unit to sample
> >* every 160ns but don't allow that by
> default unless
> >* root.
> >*
> > -  * Referring to perf's
> > -  * kernel.perf_event_max_sample_rate
> for a precedent
> > -  * (10 by default); with an OA
> exponent of 6 we get
> > -  * a period of 10.240 microseconds
> -just under 10Hz
> > +  * On Haswell the period is derived
> from the exponent
> > +  * as:
> > +  *
> > +  *   period = 80ns * 2^(exponent + 1)
> > +  */
> > + BUILD_BUG_ON(sizeof(oa_period) != 8);
> > + oa_period = 80ull * (2ull << value);
> 
> I assume now that there'll be a platform specific check for
> 80ull, while
> programming oa_period, for subquent Gen8+ platforms, which
> should be
> fine.
> 
> 
> Yeah, this code will need adapting for gen9+. I guess we'll change it
> to work in terms of ((2< 
Seems reasonable.
>  
> 
> > +
> > + /* This check is primarily to ensure
> that oa_period <=
>  

[Intel-gfx] [PATCH i-g-t v6] tests/kms_plane_multiple: CRC based atomic correctness test

2016-11-08 Thread Mika Kahola
This is a testcase with multiple planes. The idea here is the following

 - draw a uniform frame with blue color
 - grab crc for reference
 - put planes randomly on top with the same blue color
 - punch holes with black color into the primary framebuffer
 - ideally the planes should cover these holes so that the output is the
   identical to reference crc
 - composite all with one ioctl call
 - grab crc and verify that the reference crc is equal
 - repeat this for several iterations to maximize coverage

v6: Rename test_planes() to prepare_planes() (Maarten)
When grabbing reference crc, keep framebuffer and crc enabled for
atomic mode setting. (Maarten)
Fix crc collection for legacy modesetting (Maarten)

v5: Remove limit for max number of iterations and add possibility to
loop forever (Daniel)
Remove IN_RANGE() macro (Maarten)
Remove log file and show random number seed on screen instead (Maarten)
Split legacy and atomic plane tests on own functions (Maarten)
remove test_atomic() function and pass test mode info as
parameter (Maarten)
Use bigger rectangle size (256x256) for non-cursor planes and
smaller (128x128) size for cursor plane (Maarten)

v4: For atomic test enable crc capturing before entering into a
iteration loop. After each iteration, check that page flip
didn't take no more than 1 vblank, fetch all crc's and check
the values.

Introduce new command line parameter for the number of iterations.
The test run from 1 to 256 iterations.

v3: Cleanup by removing separate plane array
For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
Grab crc by using igt_pipe_crc_get_crc instead of igt_pipe_crc_collect_crc
Rename nplanes variable to max_planes
To optimize test execution, run iterations after the modeset

v2: Keep a logfile on random number seeds per subtest that are not skipped
due to unmet test requirements

Signed-off-by: Mika Kahola 
---
 tests/Makefile.sources |   1 +
 tests/kms_plane_multiple.c | 501 +
 2 files changed, 502 insertions(+)
 create mode 100644 tests/kms_plane_multiple.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..ffd59c1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs_M = \
kms_pipe_color \
kms_pipe_crc_basic \
kms_plane \
+   kms_plane_multiple \
kms_properties \
kms_psr_sink_crc \
kms_render \
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
new file mode 100644
index 000..f316488
--- /dev/null
+++ b/tests/kms_plane_multiple.c
@@ -0,0 +1,501 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple planes ");
+
+#define MAX_CRCS  1
+#define SIZE_PLANE  256
+#define SIZE_CURSOR 128
+#define LOOP_FOREVER -1
+
+typedef struct {
+   float red;
+   float green;
+   float blue;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   igt_pipe_crc_t *pipe_crc;
+   igt_plane_t *plane[IGT_MAX_PLANES];
+   struct igt_fb fb[IGT_MAX_PLANES];
+} data_t;
+
+typedef struct {
+   data_t *data;
+   igt_crc_t reference_crc;
+} test_position_t;
+
+/* Command line parameters. */
+struct {
+   int iterations;
+   bool user_seed;
+   int seed;
+} opt = {
+   .iterations = 64,
+   .user_seed = false,
+   .seed = 1,
+};
+
+static inline uint32_t pipe_select(int pipe)
+{
+   if (pipe > 1)
+   return pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
+   else if (pipe > 0)
+   return DRM_VBLANK_SECONDARY;
+   else
+ 

Re: [Intel-gfx] [PATCH v4 1/3] lib: add igt_dummyload

2016-11-08 Thread Abdiel Janulgue
By the way, series was tested on CI with no regressions.

- Abdiel

On 11/07/2016 09:48 AM, Abdiel Janulgue wrote:
> A lot of igt testcases need some GPU workload to make sure a race
> window is big enough. Unfortunately having a fixed amount of
> workload leads to spurious test failures or overtly long runtimes
> on some fast/slow platforms. This library contains functionality
> to submit GPU workloads that should consume exactly a specific
> amount of time.
> 
> v2 : Add recursive batch feature from Chris
> v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch
>  by adding a dummy reloc to the bo as suggested by Ville.
> v4:  Fix dependency reloc as write instead of read (Ville).
>  Fix wrong handling of batchbuffer start on ILK causing
>  test failure
> 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: Chris Wilson 
> Signed-off-by: Abdiel Janulgue 
> ---
>  lib/Makefile.sources |   2 +
>  lib/igt.h|   1 +
>  lib/igt_dummyload.c  | 274 
> +++
>  lib/igt_dummyload.h  |  42 
>  4 files changed, 319 insertions(+)
>  create mode 100644 lib/igt_dummyload.c
>  create mode 100644 lib/igt_dummyload.h
> 
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index e8e277b..7fc5ec2 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -75,6 +75,8 @@ lib_source_list =   \
>   igt_draw.h  \
>   igt_pm.c\
>   igt_pm.h\
> + igt_dummyload.c \
> + igt_dummyload.h \
>   uwildmat/uwildmat.h \
>   uwildmat/uwildmat.c \
>   $(NULL)
> diff --git a/lib/igt.h b/lib/igt.h
> index d751f24..a0028d5 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -32,6 +32,7 @@
>  #include "igt_core.h"
>  #include "igt_debugfs.h"
>  #include "igt_draw.h"
> +#include "igt_dummyload.h"
>  #include "igt_fb.h"
>  #include "igt_gt.h"
>  #include "igt_kms.h"
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> new file mode 100644
> index 000..2d05594
> --- /dev/null
> +++ b/lib/igt_dummyload.c
> @@ -0,0 +1,274 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include "igt.h"
> +#include "igt_dummyload.h"
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * SECTION:igt_dummyload
> + * @short_description: Library for submitting GPU workloads
> + * @title: Dummyload
> + * @include: igt.h
> + *
> + * A lot of igt testcases need some GPU workload to make sure a race window 
> is
> + * big enough. Unfortunately having a fixed amount of workload leads to
> + * spurious test failures or overtly long runtimes on some fast/slow 
> platforms.
> + * This library contains functionality to submit GPU workloads that should
> + * consume exactly a specific amount of time.
> + */
> +
> +#define NSEC_PER_SEC 10L
> +
> +#define gettid() syscall(__NR_gettid)
> +#define sigev_notify_thread_id _sigev_un._tid
> +
> +#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
> +#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
> +
> +#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
> +
> +static void
> +fill_object(struct drm_i915_gem_exec_object2 *obj, uint32_t gem_handle,
> + struct drm_i915_gem_relocation_entry *relocs, uint32_t count)
> +{
> + memset(obj, 0, sizeof(*obj));
> + obj->handle = gem_handle;
> + obj->relocation_count = count;
> + obj->relocs_ptr = (uintptr_t)relocs;
> +}
> +
> +static void
> +fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
> +uint32_t gem_handle, uint32_t offset,
> +uint32_t read_domains, uint32_t write_domains)
> +{
> + reloc->target_handle = 

Re: [Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

2016-11-08 Thread Robert Bragg
On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta  wrote:

> On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> > The maximum OA sampling frequency is now configurable via a
> > dev.i915.oa_max_sample_rate sysctl parameter.
> >
> > Following the precedent set by perf's similar
> > kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
> >
> > Signed-off-by: Robert Bragg 
> > ---
> >  drivers/gpu/drm/i915/i915_perf.c | 61 ++
> ++
> >  1 file changed, 50 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> > index e51c1d8..1a87fe9 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -82,6 +82,21 @@ static u32 i915_perf_stream_paranoid = true;
> >  #define INVALID_CTX_ID 0x
> >
> >
> > +/* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate
> > + *
> > + * 160ns is the smallest sampling period we can theoretically program
> the OA
> > + * unit with on Haswell, corresponding to 6.25MHz.
> > + */
> > +static int oa_sample_rate_hard_limit = 625;
> There's no check for 'oa_sample_rate_hard_limit' anywhere below.
>

It's in the struct ctl_table oa_table[] declaration of the
"oa_max_sample_rate" paramater, assigned to .extra2 which is referenced by
the proc_dointvec_minmax validation handler for the parameter.


>
> > +
> > +/* Theoretically we can program the OA unit to sample every 160ns but
> don't
> > + * allow that by default unless root...
> > + *
> > + * The default threshold of 10Hz is based on perf's similar
> > + * kernel.perf_event_max_sample_rate sysctl parameter.
> > + */
> > +static u32 i915_oa_max_sample_rate = 10;
> > +
> >  /* XXX: beware if future OA HW adds new report formats that the current
> >   * code assumes all reports have a power-of-two size and ~(size - 1) can
> >   * be used as a mask to align the OA tail pointer.
> > @@ -1314,6 +1329,7 @@ static int read_properties_unlocked(struct
> drm_i915_private *dev_priv,
> >   }
> >
> >   for (i = 0; i < n_props; i++) {
> > + u64 oa_period, oa_freq_hz;
> >   u64 id, value;
> >   int ret;
> >
> > @@ -1359,21 +1375,35 @@ static int read_properties_unlocked(struct
> drm_i915_private *dev_priv,
> >   return -EINVAL;
> >   }
> >
> > - /* NB: The exponent represents a period as follows:
> > -  *
> > -  *   80ns * 2^(period_exponent + 1)
> > -  *
> > -  * Theoretically we can program the OA unit to
> sample
> > + /* Theoretically we can program the OA unit to
> sample
> >* every 160ns but don't allow that by default
> unless
> >* root.
> >*
> > -  * Referring to perf's
> > -  * kernel.perf_event_max_sample_rate for a
> precedent
> > -  * (10 by default); with an OA exponent of 6
> we get
> > -  * a period of 10.240 microseconds -just under
> 10Hz
> > +  * On Haswell the period is derived from the
> exponent
> > +  * as:
> > +  *
> > +  *   period = 80ns * 2^(exponent + 1)
> > +  */
> > + BUILD_BUG_ON(sizeof(oa_period) != 8);
> > + oa_period = 80ull * (2ull << value);
> I assume now that there'll be a platform specific check for 80ull, while
> programming oa_period, for subquent Gen8+ platforms, which should be
> fine.
>

Yeah, this code will need adapting for gen9+. I guess we'll change it to
work in terms of ((2<
> > +
> > + /* This check is primarily to ensure that
> oa_period <=
> > +  * UINT32_MAX (before passing to do_div which only
> > +  * accepts a u32 denominator), but we can also skip
> > +  * checking anything < 1Hz which implicitly can't
> be
> > +  * limited via an integer oa_max_sample_rate.
> >*/
> > - if (value < 6 && !capable(CAP_SYS_ADMIN)) {
> > - DRM_ERROR("Minimum OA sampling exponent is
> 6 without root privileges\n");
> > + if (oa_period <= NSEC_PER_SEC) {
> > + u64 tmp = NSEC_PER_SEC;
> > + do_div(tmp, oa_period);
> > + oa_freq_hz = tmp;
> > + } else
> > + oa_freq_hz = 0;
> > +
> > + if (oa_freq_hz > i915_oa_max_sample_rate &&
> > + !capable(CAP_SYS_ADMIN)) {
> > +

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Always flush the dirty CPU cache when pinning the scanout

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 01:33:41PM +0200, Ville Syrjälä wrote:
> On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote:
> > -   i915_gem_object_flush_cpu_write_domain(obj);
> > +   if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> > +   i915_gem_clflush_object(obj, true);
> > +   intel_fb_obj_flush(obj, false, ORIGIN_CPU);
> 
> So one slight change in behaviour is that we won't clear the write domain
> here, but that's fine since we'll clear it below anyway.
> 
> The other is that we now call intel_fb_obj_flush() unconditionally,
> whereas before we only called if when the bo was in the CPU write
> domain. Hmm. Should we keep it conditional?

I was thinking that we should call it in the case we deferred clflush,
and I was wanting to make the preflip path closer to dirtyfb. Since to
me they both demark the frame boundary and the preparatory flushing
should be more or less the same.

> > old_write_domain = obj->base.write_domain;
> > old_read_domains = obj->base.read_domains;
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 92ab01f33208..47233b242c99 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15698,6 +15698,8 @@ static int intel_user_framebuffer_dirty(struct 
> > drm_framebuffer *fb,
> > struct drm_i915_gem_object *obj = intel_fb->obj;
> >  
> > mutex_lock(>struct_mutex);
> > +   if (obj->pin_display && obj->cache_dirty)
> > +   i915_gem_clflush_object(obj, true);
> > intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
> > mutex_unlock(>struct_mutex);

-- 
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] [drm-intel:topic/drm-misc 1/13] ERROR: "depot_save_stack" [drivers/gpu/drm/drm.ko] undefined!

2016-11-08 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   3835b46e5535d9ad534776bc93670db097682556
commit: 5705670d0463423337c82d00877989e7df8b169d [1/13] drm: Track drm_mm 
allocators and show leaks on shutdown
config: i386-randconfig-i1-201645 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
git checkout 5705670d0463423337c82d00877989e7df8b169d
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "depot_save_stack" [drivers/gpu/drm/drm.ko] undefined!
>> ERROR: "depot_fetch_stack" [drivers/gpu/drm/drm.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Always flush the dirty CPU cache when pinning the scanout

2016-11-08 Thread Ville Syrjälä
On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote:
> Currently we only clflush the scanout if it is in the CPU domain. Also
> flush if we have a pending CPU clflush. We also want to treat the
> dirtyfb path similar, and flush any pending writes there as well.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c  | 9 +
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d48509783e41..6845cf03287c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3356,12 +3356,12 @@ int i915_gem_object_set_cache_level(struct 
> drm_i915_gem_object *obj,
>   enum i915_cache_level cache_level)
>  {
>   struct i915_vma *vma;
> - int ret = 0;
> + int ret;
>  
>   lockdep_assert_held(>base.dev->struct_mutex);
>  
>   if (obj->cache_level == cache_level)
> - goto out;
> + return 0;

I added this for the pin_display case, which you now handle explicitly.
So yeah, looks like this can go. At least I can't think of another valid
use case to keep flushing on every set_cache_level(NONE).

>  
>   /* Inspect the list of currently bound VMA and unbind any that would
>* be invalid given the new cache-level. This is principally to
> @@ -3459,7 +3459,6 @@ int i915_gem_object_set_cache_level(struct 
> drm_i915_gem_object *obj,
>   vma->node.color = cache_level;
>   obj->cache_level = cache_level;
>  
> -out:
>   /* Flush the dirty CPU caches to the backing storage so that the
>* object is now coherent at its new cache level (with respect
>* to the access domain).
> @@ -3608,7 +3607,9 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>  
>   vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
>  
> - i915_gem_object_flush_cpu_write_domain(obj);
> + if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> + i915_gem_clflush_object(obj, true);
> + intel_fb_obj_flush(obj, false, ORIGIN_CPU);

So one slight change in behaviour is that we won't clear the write domain
here, but that's fine since we'll clear it below anyway.

The other is that we now call intel_fb_obj_flush() unconditionally,
whereas before we only called if when the bo was in the CPU write
domain. Hmm. Should we keep it conditional?

>  
>   old_write_domain = obj->base.write_domain;
>   old_read_domains = obj->base.read_domains;
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 92ab01f33208..47233b242c99 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15698,6 +15698,8 @@ static int intel_user_framebuffer_dirty(struct 
> drm_framebuffer *fb,
>   struct drm_i915_gem_object *obj = intel_fb->obj;
>  
>   mutex_lock(>struct_mutex);
> + if (obj->pin_display && obj->cache_dirty)
> + i915_gem_clflush_object(obj, true);
>   intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
>   mutex_unlock(>struct_mutex);
>  
> -- 
> 2.10.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 igt] igt/gem_exec_reloc: Check we write the full 64bit relocation

2016-11-08 Thread Petri Latvala
On Fri, Nov 04, 2016 at 03:03:59PM +, Chris Wilson wrote:
> Recently a patch ran successfully through BAT that broke 64bit
> relocations on a couple of machines. Oops. So lets add a very fast set
> of tests to check basic relocation handling.
> 
> Signed-off-by: Chris Wilson 
> ---



This commit was pushed without acks or reviews. Don't do that for
commits that change the BAT set.

I would revert that change otherwise, but I was just about to post
that this change has now been tested on the second CI farm and can be
deployed from CI pov. Oh well.

Don't do that.



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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove chipset flush after cache flush

2016-11-08 Thread Chris Wilson
On Mon, Nov 07, 2016 at 06:16:00PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-07 at 12:10 +, Chris Wilson wrote:
> > On Mon, Nov 07, 2016 at 02:01:46PM +0200, Joonas Lahtinen wrote:
> > > 
> > > On su, 2016-11-06 at 12:59 +, Chris Wilson wrote:
> > > > 
> > > > We always flush the chipset prior to executing with the GPU, so we can
> > > > skip the flush during ordinary domain management.
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > 
> > > Maybe even add?
> > > 
> > > Fixes: dcd79934b0dd ("drm/i915: Unconditionally flush any chipset buffers 
> > > before execbuf")
> > 
> > It is just an optimisation - I don't want to imply that we should be
> 
> Well, it's an optimization that fixes a commit which duplicated the
> call. That might be a regression in some micro-benchmark.
> 
> But fine without the tag too, if you're sure it's not a big one.

Added the reference to the commit, but without the fixes tag since I
don't think it is a big deal (as the number of unconditional chipset
flushes will be much greater than the number of unneeded flushes removed
in this patch).
-Chris

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


Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Update connector status for DP MST hotplugs

2016-11-08 Thread Ville Syrjälä
On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> Hotplugging a monitor in DP MST configuration triggers short pulses.
> Although the short pulse handling path ends up in the MST hotplug function,
> we do not perform a detect before sending the hotplug uvent. This leads to
> the connector status not being updated when the userspace calls
> DRM_IOCTL_MODE_GETCONNECTOR.
> 
> So, let's call the connector function ->detect() to update the connector
> status before sending the uevent.
> 
> v2: Update connector status inside mode_config mutex (Ville)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..8e36a96 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -492,8 +492,28 @@ static void intel_dp_mst_hotplug(struct 
> drm_dp_mst_topology_mgr *mgr)
>   struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct intel_connector *intel_connector;
> + bool changed = false;
> + enum drm_connector_status old_status;
> + struct drm_mode_config *mode_config = >mode_config;
> +
> + mutex_lock(_config->mutex);
> + for_each_intel_connector(dev, intel_connector) {
> + struct drm_connector *connector = &(intel_connector->base);
> +
> + if (intel_connector->mst_port != intel_dp)
> + continue;
> +
> + old_status = connector->status;
> + connector->status = connector->funcs->detect(connector, false);
> +
> + if (old_status != connector->status)
> + changed = true;
> + }
> + mutex_unlock(_config->mutex);

To help reviewers it might be nice to have a short explanation of the
locking situation in the commit message, mainly why is it safe to simply
take mode_config.mutex here.

>  
> - drm_kms_helper_hotplug_event(dev);
> + if (changed)
> + drm_kms_helper_hotplug_event(dev);
>  }
>  
>  static const struct drm_dp_mst_topology_cbs mst_cbs = {
> -- 
> 2.7.4

-- 
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 1/5] drm/i915: Fix scaling check for 90/270 degree plane rotation

2016-11-08 Thread Ville Syrjälä
On Mon, Nov 07, 2016 at 09:28:58PM +, Chris Wilson wrote:
> On Mon, Nov 07, 2016 at 10:20:53PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface
> > offset in the plane check hook for SKL+") we've already rotated the src
> > coordinates by 270 degrees by the time we check if a scaler is needed
> > or not, so we must not account for the rotation a second time.
> > Previously we did these steps in the opposite order and hence the
> > scaler check had to deal with rotation itself. The double rotation
> > handling causes us to enable a scaler pretty much every time 90/270
> > degree plane rotation is requested, leading to fuzzier fonts and whatnot.
> > 
> > Cc: Sivakumar Thulasimani 
> > Cc: Tvrtko Ursulin 
> > Cc: drm-intel-fi...@lists.freedesktop.org
> > Reported-by: Tvrtko Ursulin 
> > Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane 
> > check hook for SKL+")
> > Signed-off-by: Ville Syrjälä 
> 
> I believe
> 
>   Tested-by: Tvrtko Ursulin 

Thanks, forgot to amend it.

> 
> skl_plane_downscale_amount() ?
> skl_plane_relative_data_rate() ?
> skl_ddb_min_alloc()
> skl_compute_plane_wm()

Oh dear. I may have broken the world. Looks like a full blown review
of all uses of the src rect is required.

> What's the best way of keeping the reader aware of whether or not the
> coordinate transform has been applied? Similar to how to let the user
> know the rect is in fixed_16_16 or int32.

That's a good question. I guess for the fixed point stuff we could
define a new type, but then we can't use the same functions to massage
it, which doesn't sound all that nice. Hmm. Maybe we need to add some
metadata to the struct?

-- 
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] linux-next: manual merge of the tip tree with the drm-intel tree

2016-11-08 Thread Daniel Vetter
On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> FIXME: Add owner of second tree to To:
>Add author(s)/SOB of conflicting commits.
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   drivers/gpu/drm/i915/i915_gem_shrinker.c
> 
> between commits:
> 
>   1233e2db199d ("drm/i915: Move object backing storage manipulation to its 
> own locking")
> 
> from the drm-intel tree and commit:
> 
>   3ab7c086d5ec ("locking/drm: Kill mutex trickery")
>   c7faee2109f9 ("locking/drm: Fix i915_gem_shrinker_lock() locking")

Hm, this seems to be the older versions that nuke the recursive locking
trickery entirely, I thought we had version in-flight that kept that? I
know that the i915 (and msm locking fwiw) is horrible since essentially
it's a recursive BKL, and we're working (slowly, after all getting rid of
the BKL wasn't simple either) to fix this. But meanwhile I'm assuming that
we'll still need this to be able to get out of low memory situations in
i915. Has that part simply not yet landed?

Thanks, Daniel

> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/i915_gem_shrinker.c
> index a6fc1bdc48af,e9bd2a81d03a..
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@@ -35,33 -35,6 +35,15 @@@
>   #include "i915_drv.h"
>   #include "i915_trace.h"
>   
> - static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct 
> *task)
> - {
> - if (!mutex_is_locked(mutex))
> - return false;
> - 
> - #if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_MUTEX_SPIN_ON_OWNER)
> - return mutex->owner == task;
> - #else
> - /* Since UP may be pre-empted, we cannot assume that we own the lock */
> - return false;
> - #endif
> - }
> - 
>  +static bool i915_gem_shrinker_lock(struct drm_device *dev, bool *unlock)
>  +{
> - if (!mutex_trylock(>struct_mutex)) {
> - if (!mutex_is_locked_by(>struct_mutex, current))
> - return false;
> - 
> - *unlock = false;
> - } else {
> - *unlock = true;
> - }
> ++if (!mutex_trylock(>struct_mutex))
> ++return false;
>  +
> ++*unlock = true;
>  +return true;
>  +}
>  +
>   static bool any_vma_pinned(struct drm_i915_gem_object *obj)
>   {
>   struct i915_vma *vma;

-- 
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] ✓ Fi.CI.BAT: success for drm/i915: Remove two sloppy inline functions from .h (rev2)

2016-11-08 Thread Joonas Lahtinen
On ti, 2016-11-08 at 07:46 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Remove two sloppy inline functions from .h (rev2)
> URL   : https://patchwork.freedesktop.org/series/14931/
> State : success
> 

Merged the patch, thanks for the review.

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 igt v2 2/6] igt/gem_exec_parse: remove oacontrol checks

2016-11-08 Thread Chris Wilson
On Mon, Nov 07, 2016 at 10:26:59PM +, Robert Bragg wrote:
> The command parser no longer whitelists or does anything special for the
> OACONTROL register which is now considered owned by i915-perf.
> 
> As a follow up the plan is to at least check that attempting to write to
> OACONTROL from userspace must not fail with an EINVAL error, otherwise
> Mesa's graceful fallback path for not being able to write to OACONTROL
> via LRI commands will cause Mesa applications to abort().

This was part of the earlier ABI, and will remain ABI for those kernels.
If the cmdparser advertises that it expects OACONTROL to be paired, we
should keep testing that the cmdparser does as advertised.
-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 v2] drm: move allocation out of drm_get_format_name()

2016-11-08 Thread Daniel Vetter
On Mon, Nov 07, 2016 at 07:38:25PM +0200, Jani Nikula wrote:
> On Mon, 07 Nov 2016, Eric Engestrom  wrote:
> > On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
> >> On Mon, 07 Nov 2016, Eric Engestrom  wrote:
> >> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >> >
> >> > drm: make drm_get_format_name thread-safe
> >> >
> >> > Signed-off-by: Eric Engestrom 
> >> > [danvet: Clarify that the returned pointer must be freed with
> >> > kfree().]
> >> > Signed-off-by: Daniel Vetter 
> >> 
> >> The Fixes: format is:
> >> 
> >> Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
> >> 
> >> But is this a fix, really, or just an improvement? What exactly is the
> >> bug being fixed? The commit message is not sufficient.
> >
> > "The function's behaviour was changed in 90844f00049e, without changing
> > its signature, causing people to keep using it the old way without
> > realising they were now leaking memory.
> > Rob Clark also noticed it was also allocating GFP_KERNEL memory in
> > atomic contexts, breaking them.
> >
> > Instead of having to allocate GFP_ATOMIC memory and fixing the callers
> > to make them cleanup the memory afterwards, let's change the function's
> > signature by having the caller take care of the memory and passing it to
> > the function.
> > The new parameter is a single-field struct in order to enforce the size
> > of its buffer and help callers to correctly manage their memory."
> >
> > Does this sound good?
> 
> It's fine; no need to go overboard. ;)

Can you pls resend with that and corrected Fixes and all the acks
collected?
-Daniel

> 
> BR,
> Jani.
> 
> >
> >> > @@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t 
> >> > format);
> >> >  int drm_format_vert_chroma_subsampling(uint32_t format);
> >> >  int drm_format_plane_width(int width, uint32_t format, int plane);
> >> >  int drm_format_plane_height(int height, uint32_t format, int plane);
> >> > -char *drm_get_format_name(uint32_t format) __malloc;
> >> > +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
> >> > *buf);
> >> 
> >> I wonder if it would be better to make that return "const char *". If
> >> the user really wants to look under the hood, there's buf->str. *shrug*
> >
> > Good idea, I'll do that in v3 with the proper commit msg and tags. It'll
> > have to wait another day though, -ENOTIME and all.
> >
> >> 
> >> With the commit message improved,
> >> 
> >> Reviewed-by: Jani Nikula 
> >
> > Cheers :)
> >   Eric
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] [RFC i-g-t 2/4] igt_aux: Add igt_set_autoresume_delay()

2016-11-08 Thread Chris Wilson
On Mon, Nov 07, 2016 at 07:05:14PM -0500, Lyude wrote:
> The default autoresume delay is about 5 seconds. It's possible on a
> system that's not very fast this might not be a long enough time, since
> an asynchronous hotplug event we scheduled on the chamelium that was
> intended to happen during suspend could happen before we actually manage
> to suspend. So, add a function that allows us to increase the autoresume
> time to ensure this never happens during suspend/resume tests with the
> chamelium.
> 
> Signed-off-by: Lyude 
> ---
>  lib/igt_aux.c | 46 ++
>  lib/igt_aux.h |  1 +
>  2 files changed, 47 insertions(+)
> 
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index 9754148..26d32fd 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -812,6 +812,52 @@ void igt_system_suspend_autoresume(enum 
> igt_suspend_state state,
>   close(power_dir);
>  }
>  
> +static int original_autoresume_delay;
> +
> +static void igt_restore_autoresume_delay(int sig)
> +{
> + int delay_fd;
> + char delay_str[10];
> +
> + igt_assert((delay_fd = 
> open("/sys/module/suspend/parameters/pm_test_delay",
> + O_WRONLY)) >= 0);
> +
> + snprintf(delay_str, sizeof(delay_str), "%d", original_autoresume_delay);
> + igt_assert(write(delay_fd, delay_str, strlen(delay_str)));
> +
> + close(delay_fd);
> +}
> +
> +/**
> + * igt_set_autoresume_delay:
> + * @delay_secs: The delay in seconds before resuming the system
> + *
> + * Sets how long we wait to resume the system after suspending it, using the
> + * suspend.pm_test_delay variable. On exit, the original delay value is
> + * restored.
> + */
> +void igt_set_autoresume_delay(int delay_secs)
> +{
> + int delay_fd;
> + char delay_str[10];
> +
> + igt_skip_on_simulation();
> +
> + igt_assert((delay_fd = 
> open("/sys/module/suspend/parameters/pm_test_delay",
> + O_RDWR)) >= 0);

Are these test failures? No, then don't assert. Do it within your
igt_fixture() block and use igt_require to skip.
-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] [RFC i-g-t 3/4] igt_aux: Add some list helpers from wayland

2016-11-08 Thread Chris Wilson
On Mon, Nov 07, 2016 at 07:05:15PM -0500, Lyude wrote:
> Since we're going to be using lists for keeping track of EDIDs we've
> allocated on the chamelium, add some generic list helpers from the
> wayland project.

We are a little more familiar with the kernel naming convention.
-Chris

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUG

2016-11-08 Thread Daniel Vetter
On Sat, Oct 29, 2016 at 07:42:14PM +0100, Chris Wilson wrote:
> A frequent issue that arises on shutdown is the drm_mm range manager
> complaining of a leak. To aide debugging those, drm can now track the
> allocation callsite and print those for the leaks.
> 
> Signed-off-by: Chris Wilson 

Makes sense, and applied to drm-misc for easier merging.
-Daniel

> ---
>  drivers/gpu/drm/i915/Kconfig.debug | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
> b/drivers/gpu/drm/i915/Kconfig.debug
> index cee87bfd10c4..69edf196ed03 100644
> --- a/drivers/gpu/drm/i915/Kconfig.debug
> +++ b/drivers/gpu/drm/i915/Kconfig.debug
> @@ -21,6 +21,7 @@ config DRM_I915_DEBUG
>  select PREEMPT_COUNT
>  select X86_MSR # used by igt/pm_rpm
>  select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
> +select DRM_DEBUG_MM
>  default n
>  help
>Choose this option to turn on extra driver debugging that may 
> affect
> -- 
> 2.10.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 v2 02/11] drm/i915: Split request submit/execute phase into two

2016-11-08 Thread Joonas Lahtinen
On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote:
> In order to support deferred scheduling, we need to differentiate
> between when the request is ready to run (i.e. the submit fence is
> signaled) and when the request is actually run (a new execute fence).
> This is typically split between the request itself wanting to wait upon
> others (for which we use the submit fence) and the CPU wanting to wait
> upon the request, for which we use the execute fence to be sure the
> hardware is ready to signal completion.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Tvrtko Ursulin 

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 07/19] drm/atomic: Fix atomic helpers to use the new iterator macros.

2016-11-08 Thread Daniel Vetter
On Thu, Nov 03, 2016 at 06:22:05PM +0200, Ville Syrjälä wrote:
> This thing could use a commit message I think. Could at least lay out
> the basic rules on the foo->state/foo_state vs. old_state/new_state
> replacements. Might help someone understand it who doesn't know so much
> about the current state swapping mechanism.

Yup. I know Maarten doesn't like typing them, but except for
trival stuff they're needed.
-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 05/19] drm/atomic: Make add_affected_connectors look at crtc_state.

2016-11-08 Thread Daniel Vetter
On Thu, Nov 03, 2016 at 05:32:42PM +0200, Ville Syrjälä wrote:
> On Mon, Oct 17, 2016 at 02:37:04PM +0200, Maarten Lankhorst wrote:
> > This kills another dereference of connector->state. connector_mask
> > holds all unchanged connectors at least and any changed connectors
> > are already in state anyway.
> > 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 120775fcfb70..1915ec44f7eb 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1230,8 +1230,13 @@ drm_atomic_add_affected_connectors(struct 
> > drm_atomic_state *state,
> > struct drm_mode_config *config = >dev->mode_config;
> > struct drm_connector *connector;
> > struct drm_connector_state *conn_state;
> > +   struct drm_crtc_state *crtc_state;
> > int ret;
> >  
> > +   crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > +   if (IS_ERR(crtc_state))
> > +   return PTR_ERR(crtc_state);
> > +
> > ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
> > if (ret)
> > return ret;
> > @@ -1240,11 +1245,11 @@ drm_atomic_add_affected_connectors(struct 
> > drm_atomic_state *state,
> >  crtc->base.id, crtc->name, state);
> >  
> > /*
> > -* Changed connectors are already in @state, so only need to look at the
> > -* current configuration.
> > +* Changed connectors are already in @state, so only need to look
> > +* at the connector_mask in crtc_state.
> >  */
> > drm_for_each_connector(connector, state->dev) {
> > -   if (connector->state->crtc != crtc)
> > +   if (!(crtc_state->connector_mask & (1 << 
> > drm_connector_index(connector
> > continue;
> 
> So this being the new crtc state, connector_mask will include all newly 
> enabled
> connectors (these will have been already added to the top level state), and
> also any connector that was already enabled and isn't getting disabled (these
> are the ones we need to explicitly add to the top level state here).
> 
> /me wishes the top level state would be renamed to drm_atomic_transaction or 
> something...

+1 on drm_atomic_transaction, that's an awesome name. Not sure how bad it
would be to roll this out though ...
-Daniel

> 
> Any connector that is getting disabled will already have been added to
> the top level state as well, so them not being included in the new crtc
> state's connectors_mask is fine.
> 
> Reviewed-by: Ville Syrjälä 
> 
> >  
> > conn_state = drm_atomic_get_connector_state(state, connector);
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 v2 01/11] drm/i915: Create distinct lockclasses for execution vs user timelines

2016-11-08 Thread Chris Wilson
On Tue, Nov 08, 2016 at 09:43:21AM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote:
> > @@ -56,6 +61,24 @@ int i915_gem_timeline_init(struct drm_i915_private *i915,
> >     return 0;
> >  }
> >  
> > +int i915_gem_timeline_init(struct drm_i915_private *i915,
> > +      struct i915_gem_timeline *timeline,
> > +      const char *name)
> > +{
> > +   static struct lock_class_key class;
> > +   return __i915_gem_timeline_init(i915, timeline, name,
> > +   , "timeline");
> > +}
> > +
> > +int i915_gem_timeline_init__global(struct drm_i915_private *i915)
> > +{
> > +   static struct lock_class_key class;
> > +   return __i915_gem_timeline_init(i915,
> > +   >gt.global_timeline,
> > +   "[execution]",
> > +   , "global-timeline");
> > +}
> > +
> 
> These names might have potential to be confusing in lockdep splat,
> don't you think?

Urm, I lost a fixup. They are meant to be >lock and
_timeline->lock.
-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 01/19] drm/atomic: Add new iterators over all state

2016-11-08 Thread Daniel Vetter
On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
> > On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
> >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> >> replace the old for_each_xxx_in_state ones. This is useful for >1 flip
> >> depth and getting rid of all xxx->state dereferences.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/drm_atomic.c |  6 +++
> >>  drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
> >>  drivers/gpu/drm/i915/intel_display.c | 11 ++---
> >>  include/drm/drm_atomic.h | 81 
> >> ++--
> >>  include/drm/drm_atomic_helper.h  |  3 ++
> >>  5 files changed, 142 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 5dd70540219c..120775fcfb70 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state 
> >> *state,
> >>return ERR_PTR(-ENOMEM);
> >>  
> >>state->crtcs[index].state = crtc_state;
> >> +  state->crtcs[index].old_state = crtc->state;
> >> +  state->crtcs[index].new_state = crtc_state;
> >>state->crtcs[index].ptr = crtc;
> >>crtc_state->state = state;
> >>  
> >> @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
> >> *state,
> >>  
> >>state->planes[index].state = plane_state;
> >>state->planes[index].ptr = plane;
> >> +  state->planes[index].old_state = plane->state;
> >> +  state->planes[index].new_state = plane_state;
> >>plane_state->state = state;
> >>  
> >>DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
> >> @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> >> *state,
> >>  
> >>drm_connector_reference(connector);
> >>state->connectors[index].state = connector_state;
> >> +  state->connectors[index].old_state = connector->state;
> >> +  state->connectors[index].new_state = connector_state;
> >>state->connectors[index].ptr = connector;
> >>connector_state->state = state;
> >>  
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 07b432f43b98..fcb6e5b55217 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
> >>   *
> >>   * See also:
> >>   * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
> >> - * drm_atomic_helper_resume()
> >> + * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
> >>   */
> >>  struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
> >>  {
> >> @@ -2536,6 +2536,52 @@ unlock:
> >>  EXPORT_SYMBOL(drm_atomic_helper_suspend);
> >>  
> >>  /**
> >> + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
> >> + * @state: duplicated atomic state to commit
> >> + * @ctx: pointer to acquire_ctx to use for commit.
> >> + * @nonblock: commit the state non-blocking.
> >> + *
> >> + * The state returned by drm_atomic_helper_duplicate_state() and
> >> + * drm_atomic_helper_suspend() is partially invalid, and needs to
> >> + * be fixed up before commit.
> > So the old_state pointers are potentially invalid because whatever->state
> > may have changed since we duplicated the state?
> 
> Yes when you use drm_atomic_helper_duplicate_state, and commit a different 
> state before committing the duplicated state.
> This only happens during suspend/resume and gpu reset.

Kerneldoc should imo mention that suspend/resume is the only case this is
valid, and even then it depends upon the driver. Proper atomic commits
never keep drm_atomic_state around when dropping locks, so this can't
happen with an atomic ioctl. Please also directly cross-reference all
these functions.
-Daniel

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

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


Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

2016-11-08 Thread Daniel Vetter
On Thu, Nov 03, 2016 at 02:52:00PM -0400, Rob Clark wrote:
> On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom  wrote:
> > Signed-off-by: Eric Engestrom 
> > ---
> >
> > I moved the main bits to be the first diffs, shouldn't affect anything
> > when applying the patch, but I wanted to ask:
> > I don't like the hard-coded `32` the appears in both kmalloc() and
> > snprintf(), what do you think? If you don't like it either, what would
> > you suggest? Should I #define it?
> >
> > Second question is about the patch mail itself: should I send this kind
> > of patch separated by module, with a note requesting them to be squashed
> > when applying? It has to land as a single patch, but for review it might
> > be easier if people only see the bits they each care about, as well as
> > to collect ack's/r-b's.
> >
> > Cheers,
> >   Eric
> >
> > ---
> >  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  6 ++--
> >  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  6 ++--
> >  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  6 ++--
> >  drivers/gpu/drm/drm_atomic.c|  5 ++--
> >  drivers/gpu/drm/drm_crtc.c  | 21 -
> >  drivers/gpu/drm/drm_fourcc.c| 17 ++-
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  6 ++--
> >  drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
> >  drivers/gpu/drm/i915/intel_atomic_plane.c   |  6 ++--
> >  drivers/gpu/drm/i915/intel_display.c| 39 
> > -
> >  drivers/gpu/drm/radeon/atombios_crtc.c  | 12 +---
> >  include/drm/drm_fourcc.h|  2 +-
> >  12 files changed, 89 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 0645c85..38216a1 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -39,16 +39,14 @@ static char printable_char(int c)
> >   * drm_get_format_name - return a string for drm fourcc format
> >   * @format: format to compute name of
> >   *
> > - * Note that the buffer used by this function is globally shared and owned 
> > by
> > - * the function itself.
> > - *
> > - * FIXME: This isn't really multithreading safe.
> > + * Note that the buffer returned by this function is owned by the caller
> > + * and will need to be freed.
> >   */
> >  const char *drm_get_format_name(uint32_t format)
> >  {
> > -   static char buf[32];
> > +   char *buf = kmalloc(32, GFP_KERNEL);
> 
> 
> hmm, I guess I wasn't paying attention at the time this patch came by,
> but unfortunately this makes drm_get_format_name() no longer safe in
> atomic contexts :-/
> 
> We should probably either revert this or have two variants of
> drm_get_format_name()?  (ie. one that is not thread safe but is good
> enough for debugging)

Where do we need that for atomic contexts? I guess worst-case we could do
an auto-GFP trick using drm_can_sleep or something like that.
-Daniel

> 
> BR,
> -R
> 
> > -   snprintf(buf, sizeof(buf),
> > +   snprintf(buf, 32,
> >  "%c%c%c%c %s-endian (0x%08x)",
> >  printable_char(format & 0xff),
> >  printable_char((format >> 8) & 0xff),
> > @@ -73,6 +71,8 @@ EXPORT_SYMBOL(drm_get_format_name);
> >  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
> >   int *bpp)
> >  {
> > +   const char *format_name;
> > +
> > switch (format) {
> > case DRM_FORMAT_C8:
> > case DRM_FORMAT_RGB332:
> > @@ -127,8 +127,9 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int 
> > *depth,
> > *bpp = 32;
> > break;
> > default:
> > -   DRM_DEBUG_KMS("unsupported pixel format %s\n",
> > - drm_get_format_name(format));
> > +   format_name = drm_get_format_name(format);
> > +   DRM_DEBUG_KMS("unsupported pixel format %s\n", format_name);
> > +   kfree(format_name);
> > *depth = 0;
> > *bpp = 0;
> > break;
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index 7f90a39..030d22d 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -32,6 +32,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
> >  int drm_format_vert_chroma_subsampling(uint32_t format);
> >  int drm_format_plane_width(int width, uint32_t format, int plane);
> >  int drm_format_plane_height(int height, uint32_t format, int plane);
> > -const char *drm_get_format_name(uint32_t format);
> > +const char *drm_get_format_name(uint32_t format) __malloc;
> >
> >  #endif /* __DRM_FOURCC_H__ */
> > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > index c1b04e9..0bf8959 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> > +++