Re: [Intel-gfx] [PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put

[Daniel Vetter]

On Wed, Jan 04, 2017 at 03:26:48PM -0500, Alex Deucher wrote:
> On Wed, Jan 4, 2017 at 11:11 AM, Daniel Vetter  wrote:
> > On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote:
> >> I was lazy, rectify that! Also align with drm_atomic_state_get/put for
> >> ocd.
> >>
> >> v2: Git add helps.
> >>
> >> Signed-off-by: Daniel Vetter 
> >
> > Anyone feel like acking this, pretty please? ;-)
> 
> Acked-by: Alex Deucher 

Thanks, applied.
-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] ✓ Fi.CI.BAT: success for drm/i915: Header cleanup for intel_display

[Patchwork]

== Series Details ==

Series: drm/i915: Header cleanup for intel_display
URL   : https://patchwork.freedesktop.org/series/17526/
State : success

== Summary ==

Series 17526v1 drm/i915: Header cleanup for intel_display
https://patchwork.freedesktop.org/api/1.0/series/17526/revisions/1/mbox/


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:1   skip:14 
fi-bsw-n3050 total:246  pass:206  dwarn:0   dfail:0   fail:1   skip:39 
fi-bxt-j4205 total:246  pass:223  dwarn:0   dfail:0   fail:1   skip:22 
fi-byt-j1900 total:246  pass:218  dwarn:0   dfail:0   fail:1   skip:27 
fi-byt-n2820 total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 
fi-hsw-4770  total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-hsw-4770r total:246  pass:226  dwarn:0   dfail:0   fail:1   skip:19 
fi-ivb-3520m total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-kbl-7500u total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:221  dwarn:3   dfail:0   fail:1   skip:21 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:1   skip:13 
fi-snb-2520m total:246  pass:214  dwarn:0   dfail:0   fail:1   skip:31 

362e5ebefe40f1f00a7075ad2e472ef44a36a7da drm-tip: 2017y-01m-04d-20h-22m-18s UTC 
integration manifest
e441f18 drm/i915: Header cleanup for intel_display

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Header cleanup for intel_display

[Mika Kahola]

Remove reference to drm/drm_edid.h and drm/drmP.h as these are no longer
required.

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ab72858..c4e1bfa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -31,8 +31,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include "intel_drv.h"
 #include "intel_frontbuffer.h"
 #include 
-- 
2.7.4

___
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: Add render decompression support

[Ben Widawsky]

On 17-01-04 20:42:32, Ville Syrjälä wrote:

From: Ville Syrjälä 

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

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

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

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

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

Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
drivers/gpu/drm/i915/i915_reg.h  |  22 
drivers/gpu/drm/i915/intel_display.c | 219 +--
drivers/gpu/drm/i915/intel_pm.c  |   8 +-
drivers/gpu/drm/i915/intel_sprite.c  |   5 +
4 files changed, 240 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa77afa..05e18e742776 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6209,6 +6209,28 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))

+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
/* legacy palette */
#define _LGC_PALETTE_A   0x4a000
#define _LGC_PALETTE_B   0x4a800
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 38de9df0ec60..b547332eeda1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
*fb, int plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Yf_TILED:
/*
 * Bspec seems to suggest that the Yf tile width would
@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
struct drm_i915_private *dev_priv = to_i915(fb->dev);

/* AUX_DIST needs only 4K alignment */
-   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
+   if (plane == 1)


This looks wrong at least within this context, surely multi-planar formats might
have different alignment restrictions?


return 4096;

switch (fb->modifier) 

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Do not reset detect_done flag in intel_dp_detect

[Pandiyan, Dhinakaran]

On Thu, 2016-12-29 at 23:14 -0800, Dhinakaran Pandiyan wrote:

bump for review.


-DK


> From: "Navare, Manasi D" 
> 
> The detect_done flag was introduced in the 'commit 7d23e3c37bb3
> ("drm/i915: Cleaning up intel_dp_hpd_pulse")' in order to avoid multiple
> detects on hotplug where intel_dp_long_pulse() was called from HPD handler
> as well as intel_dp_detect(). Later, 'commit 1015811609c0
> ("drm/i915: Move long hpd handling into the hotplug work")' deferred long
> hpd handling to hotplug work to avoid handling it twice. But, resetting the
> flag after long hpd handling leads to the code being executed again during
> mode enumeration.
> 
> So, do not reset the detect_done flag to False in intel_dp_detect(). The
> flag is reset in intel_dp_hpd_pulse() to allow a full detect and set when
> the hotplug work does a full DPCD detect. However if ->detect() gets called
> during mode enumeration after a DPCD detect, return the cached connector
> status.
> 
> Resetting the flag in the encoder's reset callback should take care of
> hotplug between suspend/resume.
> 
> v2:
> Allow full detect after encoder reset. (Ville)
> Set the detect_done flag for connector disconnected case too. (DK)
> Commit message changes.
> 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjala 
> Cc: Ander Conselvande Oliveira 
> Cc: Jani Nikula 
> Fixes: commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
> Signed-off-by: Manasi Navare 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fb12896..6732c17 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4516,7 +4516,6 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>   intel_dp_set_edid(intel_dp);
>   if (is_edp(intel_dp) || intel_connector->detect_edid)
>   status = connector_status_connected;
> - intel_dp->detect_done = true;
>  
>   /* Try to read the source of the interrupt */
>   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> @@ -4551,10 +4550,10 @@ intel_dp_detect(struct drm_connector *connector, bool 
> force)
> connector->base.id, connector->name);
>  
>   /* If full detect is not performed yet, do a full detect */
> - if (!intel_dp->detect_done)
> + if (!intel_dp->detect_done) {
> + intel_dp->detect_done = true;
>   status = intel_dp_long_pulse(intel_dp->attached_connector);
> -
> - intel_dp->detect_done = false;
> + }
>  
>   return status;
>  }
> @@ -4859,6 +4858,8 @@ void intel_dp_encoder_reset(struct drm_encoder *encoder)
>   if (lspcon->active)
>   lspcon_resume(lspcon);
>  
> + intel_dp->detect_done = false;
> +
>   pps_lock(intel_dp);
>  
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))

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

Re: [Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

[Pandiyan, Dhinakaran]

On Wed, 2017-01-04 at 19:20 +, Pandiyan, Dhinakaran wrote:
> On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote:
> > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote:
> > > Link bandwidth is shared between multiple display streams in DP MST
> > > configurations. The DP MST topology manager structure maintains the shared
> > > link bandwidth for a primary link directly connected to the GPU. For 
> > > atomic
> > > modesetting drivers, checking if there is sufficient link bandwidth for a
> > > mode needs to be done during the atomic_check phase to avoid failed
> > > modesets. Let's encsapsulate the available link bw information in a state
> > > structure so that bw can be allocated and released atomically for each of
> > > the ports sharing the primary link.
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > 
> > Overall issue with the patch is that dp helpers now have 2 places where
> > available_slots is stored: One for atomic drivers in ->state, and the
> > legacy one. I think it'd be good to rework the legacy codepaths (i.e.
> > drm_dp_find_vcpi_slots) to use mgr->state->avail_slots, and remove
> > mgr->avail_slots entirely.
> 
> PATCH 2/6 does that. mgr->avail_slots is not updated in the legacy code
> path, so the check turns out to be against mgr->total_slots. So, I did
> just that, albeit explicitly. 
> 
> -DK
> 
> > 
> > Another design concern below, but in principle this looks like what we
> > need.
> > -Daniel
> > 
> > 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c  | 66 
> > > +++
> > >  drivers/gpu/drm/drm_atomic_helper.c   | 10 ++
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
> > >  include/drm/drm_atomic.h  | 13 +++
> > >  include/drm/drm_dp_mst_helper.h   | 13 +++
> > >  5 files changed, 112 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 681d5f9..b8e2cea 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -31,6 +31,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  
> > >  #include "drm_crtc_internal.h"
> > > @@ -62,6 +63,7 @@ void drm_atomic_state_default_release(struct 
> > > drm_atomic_state *state)
> > >   kfree(state->connectors);
> > >   kfree(state->crtcs);
> > >   kfree(state->planes);
> > > + kfree(state->dp_mst_topologies);
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_state_default_release);
> > >  
> > > @@ -189,6 +191,18 @@ void drm_atomic_state_default_clear(struct 
> > > drm_atomic_state *state)
> > >   state->planes[i].ptr = NULL;
> > >   state->planes[i].state = NULL;
> > >   }
> > > +
> > > + for (i = 0; i < state->num_mst_topologies; i++) {
> > > + struct drm_dp_mst_topology_mgr *mgr = 
> > > state->dp_mst_topologies[i].ptr;
> > > +
> > > + if (!mgr)
> > > + continue;
> > > +
> > > + kfree(state->dp_mst_topologies[i].state);
> > > + state->dp_mst_topologies[i].ptr = NULL;
> > > + state->dp_mst_topologies[i].state = NULL;
> > > + }
> > > +
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> > >  
> > > @@ -981,6 +995,58 @@ static void drm_atomic_plane_print_state(struct 
> > > drm_printer *p,
> > >   plane->funcs->atomic_print_state(p, state);
> > >  }
> > >  
> > > +struct drm_dp_mst_topology_state 
> > > *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state,
> > > + struct drm_dp_mst_topology_mgr *mgr)
> > > +{
> > > +
> > > + int ret, i;
> > > + size_t new_size;
> > > + struct __drm_dp_mst_topology_state *new_arr;
> > > + struct drm_dp_mst_topology_state *new_mst_state;
> > > + int num_topologies;
> > > + struct drm_mode_config *config = >dev->mode_config;
> > > +
> > > + WARN_ON(!state->acquire_ctx);
> > > +
> > > + ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
> > > + if (ret)
> > > + return ERR_PTR(ret);
> > > +
> > > + for (i = 0; i < state->num_mst_topologies; i++) {
> > > + if (mgr == state->dp_mst_topologies[i].ptr &&
> > > + state->dp_mst_topologies[i].state) {
> > > + return state->dp_mst_topologies[i].state;
> > > + }
> > > + }
> > > +
> > > + num_topologies = state->num_mst_topologies + 1;
> > > + new_size = sizeof(*state->dp_mst_topologies) * num_topologies;
> > > + new_arr = krealloc(state->dp_mst_topologies, new_size, GFP_KERNEL);
> > > + if (!new_arr)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + state->dp_mst_topologies = new_arr;
> > > + memset(>dp_mst_topologies[state->num_mst_topologies], 0,
> > > + sizeof(*state->dp_mst_topologies));
> > > +
> > > + new_mst_state = kmalloc(sizeof(*mgr->state), GFP_KERNEL);
> > > + if (!new_mst_state)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + new_mst_state->avail_slots = mgr->state->avail_slots;
> > > + 

Re: [Intel-gfx] [PATCH 1/9] drm: Add mode_config .get_format_info() hook

[Ben Widawsky]

On 17-01-04 20:42:24, Ville Syrjälä wrote:

From: Ville Syrjälä 

Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.

v2: Fix drm_get_format_info() kernel doc (Laurent)
   Don't pass 'dev' to the new hook (Laurent)

Cc: Laurent Pinchart 
Cc: Ben Widawsky 
Signed-off-by: Ville Syrjälä 
---
drivers/gpu/drm/drm_fb_cma_helper.c  |  2 +-
drivers/gpu/drm/drm_fourcc.c | 25 +
drivers/gpu/drm/drm_framebuffer.c|  9 +++--
drivers/gpu/drm/drm_modeset_helper.c |  2 +-
include/drm/drm_fourcc.h |  6 ++
include/drm/drm_mode_config.h| 14 ++
6 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 20a4011f790d..de3c9fe116fc 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -177,7 +177,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct 
drm_device *dev,
int ret;
int i;

-   info = drm_format_info(mode_cmd->pixel_format);
+   info = drm_get_format_info(dev, mode_cmd);
if (!info)
return ERR_PTR(-EINVAL);

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8da8eb..f9b6445e846a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32 format)
EXPORT_SYMBOL(drm_format_info);

/**
+ * drm_get_format_info - query information for a given framebuffer 
configuration
+ * @dev: DRM device
+ * @mode_cmd: metadata from the userspace fb creation request
+ *
+ * Returns:
+ * The instance of struct drm_format_info that describes the pixel format, or
+ * NULL if the format is unsupported.
+ */
+const struct drm_format_info *
+drm_get_format_info(struct drm_device *dev,
+   const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   const struct drm_format_info *info = NULL;
+
+   if (dev->mode_config.funcs->get_format_info)
+   info = dev->mode_config.funcs->get_format_info(mode_cmd);
+
+   if (!info)
+   info = drm_format_info(mode_cmd->pixel_format);
+
+   return info;
+}
+EXPORT_SYMBOL(drm_get_format_info);
+
+/**
 * drm_format_num_planes - get the number of planes for format
 * @format: pixel format (DRM_FORMAT_*)
 *
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 588ccc3a2218..e276fcdc3a62 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -126,11 +126,13 @@ int drm_mode_addfb(struct drm_device *dev,
return 0;
}

-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
+static int framebuffer_check(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
{
const struct drm_format_info *info;
int i;

+   /* check if the format is supported at all */
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
@@ -140,6 +142,9 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2 
*r)
return -EINVAL;
}

+   /* now let the driver pick its own format info */
+   info = drm_get_format_info(dev, r);
+
if (r->width == 0 || r->width % info->hsub) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
@@ -263,7 +268,7 @@ drm_internal_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}

-   ret = framebuffer_check(r);
+   ret = framebuffer_check(dev, r);
if (ret)
return ERR_PTR(ret);

diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
b/drivers/gpu/drm/drm_modeset_helper.c
index cc44a9a4b004..2b33825f2f93 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -78,7 +78,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_device *dev,
int i;

fb->dev = dev;
-   fb->format = drm_format_info(mode_cmd->pixel_format);
+   fb->format = drm_get_format_info(dev, mode_cmd);
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
for (i = 0; i < 4; i++) {
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fcc08da850c8..6942e84b6edd 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,9 @@
#include 
#include 

+struct drm_device;
+struct drm_mode_fb_cmd2;
+
/**
 * struct drm_format_info - information about a DRM format
 * @format: 4CC format identifier (DRM_FORMAT_*)
@@ -55,6 +58,9 @@ struct drm_format_name_buf {

const struct drm_format_info *__drm_format_info(u32 format);
const 

[Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

[Lyude]

Until now, it seems we've been erroneously enabling limited color ranges
for the vast majority of DisplayPort monitors. I noticed this after
writing a frame dump comparison test for the Chamelium and noticing that
every i915 device I had was failing, while amdgpu machines were fine:

https://people.freedesktop.org/~lyudess/archive/01-03-2017/

It looks like this is because the DisplayPort spec tells us to use
limited color ranges whenever we detect a CEA mode in use. However, from
the looks of it there's another rather confusing part of the spec that
got missed: source devices are allowed to use the full range of values
for pixels -even- if the sink device declares that it's using a CEA
mode. It's up to the sink device to limit the pixel range to the CEA
ranges if it needs.

Signed-off-by: Lyude 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
---
I'm really surprised that this bug would have been around as long as it looks
like it has been without anyone noticing it, so I figured I'd just send a patch
to the mailing list so you guys can point out whether or not this is really the
correct thing to do.

 drivers/gpu/drm/i915/intel_dp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d9bc19b..6642abd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1649,12 +1649,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 found:
if (intel_dp->color_range_auto) {
/*
+* We are required to use the limited CEA RGB range when a CEA
+* mode is declared in the EDID. However, limiting the pixel
+* value range is up to the sink, not the source. So, just
+* don't enable limited color ranges.
 * See:
 * CEA-861-E - 5.1 Default Encoding Parameters
 * VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
 */
-   pipe_config->limited_color_range =
-   bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
+   pipe_config->limited_color_range = false;
} else {
pipe_config->limited_color_range =
intel_dp->limited_color_range;
-- 
2.9.3

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

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

[Stephen Rothwell]

Hi all,

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

drivers/usb/Kconfig:39:error: recursive dependency detected!
drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
drivers/input/mouse/Kconfig:187:symbol MOUSE_APPLETOUCH depends on INPUT
drivers/input/Kconfig:8:symbol INPUT is selected by VT
drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
drivers/video/fbdev/Kconfig:678:symbol FB_STI depends on FB
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER depends on 
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:66: symbol DRM_KMS_HELPER is selected by DRM_NOUVEAU
drivers/gpu/drm/nouveau/Kconfig:1:  symbol DRM_NOUVEAU depends on LEDS_CLASS
drivers/leds/Kconfig:16:symbol LEDS_CLASS is selected by OMAP_DEBUG_LEDS
arch/arm/plat-omap/Kconfig:19:  symbol OMAP_DEBUG_LEDS depends on NEW_LEDS
drivers/leds/Kconfig:8: symbol NEW_LEDS is selected by ATH9K_HTC
drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB

Caused by commit

  a5ad0fd8524e ("drm: nouveau: fix build when LEDS_CLASS=m")

I have reverted that commit for today (just because I had to to make
sure that was the problem).

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

Re: [Intel-gfx] [PATCH 02/10] drm/i915/psr: program vsc header for psr2

[Jim Bride]

On Mon, Jan 02, 2017 at 05:00:55PM +0530, vathsala nagaraju wrote:
> Function hsw_psr_setup handles vsc header setup for psr1 and
> skl_psr_setup_vsc handles vsc header setup for psr2.
> 
> Setup VSC header in function skl_psr_setup_vsc for psr2 support,
> as per edp 1.4 spec, table 6-11:VSC SDP HEADER Extension for psr2
> operation.
> 
> v2: (Jani)
> - Initialize variables to 0
> - intel_dp_get_y_cord_status and intel_dp_get_y_cord_status made static
> - Correct indentation for continuation lines
> - Change DP_PSR_Y_COORDINATE to  DP_PSR2_SU_Y_COORDINATE_REQUIRED
> - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX_*
> - Change VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED to DP_VSC_*
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_dp.c  | 26 ++
>  drivers/gpu/drm/i915/intel_psr.c | 17 +++--
>  3 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 22d3f61..36dc835 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1164,6 +1164,8 @@ struct i915_psr {
>   bool psr2_support;
>   bool aux_frame_sync;
>   bool link_standby;
> + bool y_cord_support;
> + bool colorimetry_support;
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fb12896..da577c9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3042,6 +3042,24 @@ static void chv_dp_post_pll_disable(struct 
> intel_encoder *encoder,
>   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
>  }
>  
> +static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> +{
> + uint8_t psr_caps = 0;
> +
> + drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps);
> + return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
> +}
> +
> +static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
> +{
> + uint8_t dprx = 0;
> +
> + drm_dp_dpcd_readb(_dp->aux,
> + DP_DPRX_FEATURE_ENUMERATION_LIST,
> + );
> + return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
> +}
> +
>  /* These are source-specific values. */
>  uint8_t
>  intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3620,6 +3638,14 @@ void intel_dp_set_idle_link_train(struct intel_dp 
> *intel_dp)
>   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
>   DRM_DEBUG_KMS("PSR2 %s on sink",
> dev_priv->psr.psr2_support ? "supported" : "not 
> supported");
> +
> + if (dev_priv->psr.psr2_support) {
> + dev_priv->psr.y_cord_support =
> + intel_dp_get_y_cord_status(intel_dp);
> + dev_priv->psr.colorimetry_support =
> + intel_dp_get_colorimetry_status(intel_dp);
> + }
> +
>   }
>  
>   /* Read the eDP Display control capabilities registers */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 6aca8ff..c3aa649 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -122,13 +122,26 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
>  static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
>  {
>   struct edp_vsc_psr psr_vsc;
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
>  
>   /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
>   memset(_vsc, 0, sizeof(psr_vsc));
>   psr_vsc.sdp_header.HB0 = 0;
>   psr_vsc.sdp_header.HB1 = 0x7;
> - psr_vsc.sdp_header.HB2 = 0x3;
> - psr_vsc.sdp_header.HB3 = 0xb;
> + if (dev_priv->psr.colorimetry_support &&
> + dev_priv->psr.y_cord_support) {
> + psr_vsc.sdp_header.HB2 = 0x5;
> + psr_vsc.sdp_header.HB3 = 0x13;
> + } else if (dev_priv->psr.y_cord_support) {
> + psr_vsc.sdp_header.HB2 = 0x4;
> + psr_vsc.sdp_header.HB3 = 0xe;
> + } else {
> + psr_vsc.sdp_header.HB2 = 0x3;
> + psr_vsc.sdp_header.HB3 = 0xc;
> + }
> +
>   intel_psr_write_vsc(intel_dp, _vsc);
>  }
>  
> -- 
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [drm-tip:drm-tip 440/460] drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   ea0500897bf72bbbf6eca6e695c9d49289dfc768
commit: a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8 [440/460] drm: nouveau: fix 
build when LEDS_CLASS=m
config: um-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   kernel/time/Kconfig:155:warning: range is invalid
>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/video/fbdev/Kconfig:5:   symbol FB is selected by 
DRM_KMS_FB_HELPER
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpu/drm/Kconfig:72:  symbol DRM_KMS_FB_HELPER depends on 
DRM_KMS_HELPER
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpu/drm/Kconfig:66:  symbol DRM_KMS_HELPER is selected by DRM_NOUVEAU
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpu/drm/nouveau/Kconfig:1:   symbol DRM_NOUVEAU depends on LEDS_CLASS
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/net/wireless/ath/ath9k/Kconfig:158:  symbol ATH9K_HTC depends on USB
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/usb/Kconfig:39:  symbol USB is selected by MOUSE_APPLETOUCH
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/input/Kconfig:8: symbol INPUT is selected by VT
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/tty/Kconfig:12:  symbol VT is selected by FB_STI
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB
   warning: (RCU_PERF_TEST && RCU_TORTURE_TEST) selects TASKS_RCU which has 
unmet direct dependencies (!UML)
   warning: (RCU_PERF_TEST && RCU_TORTURE_TEST) selects TASKS_RCU which has 
unmet direct dependencies (!UML)
--
   kernel/time/Kconfig:155:warning: range is invalid
>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/video/fbdev/Kconfig:5:   symbol FB is selected by 
DRM_KMS_FB_HELPER
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpu/drm/Kconfig:72:  symbol DRM_KMS_FB_HELPER depends on 
DRM_KMS_HELPER
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpu/drm/Kconfig:66:  symbol DRM_KMS_HELPER is selected by DRM_NOUVEAU
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/gpu/drm/nouveau/Kconfig:1:   symbol DRM_NOUVEAU depends on LEDS_CLASS
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/net/wireless/ath/ath9k/Kconfig:158:  symbol ATH9K_HTC depends on USB
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/usb/Kconfig:39:  symbol USB is selected by MOUSE_APPLETOUCH
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency limitations"
   drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT
   For a resolution refer to Documentation/kbuild/kconfig-language.txt
   subsection "Kconfig recursive dependency 

Re: [Intel-gfx] [PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put

[Alex Deucher]

On Wed, Jan 4, 2017 at 11:11 AM, Daniel Vetter  wrote:
> On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote:
>> I was lazy, rectify that! Also align with drm_atomic_state_get/put for
>> ocd.
>>
>> v2: Git add helps.
>>
>> Signed-off-by: Daniel Vetter 
>
> Anyone feel like acking this, pretty please? ;-)

Acked-by: Alex Deucher 


> -Daniel
>
>> ---
>>  drivers/gpu/drm/drm_atomic.c |  9 ++---
>>  include/drm/drm_atomic.h | 21 -
>>  2 files changed, 22 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index b1b54011a92c..26a4cfdf 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -35,19 +35,14 @@
>>
>>  #include "drm_crtc_internal.h"
>>
>> -static void crtc_commit_free(struct kref *kref)
>> +void __drm_crtc_commit_free(struct kref *kref)
>>  {
>>   struct drm_crtc_commit *commit =
>>   container_of(kref, struct drm_crtc_commit, ref);
>>
>>   kfree(commit);
>>  }
>> -
>> -void drm_crtc_commit_put(struct drm_crtc_commit *commit)
>> -{
>> - kref_put(>ref, crtc_commit_free);
>> -}
>> -EXPORT_SYMBOL(drm_crtc_commit_put);
>> +EXPORT_SYMBOL(__drm_crtc_commit_free);
>>
>>  /**
>>   * drm_atomic_state_default_release -
>> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
>> index 91b18bd7cb50..97587ec36eae 100644
>> --- a/include/drm/drm_atomic.h
>> +++ b/include/drm/drm_atomic.h
>> @@ -199,12 +199,31 @@ struct drm_atomic_state {
>>   struct work_struct commit_work;
>>  };
>>
>> -void drm_crtc_commit_put(struct drm_crtc_commit *commit);
>> +void __drm_crtc_commit_free(struct kref *kref);
>> +
>> +/**
>> + * drm_crtc_commit_get - acquire a reference to the CRTC commit
>> + * @commit: CRTC commit
>> + *
>> + * Increases the reference of @commit.
>> + */
>>  static inline void drm_crtc_commit_get(struct drm_crtc_commit *commit)
>>  {
>>   kref_get(>ref);
>>  }
>>
>> +/**
>> + * drm_crtc_commit_put - release a reference to the CRTC commmit
>> + * @commit: CRTC commit
>> + *
>> + * This releases a reference to @commit which is freed after removing the
>> + * final reference. No locking required and callable from any context.
>> + */
>> +static inline void drm_crtc_commit_put(struct drm_crtc_commit *commit)
>> +{
>> + kref_put(>ref, __drm_crtc_commit_free);
>> +}
>> +
>>  struct drm_atomic_state * __must_check
>>  drm_atomic_state_alloc(struct drm_device *dev);
>>  void drm_atomic_state_clear(struct drm_atomic_state *state);
>> --
>> 2.11.0
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

[Chris Wilson]

On Wed, Jan 04, 2017 at 03:36:16PM +, Tvrtko Ursulin wrote:
> You beat me to solving this interesting bug. :) With the
> comments/commit slightly improved:

CI chose to ignore this, so sent the improved comments to trybot:
https://patchwork.freedesktop.org/series/17506/

Thanks,
-Chris

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: SKL+ render decompression support

[Patchwork]

== Series Details ==

Series: drm/i915: SKL+ render decompression support
URL   : https://patchwork.freedesktop.org/series/17507/
State : success

== Summary ==

Series 17507v1 drm/i915: SKL+ render decompression support
https://patchwork.freedesktop.org/api/1.0/series/17507/revisions/1/mbox/


fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 

ea0500897bf72bbbf6eca6e695c9d49289dfc768 drm-tip: 2017y-01m-04d-16h-46m-35s UTC 
integration manifest
47b7d18 drm/i915: Add render decompression support
09b28ed drm/i915: Implement .get_format_info() hook for CCS
5dc5c70 drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages
f9e982d drm/i915: Pass the correct plane index to _intel_compute_tile_offset()
0c72ad2 drm/i915: Fix Yf tile width
47a0285 drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane
0acd973 drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()
38a0f9c drm/i915: Plumb drm_framebuffer into more places
fd640ca drm: Add mode_config .get_format_info() hook

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

[Pandiyan, Dhinakaran]

On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote:
> On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote:
> > Link bandwidth is shared between multiple display streams in DP MST
> > configurations. The DP MST topology manager structure maintains the shared
> > link bandwidth for a primary link directly connected to the GPU. For atomic
> > modesetting drivers, checking if there is sufficient link bandwidth for a
> > mode needs to be done during the atomic_check phase to avoid failed
> > modesets. Let's encsapsulate the available link bw information in a state
> > structure so that bw can be allocated and released atomically for each of
> > the ports sharing the primary link.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> 
> Overall issue with the patch is that dp helpers now have 2 places where
> available_slots is stored: One for atomic drivers in ->state, and the
> legacy one. I think it'd be good to rework the legacy codepaths (i.e.
> drm_dp_find_vcpi_slots) to use mgr->state->avail_slots, and remove
> mgr->avail_slots entirely.

PATCH 2/6 does that. mgr->avail_slots is not updated in the legacy code
path, so the check turns out to be against mgr->total_slots. So, I did
just that, albeit explicitly. 

-DK

> 
> Another design concern below, but in principle this looks like what we
> need.
> -Daniel
> 
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c  | 66 
> > +++
> >  drivers/gpu/drm/drm_atomic_helper.c   | 10 ++
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
> >  include/drm/drm_atomic.h  | 13 +++
> >  include/drm/drm_dp_mst_helper.h   | 13 +++
> >  5 files changed, 112 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 681d5f9..b8e2cea 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -31,6 +31,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include "drm_crtc_internal.h"
> > @@ -62,6 +63,7 @@ void drm_atomic_state_default_release(struct 
> > drm_atomic_state *state)
> > kfree(state->connectors);
> > kfree(state->crtcs);
> > kfree(state->planes);
> > +   kfree(state->dp_mst_topologies);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >  
> > @@ -189,6 +191,18 @@ void drm_atomic_state_default_clear(struct 
> > drm_atomic_state *state)
> > state->planes[i].ptr = NULL;
> > state->planes[i].state = NULL;
> > }
> > +
> > +   for (i = 0; i < state->num_mst_topologies; i++) {
> > +   struct drm_dp_mst_topology_mgr *mgr = 
> > state->dp_mst_topologies[i].ptr;
> > +
> > +   if (!mgr)
> > +   continue;
> > +
> > +   kfree(state->dp_mst_topologies[i].state);
> > +   state->dp_mst_topologies[i].ptr = NULL;
> > +   state->dp_mst_topologies[i].state = NULL;
> > +   }
> > +
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >  
> > @@ -981,6 +995,58 @@ static void drm_atomic_plane_print_state(struct 
> > drm_printer *p,
> > plane->funcs->atomic_print_state(p, state);
> >  }
> >  
> > +struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
> > drm_atomic_state *state,
> > +   struct drm_dp_mst_topology_mgr *mgr)
> > +{
> > +
> > +   int ret, i;
> > +   size_t new_size;
> > +   struct __drm_dp_mst_topology_state *new_arr;
> > +   struct drm_dp_mst_topology_state *new_mst_state;
> > +   int num_topologies;
> > +   struct drm_mode_config *config = >dev->mode_config;
> > +
> > +   WARN_ON(!state->acquire_ctx);
> > +
> > +   ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
> > +   if (ret)
> > +   return ERR_PTR(ret);
> > +
> > +   for (i = 0; i < state->num_mst_topologies; i++) {
> > +   if (mgr == state->dp_mst_topologies[i].ptr &&
> > +   state->dp_mst_topologies[i].state) {
> > +   return state->dp_mst_topologies[i].state;
> > +   }
> > +   }
> > +
> > +   num_topologies = state->num_mst_topologies + 1;
> > +   new_size = sizeof(*state->dp_mst_topologies) * num_topologies;
> > +   new_arr = krealloc(state->dp_mst_topologies, new_size, GFP_KERNEL);
> > +   if (!new_arr)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   state->dp_mst_topologies = new_arr;
> > +   memset(>dp_mst_topologies[state->num_mst_topologies], 0,
> > +   sizeof(*state->dp_mst_topologies));
> > +
> > +   new_mst_state = kmalloc(sizeof(*mgr->state), GFP_KERNEL);
> > +   if (!new_mst_state)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   new_mst_state->avail_slots = mgr->state->avail_slots;
> > +   state->dp_mst_topologies[state->num_mst_topologies].state = 
> > new_mst_state;
> > +   state->dp_mst_topologies[state->num_mst_topologies].ptr = mgr;
> > +   state->num_mst_topologies = num_topologies;
> > +   new_mst_state->mgr = mgr;
> > +   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: add fourcc codes for 16bit R and RG (rev3)

[Patchwork]

== Series Details ==

Series: drm: add fourcc codes for 16bit R and RG (rev3)
URL   : https://patchwork.freedesktop.org/series/17471/
State : success

== Summary ==

Series 17471v3 drm: add fourcc codes for 16bit R and RG
https://patchwork.freedesktop.org/api/1.0/series/17471/revisions/3/mbox/


fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 failed to collect. IGT log at Patchwork_3434/fi-byt-n2820/igt.log

ea0500897bf72bbbf6eca6e695c9d49289dfc768 drm-tip: 2017y-01m-04d-16h-46m-35s UTC 
integration manifest
94b6499 drm: add fourcc codes for 16bit R and RG

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3434/
___
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: Add render decompression support

[Paulo Zanoni]

Em Qua, 2017-01-04 às 20:42 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display
> engine
> the location of the color control surfae (CCS) which describes
> which parts of the main surface are compressed and which are not. The
> location of CCS is provided by userspace as just another plane with
> its
> own offset.
> 
> Add the required stuff to validate the user provided AUX plane
> metadata
> and convert the user provided linear offset into something the
> hardware
> can consume.
> 
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with NV12), so finding suitable
> offsets for both requires a bit of work. Assuming we still want keep
> playing tricks with the offsets. I've just gone with a dumb "search
> backward for suitable offsets" approach, which is far from optimal,
> but it works.
> 
> Also not all planes will be capable of scanning out compressed
> surfaces,
> and eg. 90/270 degree rotation is not supported in combination with
> decompression either.
> 
> This patch may contain work from at least the following people:
> * Vandana Kannan 
> * Daniel Vetter 
> * Ben Widawsky 

As I mentioned to Ben in the other email, there are some points of
BSpec that say "if render decompression is enabled, to this", which we
largely ignored so far. I hope they are all marked as workarounds. From
a quick look, it looks like we need at least Display WAs #0390, #0531
and #1125, and maybe some other non-display WAs (please take a look at
the BSpec list). I'll assume they were not implemented yet since I
don't see WA comments on the patches. I think we need them, otherwise
we may introduce more SKL flickering problems.

Thanks,
Paulo

> 
> Cc: Vandana Kannan 
> Cc: Daniel Vetter 
> Cc: Ben Widawsky 
> Cc: Jason Ekstrand 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  22 
>  drivers/gpu/drm/i915/intel_display.c | 219
> +--
>  drivers/gpu/drm/i915/intel_pm.c  |   8 +-
>  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
>  4 files changed, 240 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa77afa..05e18e742776 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6209,6 +6209,28 @@ enum {
>   _ID(id, _PS_ECC_STAT_1A,
> _PS_ECC_STAT_2A),   \
>   _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>  
> +#define PLANE_AUX_DIST_1_A   0x701c0
> +#define PLANE_AUX_DIST_2_A   0x702c0
> +#define PLANE_AUX_DIST_1_B   0x711c0
> +#define PLANE_AUX_DIST_2_B   0x712c0
> +#define _PLANE_AUX_DIST_1(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_1_A,
> PLANE_AUX_DIST_1_B)
> +#define _PLANE_AUX_DIST_2(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_2_A,
> PLANE_AUX_DIST_2_B)
> +#define PLANE_AUX_DIST(pipe, plane) \
> + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> _PLANE_AUX_DIST_2(pipe))
> +
> +#define PLANE_AUX_OFFSET_1_A 0x701c4
> +#define PLANE_AUX_OFFSET_2_A 0x702c4
> +#define PLANE_AUX_OFFSET_1_B 0x711c4
> +#define PLANE_AUX_OFFSET_2_B 0x712c4
> +#define _PLANE_AUX_OFFSET_1(pipe)   \
> + _PIPE(pipe, PLANE_AUX_OFFSET_1_A,
> PLANE_AUX_OFFSET_1_B)
> +#define _PLANE_AUX_OFFSET_2(pipe)   \
> + _PIPE(pipe, PLANE_AUX_OFFSET_2_A,
> PLANE_AUX_OFFSET_2_B)
> +#define PLANE_AUX_OFFSET(pipe, plane)   \
> + _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
> _PLANE_AUX_OFFSET_2(pipe))
> +
>  /* legacy palette */
>  #define _LGC_PALETTE_A   0x4a000
>  #define _LGC_PALETTE_B   0x4a800
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 38de9df0ec60..b547332eeda1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
> drm_framebuffer *fb, int plane)
>   return 128;
>   else
>   return 512;
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + if (plane == 1)
> + return 64;
> + /* fall through */
>   case I915_FORMAT_MOD_Y_TILED:
>   if (IS_GEN2(dev_priv) ||
> HAS_128_BYTE_Y_TILING(dev_priv))
>   return 128;
>   else
>   return 512;
> 

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Maarten Lankhorst]

Op 04-01-17 om 17:19 schreef Chris Wilson:
> On Wed, Jan 04, 2017 at 06:06:42PM +0200, Ville Syrjälä wrote:
>> On Wed, Jan 04, 2017 at 04:00:49PM +, Chris Wilson wrote:
>>> If we are restoring the same plane_state, the old_plane_state will not
>>> be unpinned until after the swap. So prepare_fb will return the
>>> duplicate VMA with incremented pin_count.
>> During suspend we throw away the old state, and resume will read in
>> the state from the hardware. So when we do the swap we won't have the
>> original old state in place anymore.
> But in this case, we should have a plane_config from HW readout that has
> a recovered VMA? I presume the same takeover code is run after resume as
> on init...
No, we only recover it during init. On resume we still have the old vma pinned 
and in plane_state.
Which should be fine for our purpose, but even if we didn't resume should 
probably not fail.
> On the other hand, if the plane_state was removed from the hardware, its
> VMA would be unpinned and we would be free to rebind it in a new location.
> Provided the obj itself wasn't freed, the VMA will be kept. However, we
> still risk a potential error on remapping (if the vma was unbound during
> suspend). That's not a huge risk though, and does require the VMA to be
> actually unbound on suspend.

Not currently the case, but it's an implementation detail that might be 
changed. :)

~Maarten

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add fourcc codes for 16bit R and RG (rev2)

[Patchwork]

== Series Details ==

Series: drm: add fourcc codes for 16bit R and RG (rev2)
URL   : https://patchwork.freedesktop.org/series/17471/
State : failure

== Summary ==

Series 17471v2 drm: add fourcc codes for 16bit R and RG
https://patchwork.freedesktop.org/api/1.0/series/17471/revisions/2/mbox/

Test gem_sync:
Subgroup basic-store-all:
pass   -> FAIL   (fi-ivb-3770)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> INCOMPLETE (fi-byt-n2820)

fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:214  pass:182  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:0   dfail:0   fail:1   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 

ea0500897bf72bbbf6eca6e695c9d49289dfc768 drm-tip: 2017y-01m-04d-16h-46m-35s UTC 
integration manifest
a08b183 drm: add fourcc codes for 16bit R and RG

== Logs ==

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

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

[ville . syrjala]

From: Ville Syrjälä 

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

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

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

v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout

Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Reviewed-by: Ben Widawsky 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 36 ++
 include/uapi/drm/drm_fourcc.h| 49 
 2 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c4662b2e9613..38de9df0ec60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2478,6 +2478,41 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t 
fb_modifier)
}
 }
 
+static const struct drm_format_info ccs_formats[] = {
+   { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+   { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+  int num_formats, u32 format)
+{
+   int i;
+
+   for (i = 0; i < num_formats; i++) {
+   if (formats[i].format == format)
+   return [i];
+   }
+
+   return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
+{
+   switch (cmd->modifier[0]) {
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+   default:
+   return NULL;
+   }
+}
+
 static int
 intel_fill_fb_info(struct drm_i915_private *dev_priv,
   struct drm_framebuffer *fb)
@@ -16083,6 +16118,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)
 
 static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+   .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7fabcde..4581e3d41e5c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -230,6 +230,55 @@ extern "C" {
 #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
 
 /*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats,
+ * the main surface will be plane index 0 and will be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each byte of CCS contains 4 pairs of bits, with each pair of bits
+ * matching an area of 8x4 pixels of the main surface. Which would seem
+ * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
+ * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
+ * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
+ * ---
+ * | 01 | 23 |
+ *  --
+ * | 45 | 67 |
+ * ---
+ *
+ * Actually only the lower bit of the pair seems to have any effect.
+ * No idea why. 0 in the lower bit would seem to mean not compressed,
+ * and 1 is compressed.  The interpreation of the main surface data
+ * when the block is marked compressed is unknown as of now.
+ *
+ * CCS tile is laid out in 8 byte horizontal strips 

[Intel-gfx] [PATCH 4/9] drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane

[ville . syrjala]

From: Ville Syrjälä 

To make life easier let's allow skl_plane_stride() to be called for the
AUX surface even when there is no AUX surface. Avoids special cases in
the callers.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4d514ca1da88..bc398743e941 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3261,7 +3261,12 @@ static void skl_detach_scalers(struct intel_crtc 
*intel_crtc)
 u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
 unsigned int rotation)
 {
-   u32 stride = intel_fb_pitch(fb, plane, rotation);
+   u32 stride;
+
+   if (plane >= fb->format->num_planes)
+   return 0;
+
+   stride = intel_fb_pitch(fb, plane, rotation);
 
/*
 * The stride is either expressed as a multiple of 64 bytes chunks for
-- 
2.10.2

___
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 DRM_DEBUG_KMS() for framebuffer failure debug messages

[ville . syrjala]

From: Ville Syrjälä 

DRM_UT_CORE generates way too much noise usually, so having the
framebuffer init failures use DRM_UT_CORE is a pain when trying to
find out the reason why you failed in creating a framebuffer.
Let's use DRM_UT_KMS for these debug messages instead.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fee5a7ac9a4..c4662b2e9613 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2512,8 +2512,8 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
 */
if (i915_gem_object_is_tiled(intel_fb->obj) &&
(x + width) * cpp > fb->pitches[i]) {
-   DRM_DEBUG("bad fb plane %d offset: 0x%x\n",
- i, fb->offsets[i]);
+   DRM_DEBUG_KMS("bad fb plane %d offset: 0x%x\n",
+ i, fb->offsets[i]);
return -EINVAL;
}
 
@@ -2594,9 +2594,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
max_size = max(max_size, offset + size);
}
 
-   if (max_size * tile_size > to_intel_framebuffer(fb)->obj->base.size) {
-   DRM_DEBUG("fb too big for bo (need %u bytes, have %zu bytes)\n",
- max_size * tile_size, 
to_intel_framebuffer(fb)->obj->base.size);
+   if (max_size * tile_size > intel_fb->obj->base.size) {
+   DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu 
bytes)\n",
+ max_size * tile_size, intel_fb->obj->base.size);
return -EINVAL;
}
 
@@ -15904,14 +15904,14 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
 */
if (tiling != I915_TILING_NONE &&
tiling != 
intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
-   DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
+   DRM_DEBUG_KMS("tiling_mode doesn't match fb 
modifier\n");
return -EINVAL;
}
} else {
if (tiling == I915_TILING_X) {
mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
} else if (tiling == I915_TILING_Y) {
-   DRM_DEBUG("No Y tiling for legacy addfb\n");
+   DRM_DEBUG_KMS("No Y tiling for legacy addfb\n");
return -EINVAL;
}
}
@@ -15921,16 +15921,16 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
if (INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
+   DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
+ mode_cmd->modifier[0]);
return -EINVAL;
}
case DRM_FORMAT_MOD_NONE:
case I915_FORMAT_MOD_X_TILED:
break;
default:
-   DRM_DEBUG("Unsupported fb modifier 0x%llx!\n",
- mode_cmd->modifier[0]);
+   DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
+ mode_cmd->modifier[0]);
return -EINVAL;
}
 
@@ -15940,17 +15940,17 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
 */
if (INTEL_INFO(dev_priv)->gen < 4 &&
tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
-   DRM_DEBUG("tiling_mode must match fb modifier exactly on 
gen2/3\n");
+   DRM_DEBUG_KMS("tiling_mode must match fb modifier exactly on 
gen2/3\n");
return -EINVAL;
}
 
pitch_limit = intel_fb_pitch_limit(dev_priv, mode_cmd->modifier[0],
   mode_cmd->pixel_format);
if (mode_cmd->pitches[0] > pitch_limit) {
-   DRM_DEBUG("%s pitch (%u) must be at less than %d\n",
- mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
- "tiled" : "linear",
- mode_cmd->pitches[0], pitch_limit);
+   DRM_DEBUG_KMS("%s pitch (%u) must be at less than %d\n",
+ mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
+ "tiled" : "linear",
+ mode_cmd->pitches[0], pitch_limit);
return -EINVAL;
}
 
@@ -15960,9 +15960,9 @@ static int intel_framebuffer_init(struct drm_device 
*dev,
 */
if (tiling != 

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

[ville . syrjala]

From: Ville Syrjälä 

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

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

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

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

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

Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  22 
 drivers/gpu/drm/i915/intel_display.c | 219 +--
 drivers/gpu/drm/i915/intel_pm.c  |   8 +-
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 4 files changed, 240 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa77afa..05e18e742776 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6209,6 +6209,28 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
 
+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A   0x701c4
+#define PLANE_AUX_OFFSET_2_A   0x702c4
+#define PLANE_AUX_OFFSET_1_B   0x711c4
+#define PLANE_AUX_OFFSET_2_B   0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe)   \
+   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane)   \
+   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 38de9df0ec60..b547332eeda1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
*fb, int plane)
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   if (plane == 1)
+   return 64;
+   /* fall through */
case I915_FORMAT_MOD_Yf_TILED:
/*
 * Bspec seems to suggest that the Yf tile width would
@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
struct drm_i915_private *dev_priv = to_i915(fb->dev);
 
/* AUX_DIST needs only 4K alignment */
-   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
+   if (plane == 1)
return 4096;
 
switch (fb->modifier) {
@@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
if (INTEL_GEN(dev_priv) >= 9)

[Intel-gfx] [PATCH 6/9] drm/i915: Pass the correct plane index to _intel_compute_tile_offset()

[ville . syrjala]

From: Ville Syrjälä 

intel_fill_fb_info() should pass the correct plane index to
_intel_compute_tile_offset() once we start to care about the AUX
surface.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0ca0dbccc005..5fee5a7ac9a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2525,7 +2525,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
intel_fb->normal[i].y = y;
 
offset = _intel_compute_tile_offset(dev_priv, , ,
-   fb, 0, fb->pitches[i],
+   fb, i, fb->pitches[i],
DRM_ROTATE_0, tile_size);
offset /= tile_size;
 
-- 
2.10.2

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

[Intel-gfx] [PATCH 5/9] drm/i915: Fix Yf tile width

[ville . syrjala]

From: Ville Syrjälä 

Based on empirical evidence the display engine (at least) always
treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions
change based on the pixel format. Let's adjust our code to match the
hardware.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bc398743e941..0ca0dbccc005 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2070,20 +2070,12 @@ intel_tile_width_bytes(const struct drm_framebuffer 
*fb, int plane)
else
return 512;
case I915_FORMAT_MOD_Yf_TILED:
-   switch (cpp) {
-   case 1:
-   return 64;
-   case 2:
-   case 4:
-   return 128;
-   case 8:
-   case 16:
-   return 256;
-   default:
-   MISSING_CASE(cpp);
-   return cpp;
-   }
-   break;
+   /*
+* Bspec seems to suggest that the Yf tile width would
+* depend on the cpp. In reality it doesn't, at least
+* as far as the display engine is concerned.
+*/
+   return 128;
default:
MISSING_CASE(fb->modifier);
return cpp;
-- 
2.10.2

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

[Intel-gfx] [PATCH 3/9] drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()

[ville . syrjala]

From: Ville Syrjälä 

Let's try to keep the alignment requirements in one place, and so
towards that end let's move the AUX_DIST alignment handling into
intel_surf_alignment() alongside the main surface alignment stuff.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f0cb80aba89a..4d514ca1da88 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2163,6 +2163,10 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
 {
struct drm_i915_private *dev_priv = to_i915(fb->dev);
 
+   /* AUX_DIST needs only 4K alignment */
+   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
+   return 4096;
+
switch (fb->modifier) {
case DRM_FORMAT_MOD_NONE:
return intel_linear_alignment(dev_priv);
@@ -2452,13 +2456,7 @@ u32 intel_compute_tile_offset(int *x, int *y,
const struct drm_framebuffer *fb = state->base.fb;
unsigned int rotation = state->base.rotation;
int pitch = intel_fb_pitch(fb, plane, rotation);
-   u32 alignment;
-
-   /* AUX_DIST needs only 4K alignment */
-   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
-   alignment = 4096;
-   else
-   alignment = intel_surf_alignment(fb, plane);
+   u32 alignment = intel_surf_alignment(fb, plane);
 
return _intel_compute_tile_offset(dev_priv, x, y, fb, plane, pitch,
  rotation, alignment);
-- 
2.10.2

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

[Intel-gfx] [PATCH 2/9] drm/i915: Plumb drm_framebuffer into more places

[ville . syrjala]

From: Ville Syrjälä 

Now that framebuffers can be used even before calling
drm_framebuffer_init() we can start to plumb them into more places,
instead of passing individual pieces for fb metadata.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 127 +++
 drivers/gpu/drm/i915/intel_drv.h |  11 +--
 drivers/gpu/drm/i915/intel_fbdev.c   |   4 +-
 3 files changed, 57 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2150a64860c..f0cb80aba89a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2050,10 +2050,13 @@ static unsigned int intel_tile_size(const struct 
drm_i915_private *dev_priv)
return IS_GEN2(dev_priv) ? 2048 : 4096;
 }
 
-static unsigned int intel_tile_width_bytes(const struct drm_i915_private 
*dev_priv,
-  uint64_t fb_modifier, unsigned int 
cpp)
+static unsigned int
+intel_tile_width_bytes(const struct drm_framebuffer *fb, int plane)
 {
-   switch (fb_modifier) {
+   struct drm_i915_private *dev_priv = to_i915(fb->dev);
+   unsigned int cpp = fb->format->cpp[plane];
+
+   switch (fb->modifier) {
case DRM_FORMAT_MOD_NONE:
return cpp;
case I915_FORMAT_MOD_X_TILED:
@@ -2082,41 +2085,38 @@ static unsigned int intel_tile_width_bytes(const struct 
drm_i915_private *dev_pr
}
break;
default:
-   MISSING_CASE(fb_modifier);
+   MISSING_CASE(fb->modifier);
return cpp;
}
 }
 
-unsigned int intel_tile_height(const struct drm_i915_private *dev_priv,
-  uint64_t fb_modifier, unsigned int cpp)
+static unsigned int
+intel_tile_height(const struct drm_framebuffer *fb, int plane)
 {
-   if (fb_modifier == DRM_FORMAT_MOD_NONE)
+   if (fb->modifier == DRM_FORMAT_MOD_NONE)
return 1;
else
-   return intel_tile_size(dev_priv) /
-   intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
+   return intel_tile_size(to_i915(fb->dev)) /
+   intel_tile_width_bytes(fb, plane);
 }
 
 /* Return the tile dimensions in pixel units */
-static void intel_tile_dims(const struct drm_i915_private *dev_priv,
+static void intel_tile_dims(const struct drm_framebuffer *fb, int plane,
unsigned int *tile_width,
-   unsigned int *tile_height,
-   uint64_t fb_modifier,
-   unsigned int cpp)
+   unsigned int *tile_height)
 {
-   unsigned int tile_width_bytes =
-   intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
+   unsigned int tile_width_bytes = intel_tile_width_bytes(fb, plane);
+   unsigned int cpp = fb->format->cpp[plane];
 
*tile_width = tile_width_bytes / cpp;
-   *tile_height = intel_tile_size(dev_priv) / tile_width_bytes;
+   *tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes;
 }
 
 unsigned int
-intel_fb_align_height(struct drm_device *dev, unsigned int height,
- uint32_t pixel_format, uint64_t fb_modifier)
+intel_fb_align_height(const struct drm_framebuffer *fb,
+ int plane, unsigned int height)
 {
-   unsigned int cpp = drm_format_plane_cpp(pixel_format, 0);
-   unsigned int tile_height = intel_tile_height(to_i915(dev), fb_modifier, 
cpp);
+   unsigned int tile_height = intel_tile_height(fb, plane);
 
return ALIGN(height, tile_height);
 }
@@ -2158,21 +2158,23 @@ static unsigned int intel_linear_alignment(const struct 
drm_i915_private *dev_pr
return 0;
 }
 
-static unsigned int intel_surf_alignment(const struct drm_i915_private 
*dev_priv,
-uint64_t fb_modifier)
+static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
+int plane)
 {
-   switch (fb_modifier) {
+   struct drm_i915_private *dev_priv = to_i915(fb->dev);
+
+   switch (fb->modifier) {
case DRM_FORMAT_MOD_NONE:
return intel_linear_alignment(dev_priv);
case I915_FORMAT_MOD_X_TILED:
-   if (INTEL_INFO(dev_priv)->gen >= 9)
+   if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
default:
-   MISSING_CASE(fb_modifier);
+   MISSING_CASE(fb->modifier);
return 0;
}
 }
@@ -2189,7 +2191,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb, 
unsigned int rotation)
 

[Intel-gfx] [PATCH 1/9] drm: Add mode_config .get_format_info() hook

[ville . syrjala]

From: Ville Syrjälä 

Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.

v2: Fix drm_get_format_info() kernel doc (Laurent)
Don't pass 'dev' to the new hook (Laurent)

Cc: Laurent Pinchart 
Cc: Ben Widawsky 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_fb_cma_helper.c  |  2 +-
 drivers/gpu/drm/drm_fourcc.c | 25 +
 drivers/gpu/drm/drm_framebuffer.c|  9 +++--
 drivers/gpu/drm/drm_modeset_helper.c |  2 +-
 include/drm/drm_fourcc.h |  6 ++
 include/drm/drm_mode_config.h| 14 ++
 6 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 20a4011f790d..de3c9fe116fc 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -177,7 +177,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct 
drm_device *dev,
int ret;
int i;
 
-   info = drm_format_info(mode_cmd->pixel_format);
+   info = drm_get_format_info(dev, mode_cmd);
if (!info)
return ERR_PTR(-EINVAL);
 
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8da8eb..f9b6445e846a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32 format)
 EXPORT_SYMBOL(drm_format_info);
 
 /**
+ * drm_get_format_info - query information for a given framebuffer 
configuration
+ * @dev: DRM device
+ * @mode_cmd: metadata from the userspace fb creation request
+ *
+ * Returns:
+ * The instance of struct drm_format_info that describes the pixel format, or
+ * NULL if the format is unsupported.
+ */
+const struct drm_format_info *
+drm_get_format_info(struct drm_device *dev,
+   const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   const struct drm_format_info *info = NULL;
+
+   if (dev->mode_config.funcs->get_format_info)
+   info = dev->mode_config.funcs->get_format_info(mode_cmd);
+
+   if (!info)
+   info = drm_format_info(mode_cmd->pixel_format);
+
+   return info;
+}
+EXPORT_SYMBOL(drm_get_format_info);
+
+/**
  * drm_format_num_planes - get the number of planes for format
  * @format: pixel format (DRM_FORMAT_*)
  *
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 588ccc3a2218..e276fcdc3a62 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -126,11 +126,13 @@ int drm_mode_addfb(struct drm_device *dev,
return 0;
 }
 
-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
+static int framebuffer_check(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
 {
const struct drm_format_info *info;
int i;
 
+   /* check if the format is supported at all */
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
@@ -140,6 +142,9 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2 
*r)
return -EINVAL;
}
 
+   /* now let the driver pick its own format info */
+   info = drm_get_format_info(dev, r);
+
if (r->width == 0 || r->width % info->hsub) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
@@ -263,7 +268,7 @@ drm_internal_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}
 
-   ret = framebuffer_check(r);
+   ret = framebuffer_check(dev, r);
if (ret)
return ERR_PTR(ret);
 
diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
b/drivers/gpu/drm/drm_modeset_helper.c
index cc44a9a4b004..2b33825f2f93 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -78,7 +78,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_device *dev,
int i;
 
fb->dev = dev;
-   fb->format = drm_format_info(mode_cmd->pixel_format);
+   fb->format = drm_get_format_info(dev, mode_cmd);
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
for (i = 0; i < 4; i++) {
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fcc08da850c8..6942e84b6edd 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,9 @@
 #include 
 #include 
 
+struct drm_device;
+struct drm_mode_fb_cmd2;
+
 /**
  * struct drm_format_info - information about a DRM format
  * @format: 4CC format identifier (DRM_FORMAT_*)
@@ -55,6 +58,9 @@ struct drm_format_name_buf {
 
 const struct drm_format_info *__drm_format_info(u32 format);
 const struct 

[Intel-gfx] [PATCH 0/9] drm/i915: SKL+ render decompression support

[ville . syrjala]

From: Ville Syrjälä 

This series enables the SKL+ display engine render decompression
support. Some bits and pieces of the i915 code are based on work
from various people, but I just put my name on it since it
would be hard to figure out which parts came from where.

Entire series available here:
git://github.com/vsyrjala/linux.git fb_format_dedup_4_ccs

Cc: Vandana Kannan 
Cc: Daniel Vetter 
Cc: Ben Widawsky 
Cc: Jason Ekstrand 
Cc: Laurent Pinchart 

Ville Syrjälä (9):
  drm: Add mode_config .get_format_info() hook
  drm/i915: Plumb drm_framebuffer into more places
  drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()
  drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane
  drm/i915: Fix Yf tile width
  drm/i915: Pass the correct plane index to _intel_compute_tile_offset()
  drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages
  drm/i915: Implement .get_format_info() hook for CCS
  drm/i915: Add render decompression support

 drivers/gpu/drm/drm_fb_cma_helper.c  |   2 +-
 drivers/gpu/drm/drm_fourcc.c |  25 ++
 drivers/gpu/drm/drm_framebuffer.c|   9 +-
 drivers/gpu/drm/drm_modeset_helper.c |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |  22 ++
 drivers/gpu/drm/i915/intel_display.c | 474 +--
 drivers/gpu/drm/i915/intel_drv.h |  11 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |   4 +-
 drivers/gpu/drm/i915/intel_pm.c  |   8 +-
 drivers/gpu/drm/i915/intel_sprite.c  |   5 +
 include/drm/drm_fourcc.h |   6 +
 include/drm/drm_mode_config.h|  14 ++
 include/uapi/drm/drm_fourcc.h|  49 
 13 files changed, 478 insertions(+), 153 deletions(-)

-- 
2.10.2

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

[Intel-gfx] [PATCH v6] drm: add fourcc codes for 16bit R and RG

[Rainer Hochecker]

From: Rainer Hochecker 

This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..d230e58 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
 
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
little endian */
+
 /* 16 bpp RG */
 #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
 #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
 
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v5] drm: add fourcc codes for 16bit R and RG

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 07:24:09PM +0100, Rainer Hochecker wrote:
> From: Rainer Hochecker 
> 
> Thanks for bearing with me. My ml skills have greatly improved now :)
> 
> v5 of patch:
> 
> This adds fourcc codes for 16bit planes required for DRM buffer
> export to mesa.
> 
> Signed-off-by: Rainer Hochecker 
> ---
>  include/uapi/drm/drm_fourcc.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index a5890bf..e7f6bcd 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -41,10 +41,17 @@ extern "C" {
>  /* 8 bpp Red */
>  #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /* 
> [7:0] R */
>  
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16   fourcc_code('R', '1', '6', ' ') /* 
> [15:0] R */

little endian

> +
>  /* 16 bpp RG */
>  #define DRM_FORMAT_RG88  fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
>  #define DRM_FORMAT_GR88  fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
>  
> +/* 32 bpp RG */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 little endian */
> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 little endian */
> +
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> 3:3:2 */
>  #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> 2:3:3 */
> -- 
> 2.9.3

-- 
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 v5] drm: add fourcc codes for 16bit R and RG

[Rainer Hochecker]

From: Rainer Hochecker 

Thanks for bearing with me. My ml skills have greatly improved now :)

v5 of patch:

This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..e7f6bcd 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
 
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
+
 /* 16 bpp RG */
 #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
 #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
 
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v4] drm: add fourcc codes for 16bit R and RG

[Eric Engestrom]

On Wednesday, 2017-01-04 14:50:02 +0100, Rainer Hochecker wrote:
> From: Rainer Hochecker 
> 
> Signed-off-by: Rainer Hochecker 
> ---
>  include/uapi/drm/drm_fourcc.h | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index a5890bf..4d65fb6 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -41,10 +41,17 @@ extern "C" {
>  /* 8 bpp Red */
>  #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /* 
> [7:0] R */
>  
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16   fourcc_code('R', '1', '6', ' ') /* 
> [15:0] R */
> +
>  /* 16 bpp RG */
>  #define DRM_FORMAT_RG88  fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
>  #define DRM_FORMAT_GR88  fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
>  
> +/* 32 bpp RG */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] G:R 
> 16:16 little endian */

Comment above is still wrong: s/G:R/R:G/ :)

> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 little endian */
> +
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> 3:3:2 */
>  #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> 2:3:3 */
> -- 
> 2.9.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for HuC Loading Patches

[Patchwork]

== Series Details ==

Series: HuC Loading Patches
URL   : https://patchwork.freedesktop.org/series/17499/
State : warning

== Summary ==

Series 17499v1 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/17499/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> DMESG-WARN (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-3:
pass   -> DMESG-WARN (fi-ivb-3770)

fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:1   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:214  dwarn:1   dfail:0   fail:0   skip:31 

ea0500897bf72bbbf6eca6e695c9d49289dfc768 drm-tip: 2017y-01m-04d-16h-46m-35s UTC 
integration manifest
97ae46d drm/i915/get_params: Add HuC status to getparams
454ee37 drm/i915/huc: Support HuC authentication
8024997 drm/i915/huc: Add debugfs for HuC loading status check
dc8952d drm/i915/HuC: Add KBL huC loading Support
96f12e1 drm/i915/huc: Add BXT HuC Loading Support
f5c922a drm/i915/huc: Add HuC fw loading support
0f4ad78 drm/i915/huc: Unified css_header struct for GuC and HuC
4278638 drm/i915/guc: Make the GuC fw loading helper functions general

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t v2] igt_core: add igt_constructor

[Chris Wilson]

On Wed, Jan 04, 2017 at 03:20:49PM -0200, Paulo Zanoni wrote:
> Em Qua, 2016-12-21 às 15:50 -0500, Lyude escreveu:
> > This is a simple macro for executing a block of code at the beginning
> > of
> > intel-gpu-tools, before any tests have been ran. Useful for
> > initialization of global resources used in IGT libraries.
> 
> IGT doesn't compile anymore here. Reverting this patch fixes it for me.
> 
> On a brand new git clone, if I just run autogen.sh, I get this:
> 
> ./configure: line 6319: syntax error near unexpected token
> `constructor'
> ./configure: line 6319: `AX_GCC_FUNC_ATTRIBUTE(constructor)'
> 
> The gcc/autoconf/etc versions are from Fedora 24.
> 
> I'm not sure what I'm missing here...

m4/ax_gcc_func_attribute.m4

Now supplied for us luddites.
-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 i-g-t v2] igt_core: add igt_constructor

[Paulo Zanoni]

Em Qua, 2016-12-21 às 15:50 -0500, Lyude escreveu:
> This is a simple macro for executing a block of code at the beginning
> of
> intel-gpu-tools, before any tests have been ran. Useful for
> initialization of global resources used in IGT libraries.

IGT doesn't compile anymore here. Reverting this patch fixes it for me.

On a brand new git clone, if I just run autogen.sh, I get this:

./configure: line 6319: syntax error near unexpected token
`constructor'
./configure: line 6319: `AX_GCC_FUNC_ATTRIBUTE(constructor)'

The gcc/autoconf/etc versions are from Fedora 24.

I'm not sure what I'm missing here...

> 
> Signed-off-by: Lyude 
> 
> Changes since v1:
>  - Add the line number into the name of the constructor function so
> that
>    multiple constructors may be used per-file.
> ---
>  configure.ac   |  1 +
>  lib/igt_core.h | 13 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index fa31a52..411bfab 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -65,6 +65,7 @@
> AC_CHECK_TYPES([sighandler_t],[],[],[AC_INCLUDES_DEFAULT
>  #include ])
>  AC_CHECK_FUNCS([swapctl])
>  AC_CHECK_FUNCS([asprintf])
> +AX_GCC_FUNC_ATTRIBUTE([constructor])
>  
>  dnl Check for POSIX timers
>  AC_CHECK_FUNCS(timer_create, [], [
> diff --git a/lib/igt_core.h b/lib/igt_core.h
> index 661a634..b669de3 100644
> --- a/lib/igt_core.h
> +++ b/lib/igt_core.h
> @@ -281,6 +281,19 @@ void igt_simple_init_parse_opts(int *argc, char
> **argv,
>   } \
>   static void igt_tokencat(__real_main, __LINE__)(void) \
>  
> +/**
> + * igt_constructor:
> + *
> + * Convenience macro to run the provided code block when igt first
> starts,
> + * before any tests have been run. This should be used for parts of
> the igt
> + * library that require initialization of objects with global
> context.
> + *
> + * This code block will be executed exactly once.
> + */
> +#define igt_constructor \
> + __attribute__((constructor)) \
> + static void igt_tokencat(__igt_constructor_l,
> __LINE__)(void)
> +
>  __attribute__((format(printf, 1, 2)))
>  void igt_skip(const char *f, ...) __attribute__((noreturn));
>  __attribute__((format(printf, 5, 6)))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Maarten Lankhorst]

Op 04-01-17 om 16:47 schreef Ville Syrjälä:
> On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote:
>> On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote:
>>> On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote:
 From: Chris Wilson 

 With atomic plane states we are able to track an allocation right from
 preparation, during use and through to the final free after being
 swapped out for a new plane. We can couple the VMA we pin for the
 framebuffer (and its rotation) to this lifetime and avoid all the clumsy
 lookups in between.

 v2: Remove residual vma on plane cleanup (Chris)
 v3: Add a description for the vma destruction in
 intel_plane_destroy_state (Maarten)

 Signed-off-by: Chris Wilson 
 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/i915_drv.h   |  16 +---
  drivers/gpu/drm/i915/intel_atomic_plane.c |  20 +
  drivers/gpu/drm/i915/intel_display.c  | 129 
 +++---
  drivers/gpu/drm/i915/intel_drv.h  |   9 ++-
  drivers/gpu/drm/i915/intel_fbc.c  |  52 +---
  drivers/gpu/drm/i915/intel_fbdev.c|   4 +-
  drivers/gpu/drm/i915/intel_sprite.c   |   8 +-
  7 files changed, 103 insertions(+), 135 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 22d3f610212c..5369f5f9ce3a 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1079,6 +1079,8 @@ struct intel_fbc {
struct work_struct underrun_work;
  
struct intel_fbc_state_cache {
 +  struct i915_vma *vma;
 +
struct {
unsigned int mode_flags;
uint32_t hsw_bdw_pixel_rate;
 @@ -1092,15 +1094,14 @@ struct intel_fbc {
} plane;
  
struct {
 -  u64 ilk_ggtt_offset;
const struct drm_format_info *format;
unsigned int stride;
 -  int fence_reg;
 -  unsigned int tiling_mode;
} fb;
} state_cache;
  
struct intel_fbc_reg_params {
 +  struct i915_vma *vma;
 +
struct {
enum pipe pipe;
enum plane plane;
 @@ -1108,10 +1109,8 @@ struct intel_fbc {
} crtc;
  
struct {
 -  u64 ggtt_offset;
const struct drm_format_info *format;
unsigned int stride;
 -  int fence_reg;
} fb;
  
int cfb_size;
 @@ -3406,13 +3405,6 @@ i915_gem_object_to_ggtt(struct drm_i915_gem_object 
 *obj,
return i915_gem_obj_to_vma(obj, _i915(obj->base.dev)->ggtt.base, 
 view);
  }
  
 -static inline unsigned long
 -i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
 -  const struct i915_ggtt_view *view)
 -{
 -  return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
 -}
 -
  /* i915_gem_fence_reg.c */
  int __must_check i915_vma_get_fence(struct i915_vma *vma);
  int __must_check i915_vma_put_fence(struct i915_vma *vma);
 diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
 b/drivers/gpu/drm/i915/intel_atomic_plane.c
 index 4612ffd555a7..41fd94e62d3c 100644
 --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
 +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
 @@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
  
__drm_atomic_helper_plane_duplicate_state(plane, state);
  
 +  intel_state->vma = NULL;
>>> Shouldn't we be doing vma_get() instead?
>> I went with NULL (dropping the copy) for simplicity. Before the plane
>> can be used it must be prepared, so vma will always be set before
>> commiting, and using NULL avoided having the reference counting dance.
>> It also allowed detection of when we didn't prepare the plane as
>> required.
> Hmm. Does that risk some kind of failure at prepare_fb time if the vma
> got nuked in the meantime? I guess that might ahve to involve
> suspend/resume or some other case where we duplicate the state and
> don't hang on to the old state.

I think the way this is done is sane, and a nice safeguard against forgetting 
to call prepare.
The old mapping is still around when prepare_plane_fb is called, and we keep 
the vma during suspend/resume
since we never unset the plane fb. We only set crtc_state->active = false (dpms 
off).

~Maarten

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PULL] drm-misc-fixes

[Daniel Vetter]

Hi Dave,

One small bugfix to the atomic helpers from Laurent. Haz cc: stable.

Cheers, Daniel


The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:

  Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-01-04

for you to fetch changes up to aebe55c2d4b998741c0847ace1b4af47d73c763b:

  drm: Clean up planes in atomic commit helper failure path (2017-01-04 
11:08:13 +0100)


Laurent Pinchart (1):
  drm: Clean up planes in atomic commit helper failure path

 drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

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

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Chris Wilson]

On Wed, Jan 04, 2017 at 06:06:42PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 04, 2017 at 04:00:49PM +, Chris Wilson wrote:
> > If we are restoring the same plane_state, the old_plane_state will not
> > be unpinned until after the swap. So prepare_fb will return the
> > duplicate VMA with incremented pin_count.
> 
> During suspend we throw away the old state, and resume will read in
> the state from the hardware. So when we do the swap we won't have the
> original old state in place anymore.

But in this case, we should have a plane_config from HW readout that has
a recovered VMA? I presume the same takeover code is run after resume as
on init...

On the other hand, if the plane_state was removed from the hardware, its
VMA would be unpinned and we would be free to rebind it in a new location.
Provided the obj itself wasn't freed, the VMA will be kept. However, we
still risk a potential error on remapping (if the vma was unbound during
suspend). That's not a huge risk though, and does require the VMA to be
actually unbound on suspend.
-Chris

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

Re: [Intel-gfx] [PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put

[Daniel Vetter]

On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote:
> I was lazy, rectify that! Also align with drm_atomic_state_get/put for
> ocd.
> 
> v2: Git add helps.
> 
> Signed-off-by: Daniel Vetter 

Anyone feel like acking this, pretty please? ;-)
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c |  9 ++---
>  include/drm/drm_atomic.h | 21 -
>  2 files changed, 22 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b1b54011a92c..26a4cfdf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -35,19 +35,14 @@
>  
>  #include "drm_crtc_internal.h"
>  
> -static void crtc_commit_free(struct kref *kref)
> +void __drm_crtc_commit_free(struct kref *kref)
>  {
>   struct drm_crtc_commit *commit =
>   container_of(kref, struct drm_crtc_commit, ref);
>  
>   kfree(commit);
>  }
> -
> -void drm_crtc_commit_put(struct drm_crtc_commit *commit)
> -{
> - kref_put(>ref, crtc_commit_free);
> -}
> -EXPORT_SYMBOL(drm_crtc_commit_put);
> +EXPORT_SYMBOL(__drm_crtc_commit_free);
>  
>  /**
>   * drm_atomic_state_default_release -
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 91b18bd7cb50..97587ec36eae 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -199,12 +199,31 @@ struct drm_atomic_state {
>   struct work_struct commit_work;
>  };
>  
> -void drm_crtc_commit_put(struct drm_crtc_commit *commit);
> +void __drm_crtc_commit_free(struct kref *kref);
> +
> +/**
> + * drm_crtc_commit_get - acquire a reference to the CRTC commit
> + * @commit: CRTC commit
> + *
> + * Increases the reference of @commit.
> + */
>  static inline void drm_crtc_commit_get(struct drm_crtc_commit *commit)
>  {
>   kref_get(>ref);
>  }
>  
> +/**
> + * drm_crtc_commit_put - release a reference to the CRTC commmit
> + * @commit: CRTC commit
> + *
> + * This releases a reference to @commit which is freed after removing the
> + * final reference. No locking required and callable from any context.
> + */
> +static inline void drm_crtc_commit_put(struct drm_crtc_commit *commit)
> +{
> + kref_put(>ref, __drm_crtc_commit_free);
> +}
> +
>  struct drm_atomic_state * __must_check
>  drm_atomic_state_alloc(struct drm_device *dev);
>  void drm_atomic_state_clear(struct drm_atomic_state *state);
> -- 
> 2.11.0
> 

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

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 04:00:49PM +, Chris Wilson wrote:
> On Wed, Jan 04, 2017 at 05:47:50PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote:
> > > On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote:
> > > > > From: Chris Wilson 
> > > > > 
> > > > > With atomic plane states we are able to track an allocation right from
> > > > > preparation, during use and through to the final free after being
> > > > > swapped out for a new plane. We can couple the VMA we pin for the
> > > > > framebuffer (and its rotation) to this lifetime and avoid all the 
> > > > > clumsy
> > > > > lookups in between.
> > > > > 
> > > > > v2: Remove residual vma on plane cleanup (Chris)
> > > > > v3: Add a description for the vma destruction in
> > > > > intel_plane_destroy_state (Maarten)
> > > > > 
> > > > > Signed-off-by: Chris Wilson 
> > > > > Signed-off-by: Maarten Lankhorst 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.h   |  16 +---
> > > > >  drivers/gpu/drm/i915/intel_atomic_plane.c |  20 +
> > > > >  drivers/gpu/drm/i915/intel_display.c  | 129 
> > > > > +++---
> > > > >  drivers/gpu/drm/i915/intel_drv.h  |   9 ++-
> > > > >  drivers/gpu/drm/i915/intel_fbc.c  |  52 +---
> > > > >  drivers/gpu/drm/i915/intel_fbdev.c|   4 +-
> > > > >  drivers/gpu/drm/i915/intel_sprite.c   |   8 +-
> > > > >  7 files changed, 103 insertions(+), 135 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index 22d3f610212c..5369f5f9ce3a 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -1079,6 +1079,8 @@ struct intel_fbc {
> > > > >   struct work_struct underrun_work;
> > > > >  
> > > > >   struct intel_fbc_state_cache {
> > > > > + struct i915_vma *vma;
> > > > > +
> > > > >   struct {
> > > > >   unsigned int mode_flags;
> > > > >   uint32_t hsw_bdw_pixel_rate;
> > > > > @@ -1092,15 +1094,14 @@ struct intel_fbc {
> > > > >   } plane;
> > > > >  
> > > > >   struct {
> > > > > - u64 ilk_ggtt_offset;
> > > > >   const struct drm_format_info *format;
> > > > >   unsigned int stride;
> > > > > - int fence_reg;
> > > > > - unsigned int tiling_mode;
> > > > >   } fb;
> > > > >   } state_cache;
> > > > >  
> > > > >   struct intel_fbc_reg_params {
> > > > > + struct i915_vma *vma;
> > > > > +
> > > > >   struct {
> > > > >   enum pipe pipe;
> > > > >   enum plane plane;
> > > > > @@ -1108,10 +1109,8 @@ struct intel_fbc {
> > > > >   } crtc;
> > > > >  
> > > > >   struct {
> > > > > - u64 ggtt_offset;
> > > > >   const struct drm_format_info *format;
> > > > >   unsigned int stride;
> > > > > - int fence_reg;
> > > > >   } fb;
> > > > >  
> > > > >   int cfb_size;
> > > > > @@ -3406,13 +3405,6 @@ i915_gem_object_to_ggtt(struct 
> > > > > drm_i915_gem_object *obj,
> > > > >   return i915_gem_obj_to_vma(obj, 
> > > > > _i915(obj->base.dev)->ggtt.base, view);
> > > > >  }
> > > > >  
> > > > > -static inline unsigned long
> > > > > -i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
> > > > > - const struct i915_ggtt_view *view)
> > > > > -{
> > > > > - return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
> > > > > -}
> > > > > -
> > > > >  /* i915_gem_fence_reg.c */
> > > > >  int __must_check i915_vma_get_fence(struct i915_vma *vma);
> > > > >  int __must_check i915_vma_put_fence(struct i915_vma *vma);
> > > > > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> > > > > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > > > index 4612ffd555a7..41fd94e62d3c 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > > > @@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
> > > > >  
> > > > >   __drm_atomic_helper_plane_duplicate_state(plane, state);
> > > > >  
> > > > > + intel_state->vma = NULL;
> > > > 
> > > > Shouldn't we be doing vma_get() instead?
> > > 
> > > I went with NULL (dropping the copy) for simplicity. Before the plane
> > > can be used it must be prepared, so vma will always be set before
> > > commiting, and using NULL avoided having the reference counting dance.
> > > It also allowed detection of when we didn't prepare the plane as

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Chris Wilson]

On Wed, Jan 04, 2017 at 05:47:50PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote:
> > On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote:
> > > On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote:
> > > > From: Chris Wilson 
> > > > 
> > > > With atomic plane states we are able to track an allocation right from
> > > > preparation, during use and through to the final free after being
> > > > swapped out for a new plane. We can couple the VMA we pin for the
> > > > framebuffer (and its rotation) to this lifetime and avoid all the clumsy
> > > > lookups in between.
> > > > 
> > > > v2: Remove residual vma on plane cleanup (Chris)
> > > > v3: Add a description for the vma destruction in
> > > > intel_plane_destroy_state (Maarten)
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Signed-off-by: Maarten Lankhorst 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h   |  16 +---
> > > >  drivers/gpu/drm/i915/intel_atomic_plane.c |  20 +
> > > >  drivers/gpu/drm/i915/intel_display.c  | 129 
> > > > +++---
> > > >  drivers/gpu/drm/i915/intel_drv.h  |   9 ++-
> > > >  drivers/gpu/drm/i915/intel_fbc.c  |  52 +---
> > > >  drivers/gpu/drm/i915/intel_fbdev.c|   4 +-
> > > >  drivers/gpu/drm/i915/intel_sprite.c   |   8 +-
> > > >  7 files changed, 103 insertions(+), 135 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 22d3f610212c..5369f5f9ce3a 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1079,6 +1079,8 @@ struct intel_fbc {
> > > > struct work_struct underrun_work;
> > > >  
> > > > struct intel_fbc_state_cache {
> > > > +   struct i915_vma *vma;
> > > > +
> > > > struct {
> > > > unsigned int mode_flags;
> > > > uint32_t hsw_bdw_pixel_rate;
> > > > @@ -1092,15 +1094,14 @@ struct intel_fbc {
> > > > } plane;
> > > >  
> > > > struct {
> > > > -   u64 ilk_ggtt_offset;
> > > > const struct drm_format_info *format;
> > > > unsigned int stride;
> > > > -   int fence_reg;
> > > > -   unsigned int tiling_mode;
> > > > } fb;
> > > > } state_cache;
> > > >  
> > > > struct intel_fbc_reg_params {
> > > > +   struct i915_vma *vma;
> > > > +
> > > > struct {
> > > > enum pipe pipe;
> > > > enum plane plane;
> > > > @@ -1108,10 +1109,8 @@ struct intel_fbc {
> > > > } crtc;
> > > >  
> > > > struct {
> > > > -   u64 ggtt_offset;
> > > > const struct drm_format_info *format;
> > > > unsigned int stride;
> > > > -   int fence_reg;
> > > > } fb;
> > > >  
> > > > int cfb_size;
> > > > @@ -3406,13 +3405,6 @@ i915_gem_object_to_ggtt(struct 
> > > > drm_i915_gem_object *obj,
> > > > return i915_gem_obj_to_vma(obj, 
> > > > _i915(obj->base.dev)->ggtt.base, view);
> > > >  }
> > > >  
> > > > -static inline unsigned long
> > > > -i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
> > > > -   const struct i915_ggtt_view *view)
> > > > -{
> > > > -   return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
> > > > -}
> > > > -
> > > >  /* i915_gem_fence_reg.c */
> > > >  int __must_check i915_vma_get_fence(struct i915_vma *vma);
> > > >  int __must_check i915_vma_put_fence(struct i915_vma *vma);
> > > > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> > > > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > > index 4612ffd555a7..41fd94e62d3c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > > @@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
> > > >  
> > > > __drm_atomic_helper_plane_duplicate_state(plane, state);
> > > >  
> > > > +   intel_state->vma = NULL;
> > > 
> > > Shouldn't we be doing vma_get() instead?
> > 
> > I went with NULL (dropping the copy) for simplicity. Before the plane
> > can be used it must be prepared, so vma will always be set before
> > commiting, and using NULL avoided having the reference counting dance.
> > It also allowed detection of when we didn't prepare the plane as
> > required.
> 
> Hmm. Does that risk some kind of failure at prepare_fb time if the vma
> got nuked in the meantime? I guess that might ahve to involve
> suspend/resume or some other case where we duplicate the 

Re: [Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

[Tvrtko Ursulin]

On 04/01/2017 15:45, Chris Wilson wrote:

On Wed, Jan 04, 2017 at 03:36:16PM +, Tvrtko Ursulin wrote:


On 04/01/2017 14:51, Chris Wilson wrote:

During the fence registers are clobbered by a GPU reset. Hence if


During the reset I suppose, although it would sound still a bit
redundant. So maybe "Since GPU reset clobbers the fence registers,
if there is concurrent..."


I was just going to leave it as "The fence registers are clobbered by
a GPU reset. If..."


Fine by me.


there is concurrent user access to a fenced region via a GTT mmaping,
the access will not be fenced during the reset (until we restore the
fences afterwards). In order to prevent invalid access during the reset,
before we clobber the fences we must invalidate the GTT mmapings. Access
to the mmap will then be forced to fault the page, and in handling the
fault, i915_gem_fault() will take the struct_mutex and wait upon the
reset to complete.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99274
Signed-off-by: Chris Wilson 
---
drivers/gpu/drm/i915/i915_drv.c   |  3 ++-
drivers/gpu/drm/i915/i915_drv.h   |  4 +++-
drivers/gpu/drm/i915/i915_gem.c   |  7 ++-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 24 
4 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72e29fcb1638..39463fcab593 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1780,6 +1780,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
error->reset_count++;

pr_notice("drm/i915: Resetting chip after gpu hang\n");
+   i915_gem_reset_prepare(dev_priv);

disable_engines_irq(dev_priv);
ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
@@ -1793,7 +1794,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
goto error;
}

-   i915_gem_reset(dev_priv);
+   i915_gem_reset_finish(dev_priv);
intel_overlay_reset(dev_priv);

/* Ok, now get things going again... */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c035b6576efa..f16986cfa127 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3355,7 +3355,8 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return READ_ONCE(error->reset_count);
}

-void i915_gem_reset(struct drm_i915_private *dev_priv);
+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
+void i915_gem_reset_finish(struct drm_i915_private *dev_priv);
void i915_gem_set_wedged(struct drm_i915_private *dev_priv);

void i915_gem_clflush_init(struct drm_i915_private *i915);
@@ -3426,6 +3427,7 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
int __must_check i915_vma_get_fence(struct i915_vma *vma);
int __must_check i915_vma_put_fence(struct i915_vma *vma);

+void i915_gem_revoke_fences(struct drm_i915_private *dev_priv);
void i915_gem_restore_fences(struct drm_i915_private *dev_priv);

void i915_gem_detect_bit_6_swizzle(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73987014a7bd..019ea7cb13b5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2715,6 +2715,11 @@ static void reset_request(struct drm_i915_gem_request 
*request)
memset(vaddr + head, 0, request->postfix - head);
}

+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv)
+{
+   i915_gem_revoke_fences(dev_priv);
+}
+
static void i915_gem_reset_engine(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *request;
@@ -2780,7 +2785,7 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
spin_unlock_irqrestore(>timeline->lock, flags);
}

-void i915_gem_reset(struct drm_i915_private *dev_priv)
+void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index 67835d7b39c7..447abb1105ab 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -358,6 +358,30 @@ i915_vma_get_fence(struct i915_vma *vma)
}

/**
+ * i915_gem_revoke_fences - revoke fence state
+ * @dev_priv: i915 device private
+ *
+ * Clears the hw fence state and removes all GTT mmappings via the fence. This


The function doesn't clear the hw fence state - reset does that, no?


The first version did, then realised all that was required was zapping
the mmap.


Explains that then. :)

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()

[Sumit Semwal]

Hi Chris,

Thanks for your patches!

On 4 January 2017 at 20:40, Daniel Vetter  wrote:
> On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote:
>> As the fence->status is an optional field that may be set before
>> dma_fence_signal() is called to convey that the fence completed with an
>> error, we have to ensure that it is always set to zero on initialisation
>> so that the typical use (i.e. unset) always flags a successful completion.
>>
>> Signed-off-by: Chris Wilson 
>> Reviewed-by: Tvrtko Ursulin 
>
> Yeah, this looks all pretty. On the series:
>
> Reviewed-by: Daniel Vetter 
>
FWIW, please feel free, for this series, to apply my

Reviewed-by: Sumit Semwal 

> I'll defer to Gustavo for another pass over it and merging it to drm-misc.
> -Daniel
>

Best,
Sumit.
>> ---
>>  drivers/dma-buf/dma-fence.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index 3444f293ad4a..9130f790ebf3 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
>> dma_fence_ops *ops,
>>   fence->context = context;
>>   fence->seqno = seqno;
>>   fence->flags = 0UL;
>> + fence->status = 0;
>>
>>   trace_dma_fence_init(fence);
>>  }
>> --
>> 2.11.0
>>
>> ___
>> 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
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 03:14:45PM +, Chris Wilson wrote:
> On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote:
> > > From: Chris Wilson 
> > > 
> > > With atomic plane states we are able to track an allocation right from
> > > preparation, during use and through to the final free after being
> > > swapped out for a new plane. We can couple the VMA we pin for the
> > > framebuffer (and its rotation) to this lifetime and avoid all the clumsy
> > > lookups in between.
> > > 
> > > v2: Remove residual vma on plane cleanup (Chris)
> > > v3: Add a description for the vma destruction in
> > > intel_plane_destroy_state (Maarten)
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Signed-off-by: Maarten Lankhorst 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h   |  16 +---
> > >  drivers/gpu/drm/i915/intel_atomic_plane.c |  20 +
> > >  drivers/gpu/drm/i915/intel_display.c  | 129 
> > > +++---
> > >  drivers/gpu/drm/i915/intel_drv.h  |   9 ++-
> > >  drivers/gpu/drm/i915/intel_fbc.c  |  52 +---
> > >  drivers/gpu/drm/i915/intel_fbdev.c|   4 +-
> > >  drivers/gpu/drm/i915/intel_sprite.c   |   8 +-
> > >  7 files changed, 103 insertions(+), 135 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 22d3f610212c..5369f5f9ce3a 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1079,6 +1079,8 @@ struct intel_fbc {
> > >   struct work_struct underrun_work;
> > >  
> > >   struct intel_fbc_state_cache {
> > > + struct i915_vma *vma;
> > > +
> > >   struct {
> > >   unsigned int mode_flags;
> > >   uint32_t hsw_bdw_pixel_rate;
> > > @@ -1092,15 +1094,14 @@ struct intel_fbc {
> > >   } plane;
> > >  
> > >   struct {
> > > - u64 ilk_ggtt_offset;
> > >   const struct drm_format_info *format;
> > >   unsigned int stride;
> > > - int fence_reg;
> > > - unsigned int tiling_mode;
> > >   } fb;
> > >   } state_cache;
> > >  
> > >   struct intel_fbc_reg_params {
> > > + struct i915_vma *vma;
> > > +
> > >   struct {
> > >   enum pipe pipe;
> > >   enum plane plane;
> > > @@ -1108,10 +1109,8 @@ struct intel_fbc {
> > >   } crtc;
> > >  
> > >   struct {
> > > - u64 ggtt_offset;
> > >   const struct drm_format_info *format;
> > >   unsigned int stride;
> > > - int fence_reg;
> > >   } fb;
> > >  
> > >   int cfb_size;
> > > @@ -3406,13 +3405,6 @@ i915_gem_object_to_ggtt(struct drm_i915_gem_object 
> > > *obj,
> > >   return i915_gem_obj_to_vma(obj, _i915(obj->base.dev)->ggtt.base, 
> > > view);
> > >  }
> > >  
> > > -static inline unsigned long
> > > -i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
> > > - const struct i915_ggtt_view *view)
> > > -{
> > > - return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
> > > -}
> > > -
> > >  /* i915_gem_fence_reg.c */
> > >  int __must_check i915_vma_get_fence(struct i915_vma *vma);
> > >  int __must_check i915_vma_put_fence(struct i915_vma *vma);
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> > > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > index 4612ffd555a7..41fd94e62d3c 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > @@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
> > >  
> > >   __drm_atomic_helper_plane_duplicate_state(plane, state);
> > >  
> > > + intel_state->vma = NULL;
> > 
> > Shouldn't we be doing vma_get() instead?
> 
> I went with NULL (dropping the copy) for simplicity. Before the plane
> can be used it must be prepared, so vma will always be set before
> commiting, and using NULL avoided having the reference counting dance.
> It also allowed detection of when we didn't prepare the plane as
> required.

Hmm. Does that risk some kind of failure at prepare_fb time if the vma
got nuked in the meantime? I guess that might ahve to involve
suspend/resume or some other case where we duplicate the state and
don't hang on to the old state.

-- 
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: Revoke fenced GTT mmapings across GPU reset

[Chris Wilson]

On Wed, Jan 04, 2017 at 03:36:16PM +, Tvrtko Ursulin wrote:
> 
> On 04/01/2017 14:51, Chris Wilson wrote:
> >During the fence registers are clobbered by a GPU reset. Hence if
> 
> During the reset I suppose, although it would sound still a bit
> redundant. So maybe "Since GPU reset clobbers the fence registers,
> if there is concurrent..."

I was just going to leave it as "The fence registers are clobbered by
a GPU reset. If..."

> >there is concurrent user access to a fenced region via a GTT mmaping,
> >the access will not be fenced during the reset (until we restore the
> >fences afterwards). In order to prevent invalid access during the reset,
> >before we clobber the fences we must invalidate the GTT mmapings. Access
> >to the mmap will then be forced to fault the page, and in handling the
> >fault, i915_gem_fault() will take the struct_mutex and wait upon the
> >reset to complete.
> >
> >Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99274
> >Signed-off-by: Chris Wilson 
> >---
> > drivers/gpu/drm/i915/i915_drv.c   |  3 ++-
> > drivers/gpu/drm/i915/i915_drv.h   |  4 +++-
> > drivers/gpu/drm/i915/i915_gem.c   |  7 ++-
> > drivers/gpu/drm/i915/i915_gem_fence_reg.c | 24 
> > 4 files changed, 35 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >b/drivers/gpu/drm/i915/i915_drv.c
> >index 72e29fcb1638..39463fcab593 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.c
> >+++ b/drivers/gpu/drm/i915/i915_drv.c
> >@@ -1780,6 +1780,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
> > error->reset_count++;
> >
> > pr_notice("drm/i915: Resetting chip after gpu hang\n");
> >+i915_gem_reset_prepare(dev_priv);
> >
> > disable_engines_irq(dev_priv);
> > ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
> >@@ -1793,7 +1794,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
> > goto error;
> > }
> >
> >-i915_gem_reset(dev_priv);
> >+i915_gem_reset_finish(dev_priv);
> > intel_overlay_reset(dev_priv);
> >
> > /* Ok, now get things going again... */
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index c035b6576efa..f16986cfa127 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -3355,7 +3355,8 @@ static inline u32 i915_reset_count(struct 
> >i915_gpu_error *error)
> > return READ_ONCE(error->reset_count);
> > }
> >
> >-void i915_gem_reset(struct drm_i915_private *dev_priv);
> >+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
> >+void i915_gem_reset_finish(struct drm_i915_private *dev_priv);
> > void i915_gem_set_wedged(struct drm_i915_private *dev_priv);
> >
> > void i915_gem_clflush_init(struct drm_i915_private *i915);
> >@@ -3426,6 +3427,7 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
> > int __must_check i915_vma_get_fence(struct i915_vma *vma);
> > int __must_check i915_vma_put_fence(struct i915_vma *vma);
> >
> >+void i915_gem_revoke_fences(struct drm_i915_private *dev_priv);
> > void i915_gem_restore_fences(struct drm_i915_private *dev_priv);
> >
> > void i915_gem_detect_bit_6_swizzle(struct drm_i915_private *dev_priv);
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 73987014a7bd..019ea7cb13b5 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2715,6 +2715,11 @@ static void reset_request(struct drm_i915_gem_request 
> >*request)
> > memset(vaddr + head, 0, request->postfix - head);
> > }
> >
> >+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv)
> >+{
> >+i915_gem_revoke_fences(dev_priv);
> >+}
> >+
> > static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> > {
> > struct drm_i915_gem_request *request;
> >@@ -2780,7 +2785,7 @@ static void i915_gem_reset_engine(struct 
> >intel_engine_cs *engine)
> > spin_unlock_irqrestore(>timeline->lock, flags);
> > }
> >
> >-void i915_gem_reset(struct drm_i915_private *dev_priv)
> >+void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
> > {
> > struct intel_engine_cs *engine;
> > enum intel_engine_id id;
> >diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
> >b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> >index 67835d7b39c7..447abb1105ab 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> >@@ -358,6 +358,30 @@ i915_vma_get_fence(struct i915_vma *vma)
> > }
> >
> > /**
> >+ * i915_gem_revoke_fences - revoke fence state
> >+ * @dev_priv: i915 device private
> >+ *
> >+ * Clears the hw fence state and removes all GTT mmappings via the fence. 
> >This
> 
> The function doesn't clear the hw fence state - reset does that, no?

The first version did, then realised all that was required was zapping
the mmap.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH v2] drm/atomic: Fix outdated comment.

[Daniel Vetter]

On Wed, Jan 04, 2017 at 12:34:00PM +0100, Maarten Lankhorst wrote:
> Op 04-01-17 om 12:28 schreef Daniel Vetter:
> > On Wed, Jan 04, 2017 at 11:22:54AM +, Chris Wilson wrote:
> >> On Wed, Jan 04, 2017 at 12:15:55PM +0100, Maarten Lankhorst wrote:
> >>> Op 15-12-16 om 16:19 schreef Daniel Vetter:
>  On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
> > drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
> > different from commit.
> >
> > Signed-off-by: Maarten Lankhorst 
>  I think it'd be good to update the kerneldoc for the atomic_commit
>  callback to mention that drivers should grab their own references using
>  drm_atomic_state_get() when they need it.
> 
>  Applied this one meanwhile, thanks.
> >>> --->8---
> >>> Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> >>> adds reference counting to atomic state, but didn't update the comments
> >>> in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more.
> >>>
> >>> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> >>> Cc:  # v4.10-rc1+
> >>> Cc: Chris Wilson 
> >>> Signed-off-by: Maarten Lankhorst 
> >>> ---
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index 681d5f97639d..6492546476b4 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -1599,10 +1599,9 @@ EXPORT_SYMBOL(drm_atomic_check_only);
> >>>   * more locks but encountered a deadlock. The caller must then do the 
> >>> usual w/w
> >>>   * backoff dance and restart. All other errors are fatal.
> >>>   *
> >>> - * Also note that on successful execution ownership of @state is 
> >>> transferred
> >>> - * from the caller of this function to the function itself. The caller 
> >>> must not
> >>> - * free or in any other way access @state. If the function fails then 
> >>> the caller
> >>> - * must clean up @state itself.
> >>> + * In earlier versions of the atomic api, the caller was handing its 
> >>> reference
> >>> + * of @state over to this function on success. This is no longer the 
> >>> case, and
> >>> + * callers should always call drm_atomic_state_put().
> >>>   *
> >>>   * Returns:
> >>>   * 0 on success, negative error code on failure.
> >>> @@ -1630,10 +1629,9 @@ EXPORT_SYMBOL(drm_atomic_commit);
> >>>   * more locks but encountered a deadlock. The caller must then do the 
> >>> usual w/w
> >>>   * backoff dance and restart. All other errors are fatal.
> >>>   *
> >>> - * Also note that on successful execution ownership of @state is 
> >>> transferred
> >>> - * from the caller of this function to the function itself. The caller 
> >>> must not
> >>> - * free or in any other way access @state. If the function fails then 
> >>> the caller
> >>> - * must clean up @state itself.
> >>> + * In earlier versions of the atomic api, the caller was handing its 
> >>> reference
> >>> + * of @state over to this function on success. This is no longer the 
> >>> case, and
> >>> + * callers should always call drm_atomic_state_put().
> >> Reviewed-by: Chris Wilson 
> >>
> >> But do we really want the confusion of mentioning what the api doesn't do
> >> any more?
> > Agreed, kerneldoc should state what is (and why), maybe with a FIXME if it
> > only makes sense with some hystorical context and what should be done
> > instead. git blame is for figuring out what was.
> >
> > Maarten, can you pls respin?
> > -Daniel
> 
> 8<---
> Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> adds reference counting to atomic state, but didn't update the comments
> in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more.
> 
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc:  # v4.10-rc1+
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 
> Signed-off-by: Maarten Lankhorst 

Applied to drm-misc, thanks.
-Daniel

> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 681d5f97639d..672f1de84d6c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1599,10 +1599,8 @@ EXPORT_SYMBOL(drm_atomic_check_only);
>   * more locks but encountered a deadlock. The caller must then do the usual 
> w/w
>   * backoff dance and restart. All other errors are fatal.
>   *
> - * Also note that on successful execution ownership of @state is transferred
> - * from the caller of this function to the function itself. The caller must 
> not
> - * free or in any other way access @state. If the function fails then the 
> caller
> - * must clean up @state itself.
> + * This function will take its own reference on @state.
> + * Callers 

Re: [Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

[Tvrtko Ursulin]

On 04/01/2017 14:51, Chris Wilson wrote:

During the fence registers are clobbered by a GPU reset. Hence if


During the reset I suppose, although it would sound still a bit 
redundant. So maybe "Since GPU reset clobbers the fence registers, if 
there is concurrent..."



there is concurrent user access to a fenced region via a GTT mmaping,
the access will not be fenced during the reset (until we restore the
fences afterwards). In order to prevent invalid access during the reset,
before we clobber the fences we must invalidate the GTT mmapings. Access
to the mmap will then be forced to fault the page, and in handling the
fault, i915_gem_fault() will take the struct_mutex and wait upon the
reset to complete.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99274
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c   |  3 ++-
 drivers/gpu/drm/i915/i915_drv.h   |  4 +++-
 drivers/gpu/drm/i915/i915_gem.c   |  7 ++-
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 24 
 4 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72e29fcb1638..39463fcab593 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1780,6 +1780,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
error->reset_count++;

pr_notice("drm/i915: Resetting chip after gpu hang\n");
+   i915_gem_reset_prepare(dev_priv);

disable_engines_irq(dev_priv);
ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
@@ -1793,7 +1794,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
goto error;
}

-   i915_gem_reset(dev_priv);
+   i915_gem_reset_finish(dev_priv);
intel_overlay_reset(dev_priv);

/* Ok, now get things going again... */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c035b6576efa..f16986cfa127 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3355,7 +3355,8 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return READ_ONCE(error->reset_count);
 }

-void i915_gem_reset(struct drm_i915_private *dev_priv);
+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
+void i915_gem_reset_finish(struct drm_i915_private *dev_priv);
 void i915_gem_set_wedged(struct drm_i915_private *dev_priv);

 void i915_gem_clflush_init(struct drm_i915_private *i915);
@@ -3426,6 +3427,7 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
 int __must_check i915_vma_get_fence(struct i915_vma *vma);
 int __must_check i915_vma_put_fence(struct i915_vma *vma);

+void i915_gem_revoke_fences(struct drm_i915_private *dev_priv);
 void i915_gem_restore_fences(struct drm_i915_private *dev_priv);

 void i915_gem_detect_bit_6_swizzle(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73987014a7bd..019ea7cb13b5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2715,6 +2715,11 @@ static void reset_request(struct drm_i915_gem_request 
*request)
memset(vaddr + head, 0, request->postfix - head);
 }

+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv)
+{
+   i915_gem_revoke_fences(dev_priv);
+}
+
 static void i915_gem_reset_engine(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *request;
@@ -2780,7 +2785,7 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
spin_unlock_irqrestore(>timeline->lock, flags);
 }

-void i915_gem_reset(struct drm_i915_private *dev_priv)
+void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index 67835d7b39c7..447abb1105ab 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -358,6 +358,30 @@ i915_vma_get_fence(struct i915_vma *vma)
 }

 /**
+ * i915_gem_revoke_fences - revoke fence state
+ * @dev_priv: i915 device private
+ *
+ * Clears the hw fence state and removes all GTT mmappings via the fence. This


The function doesn't clear the hw fence state - reset does that, no?


+ * forces any user of the fence to reacquire that fence before continuing.
+ * One use is during GPU reset where the fence register is lost and we need to
+ * revoke concurrent user access via GTT mmaps until the hardware has been
+ * reset..
+ */
+void i915_gem_revoke_fences(struct drm_i915_private *dev_priv)
+{
+   int i;
+
+   lockdep_assert_held(_priv->drm.struct_mutex);
+
+   for (i = 0; i < dev_priv->num_fence_regs; i++) {
+   struct drm_i915_fence_reg *fence = _priv->fence_regs[i];
+
+   if (fence->vma)
+   

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] dma-fence: Clear fence->status during dma_fence_init()

[Patchwork]

== Series Details ==

Series: series starting with [1/3] dma-fence: Clear fence->status during 
dma_fence_init()
URL   : https://patchwork.freedesktop.org/series/17493/
State : warning

== Summary ==

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

Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> DMESG-WARN (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-bsw-n3050)

fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:206  dwarn:1   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:214  dwarn:1   dfail:0   fail:0   skip:31 

3ff9912451fd6840732ac0184f0561c9e6c4107f drm-tip: 2017y-01m-04d-11h-22m-41s UTC 
integration manifest
f893cc6 dma-fence: Introduce drm_fence_set_error() helper
388ab7e dma-fence: Wrap querying the fence->status
5426a73 dma-fence: Clear fence->status during dma_fence_init()

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

[Arkadiusz Hiler]

On Tue, Jan 03, 2017 at 06:59:11PM +, Srivatsa, Anusha wrote:
> 
> 
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> >Srivatsa, Anusha
> >Sent: Monday, January 2, 2017 4:09 PM
> >To: Wajdeczko, Michal 
> >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter 
> >Antoine
> >
> >Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support
> >
> >
> >
> >>-Original Message-
> >>From: Wajdeczko, Michal
> >>Sent: Tuesday, December 27, 2016 9:51 AM
> >>To: Srivatsa, Anusha 
> >>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter
> >>Antoine 
> >>Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading
> >>support
> >>
> >>On Thu, Dec 22, 2016 at 03:12:19PM -0800, Anusha Srivatsa wrote:
> >>> The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is
> >>> used for both cases.
> >>>
> >>> HuC loading needs to be before GuC loading. The WOPCM setting must be
> >>> done early before loading any of them.
> >>>
> >>> v2: rebased on-top of drm-intel-nightly.
> >>> removed if(HAS_GUC()) before the guc call. (D.Gordon)
> >>> update huc_version number of format.
> >>> v3: rebased to drm-intel-nightly, changed the file name format to
> >>> match the one in the huc package.
> >>> Changed dev->dev_private to to_i915()
> >>> v4: moved function back to where it was.
> >>> change wait_for_atomic to wait_for.
> >>> v5: rebased + comment changes.
> >>> v7: rebased.
> >>> v8: rebased.
> >>> v9: rebased. Changed the year in the copyright message to reflect the
> >>> right year.Correct the comments,remove the unwanted WARN message,
> >>> replace drm_gem_object_unreference() with i915_gem_object_put().Make
> >>> the prototypes in intel_huc.h non-extern.
> >>> v10: rebased. Update the file construction done by HuC. It is similar
> >>> to GuC.Adopted the approach used in-
> >>> https://patchwork.freedesktop.org/patch/104355/ 
> >>> v11: Fix warnings remove old declaration
> >>> v12: Change dev to dev_priv in macro definition.
> >>> Corrected comments.
> >>> v13: rebased.
> >>> v14: rebased on top of drm-tip
> >>> v15: rebased. Updated functions intel_huc_load(),intel_huc_init() and
> >>> intel_uc_fw_fetch() to accept dev_priv instead of dev. Moved contents
> >>> of intel_huc.h to intel_uc.h
> >>> v16: change SKL_FW_ to SKL_HUC_FW_. Add intel_ prefix to
> >>guc_wopcm_size().
> >>> Remove unwanted checks in intel_uc.h. Rename huc_fw in struct
> >>> intel_huc to simply fw to avoid redundency.
> >>> v17: rebased.
> >>>
> >>> Cc: Tvrtko Ursulin 
> >>> Tested-by: Xiang Haihao 
> >>> Signed-off-by: Anusha Srivatsa 
> >>> Signed-off-by: Alex Dai 
> >>> Signed-off-by: Peter Antoine 
> >>> ---
> >>>  drivers/gpu/drm/i915/Makefile   |   1 +
> >>>  drivers/gpu/drm/i915/i915_drv.c |   4 +-
> >>>  drivers/gpu/drm/i915/i915_drv.h |   3 +-
> >>>  drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
> >>>  drivers/gpu/drm/i915/intel_guc_loader.c |  11 +-
> >>> drivers/gpu/drm/i915/intel_huc_loader.c | 263
> >>
> >>>  drivers/gpu/drm/i915/intel_uc.h |  18 +++
> >>>  7 files changed, 296 insertions(+), 7 deletions(-)  create mode
> >>> 100644 drivers/gpu/drm/i915/intel_huc_loader.c
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/Makefile
> >>> b/drivers/gpu/drm/i915/Makefile index 5196509..45ae124 100644
> >>> --- a/drivers/gpu/drm/i915/Makefile
> >>> +++ b/drivers/gpu/drm/i915/Makefile
> >>> @@ -57,6 +57,7 @@ i915-y += i915_cmd_parser.o \  # general-purpose
> >>> microcontroller (GuC) support  i915-y += intel_uc.o \
> >>> intel_guc_loader.o \
> >>> +   intel_huc_loader.o \
> >>> i915_guc_submission.o
> >>>
> >>>  # autogenerated null render state
> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >>> b/drivers/gpu/drm/i915/i915_drv.c index 6428588..85a47c2 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.c
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >>> @@ -600,6 +600,7 @@ static int i915_load_modeset_init(struct
> >>> drm_device
> >>*dev)
> >>>   if (ret)
> >>>   goto cleanup_irq;
> >>>
> >>> + intel_huc_init(dev_priv);
> >>>   intel_guc_init(dev_priv);
> >>>
> >>>   ret = i915_gem_init(dev_priv);
> >>> @@ -627,6 +628,7 @@ static int i915_load_modeset_init(struct
> >>> drm_device
> >>*dev)
> >>>   DRM_ERROR("failed to idle hardware; continuing to unload!\n");
> >>>   i915_gem_fini(dev_priv);
> >>>  cleanup_irq:
> >>> + intel_huc_fini(dev);
> >>>   intel_guc_fini(dev_priv);
> >>>   drm_irq_uninstall(dev);
> >>>   intel_teardown_gmbus(dev_priv);
> >>> @@ -1313,7 +1315,7 @@ void i915_driver_unload(struct drm_device *dev)
> >>>
> >>>   /* Flush any outstanding unpin_work. */
> 

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Chris Wilson]

On Wed, Jan 04, 2017 at 05:06:46PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote:
> > From: Chris Wilson 
> > 
> > With atomic plane states we are able to track an allocation right from
> > preparation, during use and through to the final free after being
> > swapped out for a new plane. We can couple the VMA we pin for the
> > framebuffer (and its rotation) to this lifetime and avoid all the clumsy
> > lookups in between.
> > 
> > v2: Remove residual vma on plane cleanup (Chris)
> > v3: Add a description for the vma destruction in
> > intel_plane_destroy_state (Maarten)
> > 
> > Signed-off-by: Chris Wilson 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h   |  16 +---
> >  drivers/gpu/drm/i915/intel_atomic_plane.c |  20 +
> >  drivers/gpu/drm/i915/intel_display.c  | 129 
> > +++---
> >  drivers/gpu/drm/i915/intel_drv.h  |   9 ++-
> >  drivers/gpu/drm/i915/intel_fbc.c  |  52 +---
> >  drivers/gpu/drm/i915/intel_fbdev.c|   4 +-
> >  drivers/gpu/drm/i915/intel_sprite.c   |   8 +-
> >  7 files changed, 103 insertions(+), 135 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 22d3f610212c..5369f5f9ce3a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1079,6 +1079,8 @@ struct intel_fbc {
> > struct work_struct underrun_work;
> >  
> > struct intel_fbc_state_cache {
> > +   struct i915_vma *vma;
> > +
> > struct {
> > unsigned int mode_flags;
> > uint32_t hsw_bdw_pixel_rate;
> > @@ -1092,15 +1094,14 @@ struct intel_fbc {
> > } plane;
> >  
> > struct {
> > -   u64 ilk_ggtt_offset;
> > const struct drm_format_info *format;
> > unsigned int stride;
> > -   int fence_reg;
> > -   unsigned int tiling_mode;
> > } fb;
> > } state_cache;
> >  
> > struct intel_fbc_reg_params {
> > +   struct i915_vma *vma;
> > +
> > struct {
> > enum pipe pipe;
> > enum plane plane;
> > @@ -1108,10 +1109,8 @@ struct intel_fbc {
> > } crtc;
> >  
> > struct {
> > -   u64 ggtt_offset;
> > const struct drm_format_info *format;
> > unsigned int stride;
> > -   int fence_reg;
> > } fb;
> >  
> > int cfb_size;
> > @@ -3406,13 +3405,6 @@ i915_gem_object_to_ggtt(struct drm_i915_gem_object 
> > *obj,
> > return i915_gem_obj_to_vma(obj, _i915(obj->base.dev)->ggtt.base, 
> > view);
> >  }
> >  
> > -static inline unsigned long
> > -i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
> > -   const struct i915_ggtt_view *view)
> > -{
> > -   return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
> > -}
> > -
> >  /* i915_gem_fence_reg.c */
> >  int __must_check i915_vma_get_fence(struct i915_vma *vma);
> >  int __must_check i915_vma_put_fence(struct i915_vma *vma);
> > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > index 4612ffd555a7..41fd94e62d3c 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > @@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
> >  
> > __drm_atomic_helper_plane_duplicate_state(plane, state);
> >  
> > +   intel_state->vma = NULL;
> 
> Shouldn't we be doing vma_get() instead?

I went with NULL (dropping the copy) for simplicity. Before the plane
can be used it must be prepared, so vma will always be set before
commiting, and using NULL avoided having the reference counting dance.
It also allowed detection of when we didn't prepare the plane as
required.
-Chris

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

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()

[Daniel Vetter]

On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote:
> As the fence->status is an optional field that may be set before
> dma_fence_signal() is called to convey that the fence completed with an
> error, we have to ensure that it is always set to zero on initialisation
> so that the typical use (i.e. unset) always flags a successful completion.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Tvrtko Ursulin 

Yeah, this looks all pretty. On the series:

Reviewed-by: Daniel Vetter 

I'll defer to Gustavo for another pass over it and merging it to drm-misc.
-Daniel

> ---
>  drivers/dma-buf/dma-fence.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 3444f293ad4a..9130f790ebf3 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
> dma_fence_ops *ops,
>   fence->context = context;
>   fence->seqno = seqno;
>   fence->flags = 0UL;
> + fence->status = 0;
>  
>   trace_dma_fence_init(fence);
>  }
> -- 
> 2.11.0
> 
> ___
> 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 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

[Arkadiusz Hiler]

On Wed, Jan 04, 2017 at 06:55:49AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> HuC firmware css header has almost exactly same definition as GuC
> firmware except for the sw_version. Also, add a new member fw_type
> into intel_uc_fw to indicate what kind of fw it is. So, the loader
> will pull right sw_version from header.
> 
> v2: rebased on-top of drm-intel-nightly
> v3: rebased on-top of drm-intel-nightly (again).
> v4: rebased + spaces.
> v7: rebased.
> v8: rebased.
> v9: rebased. Rename device_id to guc_branch_client_version,
> make guc_sw_version a union. . Put UC_FW_TYPE_GUC
> and UC_FW_TYPE_HUC into an enum.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip.
> v13: rebased.Update dev to dev_priv in intel_uc_fw_fetch
> v14: rebased. Add INTEL_ prefix to an enum. Add fw_type declaration
> from patch 1.Combine two different unions for huc and guc version,
> reserved etc into one union with two structs.
> v15: rebased.
> v16: rebased. Change fw_type to enum.
> 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/intel_guc_fwif.h   | 23 ++
>  drivers/gpu/drm/i915/intel_guc_loader.c | 41 
> ++---
>  drivers/gpu/drm/i915/intel_uc.h |  6 +
>  3 files changed, 53 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index 3202b32..ed1ab40 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -145,7 +145,7 @@
>   * The GuC firmware layout looks like this:
>   *
>   * +---+
> - * |guc_css_header |
> + * | uc_css_header |
>   * |   |
>   * | contains major/minor version  |
>   * +---+
> @@ -172,9 +172,16 @@
>   * 3. Length info of each component can be found in header, in dwords.
>   * 4. Modulus and exponent key are not required by driver. They may not 
> appear
>   *in fw. So driver will load a truncated firmware in this case.
> + *
> + * HuC firmware layout is same as GuC firmware.
> + *
> + * HuC firmware css header is different. However, the only difference is 
> where
> + * the version information is saved. The uc_css_header is unified to support
> + * both. Driver should get HuC version from uc_css_header.huc_sw_version, 
> while
> + * uc_css_header.guc_sw_version for GuC.
>   */
>  
> -struct guc_css_header {
> +struct uc_css_header {
>   uint32_t module_type;
>   /* header_size includes all non-uCode bits, including css_header, rsa
>* key, modulus key and exponent data. */
> @@ -205,8 +212,16 @@ struct guc_css_header {
>  
>   char username[8];
>   char buildnumber[12];
> - uint32_t device_id;
> - uint32_t guc_sw_version;
> + union {
> + struct {
> + uint32_t branch_client_version;
> + uint32_t sw_version;
> + } guc;
> + struct {
> + uint32_t sw_version;
> + uint32_t reserved;
> + } huc;
> + };
>   uint32_t prod_preprod_fw;
>   uint32_t reserved[12];
>   uint32_t header_info;
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index a55cfa7..68af7ae 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -593,7 +593,7 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
>   struct pci_dev *pdev = dev_priv->drm.pdev;
>   struct drm_i915_gem_object *obj;
>   const struct firmware *fw = NULL;
> - struct guc_css_header *css;
> + struct uc_css_header *css;
>   size_t size;
>   int err;
>  
> @@ -610,19 +610,19 @@ void intel_uc_fw_fetch(struct drm_i915_private 
> *dev_priv,
>   uc_fw->path, fw);
>  
>   /* Check the size of the blob before examining buffer contents */
> - if (fw->size < sizeof(struct guc_css_header)) {
> + if (fw->size < sizeof(struct uc_css_header)) {
>   DRM_NOTE("Firmware header is missing\n");
>   goto fail;
>   }
>  
> - css = (struct guc_css_header *)fw->data;
> + css = (struct uc_css_header *)fw->data;
>  
>   /* Firmware bits always start from header */
>   uc_fw->header_offset = 0;
>   uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
>   css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
>  
> - if (uc_fw->header_size != sizeof(struct guc_css_header)) {
> + if (uc_fw->header_size != sizeof(struct uc_css_header)) {
>   DRM_NOTE("CSS header definition mismatch\n");
>   goto fail;
>  

Re: [Intel-gfx] [PATCH] drm/i915: Track pinned vma in intel_plane_state

[Ville Syrjälä]

On Wed, Jan 04, 2017 at 02:31:26PM +0100, Maarten Lankhorst wrote:
> From: Chris Wilson 
> 
> With atomic plane states we are able to track an allocation right from
> preparation, during use and through to the final free after being
> swapped out for a new plane. We can couple the VMA we pin for the
> framebuffer (and its rotation) to this lifetime and avoid all the clumsy
> lookups in between.
> 
> v2: Remove residual vma on plane cleanup (Chris)
> v3: Add a description for the vma destruction in
> intel_plane_destroy_state (Maarten)
> 
> Signed-off-by: Chris Wilson 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  16 +---
>  drivers/gpu/drm/i915/intel_atomic_plane.c |  20 +
>  drivers/gpu/drm/i915/intel_display.c  | 129 
> +++---
>  drivers/gpu/drm/i915/intel_drv.h  |   9 ++-
>  drivers/gpu/drm/i915/intel_fbc.c  |  52 +---
>  drivers/gpu/drm/i915/intel_fbdev.c|   4 +-
>  drivers/gpu/drm/i915/intel_sprite.c   |   8 +-
>  7 files changed, 103 insertions(+), 135 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 22d3f610212c..5369f5f9ce3a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1079,6 +1079,8 @@ struct intel_fbc {
>   struct work_struct underrun_work;
>  
>   struct intel_fbc_state_cache {
> + struct i915_vma *vma;
> +
>   struct {
>   unsigned int mode_flags;
>   uint32_t hsw_bdw_pixel_rate;
> @@ -1092,15 +1094,14 @@ struct intel_fbc {
>   } plane;
>  
>   struct {
> - u64 ilk_ggtt_offset;
>   const struct drm_format_info *format;
>   unsigned int stride;
> - int fence_reg;
> - unsigned int tiling_mode;
>   } fb;
>   } state_cache;
>  
>   struct intel_fbc_reg_params {
> + struct i915_vma *vma;
> +
>   struct {
>   enum pipe pipe;
>   enum plane plane;
> @@ -1108,10 +1109,8 @@ struct intel_fbc {
>   } crtc;
>  
>   struct {
> - u64 ggtt_offset;
>   const struct drm_format_info *format;
>   unsigned int stride;
> - int fence_reg;
>   } fb;
>  
>   int cfb_size;
> @@ -3406,13 +3405,6 @@ i915_gem_object_to_ggtt(struct drm_i915_gem_object 
> *obj,
>   return i915_gem_obj_to_vma(obj, _i915(obj->base.dev)->ggtt.base, 
> view);
>  }
>  
> -static inline unsigned long
> -i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
> - const struct i915_ggtt_view *view)
> -{
> - return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
> -}
> -
>  /* i915_gem_fence_reg.c */
>  int __must_check i915_vma_get_fence(struct i915_vma *vma);
>  int __must_check i915_vma_put_fence(struct i915_vma *vma);
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 4612ffd555a7..41fd94e62d3c 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
>  
>   __drm_atomic_helper_plane_duplicate_state(plane, state);
>  
> + intel_state->vma = NULL;

Shouldn't we be doing vma_get() instead?

> +
>   return state;
>  }
>  

-- 
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 7/8] drm/i915/huc: Support HuC authentication

[Anusha Srivatsa]

From: Peter Antoine 

The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.

v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
and place the prototype in intel_guc.h,correct the comments.
v10: rebased.
v11: rebased.
v12: rebased on top of drm-tip
v13: rebased. Moved intel_guc_auth_huc from i915_guc_submission.c
to intel_uc.c.Update dev to dev_priv in intel_guc_auth_huc().
Renamed HOST2GUC_ACTION_AUTHENTICATE_HUC TO INTEL_GUC_ACTION_
AUTHENTICATE_HUC
v14: rebased.
v15: rebased. Add newline on DRM_ERRORs that already dont have one.
v16: rebased. Replace wait_for with intel_wait_for_register() since
the latter employs sleep optimisations for quick responses- as pointed
out by Chris Wilson.

Cc: Chris Wilson 
Cc: Arkadiusz Hiler 
Cc: Michal Wajdeczko 
Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/intel_guc_fwif.h   |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c |  2 +
 drivers/gpu/drm/i915/intel_uc.c | 70 -
 drivers/gpu/drm/i915/intel_uc.h |  1 +
 4 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index ed1ab40..ce4e05e 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -506,6 +506,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
+   INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
INTEL_GUC_ACTION_LIMIT
 };
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index ed57ab3..0508054 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -529,6 +529,8 @@ int intel_guc_setup(struct drm_i915_private *dev_priv)
intel_uc_fw_status_repr(guc_fw->fetch_status),
intel_uc_fw_status_repr(guc_fw->load_status));
 
+   intel_guc_auth_huc(dev_priv);
+
if (i915.enable_guc_submission) {
if (i915.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index c6be352..d1a4d79 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -46,7 +46,7 @@ static bool intel_guc_recv(struct intel_guc *guc, u32 *status)
 int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   u32 status;
+   u32 status = 0;
int i;
int ret;
 
@@ -71,7 +71,11 @@ int intel_guc_send(struct intel_guc *guc, const u32 *action, 
u32 len)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No inte_guc_send command should ever take longer than 10ms.
 */
-   ret = wait_for_us(intel_guc_recv(guc, ), 10);
+   ret = intel_wait_for_register(dev_priv,
+   HUC_STATUS2,
+   HUC_FW_VERIFIED,
+   HUC_FW_VERIFIED,
+   50);
if (ret)
ret = wait_for(intel_guc_recv(guc, ), 10);
if (status != INTEL_GUC_STATUS_SUCCESS) {
@@ -140,3 +144,65 @@ int intel_guc_log_control(struct intel_guc *guc, u32 
control_val)
 
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
+
+/**
+ * intel_guc_auth_huc() - authenticate ucode
+ * @dev_priv: the drm_i915_device
+ *
+ * Triggers a HuC fw authentication request to the GuC via intel_guc_action_
+ * authenticate_huc interface.
+ * interface.
+ */
+void intel_guc_auth_huc(struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+   struct intel_huc *huc = _priv->huc;
+   struct i915_vma *vma;
+   int ret;
+   u32 data[2];
+
+   /* Bypass the case where there is no HuC firmware */
+   if (huc->fw.fetch_status == INTEL_UC_FIRMWARE_NONE ||
+   huc->fw.load_status == INTEL_UC_FIRMWARE_NONE)
+   return;
+
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate\n");
+   return;
+   }
+
+   if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: fw wasn't loaded. 

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

[Anusha Srivatsa]

From: Peter Antoine 

This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after it is
loaded and is not usable until it is verified.

v2: removed the forewakes as the registers are already force-woken.
 (T.Ursulin)
v4: rebased.
v5: rebased on top of drm-tip.
v6: rebased. Removed any reference to intel_huc.h
v7: rebased. Rename I915_PARAM_HAS_HUC to I915_PARAM_HUC_STATUS.
Remove intel_is_huc_valid() since it is used only in one place.
Put the case of I915_PARAM_HAS_HUC() in the right place.
v8: rebased. Add a comment to specify that I915_READ(reg)
does not read garbage value. The register HUC_STATUS2 is force
woken and no rpm is needed.
v9: rebased.

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Peter Antoine 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_drv.c | 7 +++
 drivers/gpu/drm/i915/intel_huc_loader.c | 1 -
 include/uapi/drm/i915_drm.h | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c9f71e0..723442c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,7 @@
 #include "i915_trace.h"
 #include "i915_vgpu.h"
 #include "intel_drv.h"
+#include "intel_uc.h"
 
 static struct drm_driver driver;
 
@@ -315,6 +316,12 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
case I915_PARAM_MIN_EU_IN_POOL:
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
+   case I915_PARAM_HUC_STATUS:
+   /* The register is already force-woken. We dont need
+* any rpm here
+*/
+   value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+   break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
 * earlier versions as 0, in effect their value is undefined as
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 57fc48b..af75d1d 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -281,4 +281,3 @@ void intel_huc_fini(struct drm_device *dev)
 
huc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE;
 }
-
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index da32c2f..57093b4 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -395,6 +395,7 @@ typedef struct drm_i915_irq_wait {
  * priorities and the driver will attempt to execute batches in priority order.
  */
 #define I915_PARAM_HAS_SCHEDULER41
+#define I915_PARAM_HUC_STATUS   42
 
 typedef struct drm_i915_getparam {
__s32 param;
-- 
2.7.4

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

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

[Anusha Srivatsa]

This patch adds the HuC Loading for the BXT by using
the updated file construction.

Version 1.7 of the HuC firmware.

v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename BXT_FW_MAJOR to BXT_HUC_FW_
v6: rebased.
v7: rebased.

Cc: Tvrtko Ursulin 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 0106a53..95993c51 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -40,6 +40,10 @@
  * Note that HuC firmware loading must be done before GuC loading.
  */
 
+#define BXT_HUC_FW_MAJOR 01
+#define BXT_HUC_FW_MINOR 07
+#define BXT_BLD_NUM 1398
+
 #define SKL_HUC_FW_MAJOR 01
 #define SKL_HUC_FW_MINOR 07
 #define SKL_BLD_NUM 1398
@@ -52,6 +56,9 @@
SKL_HUC_FW_MINOR, SKL_BLD_NUM)
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 
+#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
+   BXT_HUC_FW_MINOR, BXT_BLD_NUM)
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
 /**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm device
@@ -153,6 +160,10 @@ void intel_huc_init(struct drm_i915_private *dev_priv)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = SKL_HUC_FW_MAJOR;
huc_fw->minor_ver_wanted = SKL_HUC_FW_MINOR;
+   } else if (IS_BROXTON(dev_priv)) {
+   fw_path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = BXT_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = BXT_HUC_FW_MINOR;
}
 
huc_fw->path = fw_path;
-- 
2.7.4

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

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

[Anusha Srivatsa]

From: Peter Antoine 

Add debugfs entry for HuC loading status check.

v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
v11: rebased on top of drm-tip
v12: rebased.
v13: rebased.
v14: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 19fe38e..d99c406 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2325,6 +2325,36 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
 }
 
+static int i915_huc_load_status_info(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+
+   if (!HAS_HUC_UCODE(dev_priv))
+   return 0;
+
+   seq_puts(m, "HuC firmware status:\n");
+   seq_printf(m, "\tpath: %s\n", huc_fw->path);
+   seq_printf(m, "\tfetch: %s\n",
+   intel_uc_fw_status_repr(huc_fw->fetch_status));
+   seq_printf(m, "\tload: %s\n",
+   intel_uc_fw_status_repr(huc_fw->load_status));
+   seq_printf(m, "\tversion wanted: %d.%d\n",
+   huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted);
+   seq_printf(m, "\tversion found: %d.%d\n",
+   huc_fw->major_ver_found, huc_fw->minor_ver_found);
+   seq_printf(m, "\theader: offset is %d; size = %d\n",
+   huc_fw->header_offset, huc_fw->header_size);
+   seq_printf(m, "\tuCode: offset is %d; size = %d\n",
+   huc_fw->ucode_offset, huc_fw->ucode_size);
+   seq_printf(m, "\tRSA: offset is %d; size = %d\n",
+   huc_fw->rsa_offset, huc_fw->rsa_size);
+
+   seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
+
+   return 0;
+}
+
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4553,6 +4583,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
-- 
2.7.4

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

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

[Anusha Srivatsa]

This patch adds the support to load HuC on KBL
Version 2.0

v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_
v6: rebased. Remove old checks.
v7: rebased.

Cc: Tvrtko Ursulin 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 95993c51..57fc48b 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -48,6 +48,10 @@
 #define SKL_HUC_FW_MINOR 07
 #define SKL_BLD_NUM 1398
 
+#define KBL_HUC_FW_MAJOR 02
+#define KBL_HUC_FW_MINOR 00
+#define KBL_BLD_NUM 1810
+
 #define HUC_FW_PATH(platform, major, minor, bld_num) \
"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
__stringify(minor) "_" __stringify(bld_num) ".bin"
@@ -59,6 +63,11 @@ MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 #define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
BXT_HUC_FW_MINOR, BXT_BLD_NUM)
 MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+
+#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_HUC_FW_MAJOR, \
+   KBL_HUC_FW_MINOR, KBL_BLD_NUM)
+MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
+
 /**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm device
@@ -164,6 +173,10 @@ void intel_huc_init(struct drm_i915_private *dev_priv)
fw_path = I915_BXT_HUC_UCODE;
huc_fw->major_ver_wanted = BXT_HUC_FW_MAJOR;
huc_fw->minor_ver_wanted = BXT_HUC_FW_MINOR;
+   } else if (IS_KABYLAKE(dev_priv)) {
+   fw_path = I915_KBL_HUC_UCODE;
+   huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR;
}
 
huc_fw->path = fw_path;
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

[Anusha Srivatsa]

The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.

HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.

v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_private to to_i915()
v4: moved function back to where it was.
change wait_for_atomic to wait_for.
v5: rebased + comment changes.
v7: rebased.
v8: rebased.
v9: rebased. Changed the year in the copyright message to reflect
the right year.Correct the comments,remove the unwanted WARN message,
replace drm_gem_object_unreference() with i915_gem_object_put().Make the
prototypes in intel_huc.h non-extern.
v10: rebased. Update the file construction done by HuC. It is similar to
GuC.Adopted the approach used in-
https://patchwork.freedesktop.org/patch/104355/ 
v11: Fix warnings remove old declaration
v12: Change dev to dev_priv in macro definition.
Corrected comments.
v13: rebased.
v14: rebased on top of drm-tip
v15: rebased. Updated functions intel_huc_load(),intel_huc_init() and
intel_uc_fw_fetch() to accept dev_priv instead of dev. Moved contents
of intel_huc.h to intel_uc.h
v16: change SKL_FW_ to SKL_HUC_FW_. Add intel_ prefix to guc_wopcm_size().
Remove unwanted checks in intel_uc.h. Rename huc_fw in struct intel_huc to
simply fw to avoid redundency.
v17: rebased.
v18: rebased. Correct comments.

Cc: Arkadiusz Hiler 
Cc: Michal Wajdeczko 
Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.h |   3 +-
 drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
 drivers/gpu/drm/i915/intel_guc_loader.c |  11 +-
 drivers/gpu/drm/i915/intel_huc_loader.c | 260 
 drivers/gpu/drm/i915/intel_uc.h |  19 ++-
 7 files changed, 293 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5196509..45ae124 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -57,6 +57,7 @@ i915-y += i915_cmd_parser.o \
 # general-purpose microcontroller (GuC) support
 i915-y += intel_uc.o \
  intel_guc_loader.o \
+ intel_huc_loader.o \
  i915_guc_submission.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2c020ea..c9f71e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -599,6 +599,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
 
+   intel_huc_init(dev_priv);
intel_guc_init(dev_priv);
 
ret = i915_gem_init(dev_priv);
@@ -626,6 +627,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
 cleanup_irq:
+   intel_huc_fini(dev);
intel_guc_fini(dev_priv);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev_priv);
@@ -1312,7 +1314,7 @@ void i915_driver_unload(struct drm_device *dev)
 
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
-
+   intel_huc_fini(dev);
intel_guc_fini(dev_priv);
i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0ea63d6..854e2bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2080,6 +2080,7 @@ struct drm_i915_private {
 
struct intel_gvt *gvt;
 
+   struct intel_huc huc;
struct intel_guc guc;
 
struct intel_csr csr;
@@ -2854,7 +2855,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
 #define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-
+#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 5e638fc..f9829f6 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
 #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
 #define 

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

[Anusha Srivatsa]

From: Peter Antoine 

HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.

v2: rebased on-top of drm-intel-nightly
v3: rebased on-top of drm-intel-nightly (again).
v4: rebased + spaces.
v7: rebased.
v8: rebased.
v9: rebased. Rename device_id to guc_branch_client_version,
make guc_sw_version a union. . Put UC_FW_TYPE_GUC
and UC_FW_TYPE_HUC into an enum.
v10: rebased.
v11: rebased.
v12: rebased on top of drm-tip.
v13: rebased.Update dev to dev_priv in intel_uc_fw_fetch
v14: rebased. Add INTEL_ prefix to an enum. Add fw_type declaration
from patch 1.Combine two different unions for huc and guc version,
reserved etc into one union with two structs.
v15: rebased.
v16: rebased. Change fw_type to enum.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/intel_guc_fwif.h   | 23 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 41 ++---
 drivers/gpu/drm/i915/intel_uc.h |  6 +
 3 files changed, 53 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 3202b32..ed1ab40 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -145,7 +145,7 @@
  * The GuC firmware layout looks like this:
  *
  * +---+
- * |guc_css_header |
+ * | uc_css_header |
  * |   |
  * | contains major/minor version  |
  * +---+
@@ -172,9 +172,16 @@
  * 3. Length info of each component can be found in header, in dwords.
  * 4. Modulus and exponent key are not required by driver. They may not appear
  *in fw. So driver will load a truncated firmware in this case.
+ *
+ * HuC firmware layout is same as GuC firmware.
+ *
+ * HuC firmware css header is different. However, the only difference is where
+ * the version information is saved. The uc_css_header is unified to support
+ * both. Driver should get HuC version from uc_css_header.huc_sw_version, while
+ * uc_css_header.guc_sw_version for GuC.
  */
 
-struct guc_css_header {
+struct uc_css_header {
uint32_t module_type;
/* header_size includes all non-uCode bits, including css_header, rsa
 * key, modulus key and exponent data. */
@@ -205,8 +212,16 @@ struct guc_css_header {
 
char username[8];
char buildnumber[12];
-   uint32_t device_id;
-   uint32_t guc_sw_version;
+   union {
+   struct {
+   uint32_t branch_client_version;
+   uint32_t sw_version;
+   } guc;
+   struct {
+   uint32_t sw_version;
+   uint32_t reserved;
+   } huc;
+   };
uint32_t prod_preprod_fw;
uint32_t reserved[12];
uint32_t header_info;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index a55cfa7..68af7ae 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -593,7 +593,7 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
struct pci_dev *pdev = dev_priv->drm.pdev;
struct drm_i915_gem_object *obj;
const struct firmware *fw = NULL;
-   struct guc_css_header *css;
+   struct uc_css_header *css;
size_t size;
int err;
 
@@ -610,19 +610,19 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
uc_fw->path, fw);
 
/* Check the size of the blob before examining buffer contents */
-   if (fw->size < sizeof(struct guc_css_header)) {
+   if (fw->size < sizeof(struct uc_css_header)) {
DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
-   css = (struct guc_css_header *)fw->data;
+   css = (struct uc_css_header *)fw->data;
 
/* Firmware bits always start from header */
uc_fw->header_offset = 0;
uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
-   if (uc_fw->header_size != sizeof(struct guc_css_header)) {
+   if (uc_fw->header_size != sizeof(struct uc_css_header)) {
DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
@@ -646,21 +646,36 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
goto fail;
}
 
-   /* Header and uCode will be loaded to WOPCM. Size of the two. */
-   size = uc_fw->header_size + 

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

[Anusha Srivatsa]

These patches add HuC loading support. The driver builds a frame level
workload which is stored in the graphics memory. This workload is presented
to HuC for processing. The driver, therefore should first determine if the
HuC is enabled and also read the huC athentication status bit to determine
if HuC was successfully loaded. The GuC is required to authenticate the HuC.
The userspace patches that check for a fully loaded HuC firmware and use it
can be found at:

https://lists.freedesktop.org/archives/libva/2016-September/004554.html
https://lists.freedesktop.org/archives/libva/2016-September/004555.html
 
More information regarding the HuC, batch commands that configure the 
HuC etc can be found at-
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02a-commandreference-instructions-huc.pdf
https://www.x.org/docs/intel/CHV/intel-gfx-prm-osrc-chv-bsw-vol10-hevc.pdf

v2: rebased.
v3: rebased. Changed the code following the review comments.
v4: Added action_lock initialization fix provided by Arek
(Hiler Arkadiusz) to the first patch in the series- Make the
GuC fw loading helper functions general. 
v5: rebased on top of drm-tip. The patch series is now in sync with GuC 
code reorganization efforts by Arek-
https://patchwork.freedesktop.org/series/15896/
v6:rebased. Organize code. Move contents of intel_huc.h to intel_uc.h.
Update function intel_huc_load(),intel_huc_init() and intel_uc_fw_fetch()
to accept dev_priv instead of dev.
v7: rebased. Remove intel_is_huc_valid() since it is called onoly once.
Refactor the code to reduce redundency. Remove fiels like uc_dev which
are no longer used.
v8: rebased. Beautify the code- remove comments that no longer hold
good, add newlines etc. 
v9: rebased. Remove further redundency. Correct comments. Replace wait_for
with intel_wait_for_register() for optimisation purpose.Make fw_type an enum.


Anusha Srivatsa (3):
  drm/i915/huc: Add HuC fw loading support
  drm/i915/huc: Add BXT HuC Loading Support
  drm/i915/HuC: Add KBL huC loading Support

Peter Antoine (5):
  drm/i915/guc: Make the GuC fw loading helper functions general
  drm/i915/huc: Unified css_header struct for GuC and HuC
  drm/i915/huc: Add debugfs for HuC loading status check
  drm/i915/huc: Support HuC authentication
  drm/i915/get_params: Add HuC status to getparams

 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c|  43 -
 drivers/gpu/drm/i915/i915_drv.c|  11 +-
 drivers/gpu/drm/i915/i915_drv.h|   3 +-
 drivers/gpu/drm/i915/i915_guc_reg.h|   3 +
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  24 ++-
 drivers/gpu/drm/i915/intel_guc_loader.c| 200 ++--
 drivers/gpu/drm/i915/intel_huc_loader.c| 283 +
 drivers/gpu/drm/i915/intel_uc.c|  68 ++-
 drivers/gpu/drm/i915/intel_uc.h|  64 +--
 include/uapi/drm/i915_drm.h|   1 +
 12 files changed, 579 insertions(+), 126 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

-- 
2.7.4

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

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

[Anusha Srivatsa]

From: Peter Antoine 

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
v4: removed G from messages in shared fw fetch function.
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
v11: rebased.
v12: rebased on top of drm-tip
v13: rebased.Updated dev to dev_priv in intel_guc_setup(), guc_fw_getch()
and intel_guc_init().
v14: rebased. Remove uint32_t fw_type to patch 2. Add INTEL_ prefix for
fields in enum intel_uc_fw_status. Remove uc_dev field since its never
used.Rename uc_fw to just fw and guc_fw to fw to avoid redundency.
v15: rebased. Remove sections of code that were commented and no longer
required.
v16: rebased. Remove uc_fw_ prefix from path and obj fields
in intel_uc_fw struct as suggested by Michal.

Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 156 ++---
 drivers/gpu/drm/i915/intel_uc.h|  36 +++
 4 files changed, 104 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9d7b5a8..19fe38e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2328,7 +2328,7 @@ static int i915_llc(struct seq_file *m, void *data)
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.fw;
u32 tmp, i;
 
if (!HAS_GUC_UCODE(dev_priv))
@@ -2336,15 +2336,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)
 
seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 30e012b..48bfd35 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1484,7 +1484,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
gen9_disable_guc_interrupts(dev_priv);
@@ -1511,7 +1511,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
if (i915.guc_log_level >= 0)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 35d5690..a55cfa7 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -81,16 +81,16 @@ MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
 MODULE_FIRMWARE(I915_KBL_GUC_UCODE);
 
 /* User-friendly representation of an enum */
-const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status)
+const char *intel_uc_fw_status_repr(enum intel_uc_fw_status status)
 {
switch (status) {
-   case GUC_FIRMWARE_FAIL:
+   case INTEL_UC_FIRMWARE_FAIL:
   

[Intel-gfx] [PATCH] drm/i915: Revoke fenced GTT mmapings across GPU reset

[Chris Wilson]

During the fence registers are clobbered by a GPU reset. Hence if
there is concurrent user access to a fenced region via a GTT mmaping,
the access will not be fenced during the reset (until we restore the
fences afterwards). In order to prevent invalid access during the reset,
before we clobber the fences we must invalidate the GTT mmapings. Access
to the mmap will then be forced to fault the page, and in handling the
fault, i915_gem_fault() will take the struct_mutex and wait upon the
reset to complete.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99274
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c   |  3 ++-
 drivers/gpu/drm/i915/i915_drv.h   |  4 +++-
 drivers/gpu/drm/i915/i915_gem.c   |  7 ++-
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 24 
 4 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72e29fcb1638..39463fcab593 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1780,6 +1780,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
error->reset_count++;
 
pr_notice("drm/i915: Resetting chip after gpu hang\n");
+   i915_gem_reset_prepare(dev_priv);
 
disable_engines_irq(dev_priv);
ret = intel_gpu_reset(dev_priv, ALL_ENGINES);
@@ -1793,7 +1794,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
goto error;
}
 
-   i915_gem_reset(dev_priv);
+   i915_gem_reset_finish(dev_priv);
intel_overlay_reset(dev_priv);
 
/* Ok, now get things going again... */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c035b6576efa..f16986cfa127 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3355,7 +3355,8 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return READ_ONCE(error->reset_count);
 }
 
-void i915_gem_reset(struct drm_i915_private *dev_priv);
+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv);
+void i915_gem_reset_finish(struct drm_i915_private *dev_priv);
 void i915_gem_set_wedged(struct drm_i915_private *dev_priv);
 
 void i915_gem_clflush_init(struct drm_i915_private *i915);
@@ -3426,6 +3427,7 @@ i915_vm_to_ppgtt(struct i915_address_space *vm)
 int __must_check i915_vma_get_fence(struct i915_vma *vma);
 int __must_check i915_vma_put_fence(struct i915_vma *vma);
 
+void i915_gem_revoke_fences(struct drm_i915_private *dev_priv);
 void i915_gem_restore_fences(struct drm_i915_private *dev_priv);
 
 void i915_gem_detect_bit_6_swizzle(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73987014a7bd..019ea7cb13b5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2715,6 +2715,11 @@ static void reset_request(struct drm_i915_gem_request 
*request)
memset(vaddr + head, 0, request->postfix - head);
 }
 
+void i915_gem_reset_prepare(struct drm_i915_private *dev_priv)
+{
+   i915_gem_revoke_fences(dev_priv);
+}
+
 static void i915_gem_reset_engine(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *request;
@@ -2780,7 +2785,7 @@ static void i915_gem_reset_engine(struct intel_engine_cs 
*engine)
spin_unlock_irqrestore(>timeline->lock, flags);
 }
 
-void i915_gem_reset(struct drm_i915_private *dev_priv)
+void i915_gem_reset_finish(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index 67835d7b39c7..447abb1105ab 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -358,6 +358,30 @@ i915_vma_get_fence(struct i915_vma *vma)
 }
 
 /**
+ * i915_gem_revoke_fences - revoke fence state
+ * @dev_priv: i915 device private
+ *
+ * Clears the hw fence state and removes all GTT mmappings via the fence. This
+ * forces any user of the fence to reacquire that fence before continuing.
+ * One use is during GPU reset where the fence register is lost and we need to
+ * revoke concurrent user access via GTT mmaps until the hardware has been
+ * reset..
+ */
+void i915_gem_revoke_fences(struct drm_i915_private *dev_priv)
+{
+   int i;
+
+   lockdep_assert_held(_priv->drm.struct_mutex);
+
+   for (i = 0; i < dev_priv->num_fence_regs; i++) {
+   struct drm_i915_fence_reg *fence = _priv->fence_regs[i];
+
+   if (fence->vma)
+   i915_gem_release_mmap(fence->vma->obj);
+   }
+}
+
+/**
  * i915_gem_restore_fences - restore fence state
  * @dev_priv: i915 device private
  *
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Track pinned vma in intel_plane_state

[Patchwork]

== Series Details ==

Series: drm/i915: Track pinned vma in intel_plane_state
URL   : https://patchwork.freedesktop.org/series/17490/
State : warning

== Summary ==

Series 17490v1 drm/i915: Track pinned vma in intel_plane_state
https://patchwork.freedesktop.org/api/1.0/series/17490/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ivb-3770)

fi-bdw-5557u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-bsw-n3050 total:246  pass:207  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-byt-j1900 total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770r total:246  pass:227  dwarn:0   dfail:0   fail:0   skip:19 
fi-ivb-3520m total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-ivb-3770  total:246  pass:224  dwarn:1   dfail:0   fail:0   skip:21 
fi-kbl-7500u total:246  pass:225  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6260u total:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-skl-6700hqtotal:246  pass:226  dwarn:0   dfail:0   fail:0   skip:20 
fi-skl-6700k total:246  pass:222  dwarn:3   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:246  pass:233  dwarn:0   dfail:0   fail:0   skip:13 
fi-snb-2520m total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 

3ff9912451fd6840732ac0184f0561c9e6c4107f drm-tip: 2017y-01m-04d-11h-22m-41s UTC 
integration manifest
08b671e drm/i915: Track pinned vma in intel_plane_state

== Logs ==

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

[Intel-gfx] [PATCH 3/3] dma-fence: Introduce drm_fence_set_error() helper

[Chris Wilson]

The dma_fence.error field (formerly known as dma_fence.status) is an
optional field that may be set by drivers before calling
dma_fence_signal(). The field can be used to indicate that the fence was
completed in err rather than with success, and is visible to other
consumers of the fence and to userspace via sync_file.

This patch renames the field from status to error so that its meaning is
hopefully more clear (and distinct from dma_fence_get_status() which is
a composite between the error state and signal state) and adds a helper
that validates the preconditions of when it is suitable to adjust the
error field.

Signed-off-by: Chris Wilson 
---
 drivers/dma-buf/dma-fence.c |  2 +-
 include/linux/dma-fence.h   | 30 +-
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 7d936d19e659..ee82f36cb25e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -559,7 +559,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
dma_fence_ops *ops,
fence->context = context;
fence->seqno = seqno;
fence->flags = 0UL;
-   fence->status = 0;
+   fence->error = 0;
 
trace_dma_fence_init(fence);
 }
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 19f7af905182..6048fa404e57 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -47,7 +47,7 @@ struct dma_fence_cb;
  * can be compared to decide which fence would be signaled later.
  * @flags: A mask of DMA_FENCE_FLAG_* defined below
  * @timestamp: Timestamp when the fence was signaled.
- * @status: Optional, only valid if < 0, must be set before calling
+ * @error: Optional, only valid if < 0, must be set before calling
  * dma_fence_signal, indicates that the fence has completed with an error.
  *
  * the flags member must be manipulated and read using the appropriate
@@ -79,7 +79,7 @@ struct dma_fence {
unsigned seqno;
unsigned long flags;
ktime_t timestamp;
-   int status;
+   int error;
 };
 
 enum dma_fence_flag_bits {
@@ -133,7 +133,7 @@ struct dma_fence_cb {
  * or some failure occurred that made it impossible to enable
  * signaling. True indicates successful enabling.
  *
- * fence->status may be set in enable_signaling, but only when false is
+ * fence->error may be set in enable_signaling, but only when false is
  * returned.
  *
  * Calling dma_fence_signal before enable_signaling is called allows
@@ -145,7 +145,7 @@ struct dma_fence_cb {
  * the second time will be a noop since it was already signaled.
  *
  * Notes on signaled:
- * May set fence->status if returning true.
+ * May set fence->error if returning true.
  *
  * Notes on wait:
  * Must not be NULL, set to dma_fence_default_wait for default implementation.
@@ -395,13 +395,33 @@ static inline struct dma_fence *dma_fence_later(struct 
dma_fence *f1,
 static inline int dma_fence_get_status_locked(struct dma_fence *fence)
 {
if (dma_fence_is_signaled_locked(fence))
-   return fence->status < 0 ? fence->status : 1;
+   return fence->error ?: 1;
else
return 0;
 }
 
 int dma_fence_get_status(struct dma_fence *fence);
 
+/**
+ * dma_fence_set_error - flag an error condition on the fence
+ * @fence: [in]the dma_fence
+ * @error: [in]the error to store
+ *
+ * Drivers can supply an optional error status condition before they signal
+ * the fence, to indicate that the fence was completed due to an error
+ * rather than success. This must be set before signaling (so that the value
+ * is visible before any waiters on the signal callback are woken). This
+ * helper exists to help catching erroneous setting of #dma_fence.error.
+ */
+static inline void dma_fence_set_error(struct dma_fence *fence,
+  int error)
+{
+   BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags));
+   BUG_ON(error >= 0 || error < -MAX_ERRNO);
+
+   fence->error = error;
+}
+
 signed long dma_fence_wait_timeout(struct dma_fence *,
   bool intr, signed long timeout);
 signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()

[Chris Wilson]

As the fence->status is an optional field that may be set before
dma_fence_signal() is called to convey that the fence completed with an
error, we have to ensure that it is always set to zero on initialisation
so that the typical use (i.e. unset) always flags a successful completion.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/dma-buf/dma-fence.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 3444f293ad4a..9130f790ebf3 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
dma_fence_ops *ops,
fence->context = context;
fence->seqno = seqno;
fence->flags = 0UL;
+   fence->status = 0;
 
trace_dma_fence_init(fence);
 }
-- 
2.11.0

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

[Intel-gfx] [PATCH 2/3] dma-fence: Wrap querying the fence->status

[Chris Wilson]

The fence->status is an optional field that is only valid once the fence
has been signaled. (Driver may fill the fence->status with an error code
prior to calling dma_fence_signal().) Given the restriction upon its
validity, wrap querying of the fence->status into a helper
dma_fence_get_status().

Signed-off-by: Chris Wilson 
---
 drivers/dma-buf/dma-fence.c  | 25 +
 drivers/dma-buf/sync_debug.c | 17 -
 drivers/dma-buf/sync_file.c  |  6 ++
 include/linux/dma-fence.h| 24 
 4 files changed, 59 insertions(+), 13 deletions(-)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 9130f790ebf3..7d936d19e659 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -275,6 +275,31 @@ int dma_fence_add_callback(struct dma_fence *fence, struct 
dma_fence_cb *cb,
 EXPORT_SYMBOL(dma_fence_add_callback);
 
 /**
+ * dma_fence_get_status - returns the status upon completion
+ * @fence: [in]the dma_fence to query
+ *
+ * This wraps dma_fence_get_status_locked() to return the error status
+ * condition on a signaled fence. See dma_fence_get_status_locked() for more
+ * details.
+ *
+ * Returns 0 if the fence has not yet been signaled, 1 if the fence has
+ * been signaled without an error condition, or a negative error code
+ * if the fence has been completed in err.
+ */
+int dma_fence_get_status(struct dma_fence *fence)
+{
+   unsigned long flags;
+   int status;
+
+   spin_lock_irqsave(fence->lock, flags);
+   status = dma_fence_get_status_locked(fence);
+   spin_unlock_irqrestore(fence->lock, flags);
+
+   return status;
+}
+EXPORT_SYMBOL(dma_fence_get_status);
+
+/**
  * dma_fence_remove_callback - remove a callback from the signaling list
  * @fence: [in]the fence to wait on
  * @cb:[in]the callback to remove
diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 48b20e34fb6d..c769dc653b34 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -62,30 +62,29 @@ void sync_file_debug_remove(struct sync_file *sync_file)
 
 static const char *sync_status_str(int status)
 {
-   if (status == 0)
-   return "signaled";
+   if (status < 0)
+   return "error";
 
if (status > 0)
-   return "active";
+   return "signaled";
 
-   return "error";
+   return "active";
 }
 
 static void sync_print_fence(struct seq_file *s,
 struct dma_fence *fence, bool show)
 {
-   int status = 1;
struct sync_timeline *parent = dma_fence_parent(fence);
+   int status;
 
-   if (dma_fence_is_signaled_locked(fence))
-   status = fence->status;
+   status = dma_fence_get_status_locked(fence);
 
seq_printf(s, "  %s%sfence %s",
   show ? parent->name : "",
   show ? "_" : "",
   sync_status_str(status));
 
-   if (status <= 0) {
+   if (status) {
struct timespec64 ts64 =
ktime_to_timespec64(fence->timestamp);
 
@@ -136,7 +135,7 @@ static void sync_print_sync_file(struct seq_file *s,
int i;
 
seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
-  sync_status_str(!dma_fence_is_signaled(sync_file->fence)));
+  sync_status_str(dma_fence_get_status(sync_file->fence)));
 
if (dma_fence_is_array(sync_file->fence)) {
struct dma_fence_array *array = 
to_dma_fence_array(sync_file->fence);
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 07cb9b908f30..2321035f6204 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -373,10 +373,8 @@ static void sync_fill_fence_info(struct dma_fence *fence,
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
sizeof(info->driver_name));
-   if (dma_fence_is_signaled(fence))
-   info->status = fence->status >= 0 ? 1 : fence->status;
-   else
-   info->status = 0;
+
+   info->status = dma_fence_get_status(fence);
info->timestamp_ns = ktime_to_ns(fence->timestamp);
 }
 
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index d51a7d23c358..19f7af905182 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -378,6 +378,30 @@ static inline struct dma_fence *dma_fence_later(struct 
dma_fence *f1,
return dma_fence_is_signaled(f2) ? NULL : f2;
 }
 
+/**
+ * dma_fence_get_status_locked - returns the status upon completion
+ * @fence: [in]the dma_fence to query
+ *
+ * Drivers can supply an optional error status condition before they signal
+ * the fence (to indicate whether the fence was completed due to an error
+ * rather than success). The value of 

[Intel-gfx] ✗ Fi.CI.BAT: failure for HuC Loading Patches

[Patchwork]

== Series Details ==

Series: HuC Loading Patches
URL   : https://patchwork.freedesktop.org/series/17489/
State : failure

== Summary ==

  CC [M]  drivers/gpu/drm/i915/gvt/gvt.o
  CC [M]  drivers/gpu/drm/i915/gvt/aperture_gm.o
  CC [M]  drivers/gpu/drm/i915/gvt/vgpu.o
  CC [M]  drivers/gpu/drm/i915/gvt/handlers.o
  CC [M]  drivers/gpu/drm/i915/gvt/trace_points.o
  CC [M]  drivers/gpu/drm/i915/gvt/interrupt.o
  CC [M]  drivers/gpu/drm/i915/gvt/firmware.o
  CC [M]  drivers/gpu/drm/i915/gvt/cfg_space.o
  CC [M]  drivers/gpu/drm/i915/gvt/gtt.o
  CC [M]  drivers/gpu/drm/i915/gvt/opregion.o
  CC [M]  drivers/gpu/drm/i915/gvt/mmio.o
  CC [M]  drivers/gpu/drm/i915/gvt/display.o
  CC [M]  drivers/gpu/drm/i915/gvt/edid.o
  CC [M]  drivers/gpu/drm/i915/gvt/execlist.o
  CC [M]  drivers/gpu/drm/i915/gvt/scheduler.o
  CC [M]  drivers/gpu/drm/i915/gvt/sched_policy.o
  CC [M]  drivers/gpu/drm/i915/gvt/render.o
  CC [M]  drivers/gpu/drm/i915/gvt/cmd_parser.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/storage/built-in.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/tty/serial/8250/8250.o
  LD  drivers/iommu/built-in.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD  drivers/acpi/acpica/acpi.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD  drivers/usb/gadget/libcomposite.o
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
  LD  drivers/scsi/scsi_mod.o
  LD  sound/pci/built-in.o
  LD [M]  fs/cifs/cifs.o
  LD  drivers/acpi/acpica/built-in.o
  LD  drivers/pci/pcie/aer/aerdriver.o
  LD  drivers/pci/pcie/aer/built-in.o
  LD  drivers/pci/pcie/built-in.o
  LD  drivers/pci/built-in.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  drivers/usb/gadget/built-in.o
  LD  sound/built-in.o
  LD  drivers/video/console/built-in.o
  LD  drivers/acpi/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  drivers/video/built-in.o
drivers/gpu/drm/i915/intel_uc.c: In function ‘intel_guc_send’:
drivers/gpu/drm/i915/intel_uc.c:81:5: error: ‘status’ may be used uninitialized 
in this function [-Werror=maybe-uninitialized]
  if (status != INTEL_GUC_STATUS_SUCCESS) {
 ^
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  AR  lib/lib.a
cc1: all warnings being treated as errors
  EXPORTS lib/lib-ksyms.o
scripts/Makefile.build:293: recipe for target 'drivers/gpu/drm/i915/intel_uc.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/intel_uc.o] Error 1
make[4]: *** Waiting for unfinished jobs
  LD  lib/built-in.o
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/base/regmap/built-in.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/tty/serial/built-in.o
  LD  drivers/usb/core/built-in.o
  LD  drivers/base/power/built-in.o
  LD  net/ipv6/ipv6.o
  LD  drivers/base/built-in.o
  LD  net/ipv6/built-in.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/scsi/built-in.o
  LD  net/xfrm/built-in.o
  LD  drivers/md/md-mod.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/md/built-in.o
  LD  drivers/tty/built-in.o
  CC  arch/x86/kernel/cpu/capflags.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  arch/x86/kernel/built-in.o
  LD  net/ipv4/built-in.o
  LD  fs/btrfs/btrfs.o
  LD  arch/x86/built-in.o
  LD  fs/btrfs/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  fs/ext4/ext4.o
  LD  net/core/built-in.o
  LD  fs/ext4/built-in.o
  LD  net/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  fs/built-in.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:551: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:988: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

[Srivatsa, Anusha]

>-Original Message-
>From: Wajdeczko, Michal
>Sent: Wednesday, January 4, 2017 5:59 AM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org; Hiler, Arkadiusz 
>
>Subject: Re: [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper
>functions general
>
>On Wed, Jan 04, 2017 at 05:27:23AM -0800, Anusha Srivatsa wrote:
>> From: Peter Antoine 
>>
>> Rename some of the GuC fw loading code to make them more general. We
>> will utilise them for HuC loading as well.
>>  s/intel_guc_fw/intel_uc_fw/g
>>  s/GUC_FIRMWARE/UC_FIRMWARE/g
>>
>> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
>> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
>> same purpose.
>>
>> v2: rebased on top of nightly.
>> reapplied the search/replace as upstream code as changed.
>> v3: rebased again on drm-nightly.
>> v4: removed G from messages in shared fw fetch function.
>> v5: rebased.
>> v7: rebased.
>> v8: rebased.
>> v9: rebased.
>> v10: rebased.
>> v11: rebased.
>> v12: rebased on top of drm-tip
>> v13: rebased.Updated dev to dev_priv in intel_guc_setup(),
>> guc_fw_getch() and intel_guc_init().
>> v14: rebased. Remove uint32_t fw_type to patch 2. Add INTEL_ prefix
>> for fields in enum intel_uc_fw_status. Remove uc_dev field since its
>> never used.Rename uc_fw to just fw and guc_fw to fw to avoid redundency.
>> v15: rebased. Remove sections of code that were commented and no
>> longer required.
>> v16: rebased. Remove uc_fw_ prefix from path and obj fields in
>> intel_uc_fw struct as suggested by Michal.
>>
>> Cc: Michal Wajdeczko 
>> Cc: Arkadiusz Hiler 
>> Signed-off-by: Anusha Srivatsa 
>> Signed-off-by: Alex Dai 
>> Signed-off-by: Peter Antoine 
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
>>  drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
>>  drivers/gpu/drm/i915/intel_guc_loader.c| 156 
>> ++---
>>  drivers/gpu/drm/i915/intel_uc.h|  36 +++
>>  4 files changed, 104 insertions(+), 104 deletions(-)
>>
>
>...CUT
>
>>  /*
>>   * This structure encapsulates all the data needed during the process
>>   * of fetching, caching, and loading the firmware image into the GuC.
>>   */
>> -struct intel_guc_fw {
>> -const char *guc_fw_path;
>> -size_t  guc_fw_size;
>> -struct drm_i915_gem_object *guc_fw_obj;
>> -enum intel_guc_fw_statusguc_fw_fetch_status;
>> -enum intel_guc_fw_statusguc_fw_load_status;
>> -
>> -uint16_tguc_fw_major_wanted;
>> -uint16_tguc_fw_minor_wanted;
>> -uint16_tguc_fw_major_found;
>> -uint16_tguc_fw_minor_found;
>> +struct intel_uc_fw {
>> +const char *uc_fw_path;
>> +size_t size;
>> +struct drm_i915_gem_object *uc_fw_obj;
>
>Hmm, something must went wrong ... in v16 comment you said that "uc_fw_" is
>gone, but obviously this is not true ;(

Yes...resending :(
>Michal
>
>> +enum intel_uc_fw_status fetch_status;
>> +enum intel_uc_fw_status load_status;
>> +
>> +uint16_t major_ver_wanted;
>> +uint16_t minor_ver_wanted;
>> +uint16_t major_ver_found;
>> +uint16_t minor_ver_found;
>>
>>  uint32_t header_size;
>>  uint32_t header_offset;
>> @@ -141,7 +141,7 @@ struct intel_guc_log {  };
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

[Michal Wajdeczko]

On Wed, Jan 04, 2017 at 05:27:23AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
>  s/intel_guc_fw/intel_uc_fw/g
>  s/GUC_FIRMWARE/UC_FIRMWARE/g
> 
> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
> same purpose.
> 
> v2: rebased on top of nightly.
> reapplied the search/replace as upstream code as changed.
> v3: rebased again on drm-nightly.
> v4: removed G from messages in shared fw fetch function.
> v5: rebased.
> v7: rebased.
> v8: rebased.
> v9: rebased.
> v10: rebased.
> v11: rebased.
> v12: rebased on top of drm-tip
> v13: rebased.Updated dev to dev_priv in intel_guc_setup(), guc_fw_getch()
> and intel_guc_init().
> v14: rebased. Remove uint32_t fw_type to patch 2. Add INTEL_ prefix for
> fields in enum intel_uc_fw_status. Remove uc_dev field since its never
> used.Rename uc_fw to just fw and guc_fw to fw to avoid redundency.
> v15: rebased. Remove sections of code that were commented and no longer
> required.
> v16: rebased. Remove uc_fw_ prefix from path and obj fields
> in intel_uc_fw struct as suggested by Michal.
> 
> Cc: Michal Wajdeczko 
> Cc: Arkadiusz Hiler 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
>  drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
>  drivers/gpu/drm/i915/intel_guc_loader.c| 156 
> ++---
>  drivers/gpu/drm/i915/intel_uc.h|  36 +++
>  4 files changed, 104 insertions(+), 104 deletions(-)
> 

...CUT

>  /*
>   * This structure encapsulates all the data needed during the process
>   * of fetching, caching, and loading the firmware image into the GuC.
>   */
> -struct intel_guc_fw {
> - const char *guc_fw_path;
> - size_t  guc_fw_size;
> - struct drm_i915_gem_object *guc_fw_obj;
> - enum intel_guc_fw_statusguc_fw_fetch_status;
> - enum intel_guc_fw_statusguc_fw_load_status;
> -
> - uint16_tguc_fw_major_wanted;
> - uint16_tguc_fw_minor_wanted;
> - uint16_tguc_fw_major_found;
> - uint16_tguc_fw_minor_found;
> +struct intel_uc_fw {
> + const char *uc_fw_path;
> + size_t size;
> + struct drm_i915_gem_object *uc_fw_obj;

Hmm, something must went wrong ... in v16 comment you said that "uc_fw_" is 
gone,
but obviously this is not true ;(

Michal

> + enum intel_uc_fw_status fetch_status;
> + enum intel_uc_fw_status load_status;
> +
> + uint16_t major_ver_wanted;
> + uint16_t minor_ver_wanted;
> + uint16_t major_ver_found;
> + uint16_t minor_ver_found;
>  
>   uint32_t header_size;
>   uint32_t header_offset;
> @@ -141,7 +141,7 @@ struct intel_guc_log {
>  };
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm: add fourcc codes for 16bit R and RG

[Rainer Hochecker]

From: Rainer Hochecker 

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..4d65fb6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
 
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
+
 /* 16 bpp RG */
 #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
 #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
 
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] G:R 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
-- 
2.9.3

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

[Intel-gfx] [PATCH v3] drm: add fourcc codes for 16bit R and RG

[Rainer Hochecker]

From: Rainer Hochecker 

This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..85079cd 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
 
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
+
 /* 16 bpp RG */
 #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
 #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */
 
+/* 32 bpp GR */
+#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] G:R 
16:16 little endian */
+#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
16:16 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
-- 
2.9.3

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

[Intel-gfx] [drm-intel:drm-intel-nightly 440/455] warning: (DRM_NOUVEAU && ..) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && ..)

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head:   3ff9912451fd6840732ac0184f0561c9e6c4107f
commit: a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8 [440/455] drm: nouveau: fix 
build when LEDS_CLASS=m
config: x86_64-randconfig-x016-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has 
unmet direct dependencies (ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT)

---
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 3/8] drm/i915/huc: Add HuC fw loading support

[Anusha Srivatsa]

The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.

HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.

v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_private to to_i915()
v4: moved function back to where it was.
change wait_for_atomic to wait_for.
v5: rebased + comment changes.
v7: rebased.
v8: rebased.
v9: rebased. Changed the year in the copyright message to reflect
the right year.Correct the comments,remove the unwanted WARN message,
replace drm_gem_object_unreference() with i915_gem_object_put().Make the
prototypes in intel_huc.h non-extern.
v10: rebased. Update the file construction done by HuC. It is similar to
GuC.Adopted the approach used in-
https://patchwork.freedesktop.org/patch/104355/ 
v11: Fix warnings remove old declaration
v12: Change dev to dev_priv in macro definition.
Corrected comments.
v13: rebased.
v14: rebased on top of drm-tip
v15: rebased. Updated functions intel_huc_load(),intel_huc_init() and
intel_uc_fw_fetch() to accept dev_priv instead of dev. Moved contents
of intel_huc.h to intel_uc.h
v16: change SKL_FW_ to SKL_HUC_FW_. Add intel_ prefix to guc_wopcm_size().
Remove unwanted checks in intel_uc.h. Rename huc_fw in struct intel_huc to
simply fw to avoid redundency.
v17: rebased.
v18: rebased. Correct comments.

Cc: Arkadiusz Hiler 
Cc: Michal Wajdeczko 
Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.h |   3 +-
 drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
 drivers/gpu/drm/i915/intel_guc_loader.c |  11 +-
 drivers/gpu/drm/i915/intel_huc_loader.c | 260 
 drivers/gpu/drm/i915/intel_uc.h |  19 ++-
 7 files changed, 293 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5196509..45ae124 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -57,6 +57,7 @@ i915-y += i915_cmd_parser.o \
 # general-purpose microcontroller (GuC) support
 i915-y += intel_uc.o \
  intel_guc_loader.o \
+ intel_huc_loader.o \
  i915_guc_submission.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2c020ea..c9f71e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -599,6 +599,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
 
+   intel_huc_init(dev_priv);
intel_guc_init(dev_priv);
 
ret = i915_gem_init(dev_priv);
@@ -626,6 +627,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
 cleanup_irq:
+   intel_huc_fini(dev);
intel_guc_fini(dev_priv);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev_priv);
@@ -1312,7 +1314,7 @@ void i915_driver_unload(struct drm_device *dev)
 
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
-
+   intel_huc_fini(dev);
intel_guc_fini(dev_priv);
i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0ea63d6..854e2bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2080,6 +2080,7 @@ struct drm_i915_private {
 
struct intel_gvt *gvt;
 
+   struct intel_huc huc;
struct intel_guc guc;
 
struct intel_csr csr;
@@ -2854,7 +2855,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
 #define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
-
+#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index 5e638fc..f9829f6 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
 #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
 #define 

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

[Anusha Srivatsa]

This patch adds the support to load HuC on KBL
Version 2.0

v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_
v6: rebased. Remove old checks.
v7: rebased.

Cc: Tvrtko Ursulin 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 6cfcb51..051e7ba 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -48,6 +48,10 @@
 #define SKL_HUC_FW_MINOR 07
 #define SKL_BLD_NUM 1398
 
+#define KBL_HUC_FW_MAJOR 02
+#define KBL_HUC_FW_MINOR 00
+#define KBL_BLD_NUM 1810
+
 #define HUC_FW_PATH(platform, major, minor, bld_num) \
"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
__stringify(minor) "_" __stringify(bld_num) ".bin"
@@ -59,6 +63,11 @@ MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 #define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
BXT_HUC_FW_MINOR, BXT_BLD_NUM)
 MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+
+#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_HUC_FW_MAJOR, \
+   KBL_HUC_FW_MINOR, KBL_BLD_NUM)
+MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
+
 /**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm device
@@ -164,6 +173,10 @@ void intel_huc_init(struct drm_i915_private *dev_priv)
fw_path = I915_BXT_HUC_UCODE;
huc_fw->major_ver_wanted = BXT_HUC_FW_MAJOR;
huc_fw->minor_ver_wanted = BXT_HUC_FW_MINOR;
+   } else if (IS_KABYLAKE(dev_priv)) {
+   fw_path = I915_KBL_HUC_UCODE;
+   huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR;
}
 
huc_fw->uc_fw_path = fw_path;
-- 
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: Track pinned vma in intel_plane_state

[Maarten Lankhorst]

From: Chris Wilson 

With atomic plane states we are able to track an allocation right from
preparation, during use and through to the final free after being
swapped out for a new plane. We can couple the VMA we pin for the
framebuffer (and its rotation) to this lifetime and avoid all the clumsy
lookups in between.

v2: Remove residual vma on plane cleanup (Chris)
v3: Add a description for the vma destruction in
intel_plane_destroy_state (Maarten)

Signed-off-by: Chris Wilson 
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h   |  16 +---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  20 +
 drivers/gpu/drm/i915/intel_display.c  | 129 +++---
 drivers/gpu/drm/i915/intel_drv.h  |   9 ++-
 drivers/gpu/drm/i915/intel_fbc.c  |  52 +---
 drivers/gpu/drm/i915/intel_fbdev.c|   4 +-
 drivers/gpu/drm/i915/intel_sprite.c   |   8 +-
 7 files changed, 103 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22d3f610212c..5369f5f9ce3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1079,6 +1079,8 @@ struct intel_fbc {
struct work_struct underrun_work;
 
struct intel_fbc_state_cache {
+   struct i915_vma *vma;
+
struct {
unsigned int mode_flags;
uint32_t hsw_bdw_pixel_rate;
@@ -1092,15 +1094,14 @@ struct intel_fbc {
} plane;
 
struct {
-   u64 ilk_ggtt_offset;
const struct drm_format_info *format;
unsigned int stride;
-   int fence_reg;
-   unsigned int tiling_mode;
} fb;
} state_cache;
 
struct intel_fbc_reg_params {
+   struct i915_vma *vma;
+
struct {
enum pipe pipe;
enum plane plane;
@@ -1108,10 +1109,8 @@ struct intel_fbc {
} crtc;
 
struct {
-   u64 ggtt_offset;
const struct drm_format_info *format;
unsigned int stride;
-   int fence_reg;
} fb;
 
int cfb_size;
@@ -3406,13 +3405,6 @@ i915_gem_object_to_ggtt(struct drm_i915_gem_object *obj,
return i915_gem_obj_to_vma(obj, _i915(obj->base.dev)->ggtt.base, 
view);
 }
 
-static inline unsigned long
-i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
-   const struct i915_ggtt_view *view)
-{
-   return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
-}
-
 /* i915_gem_fence_reg.c */
 int __must_check i915_vma_get_fence(struct i915_vma *vma);
 int __must_check i915_vma_put_fence(struct i915_vma *vma);
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 4612ffd555a7..41fd94e62d3c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
 
__drm_atomic_helper_plane_duplicate_state(plane, state);
 
+   intel_state->vma = NULL;
+
return state;
 }
 
@@ -100,6 +102,24 @@ void
 intel_plane_destroy_state(struct drm_plane *plane,
  struct drm_plane_state *state)
 {
+   struct i915_vma *vma;
+
+   vma = fetch_and_zero(_intel_plane_state(state)->vma);
+
+   /*
+* FIXME: Normally intel_cleanup_plane_fb handles destruction of vma.
+* We currently don't clear all planes during driver unload, so we have
+* to be able to unpin vma here for now.
+*
+* Normally this can only happen during unload when kmscon is disabled
+* and userspace doesn't attempt to set a framebuffer at all.
+*/
+   if (vma) {
+   mutex_lock(>dev->struct_mutex);
+   intel_unpin_fb_vma(vma);
+   mutex_unlock(>dev->struct_mutex);
+   }
+
drm_atomic_helper_plane_destroy_state(plane, state);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9b64edc44e26..07f757cbc8d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2236,24 +2236,19 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb, 
unsigned int rotation)
i915_vma_pin_fence(vma);
}
 
+   i915_vma_get(vma);
 err:
intel_runtime_pm_put(dev_priv);
return vma;
 }
 
-void intel_unpin_fb_obj(struct drm_framebuffer *fb, unsigned int rotation)
+void intel_unpin_fb_vma(struct i915_vma *vma)
 {
-   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
-   struct i915_ggtt_view 

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

[Anusha Srivatsa]

These patches add HuC loading support. The driver builds a frame level
workload which is stored in the graphics memory. This workload is presented
to HuC for processing. The driver, therefore should first determine if the
HuC is enabled and also read the huC athentication status bit to determine
if HuC was successfully loaded. The GuC is required to authenticate the HuC.
The userspace patches that check for a fully loaded HuC firmware and use it
can be found at:

https://lists.freedesktop.org/archives/libva/2016-September/004554.html
https://lists.freedesktop.org/archives/libva/2016-September/004555.html
 
More information regarding the HuC, batch commands that configure the 
HuC etc can be found at-
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol02a-commandreference-instructions-huc.pdf
https://www.x.org/docs/intel/CHV/intel-gfx-prm-osrc-chv-bsw-vol10-hevc.pdf

v2: rebased.
v3: rebased. Changed the code following the review comments.
v4: Added action_lock initialization fix provided by Arek
(Hiler Arkadiusz) to the first patch in the series- Make the
GuC fw loading helper functions general. 
v5: rebased on top of drm-tip. The patch series is now in sync with GuC 
code reorganization efforts by Arek-
https://patchwork.freedesktop.org/series/15896/
v6:rebased. Organize code. Move contents of intel_huc.h to intel_uc.h.
Update function intel_huc_load(),intel_huc_init() and intel_uc_fw_fetch()
to accept dev_priv instead of dev.
v7: rebased. Remove intel_is_huc_valid() since it is called onoly once.
Refactor the code to reduce redundency. Remove fiels like uc_dev which
are no longer used.
v8: rebased. Beautify the code- remove comments that no longer hold
good, add newlines etc. 
v9: rebased. Remove further redundency. Correct comments. Replace wait_for
with intel_wait_for_register() for optimisation purpose.Make fw_type an enum.


Anusha Srivatsa (3):
  drm/i915/huc: Add HuC fw loading support
  drm/i915/huc: Add BXT HuC Loading Support
  drm/i915/HuC: Add KBL huC loading Support

Peter Antoine (5):
  drm/i915/guc: Make the GuC fw loading helper functions general
  drm/i915/huc: Unified css_header struct for GuC and HuC
  drm/i915/huc: Add debugfs for HuC loading status check
  drm/i915/huc: Support HuC authentication
  drm/i915/get_params: Add HuC status to getparams

 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c|  43 -
 drivers/gpu/drm/i915/i915_drv.c|  11 +-
 drivers/gpu/drm/i915/i915_drv.h|   3 +-
 drivers/gpu/drm/i915/i915_guc_reg.h|   3 +
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  24 ++-
 drivers/gpu/drm/i915/intel_guc_loader.c| 200 ++--
 drivers/gpu/drm/i915/intel_huc_loader.c| 283 +
 drivers/gpu/drm/i915/intel_uc.c|  68 ++-
 drivers/gpu/drm/i915/intel_uc.h|  64 +--
 include/uapi/drm/i915_drm.h|   1 +
 12 files changed, 579 insertions(+), 126 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

-- 
2.7.4

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

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

[Anusha Srivatsa]

From: Peter Antoine 

This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after it is
loaded and is not usable until it is verified.

v2: removed the forewakes as the registers are already force-woken.
 (T.Ursulin)
v4: rebased.
v5: rebased on top of drm-tip.
v6: rebased. Removed any reference to intel_huc.h
v7: rebased. Rename I915_PARAM_HAS_HUC to I915_PARAM_HUC_STATUS.
Remove intel_is_huc_valid() since it is used only in one place.
Put the case of I915_PARAM_HAS_HUC() in the right place.
v8: rebased. Add a comment to specify that I915_READ(reg)
does not read garbage value. The register HUC_STATUS2 is force
woken and no rpm is needed.
v9: rebased.

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Peter Antoine 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_drv.c | 7 +++
 drivers/gpu/drm/i915/intel_huc_loader.c | 1 -
 include/uapi/drm/i915_drm.h | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c9f71e0..723442c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,7 @@
 #include "i915_trace.h"
 #include "i915_vgpu.h"
 #include "intel_drv.h"
+#include "intel_uc.h"
 
 static struct drm_driver driver;
 
@@ -315,6 +316,12 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
case I915_PARAM_MIN_EU_IN_POOL:
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
+   case I915_PARAM_HUC_STATUS:
+   /* The register is already force-woken. We dont need
+* any rpm here
+*/
+   value = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED;
+   break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've started our numbering from 1, and so class all
 * earlier versions as 0, in effect their value is undefined as
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 051e7ba..d0a7547 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -281,4 +281,3 @@ void intel_huc_fini(struct drm_device *dev)
 
huc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE;
 }
-
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index da32c2f..57093b4 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -395,6 +395,7 @@ typedef struct drm_i915_irq_wait {
  * priorities and the driver will attempt to execute batches in priority order.
  */
 #define I915_PARAM_HAS_SCHEDULER41
+#define I915_PARAM_HUC_STATUS   42
 
 typedef struct drm_i915_getparam {
__s32 param;
-- 
2.7.4

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

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

[Anusha Srivatsa]

This patch adds the HuC Loading for the BXT by using
the updated file construction.

Version 1.7 of the HuC firmware.

v2: rebased.
v3: rebased on top of drm-tip
v4: rebased.
v5: rebased. Rename BXT_FW_MAJOR to BXT_HUC_FW_
v6: rebased.
v7: rebased.

Cc: Tvrtko Ursulin 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 6f3ed12..6cfcb51 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -40,6 +40,10 @@
  * Note that HuC firmware loading must be done before GuC loading.
  */
 
+#define BXT_HUC_FW_MAJOR 01
+#define BXT_HUC_FW_MINOR 07
+#define BXT_BLD_NUM 1398
+
 #define SKL_HUC_FW_MAJOR 01
 #define SKL_HUC_FW_MINOR 07
 #define SKL_BLD_NUM 1398
@@ -52,6 +56,9 @@
SKL_HUC_FW_MINOR, SKL_BLD_NUM)
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 
+#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
+   BXT_HUC_FW_MINOR, BXT_BLD_NUM)
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
 /**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm device
@@ -153,6 +160,10 @@ void intel_huc_init(struct drm_i915_private *dev_priv)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = SKL_HUC_FW_MAJOR;
huc_fw->minor_ver_wanted = SKL_HUC_FW_MINOR;
+   } else if (IS_BROXTON(dev_priv)) {
+   fw_path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = BXT_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = BXT_HUC_FW_MINOR;
}
 
huc_fw->uc_fw_path = fw_path;
-- 
2.7.4

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

[Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

[Anusha Srivatsa]

From: Peter Antoine 

The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.

v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
and place the prototype in intel_guc.h,correct the comments.
v10: rebased.
v11: rebased.
v12: rebased on top of drm-tip
v13: rebased. Moved intel_guc_auth_huc from i915_guc_submission.c
to intel_uc.c.Update dev to dev_priv in intel_guc_auth_huc().
Renamed HOST2GUC_ACTION_AUTHENTICATE_HUC TO INTEL_GUC_ACTION_
AUTHENTICATE_HUC
v14: rebased.
v15: rebased. Add newline on DRM_ERRORs that already dont have one.
v16: rebased. Replace wait_for with intel_wait_for_register() since
the latter employs sleep optimisations for quick responses- as pointed
out by Chris Wilson.

Cc: Chris Wilson 
Cc: Arkadiusz Hiler 
Cc: Michal Wajdeczko 
Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/intel_guc_fwif.h   |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c |  2 +
 drivers/gpu/drm/i915/intel_uc.c | 68 -
 drivers/gpu/drm/i915/intel_uc.h |  1 +
 4 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index ed1ab40..ce4e05e 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -506,6 +506,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
+   INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
INTEL_GUC_ACTION_LIMIT
 };
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index a6ac046..be76583 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -529,6 +529,8 @@ int intel_guc_setup(struct drm_i915_private *dev_priv)
intel_uc_fw_status_repr(guc_fw->fetch_status),
intel_uc_fw_status_repr(guc_fw->load_status));
 
+   intel_guc_auth_huc(dev_priv);
+
if (i915.enable_guc_submission) {
if (i915.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index c6be352..dccd39c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -71,7 +71,11 @@ int intel_guc_send(struct intel_guc *guc, const u32 *action, 
u32 len)
 * up to that length of time, then switch to a slower sleep-wait loop.
 * No inte_guc_send command should ever take longer than 10ms.
 */
-   ret = wait_for_us(intel_guc_recv(guc, ), 10);
+   ret = intel_wait_for_register(dev_priv,
+   HUC_STATUS2,
+   HUC_FW_VERIFIED,
+   HUC_FW_VERIFIED,
+   50);
if (ret)
ret = wait_for(intel_guc_recv(guc, ), 10);
if (status != INTEL_GUC_STATUS_SUCCESS) {
@@ -140,3 +144,65 @@ int intel_guc_log_control(struct intel_guc *guc, u32 
control_val)
 
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
+
+/**
+ * intel_guc_auth_huc() - authenticate ucode
+ * @dev_priv: the drm_i915_device
+ *
+ * Triggers a HuC fw authentication request to the GuC via intel_guc_action_
+ * authenticate_huc interface.
+ * interface.
+ */
+void intel_guc_auth_huc(struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+   struct intel_huc *huc = _priv->huc;
+   struct i915_vma *vma;
+   int ret;
+   u32 data[2];
+
+   /* Bypass the case where there is no HuC firmware */
+   if (huc->fw.fetch_status == INTEL_UC_FIRMWARE_NONE ||
+   huc->fw.load_status == INTEL_UC_FIRMWARE_NONE)
+   return;
+
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate\n");
+   return;
+   }
+
+   if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate\n");
+   return;
+   }
+
+   vma = i915_gem_object_ggtt_pin(huc->fw.uc_fw_obj, NULL, 0, 0, 0);
+   if (IS_ERR(vma)) {
+   DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma));
+   return;
+   }
+
+
+   /* 

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

[Anusha Srivatsa]

From: Peter Antoine 

HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.

v2: rebased on-top of drm-intel-nightly
v3: rebased on-top of drm-intel-nightly (again).
v4: rebased + spaces.
v7: rebased.
v8: rebased.
v9: rebased. Rename device_id to guc_branch_client_version,
make guc_sw_version a union. . Put UC_FW_TYPE_GUC
and UC_FW_TYPE_HUC into an enum.
v10: rebased.
v11: rebased.
v12: rebased on top of drm-tip.
v13: rebased.Update dev to dev_priv in intel_uc_fw_fetch
v14: rebased. Add INTEL_ prefix to an enum. Add fw_type declaration
from patch 1.Combine two different unions for huc and guc version,
reserved etc into one union with two structs.
v15: rebased.
v16: rebased. Change fw_type to enum.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/intel_guc_fwif.h   | 23 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 41 ++---
 drivers/gpu/drm/i915/intel_uc.h |  6 +
 3 files changed, 53 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 3202b32..ed1ab40 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -145,7 +145,7 @@
  * The GuC firmware layout looks like this:
  *
  * +---+
- * |guc_css_header |
+ * | uc_css_header |
  * |   |
  * | contains major/minor version  |
  * +---+
@@ -172,9 +172,16 @@
  * 3. Length info of each component can be found in header, in dwords.
  * 4. Modulus and exponent key are not required by driver. They may not appear
  *in fw. So driver will load a truncated firmware in this case.
+ *
+ * HuC firmware layout is same as GuC firmware.
+ *
+ * HuC firmware css header is different. However, the only difference is where
+ * the version information is saved. The uc_css_header is unified to support
+ * both. Driver should get HuC version from uc_css_header.huc_sw_version, while
+ * uc_css_header.guc_sw_version for GuC.
  */
 
-struct guc_css_header {
+struct uc_css_header {
uint32_t module_type;
/* header_size includes all non-uCode bits, including css_header, rsa
 * key, modulus key and exponent data. */
@@ -205,8 +212,16 @@ struct guc_css_header {
 
char username[8];
char buildnumber[12];
-   uint32_t device_id;
-   uint32_t guc_sw_version;
+   union {
+   struct {
+   uint32_t branch_client_version;
+   uint32_t sw_version;
+   } guc;
+   struct {
+   uint32_t sw_version;
+   uint32_t reserved;
+   } huc;
+   };
uint32_t prod_preprod_fw;
uint32_t reserved[12];
uint32_t header_info;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 15215b7..a4196e2 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -593,7 +593,7 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
struct pci_dev *pdev = dev_priv->drm.pdev;
struct drm_i915_gem_object *obj;
const struct firmware *fw = NULL;
-   struct guc_css_header *css;
+   struct uc_css_header *css;
size_t size;
int err;
 
@@ -610,19 +610,19 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
uc_fw->uc_fw_path, fw);
 
/* Check the size of the blob before examining buffer contents */
-   if (fw->size < sizeof(struct guc_css_header)) {
+   if (fw->size < sizeof(struct uc_css_header)) {
DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
-   css = (struct guc_css_header *)fw->data;
+   css = (struct uc_css_header *)fw->data;
 
/* Firmware bits always start from header */
uc_fw->header_offset = 0;
uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
-   if (uc_fw->header_size != sizeof(struct guc_css_header)) {
+   if (uc_fw->header_size != sizeof(struct uc_css_header)) {
DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
@@ -646,21 +646,36 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
goto fail;
}
 
-   /* Header and uCode will be loaded to WOPCM. Size of the two. */
-   size = uc_fw->header_size 

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

[Anusha Srivatsa]

From: Peter Antoine 

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
v4: removed G from messages in shared fw fetch function.
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
v11: rebased.
v12: rebased on top of drm-tip
v13: rebased.Updated dev to dev_priv in intel_guc_setup(), guc_fw_getch()
and intel_guc_init().
v14: rebased. Remove uint32_t fw_type to patch 2. Add INTEL_ prefix for
fields in enum intel_uc_fw_status. Remove uc_dev field since its never
used.Rename uc_fw to just fw and guc_fw to fw to avoid redundency.
v15: rebased. Remove sections of code that were commented and no longer
required.
v16: rebased. Remove uc_fw_ prefix from path and obj fields
in intel_uc_fw struct as suggested by Michal.

Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 156 ++---
 drivers/gpu/drm/i915/intel_uc.h|  36 +++
 4 files changed, 104 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9d7b5a8..150536e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2328,7 +2328,7 @@ static int i915_llc(struct seq_file *m, void *data)
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.fw;
u32 tmp, i;
 
if (!HAS_GUC_UCODE(dev_priv))
@@ -2336,15 +2336,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)
 
seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 30e012b..48bfd35 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1484,7 +1484,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
gen9_disable_guc_interrupts(dev_priv);
@@ -1511,7 +1511,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
return 0;
 
if (i915.guc_log_level >= 0)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 35d5690..15215b7 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -81,16 +81,16 @@ MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
 MODULE_FIRMWARE(I915_KBL_GUC_UCODE);
 
 /* User-friendly representation of an enum */
-const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status)
+const char *intel_uc_fw_status_repr(enum intel_uc_fw_status status)
 {
switch (status) {
-   case GUC_FIRMWARE_FAIL:
+   case INTEL_UC_FIRMWARE_FAIL:
 

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

[Anusha Srivatsa]

From: Peter Antoine 

Add debugfs entry for HuC loading status check.

v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
v11: rebased on top of drm-tip
v12: rebased.
v13: rebased.
v14: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 150536e..517ec94 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2325,6 +2325,36 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
 }
 
+static int i915_huc_load_status_info(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+
+   if (!HAS_HUC_UCODE(dev_priv))
+   return 0;
+
+   seq_puts(m, "HuC firmware status:\n");
+   seq_printf(m, "\tpath: %s\n", huc_fw->uc_fw_path);
+   seq_printf(m, "\tfetch: %s\n",
+   intel_uc_fw_status_repr(huc_fw->fetch_status));
+   seq_printf(m, "\tload: %s\n",
+   intel_uc_fw_status_repr(huc_fw->load_status));
+   seq_printf(m, "\tversion wanted: %d.%d\n",
+   huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted);
+   seq_printf(m, "\tversion found: %d.%d\n",
+   huc_fw->major_ver_found, huc_fw->minor_ver_found);
+   seq_printf(m, "\theader: offset is %d; size = %d\n",
+   huc_fw->header_offset, huc_fw->header_size);
+   seq_printf(m, "\tuCode: offset is %d; size = %d\n",
+   huc_fw->ucode_offset, huc_fw->ucode_size);
+   seq_printf(m, "\tRSA: offset is %d; size = %d\n",
+   huc_fw->rsa_offset, huc_fw->rsa_size);
+
+   seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
+
+   return 0;
+}
+
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4553,6 +4583,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
-- 
2.7.4

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

[Intel-gfx] [PATCH igt] lib: Always unbind the fbcon around igt

[Chris Wilson]

The fbcon imposes unpredictable latencies on tests - each drmIoctl has
been observed to trigger two 650us calls to console_unlock() as it
flushes printk buffer for the DRM_DEBUG around the ioctl. This makes
tests such as gem_wait fail as they expect the ioctl to be spent on the
operation under test not clogged up by the console.

References: https://bugs.freedesktop.org/show_bug.cgi?id=99130
Signed-off-by: Chris Wilson 
---
 lib/igt_core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index a18a728c..403b9423 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -67,6 +67,7 @@
 
 #include "igt_core.h"
 #include "igt_aux.h"
+#include "igt_sysfs.h"
 
 #ifdef HAVE_LIBGEN_H
 #include/* for basename() on Solaris */
@@ -512,6 +513,7 @@ static void common_exit_handler(int sig)
 {
if (!igt_only_list_subtests()) {
low_mem_killer_disable(false);
+   kick_fbcon(true);
}
 
/* When not killed by a signal check that igt_exit() has been properly
@@ -731,6 +733,7 @@ out:
exit(ret == -1 ? 0 : IGT_EXIT_INVALID);
 
if (!list_subtests) {
+   kick_fbcon(false);
kmsg(KERN_INFO "[IGT] %s: executing\n", command_str);
print_version();
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

[Daniel Vetter]

On Wed, Jan 04, 2017 at 10:26:49AM +, Chris Wilson wrote:
> On Wed, Jan 04, 2017 at 11:18:58AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 09:43:51AM +, Chris Wilson wrote:
> > > On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote:
> > > > On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote:
> > > > > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote:
> > > > > > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote:
> > > > > > > 
> > > > > > > On 03/01/2017 11:05, Chris Wilson wrote:
> > > > > > > > As the fence->status is an optional field that may be set before
> > > > > > > > dma_fence_signal() is called to convey that the fence completed 
> > > > > > > > with an
> > > > > > > > error, we have to ensure that it is always set to zero on 
> > > > > > > > initialisation
> > > > > > > > so that the typical use (i.e. unset) always flags a successful 
> > > > > > > > completion.
> > > > > > > > 
> > > > > > > > Signed-off-by: Chris Wilson 
> > > > > > > > ---
> > > > > > > >  drivers/dma-buf/dma-fence.c | 1 +
> > > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > > index 3444f293ad4a..9130f790ebf3 100644
> > > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > > @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, 
> > > > > > > > const struct dma_fence_ops *ops,
> > > > > > > > fence->context = context;
> > > > > > > > fence->seqno = seqno;
> > > > > > > > fence->flags = 0UL;
> > > > > > > > +   fence->status = 0;
> > > > > > > > 
> > > > > > > > trace_dma_fence_init(fence);
> > > > > > > >  }
> > > > > > > > 
> > > > > > > 
> > > > > > > Reviewed-by: Tvrtko Ursulin 
> > > > > > 
> > > > > > Looking at existing users there's only the sync_file stuff. And 
> > > > > > that gets
> > > > > > it wrong, because afaics no one ever sets fence->status to anything
> > > > > > useful. But sync_file blindly assumes it's correct.
> > > > > 
> > > > > In terms of doc, sync_file is using it correctly, and dma-fence isn't
> > > > > living up to its doc. The documented behaviour (sync_file) seems 
> > > > > useful.
> > > > 
> > > > Yeah, it looks like an oversight in merging sync_file and dma_fence
> > > > together, but instead of piecemeal fixing (like this patch does), fixing
> > > > it all might be better.
> > > 
> > > What's missing?
> > > 
> > >   * @status: Optional, only valid if < 0, must be set before calling
> > >   * dma_fence_signal, indicates that the fence has completed with an
> > >   * error.
> > > 
> > > dma-fence must then guarantee that is zeroed during init, then the
> > > drivers can supply the optional information prior to calling
> > > dma_fence_signal()
> > > 
> > > A dma_fence_set_status(fence, status) {
> > >   BUG_ON(test_bit(SIGNALED, >flags);
> > >   BUG_ON(!IS_ERR_VALUE(status));
> > >   BUG_ON(fence->status);
> > >   fence->status = status;
> > > } ?
> > 
> > The trouble I'm seeing is that sync_file.c and sync_debug.c _only_ look at
> > fence->status, and assume that statue > 0 means the fence is singalled.
> > That code doesn't check fence->flags at all ...
> 
> sync_file:
> sync_fill_fence_info() {
>   if (dma_fence_is_signaled(fence))
>   info->status = fence->status >= 0 ? 1 : fence->status;
>   else
>   info->status = 0;
> }
> 
> The no_fences: path is confusing since it sets info.status, but that's a
> different struct entirely.

Ah right, coffee didn't properly kick in this morning ;-)

> sync_debug:
> sync_print_fence() {
>   status = 1;
>   if (dma_fence_is_is_signaled_locked(fence))
>   status = fence->status;
> 
> That's backwards...

Yeah, that's the one I've meant. But it's for debug only

> > So maybe we need to rename status to error_status to make it clear it's
> > for failure modes only, and fix the sync_file code to look at flags, too.
> 
> It is already ^^.
>  
> > Please maybe even some userspace tests to sweeten the deal? Perhaps in our
> > hangstats tests.
> 
> I am already querying the error code in igt.

Excellent, and since sync_file works that explains why igt works ;-)

Can you pls spin some patch to fix up sync_debug, so I can pull it all in?
And I still think s/status/error_status/ would help clarity a lot. And
then maybe even the dma_fence_set_error_status helper from above.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Fix outdated comment.

[Daniel Vetter]

On Wed, Jan 04, 2017 at 11:22:54AM +, Chris Wilson wrote:
> On Wed, Jan 04, 2017 at 12:15:55PM +0100, Maarten Lankhorst wrote:
> > Op 15-12-16 om 16:19 schreef Daniel Vetter:
> > > On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
> > >> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
> > >> different from commit.
> > >>
> > >> Signed-off-by: Maarten Lankhorst 
> > > I think it'd be good to update the kerneldoc for the atomic_commit
> > > callback to mention that drivers should grab their own references using
> > > drm_atomic_state_get() when they need it.
> > >
> > > Applied this one meanwhile, thanks.
> > 
> > --->8---
> > Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> > adds reference counting to atomic state, but didn't update the comments
> > in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more.
> > 
> > Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> > Cc:  # v4.10-rc1+
> > Cc: Chris Wilson 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 681d5f97639d..6492546476b4 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1599,10 +1599,9 @@ EXPORT_SYMBOL(drm_atomic_check_only);
> >   * more locks but encountered a deadlock. The caller must then do the 
> > usual w/w
> >   * backoff dance and restart. All other errors are fatal.
> >   *
> > - * Also note that on successful execution ownership of @state is 
> > transferred
> > - * from the caller of this function to the function itself. The caller 
> > must not
> > - * free or in any other way access @state. If the function fails then the 
> > caller
> > - * must clean up @state itself.
> > + * In earlier versions of the atomic api, the caller was handing its 
> > reference
> > + * of @state over to this function on success. This is no longer the case, 
> > and
> > + * callers should always call drm_atomic_state_put().
> >   *
> >   * Returns:
> >   * 0 on success, negative error code on failure.
> > @@ -1630,10 +1629,9 @@ EXPORT_SYMBOL(drm_atomic_commit);
> >   * more locks but encountered a deadlock. The caller must then do the 
> > usual w/w
> >   * backoff dance and restart. All other errors are fatal.
> >   *
> > - * Also note that on successful execution ownership of @state is 
> > transferred
> > - * from the caller of this function to the function itself. The caller 
> > must not
> > - * free or in any other way access @state. If the function fails then the 
> > caller
> > - * must clean up @state itself.
> > + * In earlier versions of the atomic api, the caller was handing its 
> > reference
> > + * of @state over to this function on success. This is no longer the case, 
> > and
> > + * callers should always call drm_atomic_state_put().
> 
> Reviewed-by: Chris Wilson 
> 
> But do we really want the confusion of mentioning what the api doesn't do
> any more?

Agreed, kerneldoc should state what is (and why), maybe with a FIXME if it
only makes sense with some hystorical context and what should be done
instead. git blame is for figuring out what was.

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

Re: [Intel-gfx] [PATCH] drm/atomic: Fix outdated comment.

[Chris Wilson]

On Wed, Jan 04, 2017 at 12:15:55PM +0100, Maarten Lankhorst wrote:
> Op 15-12-16 om 16:19 schreef Daniel Vetter:
> > On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
> >> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
> >> different from commit.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> > I think it'd be good to update the kerneldoc for the atomic_commit
> > callback to mention that drivers should grab their own references using
> > drm_atomic_state_get() when they need it.
> >
> > Applied this one meanwhile, thanks.
> 
> --->8---
> Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> adds reference counting to atomic state, but didn't update the comments
> in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more.
> 
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc:  # v4.10-rc1+
> Cc: Chris Wilson 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 681d5f97639d..6492546476b4 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1599,10 +1599,9 @@ EXPORT_SYMBOL(drm_atomic_check_only);
>   * more locks but encountered a deadlock. The caller must then do the usual 
> w/w
>   * backoff dance and restart. All other errors are fatal.
>   *
> - * Also note that on successful execution ownership of @state is transferred
> - * from the caller of this function to the function itself. The caller must 
> not
> - * free or in any other way access @state. If the function fails then the 
> caller
> - * must clean up @state itself.
> + * In earlier versions of the atomic api, the caller was handing its 
> reference
> + * of @state over to this function on success. This is no longer the case, 
> and
> + * callers should always call drm_atomic_state_put().
>   *
>   * Returns:
>   * 0 on success, negative error code on failure.
> @@ -1630,10 +1629,9 @@ EXPORT_SYMBOL(drm_atomic_commit);
>   * more locks but encountered a deadlock. The caller must then do the usual 
> w/w
>   * backoff dance and restart. All other errors are fatal.
>   *
> - * Also note that on successful execution ownership of @state is transferred
> - * from the caller of this function to the function itself. The caller must 
> not
> - * free or in any other way access @state. If the function fails then the 
> caller
> - * must clean up @state itself.
> + * In earlier versions of the atomic api, the caller was handing its 
> reference
> + * of @state over to this function on success. This is no longer the case, 
> and
> + * callers should always call drm_atomic_state_put().

Reviewed-by: Chris Wilson 

But do we really want the confusion of mentioning what the api doesn't do
any more?
-Chris

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

[Intel-gfx] [PATCH] drm/atomic: Fix outdated comment.

[Maarten Lankhorst]

Op 15-12-16 om 16:19 schreef Daniel Vetter:
> On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
>> drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
>> different from commit.
>>
>> Signed-off-by: Maarten Lankhorst 
> I think it'd be good to update the kerneldoc for the atomic_commit
> callback to mention that drivers should grab their own references using
> drm_atomic_state_get() when they need it.
>
> Applied this one meanwhile, thanks.

--->8---
Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
adds reference counting to atomic state, but didn't update the comments
in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more.

Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Cc:  # v4.10-rc1+
Cc: Chris Wilson 
Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 681d5f97639d..6492546476b4 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1599,10 +1599,9 @@ EXPORT_SYMBOL(drm_atomic_check_only);
  * more locks but encountered a deadlock. The caller must then do the usual w/w
  * backoff dance and restart. All other errors are fatal.
  *
- * Also note that on successful execution ownership of @state is transferred
- * from the caller of this function to the function itself. The caller must not
- * free or in any other way access @state. If the function fails then the 
caller
- * must clean up @state itself.
+ * In earlier versions of the atomic api, the caller was handing its reference
+ * of @state over to this function on success. This is no longer the case, and
+ * callers should always call drm_atomic_state_put().
  *
  * Returns:
  * 0 on success, negative error code on failure.
@@ -1630,10 +1629,9 @@ EXPORT_SYMBOL(drm_atomic_commit);
  * more locks but encountered a deadlock. The caller must then do the usual w/w
  * backoff dance and restart. All other errors are fatal.
  *
- * Also note that on successful execution ownership of @state is transferred
- * from the caller of this function to the function itself. The caller must not
- * free or in any other way access @state. If the function fails then the 
caller
- * must clean up @state itself.
+ * In earlier versions of the atomic api, the caller was handing its reference
+ * of @state over to this function on success. This is no longer the case, and
+ * callers should always call drm_atomic_state_put().
  *
  * Returns:
  * 0 on success, negative error code on failure.

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

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Peter Frühberger]

Forgot to CC the list, sorry.

On Wed, Jan 4, 2017 at 11:42 AM, Peter Frühberger  wrote:

> Hi Jani,
> thanks for your reply
>
> On Wed, Jan 4, 2017 at 10:34 AM, Jani Nikula 
> wrote:
>
>> On Wed, 04 Jan 2017, Peter Frühberger  wrote:
>> > Hi
>> >
>> > On Sun, Nov 6, 2016 at 1:23 AM, Pandiyan, Dhinakaran <
>> > dhinakaran.pandi...@intel.com> wrote:
>> >
>> >> On Sat, 2016-11-05 at 21:40 +0200, Jani Nikula wrote:
>> >> > On Fri, 04 Nov 2016, "Pandiyan, Dhinakaran" <
>> >> dhinakaran.pandi...@intel.com> wrote:
>> >> > > On Fri, 2016-11-04 at 17:48 +0200, Jani Nikula wrote:
>> >> > >> On Wed, 26 Oct 2016, Dhinakaran Pandiyan <
>> >> dhinakaran.pandi...@intel.com> wrote:
>> >> > >> > Enabling DP audio stall fix is necessary to play audio over DP
>> >> HBR2. So,
>> >> > >> > let's set this bit right before enabling the audio codec.
>> Playing
>> >> audio
>> >> > >> > without setting this bit results in pipe FIFO underruns.
>> >> > >> >
>> >> > >> > This workaround is applicable only for audio sample rates up to
>> >> 96kHz. For
>> >> > >> > frequencies above 96kHz, this is insufficient and cdclk should
>> be
>> >> increased
>> >> > >> > to at least 432 MHz, just like BDW. Since, the audio driver
>> does not
>> >> > >> > support sample rates > 48 kHz, we are safe with this fix for
>> now.
>> >> > >>
>> >> > >> Do we still need this patch now that these two have been pushed?
>> >> > >>
>> >> > >> b30ce9e0552a drm/i915/dp: BDW cdclk fix for DP audio
>> >> > >> 9c7540241885 drm/i915/dp: Extend BDW DP audio workaround to GEN9
>> >> platforms
>> >> > >>
>> >> > >> BR,
>> >> > >> Jani.
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >
>> >> > > No, we are good afaik. This patch would have helped us to make use
>> of a
>> >> > > lower cdclk (337.5 MHz), with constraints on audio bit rate.
>> Operating
>> >> > > at 432 MHz, like we do now, rules out the need for this patch.
>> >> >
>> >> > Hmm, what about 5.4 Gbps link with 1 or 2 lanes?
>> >> >
>> >> > BR,
>> >> > Jani.
>> >> >
>> >>
>> >> Good point, I think it will depend on the audio sampling rate. But, I
>> >> have to figure out a way to play high sampling rate audio (> 96 KHz)
>> and
>> >> test 5.4 Gbps with 1 or 2 lanes.
>> >>
>> >> The other option is to play safe and apply this patch with even lesser
>> >> restrictions, say link rate >= 2.7 Gbps.
>> >>
>> >>
>> >> -DK
>> >>
>> >
>> > as we are currently talking about high samplerates in this context. I
>> > wanted to post a perhaps related issue. On my Apollo Lake (J4205) I have
>> > two outputs. One DVI and one HDMI 2.0 via internal DP. Via DVI the
>> > following works without issues, via DP it fails. As the original commit
>> > mentions HBR, I think there is still something missing. We submit
>> TrueHD,
>> > DTS-HD via 192 khz and 16 bit format while setting AES0=2
>> >
>> > You can easily reproduce with (you obviously need a DTS-HD, TrueHD
>> capable
>> > AVR attached to your HDMI 2.0 (DP) out):
>>
>> Just to clarify, is the DP -> HDMI2.0 converter internal to the machine?
>> LSPCON related messages in the dmesg with drm.debug=14? Do you have a DP
>> or an HDMI physical connector in the chassis?
>>
>
> The chip used is: https://media.digikey.com/pdf/Data%20Sheets/MegaChips%
> 20PDFs/MCDP28x0_Datasheet.pdf which is the same on all intel nucs,
> including the new Kabilake ones. So it's internal.
> Mainboard: http://www.asrock.com/MB/Intel/J4205-ITX/index.us.asp (DVI-D,
> HDMI (2.0 via this above chip), VGA)
> Here is the output of the a boot up with drm.debug=14:
> http://paste.ubuntu.com/23738282/
> (I used a pastebin site to not spam the ML, is that okay for the future?)
>
> Best regards
> Peter
>
>
>>
>>
>> BR,
>> Jani.
>>
>> >
>> > #TrueHD
>> > aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=2' -c8 -fs16_le -r192000
>> > testi.truehd.anssi1.ff.60s.spdif
>> > #DTS-HD
>> > aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=2' -c8 -fs16_le -r192000
>> > testi.dtshd.anssi1.ma-71-24.spdif
>> > Samples:
>> > http://www.avenard.org/files/media/mediatest/audiotest/HDAUD
>> IO/Passthrough/
>> >
>> > For the old HDMI 1.x chips it was fixed via:
>> > https://bugs.freedesktop.org/show_bug.cgi?id=49055
>> >
>> > Is this also planned for DP within that patch series?
>> >
>> > Best regards
>> > Peter
>> >
>> >>
>> >> > >
>> >> > > -DK
>> >> > >
>> >> > >> >
>> >> > >> > v2: Inlined the code change within hsw_audio_codec_enable()
>> (Jani)
>> >> > >> > Fixed the port clock typo
>> >> > >> > Added TODO comment
>> >> > >> > Signed-off-by: Dhinakaran Pandiyan <
>> dhinakaran.pandi...@intel.com>
>> >> > >> > ---
>> >> > >> >  drivers/gpu/drm/i915/i915_reg.h|  5 +
>> >> > >> >  drivers/gpu/drm/i915/intel_audio.c | 30
>> >> +-
>> >> > >> >  2 files changed, 34 insertions(+), 1 deletion(-)
>> >> > >> >
>> >> > >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> >> b/drivers/gpu/drm/i915/i915_reg.h
>> >> > >> > index 00efaa1..76dac48 100644
>> >> > >> > --- 

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

[Chris Wilson]

On Wed, Jan 04, 2017 at 11:18:58AM +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 09:43:51AM +, Chris Wilson wrote:
> > On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote:
> > > > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote:
> > > > > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote:
> > > > > > 
> > > > > > On 03/01/2017 11:05, Chris Wilson wrote:
> > > > > > > As the fence->status is an optional field that may be set before
> > > > > > > dma_fence_signal() is called to convey that the fence completed 
> > > > > > > with an
> > > > > > > error, we have to ensure that it is always set to zero on 
> > > > > > > initialisation
> > > > > > > so that the typical use (i.e. unset) always flags a successful 
> > > > > > > completion.
> > > > > > > 
> > > > > > > Signed-off-by: Chris Wilson 
> > > > > > > ---
> > > > > > >  drivers/dma-buf/dma-fence.c | 1 +
> > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > > index 3444f293ad4a..9130f790ebf3 100644
> > > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > > @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const 
> > > > > > > struct dma_fence_ops *ops,
> > > > > > >   fence->context = context;
> > > > > > >   fence->seqno = seqno;
> > > > > > >   fence->flags = 0UL;
> > > > > > > + fence->status = 0;
> > > > > > > 
> > > > > > >   trace_dma_fence_init(fence);
> > > > > > >  }
> > > > > > > 
> > > > > > 
> > > > > > Reviewed-by: Tvrtko Ursulin 
> > > > > 
> > > > > Looking at existing users there's only the sync_file stuff. And that 
> > > > > gets
> > > > > it wrong, because afaics no one ever sets fence->status to anything
> > > > > useful. But sync_file blindly assumes it's correct.
> > > > 
> > > > In terms of doc, sync_file is using it correctly, and dma-fence isn't
> > > > living up to its doc. The documented behaviour (sync_file) seems useful.
> > > 
> > > Yeah, it looks like an oversight in merging sync_file and dma_fence
> > > together, but instead of piecemeal fixing (like this patch does), fixing
> > > it all might be better.
> > 
> > What's missing?
> > 
> >   * @status: Optional, only valid if < 0, must be set before calling
> >   * dma_fence_signal, indicates that the fence has completed with an
> >   * error.
> > 
> > dma-fence must then guarantee that is zeroed during init, then the
> > drivers can supply the optional information prior to calling
> > dma_fence_signal()
> > 
> > A dma_fence_set_status(fence, status) {
> > BUG_ON(test_bit(SIGNALED, >flags);
> > BUG_ON(!IS_ERR_VALUE(status));
> > BUG_ON(fence->status);
> > fence->status = status;
> > } ?
> 
> The trouble I'm seeing is that sync_file.c and sync_debug.c _only_ look at
> fence->status, and assume that statue > 0 means the fence is singalled.
> That code doesn't check fence->flags at all ...

sync_file:
sync_fill_fence_info() {
if (dma_fence_is_signaled(fence))
info->status = fence->status >= 0 ? 1 : fence->status;
else
info->status = 0;
}

The no_fences: path is confusing since it sets info.status, but that's a
different struct entirely.

sync_debug:
sync_print_fence() {
status = 1;
if (dma_fence_is_is_signaled_locked(fence))
status = fence->status;

That's backwards...

> So maybe we need to rename status to error_status to make it clear it's
> for failure modes only, and fix the sync_file code to look at flags, too.

It is already ^^.
 
> Please maybe even some userspace tests to sweeten the deal? Perhaps in our
> hangstats tests.

I am already querying the error code in igt.
-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: add fourcc codes for 16bit R and GR

[Eric Engestrom]

On Wednesday, 2017-01-04 11:06:09 +0200, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Daniel Vetter  wrote:
> > On Tue, Jan 03, 2017 at 08:02:07PM +0100, Rainer Hochecker wrote:
> >> From: Rainer Hochecker 
> >> 
> >> Now sent with git send-email:
> >> 
> >> Signed-off-by: Rainer Hochecker 
> >> ---
> >>  include/uapi/drm/drm_fourcc.h | 7 +++
> >>  1 file changed, 7 insertions(+)
> >> 
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index a5890bf..f1ef9cb 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -41,10 +41,17 @@ extern "C" {
> >>  /* 8 bpp Red */
> >>  #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* 
> >> [7:0] R */
> >>  
> >> +/* 16 bpp Red */
> >> +#define DRM_FORMAT_R16fourcc_code('R', '1', '6', ' ') /* 
> >> [15:0] R */
> >> +
> >>  /* 16 bpp RG */
> >>  #define DRM_FORMAT_RG88   fourcc_code('R', 'G', '8', '8') /* 
> >> [15:0] R:G 8:8 little endian */
> >>  #define DRM_FORMAT_GR88   fourcc_code('G', 'R', '8', '8') /* 
> >> [15:0] G:R 8:8 little endian */
> >>  
> >> +/* 32 bpp GR */
> >> +#define DRM_FORMAT_RG32   fourcc_code('R', 'G', '3', '2') /* 
> >> [31:0] G:R 16:16 little endian */

Also, s/G:R/R:G/ in the comment above :)

> >> +#define DRM_FORMAT_GR32   fourcc_code('G', 'R', '3', '2') /* 
> >> [31:0] G:R 16:16 little endian */
> >
> > Now the define's name is inconsistent, since that would suggest a 5 bpp
> > format with 3 bits for R and 2 bits for G. I think what we want here for
> > consistency is _RG16_16 and _GR16_16, along the lines of what Ville
> > suggested.
> >
> > Sorry that this is such a bikeshed heaven ;-)
> 
> If there's going to be another version, please fix the commit message
> while at it. "Now sent with git send-email" is useless for posterity.
> 
> BR,
> Jani.
> 
> 
> > -Daniel
> >
> >> +
> >>  /* 8 bpp RGB */
> >>  #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
> >> 3:3:2 */
> >>  #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
> >> 2:3:3 */
> >> -- 
> >> 2.9.3
> >> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

[Daniel Vetter]

On Wed, Jan 04, 2017 at 09:43:51AM +, Chris Wilson wrote:
> On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote:
> > > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote:
> > > > > 
> > > > > On 03/01/2017 11:05, Chris Wilson wrote:
> > > > > > As the fence->status is an optional field that may be set before
> > > > > > dma_fence_signal() is called to convey that the fence completed 
> > > > > > with an
> > > > > > error, we have to ensure that it is always set to zero on 
> > > > > > initialisation
> > > > > > so that the typical use (i.e. unset) always flags a successful 
> > > > > > completion.
> > > > > > 
> > > > > > Signed-off-by: Chris Wilson 
> > > > > > ---
> > > > > >  drivers/dma-buf/dma-fence.c | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > > 
> > > > > > diff --git a/drivers/dma-buf/dma-fence.c 
> > > > > > b/drivers/dma-buf/dma-fence.c
> > > > > > index 3444f293ad4a..9130f790ebf3 100644
> > > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > > @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const 
> > > > > > struct dma_fence_ops *ops,
> > > > > > fence->context = context;
> > > > > > fence->seqno = seqno;
> > > > > > fence->flags = 0UL;
> > > > > > +   fence->status = 0;
> > > > > > 
> > > > > > trace_dma_fence_init(fence);
> > > > > >  }
> > > > > > 
> > > > > 
> > > > > Reviewed-by: Tvrtko Ursulin 
> > > > 
> > > > Looking at existing users there's only the sync_file stuff. And that 
> > > > gets
> > > > it wrong, because afaics no one ever sets fence->status to anything
> > > > useful. But sync_file blindly assumes it's correct.
> > > 
> > > In terms of doc, sync_file is using it correctly, and dma-fence isn't
> > > living up to its doc. The documented behaviour (sync_file) seems useful.
> > 
> > Yeah, it looks like an oversight in merging sync_file and dma_fence
> > together, but instead of piecemeal fixing (like this patch does), fixing
> > it all might be better.
> 
> What's missing?
> 
>   * @status: Optional, only valid if < 0, must be set before calling
>   * dma_fence_signal, indicates that the fence has completed with an
>   * error.
> 
> dma-fence must then guarantee that is zeroed during init, then the
> drivers can supply the optional information prior to calling
> dma_fence_signal()
> 
> A dma_fence_set_status(fence, status) {
>   BUG_ON(test_bit(SIGNALED, >flags);
>   BUG_ON(!IS_ERR_VALUE(status));
>   BUG_ON(fence->status);
>   fence->status = status;
> } ?

The trouble I'm seeing is that sync_file.c and sync_debug.c _only_ look at
fence->status, and assume that statue > 0 means the fence is singalled.
That code doesn't check fence->flags at all ...

So maybe we need to rename status to error_status to make it clear it's
for failure modes only, and fix the sync_file code to look at flags, too.

Please maybe even some userspace tests to sweeten the deal? Perhaps in our
hangstats tests.
-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 1/2] drm: refernce count event->completion

[Daniel Vetter]

On Wed, Dec 21, 2016 at 12:08:45PM +0100, Maarten Lankhorst wrote:
> Op 21-12-16 om 11:36 schreef Chris Wilson:
> > On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
> >> When writing the generic nonblocking commit code I assumed that
> >> through clever lifetime management I can assure that the completion
> >> (stored in drm_crtc_commit) only gets freed after it is completed. And
> >> that worked.
> >>
> >> I also wanted to make nonblocking helpers resilient against driver
> >> bugs, by having timeouts everywhere. And that worked too.
> >>
> >> Unfortunately taking boths things together results in oopses :( Well,
> >> at least sometimes: What seems to happen is that the drm event hangs
> >> around forever stuck in limbo land. The nonblocking helpers eventually
> >> time out, move on and release it. Now the bug I tested all this
> >> against is drivers that just entirely fail to deliver the vblank
> >> events like they should, and in those cases the event is simply
> >> leaked. But what seems to happen, at least sometimes, on i915 is that
> >> the event is set up correctly, but somohow the vblank fails to fire in
> >> time. Which means the event isn't leaked, it's still there waiting for
> >> evevntually a vblank to fire. That tends to happen when re-enabling the
> >> pipe, and then the trap springs and the kernel oopses.
> >>
> >> The correct fix here is simply to refcount the crtc commit to make
> >> sure that the event sticks around even for drivers which only
> >> sometimes fail to deliver vblanks for some arbitrary reasons. Since
> >> crtc commits are already refcounted that's easy to do.
> > Or make the event a part of the atomic state?
> > -Chris
> >
> afaict crtc commit is already taken to wait for completion, so this patch 
> makes sense.
> 
> There's just a minor typo in the subject. :)
> Not sure that release_commit should be a function pointer, regardless..
> 
> Reviewed-by: Maarten Lankhorst 

It didn't help the bug reporters against oopses (but the reporters are
supremely confusing, I have no idea what's really being tested, the
bugzilla is a mess), but I still think the patch is useful for more
robuestness, I dropped the cc: stable and applied it to drm-misc.

Thanks for the review.
-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 1/2] dma-fence: Clear fence->status during dma_fence_init()

[Chris Wilson]

On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote:
> > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote:
> > > > 
> > > > On 03/01/2017 11:05, Chris Wilson wrote:
> > > > > As the fence->status is an optional field that may be set before
> > > > > dma_fence_signal() is called to convey that the fence completed with 
> > > > > an
> > > > > error, we have to ensure that it is always set to zero on 
> > > > > initialisation
> > > > > so that the typical use (i.e. unset) always flags a successful 
> > > > > completion.
> > > > > 
> > > > > Signed-off-by: Chris Wilson 
> > > > > ---
> > > > >  drivers/dma-buf/dma-fence.c | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > > > > index 3444f293ad4a..9130f790ebf3 100644
> > > > > --- a/drivers/dma-buf/dma-fence.c
> > > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > > @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const 
> > > > > struct dma_fence_ops *ops,
> > > > >   fence->context = context;
> > > > >   fence->seqno = seqno;
> > > > >   fence->flags = 0UL;
> > > > > + fence->status = 0;
> > > > > 
> > > > >   trace_dma_fence_init(fence);
> > > > >  }
> > > > > 
> > > > 
> > > > Reviewed-by: Tvrtko Ursulin 
> > > 
> > > Looking at existing users there's only the sync_file stuff. And that gets
> > > it wrong, because afaics no one ever sets fence->status to anything
> > > useful. But sync_file blindly assumes it's correct.
> > 
> > In terms of doc, sync_file is using it correctly, and dma-fence isn't
> > living up to its doc. The documented behaviour (sync_file) seems useful.
> 
> Yeah, it looks like an oversight in merging sync_file and dma_fence
> together, but instead of piecemeal fixing (like this patch does), fixing
> it all might be better.

What's missing?

  * @status: Optional, only valid if < 0, must be set before calling
  * dma_fence_signal, indicates that the fence has completed with an
  * error.

dma-fence must then guarantee that is zeroed during init, then the
drivers can supply the optional information prior to calling
dma_fence_signal()

A dma_fence_set_status(fence, status) {
BUG_ON(test_bit(SIGNALED, >flags);
BUG_ON(!IS_ERR_VALUE(status));
BUG_ON(fence->status);
fence->status = status;
} ?
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

[Daniel Vetter]

On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote:
> On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote:
> > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote:
> > > 
> > > On 03/01/2017 11:05, Chris Wilson wrote:
> > > > As the fence->status is an optional field that may be set before
> > > > dma_fence_signal() is called to convey that the fence completed with an
> > > > error, we have to ensure that it is always set to zero on initialisation
> > > > so that the typical use (i.e. unset) always flags a successful 
> > > > completion.
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > ---
> > > >  drivers/dma-buf/dma-fence.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > > > index 3444f293ad4a..9130f790ebf3 100644
> > > > --- a/drivers/dma-buf/dma-fence.c
> > > > +++ b/drivers/dma-buf/dma-fence.c
> > > > @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const 
> > > > struct dma_fence_ops *ops,
> > > > fence->context = context;
> > > > fence->seqno = seqno;
> > > > fence->flags = 0UL;
> > > > +   fence->status = 0;
> > > > 
> > > > trace_dma_fence_init(fence);
> > > >  }
> > > > 
> > > 
> > > Reviewed-by: Tvrtko Ursulin 
> > 
> > Looking at existing users there's only the sync_file stuff. And that gets
> > it wrong, because afaics no one ever sets fence->status to anything
> > useful. But sync_file blindly assumes it's correct.
> 
> In terms of doc, sync_file is using it correctly, and dma-fence isn't
> living up to its doc. The documented behaviour (sync_file) seems useful.

Yeah, it looks like an oversight in merging sync_file and dma_fence
together, but instead of piecemeal fixing (like this patch does), fixing
it all might be better.
-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 0/6] Introduce DP MST Topology state

[Daniel Vetter]

On Tue, Jan 03, 2017 at 01:01:45PM -0800, Dhinakaran Pandiyan wrote:
> Link bandwidth is shared between multiple display streams in DP MST
> configurations. The DP MST topology manager structure maintains the shared
> link bandwidth for a primary link directly connected to the GPU. For atomic
> modesetting drivers, checking if there is sufficient link bandwidth for a
> mode needs to be done during the atomic_check phase to avoid failed
> modesets.
> 
> This series adds dp_mst_topology_state to track available link bw for
> atomic modesets and MST helpers to find and release link bw in terms of
> vcpi time slots. Using the new helpers is optional and the changes should
> not affect drivers that don't support atomic modesetting. I have made
> changes to i915 to use the new helpers, but this should be applicable to
> nouveau as well.
> 
> Patches 1-3/6 include cleanups and refactoring.
> Patch 4/6 adds the MST topology state, 5/6 adds helpers to alter the state
> and 6/6 contains i915 changes to use the helpers .

Please also cc amdgpu and nouveau maintainers on these patches, they both
will need it.
-Daniel

> 
> Dhinakaran Pandiyan (6):
>   drm/dp: Store drm_device in MST topology manager
>   drm/dp: Kill unused MST vcpi slot availability tracking
>   drm/dp: Split drm_dp_mst_allocate_vcpi
>   drm/dp: Introduce DP MST topology manager state to track DP link bw
>   drm/dp: Add DP MST helpers to atomically find and release vcpi slots
>   drm/i915/dp: Track available DP MST vcpi time slots
> 
>  drivers/gpu/drm/drm_atomic.c   | 66 +
>  drivers/gpu/drm/drm_atomic_helper.c| 10 
>  drivers/gpu/drm/drm_dp_mst_topology.c  | 89 
> ++
>  drivers/gpu/drm/i915/intel_display.c   | 39 ++-
>  drivers/gpu/drm/i915/intel_dp_mst.c| 42 ++--
>  drivers/gpu/drm/i915/intel_drv.h   |  3 ++
>  drivers/gpu/drm/nouveau/nv50_display.c |  5 +-
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  5 +-
>  include/drm/drm_atomic.h   | 11 +
>  include/drm/drm_dp_mst_helper.h| 35 -
>  10 files changed, 263 insertions(+), 42 deletions(-)
> 
> -- 
> 2.7.4
> 
> ___
> 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 v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Jani Nikula]

On Wed, 04 Jan 2017, Peter Frühberger  wrote:
> Hi
>
> On Sun, Nov 6, 2016 at 1:23 AM, Pandiyan, Dhinakaran <
> dhinakaran.pandi...@intel.com> wrote:
>
>> On Sat, 2016-11-05 at 21:40 +0200, Jani Nikula wrote:
>> > On Fri, 04 Nov 2016, "Pandiyan, Dhinakaran" <
>> dhinakaran.pandi...@intel.com> wrote:
>> > > On Fri, 2016-11-04 at 17:48 +0200, Jani Nikula wrote:
>> > >> On Wed, 26 Oct 2016, Dhinakaran Pandiyan <
>> dhinakaran.pandi...@intel.com> wrote:
>> > >> > Enabling DP audio stall fix is necessary to play audio over DP
>> HBR2. So,
>> > >> > let's set this bit right before enabling the audio codec. Playing
>> audio
>> > >> > without setting this bit results in pipe FIFO underruns.
>> > >> >
>> > >> > This workaround is applicable only for audio sample rates up to
>> 96kHz. For
>> > >> > frequencies above 96kHz, this is insufficient and cdclk should be
>> increased
>> > >> > to at least 432 MHz, just like BDW. Since, the audio driver does not
>> > >> > support sample rates > 48 kHz, we are safe with this fix for now.
>> > >>
>> > >> Do we still need this patch now that these two have been pushed?
>> > >>
>> > >> b30ce9e0552a drm/i915/dp: BDW cdclk fix for DP audio
>> > >> 9c7540241885 drm/i915/dp: Extend BDW DP audio workaround to GEN9
>> platforms
>> > >>
>> > >> BR,
>> > >> Jani.
>> > >>
>> > >>
>> > >>
>> > >
>> > > No, we are good afaik. This patch would have helped us to make use of a
>> > > lower cdclk (337.5 MHz), with constraints on audio bit rate. Operating
>> > > at 432 MHz, like we do now, rules out the need for this patch.
>> >
>> > Hmm, what about 5.4 Gbps link with 1 or 2 lanes?
>> >
>> > BR,
>> > Jani.
>> >
>>
>> Good point, I think it will depend on the audio sampling rate. But, I
>> have to figure out a way to play high sampling rate audio (> 96 KHz) and
>> test 5.4 Gbps with 1 or 2 lanes.
>>
>> The other option is to play safe and apply this patch with even lesser
>> restrictions, say link rate >= 2.7 Gbps.
>>
>>
>> -DK
>>
>
> as we are currently talking about high samplerates in this context. I
> wanted to post a perhaps related issue. On my Apollo Lake (J4205) I have
> two outputs. One DVI and one HDMI 2.0 via internal DP. Via DVI the
> following works without issues, via DP it fails. As the original commit
> mentions HBR, I think there is still something missing. We submit TrueHD,
> DTS-HD via 192 khz and 16 bit format while setting AES0=2
>
> You can easily reproduce with (you obviously need a DTS-HD, TrueHD capable
> AVR attached to your HDMI 2.0 (DP) out):

Just to clarify, is the DP -> HDMI2.0 converter internal to the machine?
LSPCON related messages in the dmesg with drm.debug=14? Do you have a DP
or an HDMI physical connector in the chassis?


BR,
Jani.

>
> #TrueHD
> aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=2' -c8 -fs16_le -r192000
> testi.truehd.anssi1.ff.60s.spdif
> #DTS-HD
> aplay -D 'hdmi:CARD=PCH,DEV=0,AES0=2' -c8 -fs16_le -r192000
> testi.dtshd.anssi1.ma-71-24.spdif
> Samples:
> http://www.avenard.org/files/media/mediatest/audiotest/HDAUDIO/Passthrough/
>
> For the old HDMI 1.x chips it was fixed via:
> https://bugs.freedesktop.org/show_bug.cgi?id=49055
>
> Is this also planned for DP within that patch series?
>
> Best regards
> Peter
>
>>
>> > >
>> > > -DK
>> > >
>> > >> >
>> > >> > v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
>> > >> > Fixed the port clock typo
>> > >> > Added TODO comment
>> > >> > Signed-off-by: Dhinakaran Pandiyan 
>> > >> > ---
>> > >> >  drivers/gpu/drm/i915/i915_reg.h|  5 +
>> > >> >  drivers/gpu/drm/i915/intel_audio.c | 30
>> +-
>> > >> >  2 files changed, 34 insertions(+), 1 deletion(-)
>> > >> >
>> > >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> > >> > index 00efaa1..76dac48 100644
>> > >> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > >> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > >> > @@ -6236,6 +6236,11 @@ enum {
>> > >> >  #define SLICE_ECO_CHICKEN0  _MMIO(0x7308)
>> > >> >  #define   PIXEL_MASK_CAMMING_DISABLE(1 << 14)
>> > >> >
>> > >> > +#define _CHICKEN_TRANS_A0x420C0
>> > >> > +#define _CHICKEN_TRANS_B0x420C4
>> > >> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A,
>> _CHICKEN_TRANS_B)
>> > >> > +#define SPARE_13(1<<13)
>> > >> > +
>> > >> >  /* WaCatErrorRejectionIssue */
>> > >> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG  _MMIO(0x9030)
>> > >> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB   (1<<11)
>> > >> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> b/drivers/gpu/drm/i915/intel_audio.c
>> > >> > index 7093cfb..894f11e 100644
>> > >> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > >> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > >> > @@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct
>> intel_encoder *encoder)
>> > >> >  {
>> > >> >  struct drm_i915_private *dev_priv =
>> 

Re: [Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

[Daniel Vetter]

On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote:
> Link bandwidth is shared between multiple display streams in DP MST
> configurations. The DP MST topology manager structure maintains the shared
> link bandwidth for a primary link directly connected to the GPU. For atomic
> modesetting drivers, checking if there is sufficient link bandwidth for a
> mode needs to be done during the atomic_check phase to avoid failed
> modesets. Let's encsapsulate the available link bw information in a state
> structure so that bw can be allocated and released atomically for each of
> the ports sharing the primary link.
> 
> Signed-off-by: Dhinakaran Pandiyan 

Overall issue with the patch is that dp helpers now have 2 places where
available_slots is stored: One for atomic drivers in ->state, and the
legacy one. I think it'd be good to rework the legacy codepaths (i.e.
drm_dp_find_vcpi_slots) to use mgr->state->avail_slots, and remove
mgr->avail_slots entirely.

Another design concern below, but in principle this looks like what we
need.
-Daniel


> ---
>  drivers/gpu/drm/drm_atomic.c  | 66 
> +++
>  drivers/gpu/drm/drm_atomic_helper.c   | 10 ++
>  drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
>  include/drm/drm_atomic.h  | 13 +++
>  include/drm/drm_dp_mst_helper.h   | 13 +++
>  5 files changed, 112 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 681d5f9..b8e2cea 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "drm_crtc_internal.h"
> @@ -62,6 +63,7 @@ void drm_atomic_state_default_release(struct 
> drm_atomic_state *state)
>   kfree(state->connectors);
>   kfree(state->crtcs);
>   kfree(state->planes);
> + kfree(state->dp_mst_topologies);
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_release);
>  
> @@ -189,6 +191,18 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   state->planes[i].ptr = NULL;
>   state->planes[i].state = NULL;
>   }
> +
> + for (i = 0; i < state->num_mst_topologies; i++) {
> + struct drm_dp_mst_topology_mgr *mgr = 
> state->dp_mst_topologies[i].ptr;
> +
> + if (!mgr)
> + continue;
> +
> + kfree(state->dp_mst_topologies[i].state);
> + state->dp_mst_topologies[i].ptr = NULL;
> + state->dp_mst_topologies[i].state = NULL;
> + }
> +
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
>  
> @@ -981,6 +995,58 @@ static void drm_atomic_plane_print_state(struct 
> drm_printer *p,
>   plane->funcs->atomic_print_state(p, state);
>  }
>  
> +struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
> drm_atomic_state *state,
> + struct drm_dp_mst_topology_mgr *mgr)
> +{
> +
> + int ret, i;
> + size_t new_size;
> + struct __drm_dp_mst_topology_state *new_arr;
> + struct drm_dp_mst_topology_state *new_mst_state;
> + int num_topologies;
> + struct drm_mode_config *config = >dev->mode_config;
> +
> + WARN_ON(!state->acquire_ctx);
> +
> + ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + for (i = 0; i < state->num_mst_topologies; i++) {
> + if (mgr == state->dp_mst_topologies[i].ptr &&
> + state->dp_mst_topologies[i].state) {
> + return state->dp_mst_topologies[i].state;
> + }
> + }
> +
> + num_topologies = state->num_mst_topologies + 1;
> + new_size = sizeof(*state->dp_mst_topologies) * num_topologies;
> + new_arr = krealloc(state->dp_mst_topologies, new_size, GFP_KERNEL);
> + if (!new_arr)
> + return ERR_PTR(-ENOMEM);
> +
> + state->dp_mst_topologies = new_arr;
> + memset(>dp_mst_topologies[state->num_mst_topologies], 0,
> + sizeof(*state->dp_mst_topologies));
> +
> + new_mst_state = kmalloc(sizeof(*mgr->state), GFP_KERNEL);
> + if (!new_mst_state)
> + return ERR_PTR(-ENOMEM);
> +
> + new_mst_state->avail_slots = mgr->state->avail_slots;
> + state->dp_mst_topologies[state->num_mst_topologies].state = 
> new_mst_state;
> + state->dp_mst_topologies[state->num_mst_topologies].ptr = mgr;
> + state->num_mst_topologies = num_topologies;
> + new_mst_state->mgr = mgr;
> + mgr->state->state = state;
> +
> + DRM_DEBUG_ATOMIC("Added [MST Topology w/ base connector:%d] %p state to 
> %p\n",
> +  mgr->conn_base_id, new_mst_state, state);
> +
> + return new_mst_state;
> +}
> +EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
> +
>  /**
>   * drm_atomic_get_connector_state - get connector state
>   * @state: global atomic state object
> 

Re: [Intel-gfx] [PATCH 6/6] drm/i915/dp: Track available DP MST vcpi time slots

[Daniel Vetter]

On Tue, Jan 03, 2017 at 01:01:51PM -0800, Dhinakaran Pandiyan wrote:
> Make use of the added MST helpers to find, allocate and release link bw
> for atomic modesets.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 39 
> +++-
>  drivers/gpu/drm/i915/intel_dp_mst.c  | 36 -
>  drivers/gpu/drm/i915/intel_drv.h |  3 +++
>  3 files changed, 76 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ab72858..71e2ac7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14072,6 +14072,40 @@ static int calc_watermark_data(struct 
> drm_atomic_state *state)
>   return 0;
>  }
>  
> +static int intel_mst_clear_config(struct drm_atomic_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + struct drm_connector *connector;
> + struct drm_connector_state *connector_state;
> + int i, j;
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc_state->active_changed || crtc_state->active)
> + continue;

I don't think the double-loop is needed.

> +
> + for_each_connector_in_state(state, connector, connector_state, 
> j) {
> + struct intel_encoder *encoder;
> + struct drm_crtc *curr_crtc;
> + int slots;
> +
> + encoder = 
> to_intel_encoder(connector->state->best_encoder);
> + if (encoder->type != INTEL_OUTPUT_DP_MST)
> + continue;
> +
> + curr_crtc = connector->state->crtc;
> + if (curr_crtc && crtc == curr_crtc) {
> + slots = 
> to_intel_crtc_state(crtc->state)->dp_m_n.tu;
> + return intel_dp_mst_reset_vcpi(encoder,
> +connector_state,
> +slots);
> + }

Hm, I think it might be useful to have a generic atomic_release function
for connectors in the core atomic helpers. E.g. something like the below:


diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index b4dfd1e1a4f0..ce55e87b50e5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -385,8 +385,12 @@ mode_fixup(struct drm_atomic_state *state)
 
WARN_ON(!!conn_state->best_encoder != !!conn_state->crtc);
 
-   if (!conn_state->crtc || !conn_state->best_encoder)
+   if (!conn_state->crtc || !conn_state->best_encoder) {
+   if (connector->helper_private->atomic_release)
+   
connector->helper_private->atomic_release(connector,
+ 
conn_state);
continue;
+   }
 
crtc_state = drm_atomic_get_existing_crtc_state(state,

conn_state->crtc);


I think we'll have other connectors in the future where we need to drop
shared resources in a similar fashion.

Cheers, Daniel


> + }
> + }
> +
> + return 0;
> +}
> +
>  /**
>   * intel_atomic_check - validate state object
>   * @dev: drm device
> @@ -14142,8 +14176,11 @@ static int intel_atomic_check(struct drm_device *dev,
>   }
>  
>   if (any_ms) {
> - ret = intel_modeset_checks(state);
> + ret = intel_mst_clear_config(state);
> + if (ret)
> + return ret;
>  
> + ret = intel_modeset_checks(state);
>   if (ret)
>   return ret;
>   } else {
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 02a1e2c..331909b 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -44,6 +44,7 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   int lane_count, slots;
>   const struct drm_display_mode *adjusted_mode = 
> _config->base.adjusted_mode;
>   int mst_pbn;
> + struct drm_dp_mst_topology_state *topology_state;
>  
>   pipe_config->has_pch_encoder = false;
>   bpp = 24;
> @@ -65,7 +66,18 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
>  
>   pipe_config->pbn = mst_pbn;
> - slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
> +
> + topology_state = drm_atomic_get_mst_topology_state(state,
> +_dp->mst_mgr);
> + if