[Intel-gfx] ✓ Fi.CI.BAT: success for Enhancement to intel_dp_aux_backlight driver (rev6)

[Patchwork]

== Series Details ==

Series: Enhancement to intel_dp_aux_backlight driver (rev6)
URL   : https://patchwork.freedesktop.org/series/21086/
State : success

== Summary ==

Series 21086v6 Enhancement to intel_dp_aux_backlight driver
https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/6/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:430s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:589s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:515s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:558s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:500s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:493s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:496s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:632s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:461s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:578s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:470s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:413s

51350ea90d1a5c8bb7e6532eb61c64a57e83ab9b drm-tip: 2017y-05m-11d-13h-05m-06s UTC 
integration manifest
7b72965 drm/i915: Set PWM divider to match desired frequency in vbt
1020108 drm: Add definition for eDP backlight frequency
b52777c drm/i915: Restore brightness level in aux backlight driver
8409812 drm/i915: Add option to support dynamic backlight via DPCD
1ede9a2 drm/i915: Set backlight mode before enable backlight
f596728 drm/i915: Allow choosing how to adjust brightness if both supported
41a4958 drm/i915: Drop AUX backlight enable check for backlight control
d34cb86 drm/i915: Correctly enable backlight brightness adjustment via DPCD
1e5dac5 drm/i915: Fix cap check for intel_dp_aux_backlight driver

== Logs ==

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

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

[kbuild test robot]

Hi Weinan,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.11 next-20170511]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Weinan-Li/drm-i915-gvt-return-the-correct-usable-aperture-size-under-gvt-environment/20170511-170356
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/i915_vgpu.c: In function 'intel_vgt_deballoon':
>> drivers/gpu//drm/i915/i915_vgpu.c:113:18: error: invalid type argument of 
>> '->' (have 'struct i915_ggtt')
   dev_priv->ggtt->base.reserved -= bl_info.space[i].size;
 ^~

vim +113 drivers/gpu//drm/i915/i915_vgpu.c

97   * @dev_priv: i915 device private data
98   *
99   * This function is called to deallocate the ballooned-out graphic 
memory, when
   100   * driver is unloaded or when ballooning fails.
   101   */
   102  void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
   103  {
   104  int i;
   105  
   106  if (!intel_vgpu_active(dev_priv))
   107  return;
   108  
   109  DRM_DEBUG("VGT deballoon.\n");
   110  
   111  for (i = 0; i < 4; i++) {
   112  if (bl_info.space[i].allocated) {
 > 113  dev_priv->ggtt->base.reserved -= 
 > bl_info.space[i].size;
   114  drm_mm_remove_node(_info.space[i]);
   115  }
   116  }
   117  
   118  memset(_info, 0, sizeof(bl_info));
   119  }
   120  
   121  static int vgt_balloon_space(struct i915_ggtt *ggtt,

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


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

Re: [Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

[Matt Roper]

On Mon, May 08, 2017 at 05:18:58PM +0530, Mahesh Kumar wrote:
> DDB minimum requirement may exceed the allocated DDB for CRTC/Pipe. This
> patch make changes to fail the flip if minimum requirement for pipe
> exceeds the total ddb allocated to the pipe.
> Previously it succeeded but making alloc_size a negative value. Which
> will make later calculations for plane ddb allocation bogus & may lead
> to screen corruption or system hang.
> 

I think originally the bspec defined the initial minimum DDB allocation
for each plane to just be '8' in all cases.  So even with 4 planes on a
pipe, your initial pipe minimum would only be 32, so the code here never
had a risk of overflowing (note that the initial minimum is different
than the WM0 minimum requirement we ultimately wind up calculating).
But then the bspec was updated to suggest a higher initial minimum for
y-tiled buffers (calculated based on the width of the buffer), so our
initial assumptions here don't really hold anymore.  We should still be
safe if we're not using y-tile, but even a single 4k y-tiled plane would
have an initial minimum of something like 250 blocks iirc., so we can't
assume we're always safe anymore.


> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2a4e9d89cd6f..0ace94d67432 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3591,6 +3591,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   int num_active;
>   unsigned plane_data_rate[I915_MAX_PLANES] = {};
>   unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> + uint16_t total_min_blocks = 0;
>  
>   /* Clear the partitioning for disabled planes. */
>   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> @@ -3618,10 +3619,18 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>*/
>  
>   for_each_plane_id_on_crtc(intel_crtc, plane_id) {
> - alloc_size -= minimum[plane_id];
> - alloc_size -= y_minimum[plane_id];
> + total_min_blocks += minimum[plane_id];
> + total_min_blocks += y_minimum[plane_id];
>   }
>  
> + if ((total_min_blocks > alloc_size)) {
> + DRM_DEBUG_KMS("Requested display configuration exceeds system 
> DDB limitations");
> + DRM_DEBUG_KMS("minimum required %d/%d\n", total_min_blocks,
> + alloc_size);
> + return-EINVAL;

I think you're missing a space here?

With that fixed,

Reviewed-by: Matt Roper 

> + }
> +
> + alloc_size -= total_min_blocks;
>   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
> minimum[PLANE_CURSOR];
>   ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
>  
> -- 
> 2.11.0
> 

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

Re: [Intel-gfx] [PATCH 08/11] drm/i915/skl+: Watermark calculation cleanup

[Matt Roper]

On Mon, May 08, 2017 at 05:18:59PM +0530, Mahesh Kumar wrote:
> This patch cleanup/reorganises the watermark calculation functions.
> This patch also make use of already available macro
> "drm_atomic_crtc_state_for_each_plane_state" to walk through
> plane_state list instead of calculating plane_state in function itself.
> Now we iterate over WM levels in skl_compute_wm_level function instead
> of "skl_build_pipe_wm" function.

I'd split the minor cleanup (const-ifying,
drm_atomic_crtc_state_for_each_plane_state usage, etc.) into a separate
patch from the code flow change (looping over levels in
skl_compute_wm_level instead of skl_build_pipe_wm).  You'll probably
also want to rename the function to skl_compute_wm_level*s* (plural) if
its going to calculate all levels now instead of just one.


Matt

> 
> This restructuring will help later patch for new DDB allocation
> algorithm to do only algo related changes.
> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 89 
> +
>  1 file changed, 37 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0ace94d67432..9d0225862a7e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3732,7 +3732,7 @@ static uint_fixed_16_16_t skl_wm_method2(uint32_t 
> pixel_rate,
>  }
>  
>  static uint32_t skl_adjusted_plane_pixel_rate(const struct intel_crtc_state 
> *cstate,
> -   struct intel_plane_state *pstate)
> +   const struct intel_plane_state 
> *pstate)
>  {
>   uint64_t adjusted_pixel_rate;
>   uint_fixed_16_16_t downscale_amount;
> @@ -3754,7 +3754,7 @@ static uint32_t skl_adjusted_plane_pixel_rate(const 
> struct intel_crtc_state *cst
>  
>  static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
>   struct intel_crtc_state *cstate,
> - struct intel_plane_state *intel_pstate,
> + const struct intel_plane_state *intel_pstate,
>   uint16_t ddb_allocation,
>   int level,
>   uint16_t *out_blocks, /* out */
> @@ -3762,8 +3762,8 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   bool *enabled /* out */)
>  {
>   struct intel_plane *plane = to_intel_plane(intel_pstate->base.plane);
> - struct drm_plane_state *pstate = _pstate->base;
> - struct drm_framebuffer *fb = pstate->fb;
> + const struct drm_plane_state *pstate = _pstate->base;
> + const struct drm_framebuffer *fb = pstate->fb;
>   uint32_t latency = dev_priv->wm.skl_latency[level];
>   uint_fixed_16_16_t method1, method2;
>   uint_fixed_16_16_t plane_blocks_per_line;
> @@ -3918,52 +3918,36 @@ static int
>  skl_compute_wm_level(const struct drm_i915_private *dev_priv,
>struct skl_ddb_allocation *ddb,
>struct intel_crtc_state *cstate,
> -  struct intel_plane *intel_plane,
> -  int level,
> -  struct skl_wm_level *result)
> +  const struct intel_plane_state *intel_pstate,
> +  struct skl_plane_wm *wm)
>  {
> - struct drm_atomic_state *state = cstate->base.state;
>   struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
> - struct drm_plane *plane = _plane->base;
> - struct intel_plane_state *intel_pstate = NULL;
> + struct drm_plane *plane = intel_pstate->base.plane;
> + struct intel_plane *intel_plane = to_intel_plane(plane);
>   uint16_t ddb_blocks;
>   enum pipe pipe = intel_crtc->pipe;
> + int level, max_level = ilk_wm_max_level(dev_priv);
>   int ret;
>  
> - if (state)
> - intel_pstate =
> - intel_atomic_get_existing_plane_state(state,
> -   intel_plane);
> -
> - /*
> -  * Note: If we start supporting multiple pending atomic commits against
> -  * the same planes/CRTC's in the future, plane->state will no longer be
> -  * the correct pre-state to use for the calculations here and we'll
> -  * need to change where we get the 'unchanged' plane data from.
> -  *
> -  * For now this is fine because we only allow one queued commit against
> -  * a CRTC.  Even if the plane isn't modified by this transaction and we
> -  * don't have a plane lock, we still have the CRTC's lock, so we know
> -  * that no other transactions are racing with us to update it.
> -  */
> - if (!intel_pstate)
> - intel_pstate = to_intel_plane_state(plane->state);
> -
>   if (WARN_ON(!intel_pstate->base.fb))
>   return -EINVAL;
>  
>   ddb_blocks = 

Re: [Intel-gfx] [PATCH 04/11] drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed point

[Matt Roper]

On Mon, May 08, 2017 at 05:18:55PM +0530, Mahesh Kumar wrote:
> This patch make changes to calculate adjusted plane pixel rate &
> plane downscale amount using fixed_point functions available.
> This patch will give uniformity in code, & will help to avoid mixing of
> 32bit uint32_t variable for fixed-16.16 with fixed_16_16_t variables in
> later patch in the series.
> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 37 +++--
>  1 file changed, 19 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 66b542ba47ad..6414701ef09e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3360,26 +3360,27 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
> *dev_priv,
>   * Return value is provided in 16.16 fixed point form to retain fractional 
> part.
>   * Caller should take care of dividing & rounding off the value.
>   */
> -static uint32_t
> +static uint_fixed_16_16_t
>  skl_plane_downscale_amount(const struct intel_crtc_state *cstate,
>  const struct intel_plane_state *pstate)
>  {
>   struct intel_plane *plane = to_intel_plane(pstate->base.plane);
> - uint32_t downscale_h, downscale_w;
>   uint32_t src_w, src_h, dst_w, dst_h;
> + uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
> + uint_fixed_16_16_t downscale_h, downscale_w;
>  
>   if (WARN_ON(!intel_wm_plane_visible(cstate, pstate)))
> - return DRM_PLANE_HELPER_NO_SCALING;
> + return u32_to_fixed_16_16(0);

I don't think this really changes anything, right?  Both of the places
that call this function have already bailed out and returned 0 data rate
if the plane is invisible.  Not that it hurts anything either.

>  
>   /* n.b., src is 16.16 fixed point, dst is whole integer */
>   if (plane->id == PLANE_CURSOR) {
> - src_w = pstate->base.src_w;
> - src_h = pstate->base.src_h;
> + src_w = pstate->base.src_w >> 16;
> + src_h = pstate->base.src_h >> 16;
>   dst_w = pstate->base.crtc_w;
>   dst_h = pstate->base.crtc_h;
>   } else {
> - src_w = drm_rect_width(>base.src);
> - src_h = drm_rect_height(>base.src);
> + src_w = drm_rect_width(>base.src) >> 16;
> + src_h = drm_rect_height(>base.src) >> 16;
>   dst_w = drm_rect_width(>base.dst);
>   dst_h = drm_rect_height(>base.dst);
>   }
> @@ -3387,11 +3388,13 @@ skl_plane_downscale_amount(const struct 
> intel_crtc_state *cstate,
>   if (drm_rotation_90_or_270(pstate->base.rotation))
>   swap(dst_w, dst_h);
>  
> - downscale_h = max(src_h / dst_h, (uint32_t)DRM_PLANE_HELPER_NO_SCALING);
> - downscale_w = max(src_w / dst_w, (uint32_t)DRM_PLANE_HELPER_NO_SCALING);
> + fp_w_ratio = fixed_16_16_div(src_w, dst_w);
> + fp_h_ratio = fixed_16_16_div(src_h, dst_h);
> + downscale_w = max_fixed_16_16(fp_w_ratio, u32_to_fixed_16_16(1));
> + downscale_h = max_fixed_16_16(fp_h_ratio, u32_to_fixed_16_16(1));
>  
>   /* Provide result in 16.16 fixed point */
> - return (uint64_t)downscale_w * downscale_h >> 16;
> + return mul_fixed_16_16(downscale_w, downscale_h);

I think we can drop the comment here now; it was originally added to
remind why we were doing the extra shift at return, but now it's pretty
obvious at this point that everything here is dealing with fixed point.

With or without the comment dropped,

Reviewed-by: Matt Roper 

>  }
>  
>  static unsigned int
> @@ -3401,10 +3404,11 @@ skl_plane_relative_data_rate(const struct 
> intel_crtc_state *cstate,
>  {
>   struct intel_plane *plane = to_intel_plane(pstate->plane);
>   struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
> - uint32_t down_scale_amount, data_rate;
> + uint32_t data_rate;
>   uint32_t width = 0, height = 0;
>   struct drm_framebuffer *fb;
>   u32 format;
> + uint_fixed_16_16_t down_scale_amount;
>  
>   if (!intel_pstate->base.visible)
>   return 0;
> @@ -3438,7 +3442,7 @@ skl_plane_relative_data_rate(const struct 
> intel_crtc_state *cstate,
>  
>   down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
>  
> - return (uint64_t)data_rate * down_scale_amount >> 16;
> + return mul_u32_fixed_16_16_round_up(data_rate, down_scale_amount);
>  }
>  
>  /*
> @@ -3724,8 +3728,7 @@ static uint32_t skl_adjusted_plane_pixel_rate(const 
> struct intel_crtc_state *cst
> struct intel_plane_state *pstate)
>  {
>   uint64_t adjusted_pixel_rate;
> - uint64_t downscale_amount;
> - uint64_t pixel_rate;
> + uint_fixed_16_16_t downscale_amount;
>  
>   /* Shouldn't reach here on disabled planes... */
>   if 

Re: [Intel-gfx] [PATCH 05/11] drm/i915/skl: Fail the flip if no FB for WM calculation

[Matt Roper]

On Mon, May 08, 2017 at 05:31:30PM +0530, Mahesh Kumar wrote:
> Hi,
> 
> 
> On Monday 08 May 2017 05:18 PM, Lankhorst, Maarten wrote:
> > Mahesh Kumar schreef op ma 08-05-2017 om 17:18 [+0530]:
> > > Fail the flip if no FB is present but plane_state is set as visible.
> > > Above is not a valid combination so instead of continue fail the
> > > flip.
> > Why is this patch necessary? drm_atomic_plane_check handles this.
> Ideally we should never get such combination here. But current WM code
> checks for this situation and even if it's true it proceeds further. This
> patch just corrects the WM code flow decision.
> I also think some of these checks are redundant here.

Yeah, WARN()'s are basically "I'm sure this could never happen" type
assertions.  Of course sometimes we restructure parts of the code and
forget about assumptions we've made elsewhere (or we just plain screw up
and add new bugs to existing code), so we wind up hitting the WARN()'s
anyway.  If proceeding on here could lead to a panic (which I think it
could since we dereference the fb in skl_compute_plane_wm()), then
adding a sensible bail-out here seems okay to me; the extra paranoia
only costs one extra line of code.


Matt

> 
> -Mahesh
> 
> > 
> > ~Maarten
> 

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

Re: [Intel-gfx] [PATCH 06/11] drm/i915/skl+: no need to memset again

[Matt Roper]

On Mon, May 08, 2017 at 05:18:57PM +0530, Mahesh Kumar wrote:
> We are already doing memset of ddb structure at the begining of 
> skl_allocate_pipe_ddb
> function, No need to again do a memset.
> 
> Signed-off-by: Mahesh Kumar 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1d7c67d7e539..2a4e9d89cd6f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3606,10 +3606,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>  
>   skl_ddb_get_pipe_allocation_limits(dev, cstate, alloc, _active);
>   alloc_size = skl_ddb_entry_size(alloc);
> - if (alloc_size == 0) {
> - memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> + if (alloc_size == 0)
>   return 0;
> - }
>  
>   skl_ddb_calc_min(cstate, num_active, minimum, y_minimum);
>  
> -- 
> 2.11.0
> 

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

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

[Li, Weinan Z]

Thanks.
Best Regards.
Weinan, LI


> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Thursday, May 11, 2017 8:56 PM
> To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; 
> intel-
> gvt-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Subject: Re: [PATCH v4] drm/i915/gvt: return the correct usable aperture size
> under gvt environment
> 
> On to, 2017-05-11 at 06:51 +, Li, Weinan Z wrote:
> > >
> > > -Original Message-
> > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > > Sent: Wednesday, May 10, 2017 6:43 PM
> > > To: Li, Weinan Z ;
> > > intel-gfx@lists.freedesktop.org; intel-
> > > gvt-...@lists.freedesktop.org
> > > Cc: Chris Wilson 
> > > Subject: Re: [PATCH v4] drm/i915/gvt: return the correct usable
> > > aperture size under gvt environment
> > >
> > > On ke, 2017-05-10 at 10:59 +0800, Weinan Li wrote:
> > > >
> > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> > > userspace.
> > > >
> > > > In gvt environment, each vm only use the ballooned part of
> > > > aperture, so we should return the correct available aperture size
> > > > exclude the reserved part by balloon.
> > > >
> > > > v2: add 'reserved' in struct i915_address_space to record the
> > > > reserved size in ggtt.
> > > >
> > > > v3: remain aper_size as total, adjust aper_available_size exclude
> > > > reserved and pinned. UMD driver need to adjust the max allocation
> > > > size according to the available aperture size but not total size.
> > > > KMD return the correct usable aperture size any time.
> > > >
> > > > v4: add onion teardown to balloon and deballoon to make sure the
> > > > reserved stays correct. Code style refine.
> > >
> > > There's no onion teardown seen yet, please read:
> > >
> > > https://www.kernel.org/doc/html/v4.10/process/coding-style.html#cent
> > > ral
> > > ized-exiting-of-functions
> > >
> > > Please incorporate the addition to vgt_balloon_space function to
> > > reduce code duplication.
> > >
> > > Once the proper teardown is implemented, intel_vgt_deballoon
> > > function should unconditionally remove the drm_mm nodes as there's
> > > no condition when only one of them would be allocated. And
> > > intel_vgt_balloon definitely should not call intel_vgt_deballoon in error
> path as per the coding style above.
> >
> > Thanks Joonas. A little change is brought in if move the fail checking
> > into balloon_space() There are 4 balloon spaces, current policy is if
> > any one fail clean up all the success ones, with this change it won't clean 
> > up
> the success ones. It should not impact the driver's behavior.
> 
> Please re-read the "Centralized exiting of function", in this case you'd have
> three labels for onion teardown if any of the space reservations fails, you 
> jump
> to the right one. Please take a look in the i915 to similar initialization 
> functions
> for examples.
> 
> > @@ -127,9 +130,14 @@ static int vgt_balloon_space(struct i915_ggtt
> > *ggtt,
> >
> > DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
> >  start, end, size / 1024);
> > -   return i915_gem_gtt_reserve(>base, node,
> > +   ret = i915_gem_gtt_reserve(>base, node,
> > size, start,
> > I915_COLOR_UNEVICTABLE,
> > 0);
> > +   if (!ret)
> > +   ggtt->base.reserved += size;
> > +   else
> > +   memset(node, 0, sizeof(*node));
> 
> This should not be needed. Either all of the nodes have been successfully
> initialize or not. The only partial states are in the intel_vgt_balloon 
> function,
> which should use different labels to back off from different stages of
> initialization.
Thanks Joonas' guidance.
I add 4 labels in intel_vgt_balloon for cleaning up ballooned space, the 
reserved size
will increase when one balloon space reserve success, and will clean up if 
anyone reserve
fail step by step.

diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 4ab8a97..e21cfff 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -109,8 +109,8 @@ void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
DRM_DEBUG("VGT deballoon.\n");

for (i = 0; i < 4; i++) {
-   if (bl_info.space[i].allocated)
-   drm_mm_remove_node(_info.space[i]);
+   dev_priv->ggtt.base.reserved -= bl_info.space[i].size;
+   drm_mm_remove_node(_info.space[i]);
}

memset(_info, 0, sizeof(bl_info));
@@ -120,6 +120,7 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
 struct drm_mm_node *node,
 unsigned long start, unsigned long end)
 {
+   int ret;
unsigned long size = end - start;

if (start 

Re: [Intel-gfx] [PATCH v7 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Pandiyan, Dhinakaran]

On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
> There are some panel that
> (1) does not support display backlight enable via AUX
> (2) support display backlight adjustment via AUX
> (3) support display backlight enable via eDP BL_ENABLE pin
> 
> The current driver required that (1) must be support to enable (2).
> This patch drops that requirement.
> 

You sent this version before I finished my follow-up questions, copying
the conversation here for context. 


DK: Won't DP_EDP_BACKLIGHT_AUX_ENABLE_CAP be 1 always? The code below,
in
intel_dp_aux_display_control_capable(), makes sure
DP_EDP_BACKLIGHT_PIN_ENABLE_CAP=0. The spec says at least one of these
has to be 1.

Puthikorn: We will drop the  DP_EDP_BACKLIGHT_PIN_ENABLE_CAP != 0 check
in next patch set.
This patch adds check here to prepare for that.


1) So, this patch does not really fix what the commit message claims
because it is dependent on the following patch. Does it make sense to
remove this check in this patch? That way, this patch by itself is the
fix that the commit message says.

-   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) 


2) If a panel supports backlight enable via AUX and BL_ENABLE pin, this
patch (along with the next) enables backlight twice, doesn't it?
_intel_edp_backlight_on(intel_dp) in intel_dp.c is called
unconditionally after intel_dp_aux_enable_backlight(). I don't know how
likely this configuration is or if it's alright to enable via both AUX
and BL_ENABLE pin.




> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 870c03fc0f3a..c22712762957 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
> *intel_dp, bool enable)
>  {
>   uint8_t reg_val = 0;
>  
> +   /* Early return when display use other mechanism to enable backlight. 
> */
> + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> + return;
> +
>   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
> _val) < 0) {
>   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> @@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct 
> intel_connector *connector)
>* the panel can support backlight control over the aux channel
>*/
>   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
>   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
>   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> (intel_dp->edp_dpcd[2] & 
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {

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

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Alex Williamson]

On Fri, 12 May 2017 02:12:10 +
"Chen, Xiaoguang"  wrote:

> Hi Alex and Gerd,
> 
> >-Original Message-
> >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> >Behalf Of Alex Williamson
> >Sent: Thursday, May 11, 2017 11:45 PM
> >To: Gerd Hoffmann 
> >Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; 
> >linux-
> >ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
> >; Chen, Xiaoguang ; intel-
> >gvt-...@lists.freedesktop.org; Wang, Zhi A 
> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
> >
> >On Thu, 11 May 2017 15:27:53 +0200
> >Gerd Hoffmann  wrote:
> >  
> >>   Hi,
> >>  
> >> > While read the framebuffer region we have to tell the vendor driver 
> >> > which  
> >framebuffer we want to read? There are two framebuffers now in KVMGT that is
> >primary and cursor.  
> >> > There are two methods to implement this:
> >> > 1) write the plane id first and then read the framebuffer.
> >> > 2) create 2 vfio regions one for primary and one for cursor.  
> >>
> >> (3) Place information for both planes into one vfio region.
> >> Which allows to fetch both with a single read() syscall.
> >>
> >> The question is how you'll get the file descriptor then.  If the ioctl
> >> returns the dma-buf fd only you have a racy interface:  Things can
> >> change between read(vfio-region) and ioctl(need-dmabuf-fd).
> >>
> >> ioctl(need-dma-buf) could return both dmabuf fd and plane info to fix
> >> the race, but then it is easier to go with ioctl only interface
> >> (simliar to the orginal one from dec last year) I think.  
> >
> >If the dmabuf fd is provided by a separate mdev vendor driver specific 
> >ioctl, I
> >don't see how vfio regions should be involved.  Selecting which framebuffer
> >should be an ioctl parameter.
> Based on your last mail. I think the implementation looks like this:
> 1) user query the framebuffer information by reading the vfio region.
> 2) if the framebuffer changed(such as framebuffer's graphics address changed, 
> size changed etc) we will need to create a new dmabuf fd.
> 3) create a new dmabuf fd using vfio device specific ioctl.
> 
> >What sort of information needs to be conveyed
> >about each plane?
> Only plane id is needed.
> 
> >Is it static information or something that needs to be read
> >repeatedly?   
> It is static information. For our case plane id 1 represent primary plane and 
> 3 for cursor plane. 2 means sprite plane which will not be used in our case.
> 
> >Do we need it before we get the dmabuf fd or can it be an ioctl on
> >the dmabuf fd?  
> We need it while query the framebuffer. In kernel we need the plane id to 
> decide which plane we should decode.
> Below is my current implementation:
> 1) user first query the framebuffer(primary or cursor) and kernel decode the 
> framebuffer and return the framebuffer information to user and also save a 
> copy in kernel.
> 2) user compared the framebuffer and if the framebuffer changed  creating a 
> new dmabuf fd.

If the contents of the framebuffer change or if the parameters of the
framebuffer change?  I can't image that creating a new dmabuf fd for
every visual change within the framebuffer would be efficient, but I
don't have any concept of what a dmabuf actually does.

> 3) kernel create a new dmabuf fd based on saved framebuffer information.
> 
> So we need plane id in step 1.
> In step 3 we create a dmabuf fd only using saved framebuffer information(no 
> other information is needed).

What changes to the framebuffer require a new dmabuf fd?  Shouldn't the
user query the parameters of the framebuffer through a dmabuf fd and
shouldn't the dmabuf fd have some signaling mechanism to the user
(eventfd perhaps) to notify the user to re-evaluate the parameters?
Otherwise are you imagining that the user polls the vfio region?  Why
can a dmabuf fd not persist across changes to the framebuffer?  Can
someone explain what a dmabuf is and how it works in terms that a
non-graphics person can understand?  Thanks,

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

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Chen, Xiaoguang]

>-Original Message-
>From: Alex Williamson [mailto:alex.william...@redhat.com]
>Sent: Friday, May 12, 2017 10:58 AM
>To: Chen, Xiaoguang 
>Cc: Gerd Hoffmann ; Tian, Kevin ;
>intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>zhen...@linux.intel.com; Lv, Zhiyuan ; intel-gvt-
>d...@lists.freedesktop.org; Wang, Zhi A 
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fri, 12 May 2017 02:12:10 +
>"Chen, Xiaoguang"  wrote:
>
>> Hi Alex and Gerd,
>>
>> >-Original Message-
>> >From: intel-gvt-dev
>> >[mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On Behalf Of
>> >Alex Williamson
>> >Sent: Thursday, May 11, 2017 11:45 PM
>> >To: Gerd Hoffmann 
>> >Cc: Tian, Kevin ;
>> >intel-gfx@lists.freedesktop.org; linux- ker...@vger.kernel.org;
>> >zhen...@linux.intel.com; Lv, Zhiyuan ; Chen,
>> >Xiaoguang ; intel-
>> >gvt-...@lists.freedesktop.org; Wang, Zhi A 
>> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the
>> >dmabuf
>> >
>> >On Thu, 11 May 2017 15:27:53 +0200
>> >Gerd Hoffmann  wrote:
>> >
>> >>   Hi,
>> >>
>> >> > While read the framebuffer region we have to tell the vendor
>> >> > driver which
>> >framebuffer we want to read? There are two framebuffers now in KVMGT
>> >that is primary and cursor.
>> >> > There are two methods to implement this:
>> >> > 1) write the plane id first and then read the framebuffer.
>> >> > 2) create 2 vfio regions one for primary and one for cursor.
>> >>
>> >> (3) Place information for both planes into one vfio region.
>> >> Which allows to fetch both with a single read() syscall.
>> >>
>> >> The question is how you'll get the file descriptor then.  If the
>> >> ioctl returns the dma-buf fd only you have a racy interface:
>> >> Things can change between read(vfio-region) and ioctl(need-dmabuf-fd).
>> >>
>> >> ioctl(need-dma-buf) could return both dmabuf fd and plane info to
>> >> fix the race, but then it is easier to go with ioctl only interface
>> >> (simliar to the orginal one from dec last year) I think.
>> >
>> >If the dmabuf fd is provided by a separate mdev vendor driver
>> >specific ioctl, I don't see how vfio regions should be involved.  Selecting 
>> >which
>framebuffer
>> >should be an ioctl parameter.
>> Based on your last mail. I think the implementation looks like this:
>> 1) user query the framebuffer information by reading the vfio region.
>> 2) if the framebuffer changed(such as framebuffer's graphics address changed,
>size changed etc) we will need to create a new dmabuf fd.
>> 3) create a new dmabuf fd using vfio device specific ioctl.
>>
>> >What sort of information needs to be conveyed
>> >about each plane?
>> Only plane id is needed.
>>
>> >Is it static information or something that needs to be read
>> >repeatedly?
>> It is static information. For our case plane id 1 represent primary plane 
>> and 3 for
>cursor plane. 2 means sprite plane which will not be used in our case.
>>
>> >Do we need it before we get the dmabuf fd or can it be an ioctl on
>> >the dmabuf fd?
>> We need it while query the framebuffer. In kernel we need the plane id to
>decide which plane we should decode.
>> Below is my current implementation:
>> 1) user first query the framebuffer(primary or cursor) and kernel decode the
>framebuffer and return the framebuffer information to user and also save a copy
>in kernel.
>> 2) user compared the framebuffer and if the framebuffer changed  creating a
>new dmabuf fd.
>
>If the contents of the framebuffer change or if the parameters of the 
>framebuffer
>change?  
If the parameters of the framebuffer change we need to create new dmabuf.


>I can't image that creating a new dmabuf fd for every visual change
>within the framebuffer would be efficient, but I don't have any concept of 
>what a
>dmabuf actually does.
>
>> 3) kernel create a new dmabuf fd based on saved framebuffer information.
>>
>> So we need plane id in step 1.
>> In step 3 we create a dmabuf fd only using saved framebuffer information(no
>other information is needed).
>
>What changes to the framebuffer require a new dmabuf fd?  Shouldn't the user
>query the parameters of the framebuffer through a dmabuf fd and shouldn't the
>dmabuf fd have some signaling mechanism to the user (eventfd perhaps) to notify
>the user to re-evaluate the parameters?
>Otherwise are you imagining that the user polls the vfio region?  Why can a
>dmabuf fd not persist across changes to the framebuffer?  Can someone explain
>what a dmabuf is and how it works in terms that a non-graphics person can
>understand?  Thanks,

A dmabuf will be associated a gem object. In our case the backing storage of 
the gem object is from the framebuffer.
We use the GMA(graphics 

[Intel-gfx] [PATCH v7 6/9] drm/i915: Add option to support dynamic backlight via DPCD

[Puthikorn Voravootivat]

This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/i915_params.c|  5 
 drivers/gpu/drm/i915/i915_params.h|  3 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 40 +++
 3 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 13cf3f1572ab..6eaf660e74da 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = -1,
.enable_gvt = false,
+   .enable_dbc = false,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -255,3 +256,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host 
support(default:false)");
+
+module_param_named(enable_dbc, i915.enable_dbc, bool, 0600);
+MODULE_PARM_DESC(enable_dbc,
+   "Enable support for dynamic backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index ac02efce6e22..2de3e2850b54 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -67,7 +67,8 @@
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
func(int, enable_dpcd_backlight); \
-   func(bool, enable_gvt)
+   func(bool, enable_gvt); \
+   func(bool, enable_dbc)
 
 #define MEMBER(T, member) T member
 struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index a72893da78d0..1c5459bc20ae 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
*connector, u32 level)
}
 }
 
+/*
+ * Set minimum / maximum dynamic brightness percentage. This value is expressed
+ * as the percentage of normal brightness in 5% increments.
+ */
+static void
+intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
+  u32 min, u32 max)
+{
+   u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
+ dbc, sizeof(dbc) < 0)) {
+   DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
if (drm_dp_dpcd_readb(_dp->aux,
@@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
return;
}
 
+   new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
 
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
-   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
-   if (drm_dp_dpcd_writeb(_dp->aux,
-   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
-   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
-   }
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
break;
 
/* Do nothing when it is already DPCD mode */
@@ -130,6 +144,20 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
break;
}
 
+   if (i915.enable_dbc &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
+   new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
+   intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
+   DRM_DEBUG_KMS("Enable dynamic brightness.\n");
+   }
+
+   if (new_dpcd_buf != dpcd_buf) {
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   }
+
set_aux_backlight_enable(intel_dp, true);
 }
 
-- 
2.13.0.rc2.291.g57267f2277-goog

[Intel-gfx] [PATCH v7 7/9] drm/i915: Restore brightness level in aux backlight driver

[Puthikorn Voravootivat]

Some panel will default to zero brightness when turning the
panel off and on again. This patch restores last brightness
level back when panel is turning back on.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 1c5459bc20ae..0b48851013cc 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -159,6 +159,7 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
}
 
set_aux_backlight_enable(intel_dp, true);
+   intel_dp_aux_set_backlight(connector, connector->panel.backlight.level);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [Intel-gfx] [PATCH v7 6/9] drm/i915: Add option to support dynamic backlight via DPCD

[Pandiyan, Dhinakaran]

On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat wrote:
> This patch adds option to enable dynamic backlight for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.
> 
> Signed-off-by: Puthikorn Voravootivat 
> ---
>  drivers/gpu/drm/i915/i915_params.c|  5 
>  drivers/gpu/drm/i915/i915_params.h|  3 +-
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 40 
> +++
>  3 files changed, 41 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 13cf3f1572ab..6eaf660e74da 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
>   .inject_load_failure = 0,
>   .enable_dpcd_backlight = -1,
>   .enable_gvt = false,
> + .enable_dbc = false,

Thanks for adding this switch, however I am not sure about doing this
via a kernel parameter. Controlling this via a drm_property is another
way. But, that would require user space changes. 

Jani, 
What are your thoughts on adding another kernel parameter. iirc there
were some concerns in the mailing list about adding new params a while
back. 


-DK


>  };
>  
>  module_param_named(modeset, i915.modeset, int, 0400);
> @@ -255,3 +256,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
>  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
>  MODULE_PARM_DESC(enable_gvt,
>   "Enable support for Intel GVT-g graphics virtualization host 
> support(default:false)");
> +
> +module_param_named(enable_dbc, i915.enable_dbc, bool, 0600);
> +MODULE_PARM_DESC(enable_dbc,
> + "Enable support for dynamic backlight control (default:false)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index ac02efce6e22..2de3e2850b54 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -67,7 +67,8 @@
>   func(bool, nuclear_pageflip); \
>   func(bool, enable_dp_mst); \
>   func(int, enable_dpcd_backlight); \
> - func(bool, enable_gvt)
> + func(bool, enable_gvt); \
> + func(bool, enable_dbc)
>  
>  #define MEMBER(T, member) T member
>  struct i915_params {
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index a72893da78d0..1c5459bc20ae 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
> *connector, u32 level)
>   }
>  }
>  
> +/*
> + * Set minimum / maximum dynamic brightness percentage. This value is 
> expressed
> + * as the percentage of normal brightness in 5% increments.
> + */
> +static void
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> +   dbc, sizeof(dbc) < 0)) {
> + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> + }
> +}
> +
>  static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
>   uint8_t dpcd_buf = 0;
> + uint8_t new_dpcd_buf = 0;
>   uint8_t edp_backlight_mode = 0;
>  
>   if (drm_dp_dpcd_readb(_dp->aux,
> @@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   return;
>   }
>  
> + new_dpcd_buf = dpcd_buf;
>   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>  
>   switch (edp_backlight_mode) {
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
>   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> - if (drm_dp_dpcd_writeb(_dp->aux,
> - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
> - DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
> - }
> + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>   break;
>  
>   /* Do nothing when it is already DPCD mode */
> @@ -130,6 +144,20 @@ static void intel_dp_aux_enable_backlight(struct 
> intel_connector *connector)
>   break;
>   }
>  
> + if (i915.enable_dbc &&
> + (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
> + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> + 

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

[Juergen Gross]

On 11/05/17 23:08, Pavel Machek wrote:
> On Mon 2017-01-23 10:39:27, Juergen Gross wrote:
>> On 13/01/17 15:41, Juergen Gross wrote:
>>> On 12/01/17 10:21, Chris Wilson wrote:
 On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
> On 11/01/17 18:08, Chris Wilson wrote:
>> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
>>> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
>>>
>>> [   49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
>>> [1431], reason: Hang on render ring, action: reset
>>> [   49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
>>> gfx stack, including userspace.
>>> [   49.213700] [drm] Please file a _new_ bug report on
>>> bugs.freedesktop.org against DRI -> DRM/Intel
>>> [   49.213700] [drm] drm/i915 developers can then reassign to the right
>>> component if it's not a kernel issue.
>>> [   49.213700] [drm] The gpu crash dump is required to analyze gpu
>>> hangs, so please always attach it.
>>> [   49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
>>> [   49.213755] drm/i915: Resetting chip after gpu hang
>>> [   60.213769] drm/i915: Resetting chip after gpu hang
>>> [   71.189737] drm/i915: Resetting chip after gpu hang
>>> [   82.165747] drm/i915: Resetting chip after gpu hang
>>> [   93.205727] drm/i915: Resetting chip after gpu hang
>>>
>>> The dump is attached.
>>
>> That's a nasty one. The first couple of pages of the batchbuffer appear
>> to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That
>> may be a concurrent write by either the GPU or CPU, or we may have
>> incorrected mapped a set of pages. That it doesn't recovered suggests
>> that the corruption occurs frequently, probably on every request/batch.
>
> I hoped someone would have an idea already.

 Sorry, first report of something like this in a long time (that I can
 remember at least). And the problem is that it can be anything from a
 coherency to a concurrency issue, so no one patch springs to mind.
 Thankfully it appears to be kernel related.
 -Chris

>>>
>>> Bisecting took longer than I thought, but I had to cherry pick some
>>> patches and rebase one of them multiple times...
>>>
>>> Finally I found the commit to blame: 920cf4194954ec ("drm/i915:
>>> Introduce an internal allocator for disposable private objects")
>>>
>>> In case you need me to produce some more data or test a patch
>>> feel free to reach out.
>>
>> Anything new for this severe regression?
>>
>> Without a fix 4.10 will be unusable with Xen on a machine with i915
>> graphics!
> 
> Did this get solved?

Yes. Commit 7152187159193056f30ad5726741bb25028672bf.


Juergen

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

[Intel-gfx] [PATCH v7 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

There are some panel that
(1) does not support display backlight enable via AUX
(2) support display backlight adjustment via AUX
(3) support display backlight enable via eDP BL_ENABLE pin

The current driver required that (1) must be support to enable (2).
This patch drops that requirement.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 870c03fc0f3a..c22712762957 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
 {
uint8_t reg_val = 0;
 
+   /* Early return when display use other mechanism to enable backlight. */
+   if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+   return;
+
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
  _val) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 * the panel can support backlight control over the aux channel
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v7 8/9] drm: Add definition for eDP backlight frequency

[Puthikorn Voravootivat]

This patch adds the following definition
- Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap
  register which only use bit 0:4
- Base frequency (27 MHz) for backlight PWM frequency
  generator.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..eaa307f6ae8c 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -572,10 +572,12 @@
 #define DP_EDP_PWMGEN_BIT_COUNT 0x724
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726
+# define  DP_EDP_PWMGEN_BIT_COUNT_MASK  (0x1f << 0)
 
 #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727
 
 #define DP_EDP_BACKLIGHT_FREQ_SET   0x728
+# define DP_EDP_BACKLIGHT_FREQ_BASE_KHZ 27000
 
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB   0x72a
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID   0x72b
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v7 5/9] drm/i915: Set backlight mode before enable backlight

[Puthikorn Voravootivat]

We should set backlight mode register before set register to
enable the backlight.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 5ee1d90a3263..a72893da78d0 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -103,8 +103,6 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
uint8_t dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
-   set_aux_backlight_enable(intel_dp, true);
-
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -131,6 +129,8 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
default:
break;
}
+
+   set_aux_backlight_enable(intel_dp, true);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v7 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

[Puthikorn Voravootivat]

Add option to allow choosing how to adjust brightness if
panel supports both PWM pin and AUX channel.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/i915_params.c|  8 +---
 drivers/gpu/drm/i915/i915_params.h|  2 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 24 +++-
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..13cf3f1572ab 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
-   .enable_dpcd_backlight = false,
+   .enable_dpcd_backlight = -1,
.enable_gvt = false,
 };
 
@@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
 module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
 MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
0600);
 MODULE_PARM_DESC(enable_dpcd_backlight,
-   "Enable support for DPCD backlight control (default:false)");
+   "Enable support for DPCD backlight control "
+   "(-1:disable (default), 0:Use PWM pin if both supported, "
+   "1:Use DPCD if both supported");
 
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
-   func(bool, enable_dpcd_backlight); \
+   func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
 
 #define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index c22712762957..5ee1d90a3263 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -167,21 +167,35 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
/* Check the  eDP Display control capabilities registers to determine if
 * the panel can support backlight control over the aux channel
 */
-   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
-   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
- (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
+   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
 }
 
+static bool
+intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+
+   /* Check the  eDP Display control capabilities registers to determine if
+* the panel can support backlight control via BL_PWM_DIM eDP pin
+*/
+   return (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP);
+}
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_panel *panel = _connector->panel;
 
-   if (!i915.enable_dpcd_backlight)
+   if (i915.enable_dpcd_backlight == -1)
+   return -ENODEV;
+
+   if (i915.enable_dpcd_backlight == 0 &&
+   intel_dp_pwm_pin_display_control_capable(intel_connector))
return -ENODEV;
 
if (!intel_dp_aux_display_control_capable(intel_connector))
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency is still within 25%
of the desired frequency.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 0b48851013cc..6f10a2f1ab76 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -113,12 +113,86 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
intel_dp *intel_dp,
}
 }
 
+/*
+ * Set PWM Frequency divider to match desired frequency in vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
+static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+   int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
+   u8 pn, pn_min, pn_max;
+
+   /* Find desired value of (F x P)
+* Note that, if F x P is out of supported range, the maximum value or
+* minimum value will applied automatically. So no need to check that.
+*/
+   freq = dev_priv->vbt.backlight.pwm_freq_hz;
+   DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
+   if (!freq) {
+   DRM_DEBUG_KMS("Use panel default backlight frequency\n");
+   return;
+   }
+
+   fxp = KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ) / freq;
+
+   /* Use highest possible value of Pn for more granularity of brightness
+* adjustment while satifying the conditions below.
+* - Pn is in the range of Pn_min and Pn_max
+* - F is in the range of 1 and 255
+* - Effective frequency is within 25% of desired frequency.
+*/
+   if (drm_dp_dpcd_readb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
+   return;
+   }
+   if (drm_dp_dpcd_readb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
+   return;
+   }
+   pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+   pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+
+   fxp_min = fxp * 3 / 4;
+   fxp_max = fxp * 5 / 4;
+   if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
+   DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
+   return;
+   }
+
+   for (pn = pn_max; pn > pn_min; pn--) {
+   f = clamp(fxp >> pn, 1, 255);
+   fxp_actual = f << pn;
+   if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
+   break;
+   }
+
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
+   return;
+   }
+   if (drm_dp_dpcd_writeb(_dp->aux,
+  DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
+   return;
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
+   bool freq_cap;
 
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
@@ -151,6 +225,10 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
DRM_DEBUG_KMS("Enable dynamic brightness.\n");
}
 
+   freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
+   if (freq_cap)
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
@@ -158,6 +236,9 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
}
}
 
+   if (freq_cap)
+   intel_dp_aux_set_pwm_freq(connector);
+

[Intel-gfx] [PATCH v7 0/9] Enhancement to intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

This patch set contain 9 patches.
- First five patches fix bug in the driver and allow choosing which
  way to adjust brightness if both PWM pin and AUX are supported
- Next patch adds enable DBC by default
- Next patch makes the driver restore last brightness level after
  turning display off and on.
- Last two patches set the PWM freqency to match data in panel vbt.

This patch set is reviewed by Dhinakaran in patch #1, 2, 5, 7, 8

Change log:
v7:
- Add check in intel_dp_pwm_pin_display_control_capable in patch #4
- Add option in patch #6 to enable DPCD or not
- Change definition in patch #8 and implementation in #9 to use Khz
- Fix compiler warning from build bot in patch #9

v6:
- Address review from Dhinakaran
- Make PWM frequency to have highest value of Pn that make the
  frequency still within 25% of desired frequency.

v5:
- Split first patch in v4 to 3 patches
- Bump priority for "Correctly enable backlight brightness adjustment via DPCD"
- Make logic clearer for the case that both PWM pin and AUX are supported
- Add more log when write to register fail
- Add log when enable DBC

v4:
- Rebase / minor typo fix.

v3:
- Add new implementation of PWM frequency patch

v2:
- Drop PWM frequency patch
- Address suggestion from Jani Nikula


Puthikorn Voravootivat (9):
  drm/i915: Fix cap check for intel_dp_aux_backlight driver
  drm/i915: Correctly enable backlight brightness adjustment via DPCD
  drm/i915: Drop AUX backlight enable check for backlight control
  drm/i915: Allow choosing how to adjust brightness if both supported
  drm/i915: Set backlight mode before enable backlight
  drm/i915: Add option to support dynamic backlight via DPCD
  drm/i915: Restore brightness level in aux backlight driver
  drm: Add definition for eDP backlight frequency
  drm/i915: Set PWM divider to match desired frequency in vbt

 drivers/gpu/drm/i915/i915_params.c|  13 +-
 drivers/gpu/drm/i915/i915_params.h|   5 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 --
 include/drm/drm_dp_helper.h   |   2 +
 4 files changed, 176 insertions(+), 17 deletions(-)

-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v7 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

intel_dp_aux_backlight driver should check for the
DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 6532e226db29..341bf2cb0c25 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -144,6 +144,7 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v7 2/9] drm/i915: Correctly enable backlight brightness adjustment via DPCD

[Puthikorn Voravootivat]

intel_dp_aux_enable_backlight() assumed that the register
BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
(DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.

This patch fixed that by handling all cases of that register.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 33 ++-
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 341bf2cb0c25..870c03fc0f3a 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,15 +97,36 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t edp_backlight_mode = 0;
 
set_aux_backlight_enable(intel_dp, true);
 
-   if ((drm_dp_dpcd_readb(_dp->aux,
-  DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) 
== 1) &&
-   ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
-DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
-   drm_dp_dpcd_writeb(_dp->aux, 
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
-  (dpcd_buf | 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
+   if (drm_dp_dpcd_readb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
+   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+   return;
+   }
+
+   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+
+   switch (edp_backlight_mode) {
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
+   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   break;
+
+   /* Do nothing when it is already DPCD mode */
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
+   default:
+   break;
+   }
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Add more wrapper for fixed_point_16_16 operations

[Matt Roper]

On Mon, May 08, 2017 at 05:18:53PM +0530, Mahesh Kumar wrote:
> This patch adds few wrapper to perform fixed_point_16_16 operations
> mul_u32_fixed_16_16_round_up : Multiplies u32 and fixed_16_16_t
>   variables & returns u32 result with
>   rounding-off.
> mul_fixed_16_16 : Multiplies two fixed_16_16_t variable & returns
>   fixed_16_16
> div_round_up_fixed_16_16 : Perform division operation on fixed_16_16_t
>   variables & return u32 result with round-off
> fixed_16_16_div_round_up_u64 : devide uint32_t variable by fixed_16_16
>   variable and round_up the result to uint32_t.

Minor nitpick, but I'd say "rounding-up" rather than "rounding-off" in
your descriptions here.

> 
> These wrappers will be used by later patches in the series.

The name on this last one (fixed_16_16_div_round_up_u64) doesn't seem to
match what it does.  You're using u64 internally, but the actual
operands are a u32 and a fixed point value.  Wouldn't it make more sense
to call it div_round_up_u32_fixed_16_16 (that also keeps the dividend
first and the divisor second, which seems more natural to me).

Actually the naming of all the fixed point math functions is a bit
confusing/inconsistent.  Some of them are "op_type[_type][_round_up],"
some of them are "op[_round_up]_type," some of them are
"type_op[_round_up]," and some of them are "type_op[_round_up]_type."
Also, none of them specify the return value type, but I guess that's not
too much of a problem since the use of a fixed point structure will
ensure the compiler warns if someone tries to use them assuming the
wrong kind of result.

Maybe we could standardize the names a bit to help avoid confusion?  I'd
suggest "op[_round_up]_type1_type2."  If both types are the same, we'd
still repeat the type for clarity, but maybe we could just use "fixed16"
or "fix16" to keep the overall names from getting too long.  And for
division we'd always keep the dividend as the first type, divisor as
second.

E.g.,
mul_round_up_u32_fixed16()
div_round_up_u32_fixed16()
mul_fixed16_fixed16()
div_round_up_fixed16_fixed16()

And presumably the existing fixed point operations could be renamed in
the same manner.


Matt

> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 43 
> +
>  1 file changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5804734d30a3..5ff0091707c0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -152,6 +152,38 @@ static inline uint_fixed_16_16_t 
> max_fixed_16_16(uint_fixed_16_16_t max1,
>   return max;
>  }
>  
> +static inline uint32_t div_round_up_fixed_16_16(uint_fixed_16_16_t val,
> + uint_fixed_16_16_t d)
> +{
> + return DIV_ROUND_UP(val.val, d.val);
> +}
> +
> +static inline uint32_t mul_u32_fixed_16_16_round_up(uint32_t val,
> + uint_fixed_16_16_t mul)
> +{
> +   uint64_t intermediate_val;
> +   uint32_t result;
> +
> +   intermediate_val = (uint64_t) val * mul.val;
> +   intermediate_val = DIV_ROUND_UP_ULL(intermediate_val, 1 << 16);
> +   WARN_ON(intermediate_val >> 32);
> +   result = clamp_t(uint32_t, intermediate_val, 0, ~0);
> +   return result;
> +}
> +
> +static inline uint_fixed_16_16_t mul_fixed_16_16(uint_fixed_16_16_t val,
> +  uint_fixed_16_16_t mul)
> +{
> + uint64_t intermediate_val;
> + uint_fixed_16_16_t fp;
> +
> + intermediate_val = (uint64_t) val.val * mul.val;
> + intermediate_val = intermediate_val >> 16;
> + WARN_ON(intermediate_val >> 32);
> + fp.val = clamp_t(uint32_t, intermediate_val, 0, ~0);
> + return fp;
> +}
> +
>  static inline uint_fixed_16_16_t fixed_16_16_div(uint32_t val, uint32_t d)
>  {
>   uint_fixed_16_16_t fp, res;
> @@ -174,6 +206,17 @@ static inline uint_fixed_16_16_t 
> fixed_16_16_div_u64(uint32_t val, uint32_t d)
>   return res;
>  }
>  
> +static inline uint32_t fixed_16_16_div_round_up_u64(uint32_t val,
> + uint_fixed_16_16_t d)
> +{
> + uint64_t interm_val;
> +
> + interm_val = (uint64_t)val << 16;
> + interm_val = DIV_ROUND_UP_ULL(interm_val, d.val);
> + WARN_ON(interm_val >> 32);
> + return clamp_t(uint32_t, interm_val, 0, ~0);
> +}
> +
>  static inline uint_fixed_16_16_t mul_u32_fixed_16_16(uint32_t val,
>uint_fixed_16_16_t mul)
>  {
> -- 
> 2.11.0
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Use fixed_16_16 wrapper for division operation

[Matt Roper]

On Mon, May 08, 2017 at 05:18:54PM +0530, Mahesh Kumar wrote:
> Don't use fixed_16_16 structure members directly, instead use wrapper to
> perform fixed_16_16 division operation.
> 
> Signed-off-by: Mahesh Kumar 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 91f09dfdb618..66b542ba47ad 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3867,8 +3867,8 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   }
>  
>   res_blocks = fixed_16_16_to_u32_round_up(selected_result) + 1;
> - res_lines = DIV_ROUND_UP(selected_result.val,
> -  plane_blocks_per_line.val);
> + res_lines = div_round_up_fixed_16_16(selected_result,
> +  plane_blocks_per_line);
>  
>   if (level >= 1 && level <= 7) {
>   if (y_tiled) {
> -- 
> 2.11.0
> 

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

Re: [Intel-gfx] [PATCH 00/11] Implement DDB algorithm and WM cleanup

[Matt Roper]

On Mon, May 08, 2017 at 05:18:51PM +0530, Mahesh Kumar wrote:
> This series implements new DDB allocation algorithm to solve the cases,
> where we have sufficient DDB available to enable multiple planes, But
> due to the current algorithm not dividing it properly among planes, we
> end-up failing the flip.
> It also takes care of enabling same watermark level for each
> plane, for efficient power saving.
> Series also fixes/cleans-up few bug in present code.
> 
> There are two steps in current WM programming.
> 
> 1. Calculate minimum number of blocks required  for a WM level to be
> enabled. For 1440x2560 panel we need 41 blocks as minimum number of
> blocks to enable WM0. This is the step which doesn't use vertical size.
> It only depends on Pipe drain rate and plane horizontal size as per the
> current Bspec algorithm.
> So all the plane below have minimum  number of blocks required to enable
> WM0 as 41
> Plane 1  - 1440x2560-Min blocks to enable WM0 = 41
> Plane 2  - 1440x2560-Min blocks to enable WM0 = 41
> Plane 3  - 1440x48  -Min blocks to enable WM0 = 41
> Plane 4  - 1440x96  -Min blocks to enable WM0 = 41
> 
> 2. Number of blocks allotted by the driver
> Driver allocates  12 for Plane 3   &  16 for plane 4
> 
> Total Dbuf Available = 508
> Dbuf Available after 32 blocks for cursor = 508 - (32)  = 476

Given the dbuf size of 508, I assume this example is for Broxton
hardware, right?  In that case, you wouldn't actually be able to use the
cursor plane since Plane 4 (1440x96) is mutually exclusive with the
cursor, so there wouldn't be a need to reserve these 32 blocks.   I
guess there's also the issue that the upstream driver can't actually
expose/use Plane 4 at all today.

That said, your overall example here still gets the important points
across and is very much appreciated.


> allocate minimum blocks for each plane 8 * 4 = 32
> remaining blocks = 476 - 32 = 444
> Relative Data Rate for Planes
>Plane 1  =  1440 * 2560 * 3  =  11059200
>Plane 2  =  1440 * 2560 * 3  =  11059200
>Plane 3  =  1440 * 48   * 3  =  207360
>Plane 4  =  1440 * 96   * 3  =  414720
>Total Relative BW=  22740480
> 
> -   Allocate Buffer
> buffer allocation = (Plane relative data rate / total data rate)
>   * total remaming DDB + minimum plane DDB
>  Plane 1  buffer allocation = (11059200 / 22740480) * 444 + 8 = 223
>  Plane 2  buffer allocation = (11059200 / 22740480) * 444 + 8 = 223
>  Plane 3  buffer allocation = (207360   / 22740480) * 444 + 8 = 12
>  Plane 4  buffer allocation = (414720   / 22740480) * 444 + 8 = 16
> 
> In this case it forced driver to disable Plane 3 & 4. Driver need to use
> more efficient way to allocate buffer that is optimum for power.
> 
> New Algorithm suggested by HW team is:
> 
> 1. Calculate minimum buffer allocations for each plane and for each
> watermark level
> 
> 2. Add minimum buffer allocations required for enabling WM7
> for all the planes
> 
> Level 0 =  41 + 41 + 41 + 41  = 164
> Level 1 =  42 + 42 + 42 + 42  = 168
> Level 2 =  42 + 42 + 42 + 42  = 168
> Level 3 =  94 + 94 + 94 + 94 =  376
> Level 4 =  94 + 94 + 94 + 94 =  376
> Level 5 =  94 + 94 + 94 + 94 =  376
> Level 6 =  94 + 94 + 94 + 94 =  376
> Level 7 =  94 + 94 + 94 + 94 =  376
> 
> 3. Check to see how many buffer allocation are left and enable
> the best case. In this case since we have 476 blocks we can enable
> WM0-7 on all 4 planes.
> Let's say if we have only 200 block available then the best cases
> allocation is to enable Level2 which requires 168 blocks

It's probably worth noting that the use cases that are most likely to
benefit from this are those with large differences in the height of the
'shortest' plane vs the height of the 'tallest' plane.  It's the
blind proportional distribution of remaining blocks in the current
algorithm that prevents 'short' planes from reaching their minimum block
requirements for various watermark levels (and if they can't even reach
the WM0 minimum, then the plane can't be used at all).

There will certainly still be cases where the overall display
configuration (with lots of pipes and planes in use) simply requires
more blocks than the hardware has to even reach WM0, no matter how we
slice up the limited DDB size, but the changes here will definitely help
prevent us from rejecting atomic commits for some configurations we
actually could handle.


Matt

> 
> Mahesh Kumar (11):
>   drm/i915: fix naming of fixed_16_16 wrapper.
>   drm/i915: Add more wrapper for fixed_point_16_16 operations
>   drm/i915: Use fixed_16_16 wrapper for division operation
>   drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed
> point
>   drm/i915/skl: Fail the flip if no FB for WM calculation
>   drm/i915/skl+: no need to memset again
>   drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe
>

Re: [Intel-gfx] [PATCH 01/11] drm/i915: fix naming of fixed_16_16 wrapper.

[Matt Roper]

On Mon, May 08, 2017 at 05:18:52PM +0530, Mahesh Kumar wrote:
> fixed_16_16_div_round_up(_u64), wrapper for fixed_16_16 division
> operation don't really round_up the result. Wrapper round_up only the
> fraction part of the result to make it 16-bit.
> This patch eliminates round_up keyword from the wrapper.
> 
> Later patch will introduce the new wrapper to do rounding-off the result
> and give unt32_t output to cleanup mix use of fixed_16_16_t & uint32_t
> variables.
> 
> Signed-off-by: Mahesh Kumar 

Yeah, the naming here is confusing.  You're not rounding up to the next
integer value (which is typically what "round up" refers to), but you
are rounding the fractional part up rather than taking a floor.  Do we
actually need to DIV_ROUND_UP the fractional part in the implementation
of the function?  If we can just use a standard '/' there, it will more
closely match the new function name since since there won't be any round
happening.

Not that it really matters much either way.  With or without changes,

Reviewed-by: Matt Roper 


> ---
>  drivers/gpu/drm/i915/i915_drv.h | 6 ++
>  drivers/gpu/drm/i915/intel_pm.c | 6 +++---
>  2 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b20ed16da0ad..5804734d30a3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -152,8 +152,7 @@ static inline uint_fixed_16_16_t 
> max_fixed_16_16(uint_fixed_16_16_t max1,
>   return max;
>  }
>  
> -static inline uint_fixed_16_16_t fixed_16_16_div_round_up(uint32_t val,
> -   uint32_t d)
> +static inline uint_fixed_16_16_t fixed_16_16_div(uint32_t val, uint32_t d)
>  {
>   uint_fixed_16_16_t fp, res;
>  
> @@ -162,8 +161,7 @@ static inline uint_fixed_16_16_t 
> fixed_16_16_div_round_up(uint32_t val,
>   return res;
>  }
>  
> -static inline uint_fixed_16_16_t fixed_16_16_div_round_up_u64(uint32_t val,
> -   uint32_t d)
> +static inline uint_fixed_16_16_t fixed_16_16_div_u64(uint32_t val, uint32_t 
> d)
>  {
>   uint_fixed_16_16_t res;
>   uint64_t interm_val;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index cacb65fa2dd5..91f09dfdb618 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3698,7 +3698,7 @@ static uint_fixed_16_16_t skl_wm_method1(uint32_t 
> pixel_rate, uint8_t cpp,
>   return FP_16_16_MAX;
>  
>   wm_intermediate_val = latency * pixel_rate * cpp;
> - ret = fixed_16_16_div_round_up_u64(wm_intermediate_val, 1000 * 512);
> + ret = fixed_16_16_div_u64(wm_intermediate_val, 1000 * 512);
>   return ret;
>  }
>  
> @@ -3834,8 +3834,8 @@ static int skl_compute_plane_wm(const struct 
> drm_i915_private *dev_priv,
>   if (y_tiled) {
>   interm_pbpl = DIV_ROUND_UP(plane_bytes_per_line *
>  y_min_scanlines, 512);
> - plane_blocks_per_line =
> -   fixed_16_16_div_round_up(interm_pbpl, y_min_scanlines);
> + plane_blocks_per_line = fixed_16_16_div(interm_pbpl,
> + y_min_scanlines);
>   } else if (x_tiled) {
>   interm_pbpl = DIV_ROUND_UP(plane_bytes_per_line, 512);
>   plane_blocks_per_line = u32_to_fixed_16_16(interm_pbpl);
> -- 
> 2.11.0
> 

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

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations

[Zheng, Lv]

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations
> 
> On Tue, May 9, 2017 at 9:02 AM, Lv Zheng  wrote:
> > Since notification side has been changed to always notify kernel listeners
> > using _LID returning value. Now listeners needn't invoke acpi_lid_open(),
> > it should use a spec suggested control method lid device usage model:
> > register lid notification and use the notified value instead, which is the
> > only way to ensure the value is correct for "button.lid_init_state=ignore"
> > mode or other modes with "button.lid_fake_events=N" specified.
> >
> > This patch fixes i915 driver to drop acpi_lid_open() user. It's not
> > possible to change nouveau_connector.c user using a simple way now. So this
> > patch only marks acpi_lid_open() as deprecated to accelerate this process
> > by indicating this change to the nouveau developers.
> 
> If  the only 2 users of acpi_lid_open() are intel and nouveau, and if
> they should rely on the value stored in the input node, not the one
> exported by the _LID method (which can be wrong on some platforms),
> how about simply changing the implementation of acpi_lid_open() to
> fetch the value from the input node directly?

See my reply of PATCH 4.
It seems they trust _LID return value more than what we send to them.

We can actually send faked "open/close" to them when 
button.lid_init_state=open/close is specified.

So these 2 patches [PATCH 4-5/5] are used to do a small cleanup for lid event 
notifier APIs.
I think they are not strictly related to the lid issues we are talking about.

Cheers,
Lv

> 
> Cheers,
> Benjamin
> 
> >
> > Cc: 
> > Cc: 
> > Signed-off-by: Lv Zheng 
> > ---
> >  drivers/acpi/button.c | 7 ++-
> >  drivers/gpu/drm/i915/intel_lvds.c | 2 +-
> >  2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index 7ff3a75..50d7898 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -348,7 +348,12 @@ int acpi_lid_notifier_unregister(struct notifier_block 
> > *nb)
> >  }
> >  EXPORT_SYMBOL(acpi_lid_notifier_unregister);
> >
> > -int acpi_lid_open(void)
> > +/*
> > + * The intentional usage model is to register a lid notifier and use the
> > + * notified value instead. Directly evaluating _LID without seeing a
> > + * Notify(lid, 0x80) is not reliable.
> > + */
> > +int __deprecated acpi_lid_open(void)
> >  {
> > if (!lid_device)
> > return -ENODEV;
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index 9ca4dc4..8ca9080 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -548,7 +548,7 @@ static int intel_lid_notify(struct notifier_block *nb, 
> > unsigned long val,
> > /* Don't force modeset on machines where it causes a GPU lockup */
> > if (dmi_check_system(intel_no_modeset_on_lid))
> > goto exit;
> > -   if (!acpi_lid_open()) {
> > +   if (!val) {
> > /* do modeset on next lid open event */
> > dev_priv->modeset_restore = MODESET_ON_LID_OPEN;
> > goto exit;
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Chen, Xiaoguang]

Hi Alex and Gerd,

>-Original Message-
>From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>Behalf Of Alex Williamson
>Sent: Thursday, May 11, 2017 11:45 PM
>To: Gerd Hoffmann 
>Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; Chen, Xiaoguang ; intel-
>gvt-...@lists.freedesktop.org; Wang, Zhi A 
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Thu, 11 May 2017 15:27:53 +0200
>Gerd Hoffmann  wrote:
>
>>   Hi,
>>
>> > While read the framebuffer region we have to tell the vendor driver which
>framebuffer we want to read? There are two framebuffers now in KVMGT that is
>primary and cursor.
>> > There are two methods to implement this:
>> > 1) write the plane id first and then read the framebuffer.
>> > 2) create 2 vfio regions one for primary and one for cursor.
>>
>> (3) Place information for both planes into one vfio region.
>> Which allows to fetch both with a single read() syscall.
>>
>> The question is how you'll get the file descriptor then.  If the ioctl
>> returns the dma-buf fd only you have a racy interface:  Things can
>> change between read(vfio-region) and ioctl(need-dmabuf-fd).
>>
>> ioctl(need-dma-buf) could return both dmabuf fd and plane info to fix
>> the race, but then it is easier to go with ioctl only interface
>> (simliar to the orginal one from dec last year) I think.
>
>If the dmabuf fd is provided by a separate mdev vendor driver specific ioctl, I
>don't see how vfio regions should be involved.  Selecting which framebuffer
>should be an ioctl parameter.  
Based on your last mail. I think the implementation looks like this:
1) user query the framebuffer information by reading the vfio region.
2) if the framebuffer changed(such as framebuffer's graphics address changed, 
size changed etc) we will need to create a new dmabuf fd.
3) create a new dmabuf fd using vfio device specific ioctl.

>What sort of information needs to be conveyed
>about each plane?  
Only plane id is needed.

>Is it static information or something that needs to be read
>repeatedly? 
It is static information. For our case plane id 1 represent primary plane and 3 
for cursor plane. 2 means sprite plane which will not be used in our case.

>Do we need it before we get the dmabuf fd or can it be an ioctl on
>the dmabuf fd?
We need it while query the framebuffer. In kernel we need the plane id to 
decide which plane we should decode.
Below is my current implementation:
1) user first query the framebuffer(primary or cursor) and kernel decode the 
framebuffer and return the framebuffer information to user and also save a copy 
in kernel.
2) user compared the framebuffer and if the framebuffer changed  creating a new 
dmabuf fd.
3) kernel create a new dmabuf fd based on saved framebuffer information.

So we need plane id in step 1.
In step 3 we create a dmabuf fd only using saved framebuffer information(no 
other information is needed).

Chenxg.
>Thanks,
>
>Alex
>___
>intel-gvt-dev mailing list
>intel-gvt-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Detect USB-C specific dongles before reducing M and N

[Patchwork]

== Series Details ==

Series: drm/i915: Detect USB-C specific dongles before reducing M and N
URL   : https://patchwork.freedesktop.org/series/24254/
State : failure

== Summary ==

Series 24254v1 drm/i915: Detect USB-C specific dongles before reducing M and N
https://patchwork.freedesktop.org/api/1.0/series/24254/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> INCOMPLETE (fi-bxt-t5700)

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:443s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:439s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:515s
fi-bxt-t5700 total:209  pass:195  dwarn:0   dfail:0   fail:0   skip:13 
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:432s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:580s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:577s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:471s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:503s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:438s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

4149c7b22164d81960dae0987f497725117b68e6 drm-tip: 2017y-05m-10d-18h-09m-15s UTC 
integration manifest
d1b8be1 drm/i915: Detect USB-C specific dongles before reducing M and N

== Logs ==

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

[Intel-gfx] [PATCH 1/2] drm/i915: Fix hw state verifier access to crtc->state.

[Maarten Lankhorst]

We shouldn't inspect crtc->state, instead grab the crtc state.
At this point the hw state verifier should be able to run even if
crtc->state has been updated (which cannot currently happen).

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 295e17d0f272..e5205d338e3c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5893,9 +5893,10 @@ void intel_encoder_destroy(struct drm_encoder *encoder)
 
 /* Cross check the actual hw state with our own modeset state tracking (and 
it's
  * internal consistency). */
-static void intel_connector_verify_state(struct intel_connector *connector)
+static void intel_connector_verify_state(struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
 {
-   struct drm_crtc *crtc = connector->base.state->crtc;
+   struct intel_connector *connector = 
to_intel_connector(conn_state->connector);
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.base.id,
@@ -5903,15 +5904,14 @@ static void intel_connector_verify_state(struct 
intel_connector *connector)
 
if (connector->get_hw_state(connector)) {
struct intel_encoder *encoder = connector->encoder;
-   struct drm_connector_state *conn_state = connector->base.state;
 
-   I915_STATE_WARN(!crtc,
+   I915_STATE_WARN(!crtc_state,
 "connector enabled without attached crtc\n");
 
-   if (!crtc)
+   if (!crtc_state)
return;
 
-   I915_STATE_WARN(!crtc->state->active,
+   I915_STATE_WARN(!crtc_state->active,
  "connector is active, but attached crtc isn't\n");
 
if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
@@ -5923,9 +5923,9 @@ static void intel_connector_verify_state(struct 
intel_connector *connector)
I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
"attached encoder crtc differs from connector crtc\n");
} else {
-   I915_STATE_WARN(crtc && crtc->state->active,
+   I915_STATE_WARN(crtc_state && crtc_state->active,
"attached crtc is active, but connector isn't\n");
-   I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
+   I915_STATE_WARN(!crtc_state && conn_state->best_encoder,
"best encoder set without crtc!\n");
}
 }
@@ -11859,11 +11859,15 @@ verify_connector_state(struct drm_device *dev,
 
for_each_new_connector_in_state(state, connector, new_conn_state, i) {
struct drm_encoder *encoder = connector->encoder;
+   struct drm_crtc_state *crtc_state = NULL;
 
if (new_conn_state->crtc != crtc)
continue;
 
-   intel_connector_verify_state(to_intel_connector(connector));
+   if (crtc)
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
+
+   intel_connector_verify_state(crtc_state, new_conn_state);
 
I915_STATE_WARN(new_conn_state->best_encoder != encoder,
 "connector's atomic encoder doesn't match legacy 
encoder\n");
@@ -11981,7 +11985,7 @@ verify_crtc_state(struct drm_crtc *crtc,
 
intel_pipe_config_sanity_check(dev_priv, pipe_config);
 
-   sw_config = to_intel_crtc_state(crtc->state);
+   sw_config = to_intel_crtc_state(new_crtc_state);
if (!intel_pipe_config_compare(dev_priv, sw_config,
   pipe_config, false)) {
I915_STATE_WARN(1, "pipe state doesn't match!\n");
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove vma unpin in intel_plane_destroy

[Daniel Vetter]

On Thu, May 11, 2017 at 10:28:44AM +0200, Maarten Lankhorst wrote:
> commit a667fb402c1e856209bf9e77ba41fc1cf356b867
> Author: Maarten Lankhorst 
> Date:   Thu Dec 15 15:29:44 2016 +0100
> 
> drm/i915: Disable all crtcs during driver unload, v2.
> 
> made sure that all crtc's are disabled on driver unload, but only the
> following commit made sure all fb's are cleaned up correctly:
> 
> commit 9b2104f423de5c148749a07e8197dbab4c449877
> Author: Maarten Lankhorst 
> Date:   Tue Feb 21 14:51:40 2017 +0100
> 
> drm/atomic: Make disable_all helper fully disable the crtc.
> 
> Finally remove this and add a WARN_ON when vma is set. It should
> have been removed by intel_cleanup_plane_fb().
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_atomic_plane.c | 18 +-
>  1 file changed, 1 insertion(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index cfb47293fd53..cd74a7dca3ce 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -102,23 +102,7 @@ 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);
> - }
> + WARN_ON(to_intel_plane_state(state)->vma);
>  
>   drm_atomic_helper_plane_destroy_state(plane, state);
>  }
> -- 
> 2.11.0
> 
> ___
> 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 v1 4/4] drm/i915: enable guest full ppgtt when device model supports

[Joonas Lahtinen]

On to, 2017-05-11 at 10:33 +0800, Tina Zhang wrote:
> Add full ppgtt capability check in guest i915 driver and enable the full
> ppgtt in guest only when device mode supports.
> 
> Signed-off-by: Tina Zhang 



> @@ -1909,6 +1909,7 @@ struct i915_workarounds {
>  
>  struct i915_virtual_gpu {
>   bool active;
> + uint32_t  caps;

u32, and no extra spaces.

> @@ -141,8 +141,8 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private 
> *dev_priv,
>   has_full_ppgtt = dev_priv->info.has_full_ppgtt;
>   has_full_48bit_ppgtt = dev_priv->info.has_full_48bit_ppgtt;
>  
> - if (intel_vgpu_active(dev_priv)) {
> - /* emulation is too hard */
> + if (intel_vgpu_active(dev_priv) &&
> + (!intel_vgpu_has_full_ppgtt(dev_priv))) {
>   has_full_ppgtt = false;
>   has_full_48bit_ppgtt = false;

has_full_ppgtt = dev_priv->info.has_full_ppgtt;

if (intel_vpgu_active(dev_priv))
has_full_ppgtt = intel_vgpu_has_full_ppgtt(dev_priv);

    has_full_48bit_ppgtt = has_full_ppgtt &&
       dev_priv->info.has_full_48bit_ppgtt;

Would make for cleanest code.

>   }
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 4ab8a97..9b92c73 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -77,10 +77,16 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
>   return;
>   }
>  
> + dev_priv->vgpu.caps = __raw_i915_read32(dev_priv, vgtif_reg(vgt_caps));

Newline.

>   dev_priv->vgpu.active = true;
>   DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
>  }
>  
> +bool intel_vgpu_has_full_ppgtt(struct drm_i915_private *dev_priv)
> +{
> + return (dev_priv->vgpu.caps & VGT_CAPS_FULL_PPGTT) ? true : false;
> +}

The ternary operator is not needed.

> +
>  struct _balloon_info_ {
>   /*
>    * There are up to 2 regions per mappable/unmappable graphic
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.h 
> b/drivers/gpu/drm/i915/i915_vgpu.h
> index 3c3b2d2..4fc20aa 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.h
> +++ b/drivers/gpu/drm/i915/i915_vgpu.h
> @@ -29,5 +29,6 @@
>  void i915_check_vgpu(struct drm_i915_private *dev_priv);

Add the new function here and add a newline to separate.

Regards, Joonas

>  int intel_vgt_balloon(struct drm_i915_private *dev_priv);
>  void intel_vgt_deballoon(struct drm_i915_private *dev_priv);
> +bool intel_vgpu_has_full_ppgtt(struct drm_i915_private *dev_priv);
>  
>  #endif /* _I915_VGPU_H_ */
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/skl+: consider max supported plane pixel rate while scaling

[Mahesh Kumar]

A display resolution is only supported if it meets all the restrictions
below for Maximum Pipe Pixel Rate.

The display resolution must fit within the maximum pixel rate output
from the pipe. Make sure that the display pipe is able to feed pixels at
a rate required to support the desired resolution.
For each enabled plane on the pipe {
If plane scaling enabled {
Horizontal down scale amount = Maximum[1, plane horizontal size /
scaler horizontal window size]
Vertical down scale amount = Maximum[1, plane vertical size /
scaler vertical window size]
Plane down scale amount = Horizontal down scale amount *
Vertical down scale amount
Plane Ratio = 1 / Plane down scale amount
}
Else {
Plane Ratio = 1
}
If plane source pixel format is 64 bits per pixel {
Plane Ratio = Plane Ratio * 8/9
}
}

Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe

If pipe scaling is enabled {
Horizontal down scale amount = Maximum[1, pipe horizontal source size /
scaler horizontal window size]
Vertical down scale amount = Maximum[1, pipe vertical source size /
scaler vertical window size]
Note: The progressive fetch - interlace display mode is equivalent to a
2.0 vertical down scale
Pipe down scale amount = Horizontal down scale amount *
Vertical down scale amount
Pipe Ratio = Pipe Ratio / Pipe down scale amount
}

Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio

Changes since V1:
 - separate out fixed_16_16 wrapper API definition
Changes since V2:
 - Fix buggy crtc !active condition (Maarten)
 - use intel_wm_plane_visible wrapper as per Maarten's suggestion

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c |  3 ++
 drivers/gpu/drm/i915/intel_drv.h |  2 +
 drivers/gpu/drm/i915/intel_pm.c  | 88 
 3 files changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..d64367e810f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10992,6 +10992,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
ret = skl_update_scaler_crtc(pipe_config);
 
if (!ret)
+   ret = skl_check_pipe_max_pixel_rate(intel_crtc,
+   pipe_config);
+   if (!ret)
ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
 pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54f3ff840812..8323fc2ec4f2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1859,6 +1859,8 @@ bool skl_ddb_allocation_overlaps(const struct 
skl_ddb_entry **entries,
 int ignore);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *cstate);
 static inline int intel_enable_rc6(void)
 {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 041cbca7105e..92b047054f7e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3397,6 +3397,94 @@ skl_plane_downscale_amount(const struct intel_crtc_state 
*cstate,
return mul_fixed_16_16(downscale_w, downscale_h);
 }
 
+static uint_fixed_16_16_t
+skl_pipe_downscale_amount(const struct intel_crtc_state *config)
+{
+   uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
+
+   if (!config->base.active)
+   return pipe_downscale;
+
+   if (config->pch_pfit.enabled) {
+   uint32_t src_w, src_h, dst_w, dst_h;
+   uint32_t pfit_size = config->pch_pfit.size;
+   uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
+   uint_fixed_16_16_t downscale_h, downscale_w;
+
+   src_w = config->pipe_src_w;
+   src_h = config->pipe_src_h;
+   dst_w = pfit_size >> 16;
+   dst_h = pfit_size & 0x;
+
+   if (!dst_w || !dst_h)
+   return pipe_downscale;
+
+   fp_w_ratio = fixed_16_16_div(src_w, dst_w);
+   fp_h_ratio = fixed_16_16_div(src_h, dst_h);
+   downscale_w = max_fixed_16_16(fp_w_ratio, 
u32_to_fixed_16_16(1));
+   downscale_h = max_fixed_16_16(fp_h_ratio, 
u32_to_fixed_16_16(1));
+
+   pipe_downscale = mul_fixed_16_16(downscale_w, downscale_h);
+   }
+
+   return pipe_downscale;
+}
+

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove the duplicated size check in i915_gem_dmabuf_mmap()

[Patchwork]

== Series Details ==

Series: drm/i915: remove the duplicated size check in i915_gem_dmabuf_mmap()
URL   : https://patchwork.freedesktop.org/series/24272/
State : success

== Summary ==

Series 24272v1 drm/i915: remove the duplicated size check in 
i915_gem_dmabuf_mmap()
https://patchwork.freedesktop.org/api/1.0/series/24272/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:438s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:519s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:564s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:479s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:437s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:509s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:476s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:577s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:582s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:498s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:438s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:410s

4149c7b22164d81960dae0987f497725117b68e6 drm-tip: 2017y-05m-10d-18h-09m-15s UTC 
integration manifest
5a9ab85 drm/i915: remove the duplicated size check in i915_gem_dmabuf_mmap()

== Logs ==

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

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Chen, Xiaoguang]

Hi Alex,

>-Original Message-
>From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
>Behalf Of Alex Williamson
>Sent: Friday, May 05, 2017 11:11 PM
>To: Gerd Hoffmann 
>Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux-
>ker...@vger.kernel.org; zhen...@linux.intel.com; Lv, Zhiyuan
>; Chen, Xiaoguang ; intel-
>gvt-...@lists.freedesktop.org; Wang, Zhi A 
>Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf
>
>On Fri, 05 May 2017 08:55:31 +0200
>Gerd Hoffmann  wrote:
>
>>   Hi,
>>
>> > > >>Hmm, that looks like a rather strange way to return a file descriptor.
>> > > >>
>> > > >>What is the reason to not use ioctls on the vfio file handle, like
>> > > >>older version of these patches did?
>> > > >If I understood correctly that Alex prefer not to change the
>> > > >ioctls on the vfio file handle like the old version.
>> > > >So I used this way the smallest change to general vfio framework
>> > > >only adding a subregion definition.
>> >
>> > I think I was hoping we could avoid a separate file descriptor
>> > altogether and use a vfio region instead.
>>
>> What exactly did you have in mind?  Put the framebuffer information
>> (struct intel_vgpu_dmabuf) into the vfio region, then access it using
>> read/write/mmap?
>
>Yeah, that was my hope.  Adding a new file descriptor means we have one more
>reference floating around complicating the life cycle of the device, group, and
>container.  Furthermore this one is really only visible to the mdev vendor 
>driver,
>so we can't rely on vfio-core, the vendor driver will need to consider the
>reference when releasing the device.
While read the framebuffer region we have to tell the vendor driver which 
framebuffer we want to read? There are two framebuffers now in KVMGT that is 
primary and cursor.
There are two methods to implement this:
1) write the plane id first and then read the framebuffer.
2) create 2 vfio regions one for primary and one for cursor.

Which method do you prefer? Or do you have other idea to handle this problem?

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

Re: [Intel-gfx] [PATCH 11/11] drm/i915/skl+: consider max supported plane pixel rate while scaling

[Mahesh Kumar]

Hi,

Thanks for review.

On Wednesday 10 May 2017 06:52 PM, Maarten Lankhorst wrote:

Op 08-05-17 om 13:49 schreef Mahesh Kumar:

A display resolution is only supported if it meets all the restrictions
below for Maximum Pipe Pixel Rate.

The display resolution must fit within the maximum pixel rate output
from the pipe. Make sure that the display pipe is able to feed pixels at
a rate required to support the desired resolution.
For each enabled plane on the pipe {
 If plane scaling enabled {
Horizontal down scale amount = Maximum[1, plane horizontal size /
scaler horizontal window size]
Vertical down scale amount = Maximum[1, plane vertical size /
scaler vertical window size]
Plane down scale amount = Horizontal down scale amount *
Vertical down scale amount
Plane Ratio = 1 / Plane down scale amount
 }
 Else {
Plane Ratio = 1
 }
 If plane source pixel format is 64 bits per pixel {
Plane Ratio = Plane Ratio * 8/9
 }
}

Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe

If pipe scaling is enabled {
 Horizontal down scale amount = Maximum[1, pipe horizontal source size /
scaler horizontal window size]
 Vertical down scale amount = Maximum[1, pipe vertical source size /
scaler vertical window size]
 Note: The progressive fetch - interlace display mode is equivalent to a
2.0 vertical down scale
 Pipe down scale amount = Horizontal down scale amount *
Vertical down scale amount
 Pipe Ratio = Pipe Ratio / Pipe down scale amount
}

Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio

Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/i915/intel_display.c |  3 ++
  drivers/gpu/drm/i915/intel_drv.h |  2 +
  drivers/gpu/drm/i915/intel_pm.c  | 87 
  3 files changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..d64367e810f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10992,6 +10992,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
ret = skl_update_scaler_crtc(pipe_config);
  
  		if (!ret)

+   ret = skl_check_pipe_max_pixel_rate(intel_crtc,
+   pipe_config);
+   if (!ret)
ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
 pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54f3ff840812..8323fc2ec4f2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1859,6 +1859,8 @@ bool skl_ddb_allocation_overlaps(const struct 
skl_ddb_entry **entries,
 int ignore);
  bool ilk_disable_lp_wm(struct drm_device *dev);
  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *cstate);
  static inline int intel_enable_rc6(void)
  {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 92600cf42e12..69b1692ffd07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3397,6 +3397,93 @@ skl_plane_downscale_amount(const struct intel_crtc_state 
*cstate,
return mul_fixed_16_16(downscale_w, downscale_h);
  }
  
+static uint_fixed_16_16_t

+skl_pipe_downscale_amount(const struct intel_crtc_state *config)
+{
+   uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
+
+   if (!config->base.active)
+   return pipe_downscale;
+
+   if (config->pch_pfit.enabled) {
+   uint32_t src_w, src_h, dst_w, dst_h;
+   uint32_t pfit_size = config->pch_pfit.size;
+   uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
+   uint_fixed_16_16_t downscale_h, downscale_w;
+
+   src_w = config->pipe_src_w;
+   src_h = config->pipe_src_h;
+   dst_w = pfit_size >> 16;
+   dst_h = pfit_size & 0x;
+
+   if (!dst_w || !dst_h)
+   return pipe_downscale;
+
+   fp_w_ratio = fixed_16_16_div(src_w, dst_w);
+   fp_h_ratio = fixed_16_16_div(src_h, dst_h);
+   downscale_w = max_fixed_16_16(fp_w_ratio, 
u32_to_fixed_16_16(1));
+   downscale_h = max_fixed_16_16(fp_h_ratio, 
u32_to_fixed_16_16(1));
+
+   pipe_downscale = mul_fixed_16_16(downscale_w, downscale_h);
+   }
+
+   return pipe_downscale;
+}
+
+int skl_check_pipe_max_pixel_rate(struct intel_crtc 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove the duplicated size check in i915_gem_dmabuf_mmap()

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Patchwork
> Sent: Thursday, May 11, 2017 9:23 AM
> To: hw...@emeril.freedesktop.org; Hwang, Dongseong
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove the duplicated
> size check in i915_gem_dmabuf_mmap()
> 
> == Series Details ==
> 
> Series: drm/i915: remove the duplicated size check in
> i915_gem_dmabuf_mmap()
> URL   : https://patchwork.freedesktop.org/series/24272/
> State : success
> 
> == Summary ==
> 
> Series 24272v1 drm/i915: remove the duplicated size check in
> i915_gem_dmabuf_mmap()
> https://patchwork.freedesktop.org/api/1.0/series/24272/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:438s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:433s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:578s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:519s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time:564s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:495s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:479s
> fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
> time:437s
Now also ELK happy. SO ELK is bit unstable on CI. 

> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:418s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:407s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:425s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:509s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:476s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:466s
> fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
> time:577s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:460s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:582s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:466s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:498s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:438s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:535s
> fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
> time:410s
> 
> 4149c7b22164d81960dae0987f497725117b68e6 drm-tip: 2017y-05m-10d-18h-
> 09m-15s UTC integration manifest
> 5a9ab85 drm/i915: remove the duplicated size check in
> i915_gem_dmabuf_mmap()
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4669/


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



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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Detect USB-C specific dongles before reducing M and N

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Patchwork
> Sent: Thursday, May 11, 2017 9:06 AM
> To: Taylor, Clinton A 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Detect USB-C specific
> dongles before reducing M and N
> 
> == Series Details ==
> 
> Series: drm/i915: Detect USB-C specific dongles before reducing M and N
> URL   : https://patchwork.freedesktop.org/series/24254/
> State : failure
> 
> == Summary ==
> 
> Series 24254v1 drm/i915: Detect USB-C specific dongles before reducing M
> and N
> https://patchwork.freedesktop.org/api/1.0/series/24254/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> INCOMPLETE (fi-bxt-t5700)
Re-run this to see if ELK was happy now as it was. But now Joule is not. 
> 
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:443s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:439s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:581s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:515s
> fi-bxt-t5700 total:209  pass:195  dwarn:0   dfail:0   fail:0   skip:13
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:492s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:483s
> fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
> time:432s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:415s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:414s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:423s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:487s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:476s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:462s
> fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:580s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:459s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:577s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:471s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:503s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:438s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:541s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time:408s
> 
> 4149c7b22164d81960dae0987f497725117b68e6 drm-tip: 2017y-05m-10d-18h-
> 09m-15s UTC integration manifest
> d1b8be1 drm/i915: Detect USB-C specific dongles before reducing M and N
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4668/

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



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

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

[Li, Weinan Z]

> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, May 10, 2017 6:43 PM
> To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; 
> intel-
> gvt-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Subject: Re: [PATCH v4] drm/i915/gvt: return the correct usable aperture size
> under gvt environment
> 
> On ke, 2017-05-10 at 10:59 +0800, Weinan Li wrote:
> > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> userspace.
> > In gvt environment, each vm only use the ballooned part of aperture,
> > so we should return the correct available aperture size exclude the
> > reserved part by balloon.
> >
> > v2: add 'reserved' in struct i915_address_space to record the reserved
> > size in ggtt.
> >
> > v3: remain aper_size as total, adjust aper_available_size exclude
> > reserved and pinned. UMD driver need to adjust the max allocation size
> > according to the available aperture size but not total size. KMD
> > return the correct usable aperture size any time.
> >
> > v4: add onion teardown to balloon and deballoon to make sure the
> > reserved stays correct. Code style refine.
> 
> There's no onion teardown seen yet, please read:
> 
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html#central
> ized-exiting-of-functions
> 
> Please incorporate the addition to vgt_balloon_space function to reduce code
> duplication.
> 
> Once the proper teardown is implemented, intel_vgt_deballoon function should
> unconditionally remove the drm_mm nodes as there's no condition when only
> one of them would be allocated. And intel_vgt_balloon definitely should not 
> call
> intel_vgt_deballoon in error path as per the coding style above.

Thanks Joonas. A little change is brought in if move the fail checking into 
balloon_space()
There are 4 balloon spaces, current policy is if any one fail clean up all the 
success ones, with
this change it won't clean up the success ones. It should not impact the 
driver's behavior.

@@ -120,6 +122,7 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
 struct drm_mm_node *node,
 unsigned long start, unsigned long end)
 {
+   int ret;
unsigned long size = end - start;

if (start >= end)
@@ -127,9 +130,14 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,

DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
 start, end, size / 1024);
-   return i915_gem_gtt_reserve(>base, node,
+   ret = i915_gem_gtt_reserve(>base, node,
size, start, I915_COLOR_UNEVICTABLE,
0);
+   if (!ret)
+   ggtt->base.reserved += size;
+   else
+   memset(node, 0, sizeof(*node));
+   return ret;
 }

 /**
@@ -247,6 +255,5 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)

 err:
DRM_ERROR("VGT balloon fail\n");
-   intel_vgt_deballoon(dev_priv);
return ret;
 }
> 
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: remove the duplicated size check in i915_gem_dmabuf_mmap()

[Chris Wilson]

On Wed, May 10, 2017 at 09:05:37PM -0700, Dongseong Hwang wrote:
> dma_buf_mmap_internal() already checks for overflowing the buffer's size.
> In addition, the check in i915_gem_dmabuf_mmap() is incomplete, which doesn't
> consider a page offset.

Please read Documentation/process/submitting-patches, in particular the
Developer's Certificate of Origin 1.1, and apply your s-o-b.

When resending please wrap the commitlog at 72cols (no more than
75cols).
-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 v1 2/4] drm/i915: introduce vgt_caps to pvinfo

[Joonas Lahtinen]

On to, 2017-05-11 at 10:33 +0800, Tina Zhang wrote:
> vgt_caps is used for guest i915 driver to get the vgpu capabilities
> from the device model.
> 
> Signed-off-by: Tina Zhang 



> +++ b/drivers/gpu/drm/i915/i915_pvinfo.h
> @@ -58,7 +58,8 @@ struct vgt_if {
>   uint16_t version_major;
>   uint16_t version_minor;
>   u32 vgt_id; /* ID of vGT instance */
> - u32 rsv1[12];   /* pad to offset 0x40 */
> + uint32_t  vgt_caps; /* VGT capabilities */

This should really be u32 too.

Regards, Joonas

> + u32 rsv1[11];   /* pad to offset 0x40 */
>   /*
>    *  Data structure to describe the balooning info of resources.
>    *  Each VM can only have one portion of continuous area for now.
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Remove vma unpin in intel_plane_destroy

[Maarten Lankhorst]

commit a667fb402c1e856209bf9e77ba41fc1cf356b867
Author: Maarten Lankhorst 
Date:   Thu Dec 15 15:29:44 2016 +0100

drm/i915: Disable all crtcs during driver unload, v2.

made sure that all crtc's are disabled on driver unload, but only the
following commit made sure all fb's are cleaned up correctly:

commit 9b2104f423de5c148749a07e8197dbab4c449877
Author: Maarten Lankhorst 
Date:   Tue Feb 21 14:51:40 2017 +0100

drm/atomic: Make disable_all helper fully disable the crtc.

Finally remove this and add a WARN_ON when vma is set. It should
have been removed by intel_cleanup_plane_fb().

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index cfb47293fd53..cd74a7dca3ce 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -102,23 +102,7 @@ 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);
-   }
+   WARN_ON(to_intel_plane_state(state)->vma);
 
drm_atomic_helper_plane_destroy_state(plane, state);
 }
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix hw state verifier access to crtc->state.

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix hw state verifier access to 
crtc->state.
URL   : https://patchwork.freedesktop.org/series/24281/
State : success

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:435s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:437s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:593s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:518s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:553s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:487s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:490s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:577s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:464s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:582s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:503s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:410s

4149c7b22164d81960dae0987f497725117b68e6 drm-tip: 2017y-05m-10d-18h-09m-15s UTC 
integration manifest
10cf0f5 drm/i915: Remove vma unpin in intel_plane_destroy
afc741a drm/i915: Fix hw state verifier access to crtc->state.

== Logs ==

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

Re: [Intel-gfx] [PATCH 11/67] drm/i915/cnl: add IS_CNL_REVID macro

[Jim Bride]

On Thu, Apr 06, 2017 at 12:15:07PM -0700, Rodrigo Vivi wrote:
> From: Paulo Zanoni 
> 
> We're going to use it in the next commits.
> 
> Signed-off-by: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a357862..7dda202 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2830,6 +2830,12 @@ static inline struct scatterlist *__sg_next(struct 
> scatterlist *sg)
>  #define IS_GLK_REVID(dev_priv, since, until) \
>   (IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
>  
> +#define CNL_REVID_A0 0x0
> +#define CNL_REVID_B0 0x1
> +
> +#define IS_CNL_REVID(p, since, until) \
> + (IS_CANNONLAKE(p) && IS_REVID(p, since, until))
> +
>  /*
>   * The genX designation typically refers to the render engine, so render
>   * capability related checks should use IS_GEN, while display and other 
> checks
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 13/22] drm/i915: expose _SUBSLICE_MASK GETPARM

[Lionel Landwerlin]

From: Robert Bragg 

Assuming a uniform mask across all slices, this enables userspace to
determine the specific sub slices enabled. This information is required,
for example, to be able to analyse some OA counter reports where the
counter configuration depends on the HW sub slice configuration.

Signed-off-by: Robert Bragg 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c | 12 
 include/uapi/drm/i915_drm.h |  5 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ebe0a2b328f..927e1ed5130e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -370,6 +370,18 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
mutex_unlock(_priv->drm.struct_mutex);
break;
}
+   case I915_PARAM_SUBSLICE_MASK: {
+   const const struct sseu_dev_info *sseu;
+   int ret = i915_mutex_lock_interruptible(_priv->drm);
+   if (ret)
+   return ret;
+
+   sseu = i915_oa_get_sseu(dev_priv, NULL);
+   value = sseu->subslice_mask;
+
+   mutex_unlock(_priv->drm.struct_mutex);
+   break;
+   }
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 25695c3d9a76..464547d08173 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -421,6 +421,11 @@ typedef struct drm_i915_irq_wait {
 /* Query the mask of slices available for this system */
 #define I915_PARAM_SLICE_MASK   46
 
+/* Assuming it's uniform for each slice, this queries the mask of subslices
+ * per-slice for this system.
+ */
+#define I915_PARAM_SUBSLICE_MASK47
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
-- 
2.11.0

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

[Intel-gfx] [PATCH 16/22] drm/i915/perf: Add OA unit support for Gen 8+

[Lionel Landwerlin]

From: Robert Bragg 

Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.

Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.

The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).

This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.

The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).

Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.

v5: Drain submitted requests when enabling metric set to ensure no
lite-restore erases the context image we just updated (Lionel)

v6: In addition to drain, switch to kernel context & update all
context in place (Chris)

v7: Add missing mutex_unlock() if switching to kernel context fails
(Matthew)

v8: Simplify OA period/flex-eu-counters programming by using the
batchbuffer instead of modifying ctx-image (Lionel)

v9: Back to updating the context image (due to erroneous testing,
batchbuffer programming the OA unit doesn't actually work)
(Lionel)
Pin context before updating context image (Chris)
Drop MMIO programming now that we switch to a kernel context with
right values in initial context image (Chris)

v10: Just pin_map the contexts we want to modify or let the
 configuration happen on first use (Chris)

v11: Update kernel context OA config through the batchbuffer rather
 than on the fly ctx-image update (Lionel)

v12: Rework OA context registers update again by swithing away from
 user contexts and reconfiguring the kernel context through the
 batchbuffer and updating all the other contexts' context image.
 Also take care to lock slice/subslice configuration when OA is
 on. (Lionel)

Signed-off-by: Robert Bragg 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld  \o/
---
 drivers/gpu/drm/i915/i915_drv.h  |   45 +-
 drivers/gpu/drm/i915/i915_perf.c | 1023 +++---
 drivers/gpu/drm/i915/i915_reg.h  |   22 +
 drivers/gpu/drm/i915/intel_lrc.c |   12 +-
 drivers/gpu/drm/i915/intel_lrc.h |5 +
 include/uapi/drm/i915_drm.h  |   19 +-
 6 files changed, 1029 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7e3d88f2f0dd..e24165510320 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1949,9 +1949,17 @@ struct i915_oa_ops {
void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
 
/**
-* @enable_metric_set: Applies any MUX configuration to set up the
-* Boolean and Custom (B/C) counters that are part of the counter
-* reports being sampled. May apply system constraints such as
+* @select_metric_set: The auto generated 

[Intel-gfx] [PATCH 15/22] drm/i915/perf: Add 'render basic' Gen8+ OA unit configs

[Lionel Landwerlin]

From: Robert Bragg 

Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:

 https://github.com/rib/gputop
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic

v2: add newlines to debug messages + fix comment (Matthew Auld)

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
Acked-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/Makefile |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_oa_bdw.c| 380 ++
 drivers/gpu/drm/i915/i915_oa_bdw.h|  38 
 drivers/gpu/drm/i915/i915_oa_bxt.c| 238 +
 drivers/gpu/drm/i915/i915_oa_bxt.h|  38 
 drivers/gpu/drm/i915/i915_oa_chv.c| 225 
 drivers/gpu/drm/i915/i915_oa_chv.h|  38 
 drivers/gpu/drm/i915/i915_oa_sklgt2.c | 228 
 drivers/gpu/drm/i915/i915_oa_sklgt2.h |  38 
 drivers/gpu/drm/i915/i915_oa_sklgt3.c | 236 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.h |  38 
 drivers/gpu/drm/i915/i915_oa_sklgt4.c | 247 ++
 drivers/gpu/drm/i915/i915_oa_sklgt4.h |  38 
 14 files changed, 1791 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7b05fb802f4c..aabc660f94cb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -128,7 +128,13 @@ i915-y += i915_vgpu.o
 
 # perf code
 i915-y += i915_perf.o \
- i915_oa_hsw.o
+ i915_oa_hsw.o \
+ i915_oa_bdw.o \
+ i915_oa_chv.o \
+ i915_oa_sklgt2.o \
+ i915_oa_sklgt3.o \
+ i915_oa_sklgt4.o \
+ i915_oa_bxt.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a2044eda9e6..7e3d88f2f0dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2352,6 +2352,8 @@ struct drm_i915_private {
int n_mux_regs;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+   const struct i915_oa_reg *flex_regs;
+   int flex_regs_len;
 
struct {
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c 
b/drivers/gpu/drm/i915/i915_oa_bdw.c
new file mode 100644
index ..b0b1b75fb431
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -0,0 +1,380 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_bdw.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_bdw = 1;
+
+static const struct i915_oa_reg 

[Intel-gfx] [PATCH 22/22] drm/i915/perf: add GLK support

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/Makefile  |3 +-
 drivers/gpu/drm/i915/i915_oa_glk.c | 2600 
 drivers/gpu/drm/i915/i915_oa_glk.h |   38 +
 drivers/gpu/drm/i915/i915_perf.c   |   15 +-
 4 files changed, 2654 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 859e1751d7ab..bb781bc628df 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -136,7 +136,8 @@ i915-y += i915_perf.o \
  i915_oa_sklgt4.o \
  i915_oa_bxt.o \
  i915_oa_kblgt2.o \
- i915_oa_kblgt3.o
+ i915_oa_kblgt3.o \
+ i915_oa_glk.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_oa_glk.c 
b/drivers/gpu/drm/i915/i915_oa_glk.c
new file mode 100644
index ..bda07ffaa40b
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_glk.c
@@ -0,0 +1,2600 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_glk.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_RENDER_PIPE_PROFILE,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_COMPUTE_L3_CACHE,
+   METRIC_SET_ID_HDC_AND_SF,
+   METRIC_SET_ID_L3_1,
+   METRIC_SET_ID_RASTERIZER_AND_PIXEL_BACKEND,
+   METRIC_SET_ID_SAMPLER,
+   METRIC_SET_ID_TDL_1,
+   METRIC_SET_ID_TDL_2,
+   METRIC_SET_ID_COMPUTE_EXTRA,
+   METRIC_SET_ID_TEST_OA,
+};
+
+int i915_oa_n_builtin_metric_sets_glk = 15;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2740), 0x },
+};
+
+static const struct i915_oa_reg flex_eu_config_render_basic[] = {
+   { _MMIO(0xe458), 0x5004 },
+   { _MMIO(0xe558), 0x00010003 },
+   { _MMIO(0xe658), 0x00012011 },
+   { _MMIO(0xe758), 0x00015014 },
+   { _MMIO(0xe45c), 0x00051050 },
+   { _MMIO(0xe55c), 0x00053052 },
+   { _MMIO(0xe65c), 0x00055054 },
+};
+
+static const struct i915_oa_reg mux_config_render_basic[] = {
+   { _MMIO(0x9888), 0x166c00f0 },
+   { _MMIO(0x9888), 0x12120280 },
+   { _MMIO(0x9888), 0x12320280 },
+   { _MMIO(0x9888), 0x11930317 },
+   { _MMIO(0x9888), 0x159303df },
+   { _MMIO(0x9888), 0x3f900c00 },
+   { _MMIO(0x9888), 0x419000a0 },
+   { _MMIO(0x9888), 0x002d1000 },
+   { _MMIO(0x9888), 0x062d4000 },
+   { _MMIO(0x9888), 0x082d5000 },
+   { _MMIO(0x9888), 0x0a2d1000 },
+   { _MMIO(0x9888), 0x0c2e0800 },
+   { _MMIO(0x9888), 0x0e2e5900 },
+   { _MMIO(0x9888), 0x0a4c8000 },
+   { _MMIO(0x9888), 0x0c4c8000 },
+   { _MMIO(0x9888), 0x0e4c4000 },
+   { _MMIO(0x9888), 0x064e8000 },
+   { _MMIO(0x9888), 0x084e8000 },
+   { _MMIO(0x9888), 0x0a4e2000 },
+   { _MMIO(0x9888), 0x1c4f0010 },
+   { _MMIO(0x9888), 0x0a6c0053 },
+   { _MMIO(0x9888), 0x106c },
+   { _MMIO(0x9888), 0x1c6c },
+   { _MMIO(0x9888), 0x1a0fcc00 },
+   { _MMIO(0x9888), 0x1c0f0002 },
+   { _MMIO(0x9888), 0x1c2c0040 },
+   { _MMIO(0x9888), 0x00101000 },
+   { _MMIO(0x9888), 0x04101000 },
+   { _MMIO(0x9888), 0x00114000 },
+   { _MMIO(0x9888), 0x08114000 },
+   { _MMIO(0x9888), 0x00120020 },
+   { _MMIO(0x9888), 0x08120021 },
+   { _MMIO(0x9888), 0x00141000 

[Intel-gfx] [PATCH 14/22] drm/i915/perf: rework mux configurations queries

[Lionel Landwerlin]

Gen8+ might have mux configurations per slices/subslices. Depending on
whether slices/subslices have been fused off, only part of the
configuration needs to be applied. This change reworks the mux
configurations query mechanism to allow more than one set of registers
to be programmed.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h|   5 +-
 drivers/gpu/drm/i915/i915_oa_hsw.c | 211 -
 drivers/gpu/drm/i915/i915_perf.c   |   7 +-
 3 files changed, 144 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3733b7433d40..7a2044eda9e6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2347,8 +2347,9 @@ struct drm_i915_private {
 
int metrics_set;
 
-   const struct i915_oa_reg *mux_regs;
-   int mux_regs_len;
+   const struct i915_oa_reg *mux_regs[1];
+   int mux_regs_lens[1];
+   int n_mux_regs;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
 
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 4ddf756add31..ccd6e5124992 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -109,12 +109,21 @@ static const struct i915_oa_reg mux_config_render_basic[] 
= {
{ _MMIO(0x25428), 0x00042049 },
 };
 
-static const struct i915_oa_reg *
+static int
 get_render_basic_mux_config(struct drm_i915_private *dev_priv,
-   int *len)
+   const struct i915_oa_reg **regs,
+   int *lens)
 {
-   *len = ARRAY_SIZE(mux_config_render_basic);
-   return mux_config_render_basic;
+   int n = 0;
+
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+   regs[n] = mux_config_render_basic;
+   lens[n] = ARRAY_SIZE(mux_config_render_basic);
+   n++;
+
+   return n;
 }
 
 static const struct i915_oa_reg b_counter_config_compute_basic[] = {
@@ -172,12 +181,21 @@ static const struct i915_oa_reg 
mux_config_compute_basic[] = {
{ _MMIO(0x25428), 0x0c03 },
 };
 
-static const struct i915_oa_reg *
+static int
 get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
-int *len)
+const struct i915_oa_reg **regs,
+int *lens)
 {
-   *len = ARRAY_SIZE(mux_config_compute_basic);
-   return mux_config_compute_basic;
+   int n = 0;
+
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+   regs[n] = mux_config_compute_basic;
+   lens[n] = ARRAY_SIZE(mux_config_compute_basic);
+   n++;
+
+   return n;
 }
 
 static const struct i915_oa_reg b_counter_config_compute_extended[] = {
@@ -221,12 +239,21 @@ static const struct i915_oa_reg 
mux_config_compute_extended[] = {
{ _MMIO(0x25428), 0x },
 };
 
-static const struct i915_oa_reg *
+static int
 get_compute_extended_mux_config(struct drm_i915_private *dev_priv,
-   int *len)
+   const struct i915_oa_reg **regs,
+   int *lens)
 {
-   *len = ARRAY_SIZE(mux_config_compute_extended);
-   return mux_config_compute_extended;
+   int n = 0;
+
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+   regs[n] = mux_config_compute_extended;
+   lens[n] = ARRAY_SIZE(mux_config_compute_extended);
+   n++;
+
+   return n;
 }
 
 static const struct i915_oa_reg b_counter_config_memory_reads[] = {
@@ -281,12 +308,21 @@ static const struct i915_oa_reg mux_config_memory_reads[] 
= {
{ _MMIO(0x25428), 0x },
 };
 
-static const struct i915_oa_reg *
+static int
 get_memory_reads_mux_config(struct drm_i915_private *dev_priv,
-   int *len)
+   const struct i915_oa_reg **regs,
+   int *lens)
 {
-   *len = ARRAY_SIZE(mux_config_memory_reads);
-   return mux_config_memory_reads;
+   int n = 0;
+
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs) < 1);
+   BUILD_BUG_ON(ARRAY_SIZE(dev_priv->perf.oa.mux_regs_lens) < 1);
+
+   regs[n] = mux_config_memory_reads;
+   lens[n] = ARRAY_SIZE(mux_config_memory_reads);
+   n++;
+
+   return n;
 }
 
 static const struct i915_oa_reg b_counter_config_memory_writes[] = {
@@ -341,12 +377,21 @@ static const struct i915_oa_reg 
mux_config_memory_writes[] = {
{ _MMIO(0x25428), 0x },
 };
 
-static 

[Intel-gfx] [PATCH 12/22] drm/i915: expose _SLICE_MASK GETPARM

[Lionel Landwerlin]

From: Robert Bragg 

Enables userspace to determine the number of slices enabled and also
know what specific slices are enabled. This information is required, for
example, to be able to analyse some OA counter reports where the counter
configuration depends on the HW slice configuration.

Signed-off-by: Robert Bragg 
Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c | 12 
 drivers/gpu/drm/i915/i915_drv.h | 28 
 include/uapi/drm/i915_drm.h |  3 +++
 3 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72fb47a439d2..1ebe0a2b328f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -358,6 +358,18 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 */
value = 1;
break;
+   case I915_PARAM_SLICE_MASK: {
+   const const struct sseu_dev_info *sseu;
+   int ret = i915_mutex_lock_interruptible(_priv->drm);
+   if (ret)
+   return ret;
+
+   sseu = i915_oa_get_sseu(dev_priv, NULL);
+   value = sseu->slice_mask;
+
+   mutex_unlock(_priv->drm.struct_mutex);
+   break;
+   }
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4c47975d149..3733b7433d40 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3454,6 +3454,34 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
 
+/* Decide what sseu configuration should be used. There are 3 cases :
+ * - If OA is not used, we should use the context's configuration
+ * - If OA is used but not monitoring a particular context, we should use
+ *   the device's configuration
+ * - If OA is used and monitoring a particular context, we should the
+ *   monitored context's configuration
+ */
+static inline const struct sseu_dev_info *
+i915_oa_get_sseu(struct drm_i915_private *dev_priv,
+struct i915_gem_context *ctx)
+{
+   struct i915_perf_stream *stream;
+
+   lockdep_assert_held(_priv->drm.struct_mutex);
+
+   if (!dev_priv->perf.initialized)
+   return ctx ? >sseu : _INFO(dev_priv)->sseu;
+
+   stream = dev_priv->perf.oa.exclusive_stream;
+   if (!stream)
+   return ctx ? >sseu : _INFO(dev_priv)->sseu;
+
+   if (!stream->ctx)
+   return _INFO(dev_priv)->sseu;
+
+   return >ctx->sseu;
+}
+
 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct i915_address_space *vm,
  u64 min_size, u64 alignment,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f24a80d2d42e..25695c3d9a76 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -418,6 +418,9 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_HAS_EXEC_CAPTURE 45
 
+/* Query the mask of slices available for this system */
+#define I915_PARAM_SLICE_MASK   46
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
-- 
2.11.0

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

[Intel-gfx] [PATCH 18/22] drm/i915/perf: per-gen timebase for checking sample freq

[Lionel Landwerlin]

From: Robert Bragg 

An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5MHz
timebase as we did for Haswell.

Accordingly the oa_sample_rate_hard_limit value that's referenced by
proc_dointvec_minmax defining the absolute limit for the OA sampling
frequency is now initialized to (timestamp_frequency / 2) instead of the
6.25MHz constant for Haswell.

v2:
Specify frequency of 19.2MHz for BXT (Ville)
Initialize oa_sample_rate_hard_limit per-gen too (Lionel)

Signed-off-by: Robert Bragg 
Cc: Lionel Landwerlin 
Cc: Ville Syrjälä 
Reviewed-by: Matthew Auld 
Acked-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 39 ---
 2 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ddacf1125108..a01c542aaf4b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2345,6 +2345,7 @@ struct drm_i915_private {
 
bool periodic;
int period_exponent;
+   int timestamp_frequency;
 
int metrics_set;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c05c5e8a2328..c23abea47d80 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -288,10 +288,12 @@ static u32 i915_perf_stream_paranoid = true;
 
 /* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate
  *
- * 160ns is the smallest sampling period we can theoretically program the OA
- * unit with on Haswell, corresponding to 6.25MHz.
+ * The highest sampling frequency we can theoretically program the OA unit
+ * with is always half the timestamp frequency: E.g. 6.25Mhz for Haswell.
+ *
+ * Initialized just before we register the sysctl parameter.
  */
-static int oa_sample_rate_hard_limit = 625;
+static int oa_sample_rate_hard_limit;
 
 /* Theoretically we can program the OA unit to sample every 160ns but don't
  * allow that by default unless root...
@@ -2632,6 +2634,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
return ret;
 }
 
+static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
+{
+   return div_u64(10ULL * (2ULL << exponent),
+  dev_priv->perf.oa.timestamp_frequency);
+}
+
 /**
  * read_properties_unlocked - validate + copy userspace stream open properties
  * @dev_priv: i915 device instance
@@ -2728,16 +2736,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
}
 
/* Theoretically we can program the OA unit to sample
-* every 160ns but don't allow that by default unless
-* root.
-*
-* On Haswell the period is derived from the exponent
-* as:
-*
-*   period = 80ns * 2^(exponent + 1)
+* e.g. every 160ns for HSW, 167ns for BDW/SKL or 104ns
+* for BXT. We don't allow such high sampling
+* frequencies by default unless root.
 */
+
BUILD_BUG_ON(sizeof(oa_period) != 8);
-   oa_period = 80ull * (2ull << value);
+   oa_period = oa_exponent_to_ns(dev_priv, value);
 
/* This check is primarily to ensure that oa_period <=
 * UINT32_MAX (before passing to do_div which only
@@ -2993,6 +2998,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
 
+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
 
dev_priv->perf.oa.n_builtin_sets =
@@ -3008,6 +3015,9 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
if (IS_GEN8(dev_priv)) {
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
+
+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
 
if (IS_BROADWELL(dev_priv)) {
@@ -3024,6 +3034,9 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
} else if 

[Intel-gfx] [PATCH 19/22] drm/i915/perf: remove perf.hook_lock

[Lionel Landwerlin]

From: Robert Bragg 

In earlier iterations of the i915-perf driver we had a number of
callbacks/hooks from other parts of the i915 driver to e.g. notify us
when a legacy context was pinned and these could run asynchronously with
respect to the stream file operations and might also run in atomic
context.

dev_priv->perf.hook_lock had been for serialising access to state needed
within these callbacks, but as the code has evolved some of the hooks
have gone away or are implemented to avoid needing to lock any state.

The remaining use of this lock was actually redundant considering how
the gen7 oacontrol state used to be updated as part of a context pin
hook.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
Acked-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 --
 drivers/gpu/drm/i915/i915_perf.c | 32 ++--
 2 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a01c542aaf4b..e9df52031eae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2326,8 +2326,6 @@ struct drm_i915_private {
struct mutex lock;
struct list_head streams;
 
-   spinlock_t hook_lock;
-
struct {
struct i915_perf_stream *exclusive_stream;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c23abea47d80..58c928eb70e6 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1829,9 +1829,17 @@ static void gen8_disable_metric_set(struct 
drm_i915_private *dev_priv)
gen8_configure_all_contexts(dev_priv, false);
 }
 
-static void gen7_update_oacontrol_locked(struct drm_i915_private *dev_priv)
+static void gen7_oa_enable(struct drm_i915_private *dev_priv)
 {
-   lockdep_assert_held(_priv->perf.hook_lock);
+   /* Reset buf pointers so we don't forward reports from before now.
+*
+* Think carefully if considering trying to avoid this, since it
+* also ensures status flags and the buffer itself are cleared
+* in error paths, and we have checks for invalid reports based
+* on the assumption that certain fields are written to zeroed
+* memory which this helps maintains.
+*/
+   gen7_init_oa_buffer(dev_priv);
 
if (dev_priv->perf.oa.exclusive_stream->enabled) {
struct i915_gem_context *ctx =
@@ -1854,25 +1862,6 @@ static void gen7_update_oacontrol_locked(struct 
drm_i915_private *dev_priv)
I915_WRITE(GEN7_OACONTROL, 0);
 }
 
-static void gen7_oa_enable(struct drm_i915_private *dev_priv)
-{
-   unsigned long flags;
-
-   /* Reset buf pointers so we don't forward reports from before now.
-*
-* Think carefully if considering trying to avoid this, since it
-* also ensures status flags and the buffer itself are cleared
-* in error paths, and we have checks for invalid reports based
-* on the assumption that certain fields are written to zeroed
-* memory which this helps maintains.
-*/
-   gen7_init_oa_buffer(dev_priv);
-
-   spin_lock_irqsave(_priv->perf.hook_lock, flags);
-   gen7_update_oacontrol_locked(dev_priv);
-   spin_unlock_irqrestore(_priv->perf.hook_lock, flags);
-}
-
 static void gen8_oa_enable(struct drm_i915_private *dev_priv)
 {
u32 report_format = dev_priv->perf.oa.oa_buffer.format;
@@ -3088,7 +3077,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 
INIT_LIST_HEAD(_priv->perf.streams);
mutex_init(_priv->perf.lock);
-   spin_lock_init(_priv->perf.hook_lock);
spin_lock_init(_priv->perf.oa.oa_buffer.ptr_lock);
 
oa_sample_rate_hard_limit =
-- 
2.11.0

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

[Intel-gfx] [PATCH 20/22] drm/i915: add KBL GT2/GT3 check macros

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e9df52031eae..88906c79f982 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2752,6 +2752,10 @@ intel_info(const struct drm_i915_private *dev_priv)
 (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0020)
 #define IS_SKL_GT4(dev_priv)   (IS_SKYLAKE(dev_priv) && \
 (INTEL_DEVID(dev_priv) & 0x00F0) == 0x0030)
+#define IS_KBL_GT2(dev_priv)   (IS_KABYLAKE(dev_priv) && \
+(INTEL_DEVID(dev_priv) & 0x00F0) == 0x0010)
+#define IS_KBL_GT3(dev_priv)   (IS_KABYLAKE(dev_priv) && \
+(INTEL_DEVID(dev_priv) & 0x00F0) == 0x0020)
 
 #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
 
-- 
2.11.0

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

[Intel-gfx] [PATCH 03/22] drm/i915/perf: avoid read back of head register

[Lionel Landwerlin]

From: Robert Bragg 

There's no need for the driver to keep reading back the head pointer
from hardware since the hardware doesn't update it automatically. This
way we can treat any invalid head pointer value as a software/driver
bug instead of spurious hardware behaviour.

This change is also a small stepping stone towards re-working how
the head and tail state is managed as part of an improved workaround
for the tail register race condition.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h  | 11 ++
 drivers/gpu/drm/i915/i915_perf.c | 46 ++--
 2 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff3574a56812..080dcb0c5bd6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2372,6 +2372,17 @@ struct drm_i915_private {
u8 *vaddr;
int format;
int format_size;
+
+   /**
+* Although we can always read back the head
+* pointer register, we prefer to avoid
+* trusting the HW state, just to avoid any
+* risk that some hardware condition could
+* somehow bump the head pointer unpredictably
+* and cause us to forward the wrong OA buffer
+* data to userspace.
+*/
+   u32 head;
} oa_buffer;
 
u32 gen7_latched_oastatus1;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e1158893c6cb..838ebc03976f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -322,9 +322,8 @@ struct perf_open_properties {
 static bool gen7_oa_buffer_is_empty_fop_unlocked(struct drm_i915_private 
*dev_priv)
 {
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
-   u32 oastatus2 = I915_READ(GEN7_OASTATUS2);
u32 oastatus1 = I915_READ(GEN7_OASTATUS1);
-   u32 head = oastatus2 & GEN7_OASTATUS2_HEAD_MASK;
+   u32 head = dev_priv->perf.oa.oa_buffer.head;
u32 tail = oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
 
return OA_TAKEN(tail, head) <
@@ -458,16 +457,24 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
return -EIO;
 
head = *head_ptr - gtt_offset;
+
+   /* An out of bounds or misaligned head pointer implies a driver bug
+* since we are in full control of head pointer which should only
+* be incremented by multiples of the report size (notably also
+* all a power of two).
+*/
+   if (WARN_ONCE(head > OA_BUFFER_SIZE || head % report_size,
+ "Inconsistent OA buffer head pointer = %u\n", head))
+   return -EIO;
+
tail -= gtt_offset;
 
/* The OA unit is expected to wrap the tail pointer according to the OA
-* buffer size and since we should never write a misaligned head
-* pointer we don't expect to read one back either...
+* buffer size
 */
-   if (tail > OA_BUFFER_SIZE || head > OA_BUFFER_SIZE ||
-   head % report_size) {
-   DRM_ERROR("Inconsistent OA buffer pointer (head = %u, tail = 
%u): force restart\n",
- head, tail);
+   if (tail > OA_BUFFER_SIZE) {
+   DRM_ERROR("Inconsistent OA buffer tail pointer = %u: force 
restart\n",
+ tail);
dev_priv->perf.oa.ops.oa_disable(dev_priv);
dev_priv->perf.oa.ops.oa_enable(dev_priv);
*head_ptr = I915_READ(GEN7_OASTATUS2) &
@@ -562,8 +569,6 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
size_t *offset)
 {
struct drm_i915_private *dev_priv = stream->dev_priv;
-   int report_size = dev_priv->perf.oa.oa_buffer.format_size;
-   u32 oastatus2;
u32 oastatus1;
u32 head;
u32 tail;
@@ -572,10 +577,9 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
if (WARN_ON(!dev_priv->perf.oa.oa_buffer.vaddr))
return -EIO;
 
-   oastatus2 = I915_READ(GEN7_OASTATUS2);
oastatus1 = I915_READ(GEN7_OASTATUS1);
 
-   head = oastatus2 & GEN7_OASTATUS2_HEAD_MASK;
+   head = dev_priv->perf.oa.oa_buffer.head;
tail = oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
 
/* XXX: On Haswell we don't have a safe way to clear oastatus1
@@ -616,10 +620,9 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
dev_priv->perf.oa.ops.oa_disable(dev_priv);

[Intel-gfx] [PATCH 08/22] drm/i915/perf: rate limit spurious oa report notice

[Lionel Landwerlin]

From: Robert Bragg 

This change is pre-emptively aiming to avoid a potential cause of kernel
logging noise in case some condition were to result in us seeing invalid
OA reports.

The workaround for the OA unit's tail pointer race condition is what
avoids the primary known cause of invalid reports being seen and with
that in place we aren't expecting to see this notice but it can't be
entirely ruled out.

Just in case some condition does lead to the notice then it's likely
that it will be triggered repeatedly while attempting to append a
sequence of reports and depending on the configured OA sampling
frequency that might be a large number of repeat notices.

v2: (Chris) avoid inconsistent warning on throttle with
printk_ratelimit()
v3: (Matt) init and summarise with stream init/close not driver init/fini

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h  |  6 ++
 drivers/gpu/drm/i915/i915_perf.c | 28 +++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 22b2ea3ea66f..66dee15e4fc0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2354,6 +2354,12 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
 
+   /**
+* For rate limiting any notifications of spurious
+* invalid OA reports
+*/
+   struct ratelimit_state spurious_report_rs;
+
bool periodic;
int period_exponent;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index dbed19a5a1b2..665a3c53e388 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -632,7 +632,8 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
 * copying it to userspace...
 */
if (report32[0] == 0) {
-   DRM_NOTE("Skipping spurious, invalid OA report\n");
+   if (__ratelimit(_priv->perf.oa.spurious_report_rs))
+   DRM_NOTE("Skipping spurious, invalid OA 
report\n");
continue;
}
 
@@ -912,6 +913,11 @@ static void i915_oa_stream_destroy(struct i915_perf_stream 
*stream)
oa_put_render_ctx_id(stream);
 
dev_priv->perf.oa.exclusive_stream = NULL;
+
+   if (dev_priv->perf.oa.spurious_report_rs.missed) {
+   DRM_NOTE("%d spurious OA report notices suppressed due to 
ratelimiting\n",
+dev_priv->perf.oa.spurious_report_rs.missed);
+   }
 }
 
 static void gen7_init_oa_buffer(struct drm_i915_private *dev_priv)
@@ -1267,6 +1273,26 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
return -EINVAL;
}
 
+   /* We set up some ratelimit state to potentially throttle any _NOTES
+* about spurious, invalid OA reports which we don't forward to
+* userspace.
+*
+* The initialization is associated with opening the stream (not driver
+* init) considering we print a _NOTE about any throttling when closing
+* the stream instead of waiting until driver _fini which no one would
+* ever see.
+*
+* Using the same limiting factors as printk_ratelimit()
+*/
+   ratelimit_state_init(_priv->perf.oa.spurious_report_rs,
+5 * HZ, 10);
+   /* Since we use a DRM_NOTE for spurious reports it would be
+* inconsistent to let __ratelimit() automatically print a warning for
+* throttling.
+*/
+   ratelimit_set_flags(_priv->perf.oa.spurious_report_rs,
+   RATELIMIT_MSG_ON_RELEASE);
+
stream->sample_size = sizeof(struct drm_i915_perf_record_header);
 
format_size = dev_priv->perf.oa.oa_formats[props->oa_format].size;
-- 
2.11.0

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

[Intel-gfx] [PATCH 06/22] drm/i915/perf: improve invalid OA format debug message

[Lionel Landwerlin]

From: Robert Bragg 

A minor improvement to debugging output

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_perf.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index dd60045e1840..99c9c51c6617 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1903,11 +1903,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
break;
case DRM_I915_PERF_PROP_OA_FORMAT:
if (value == 0 || value >= I915_OA_FORMAT_MAX) {
-   DRM_DEBUG("Invalid OA report format\n");
+   DRM_DEBUG("Out-of-range OA report format 
%llu\n",
+ value);
return -EINVAL;
}
if (!dev_priv->perf.oa.oa_formats[value].size) {
-   DRM_DEBUG("Invalid OA report format\n");
+   DRM_DEBUG("Unsupported OA report format %llu\n",
+ value);
return -EINVAL;
}
props->oa_format = value;
-- 
2.11.0

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

[Intel-gfx] [PATCH 05/22] drm/i915/perf: improve tail race workaround

[Lionel Landwerlin]

From: Robert Bragg 

There's a HW race condition between OA unit tail pointer register
updates and writes to memory whereby the tail pointer can sometimes get
ahead of what's been written out to the OA buffer so far (in terms of
what's visible to the CPU).

Although this can be observed explicitly while copying reports to
userspace by checking for a zeroed report-id field in tail reports, we
want to account for this earlier, as part of the _oa_buffer_check to
avoid lots of redundant read() attempts.

Previously the driver used to define an effective tail pointer that
lagged the real pointer by a 'tail margin' measured in bytes derived
from OA_TAIL_MARGIN_NSEC and the configured sampling frequency.
Unfortunately this was flawed considering that the OA unit may also
automatically generate non-periodic reports (such as on context switch)
or the OA unit may be enabled without any periodic sampling.

This improves how we define a tail pointer for reading that lags the
real tail pointer by at least %OA_TAIL_MARGIN_NSEC nanoseconds, which
gives enough time for the corresponding reports to become visible to the
CPU.

The driver now maintains two tail pointers:
 1) An 'aging' tail with an associated timestamp that is tracked until we
can trust the corresponding data is visible to the CPU; at which point
it is considered 'aged'.
 2) An 'aged' tail that can be used for read()ing.

The two separate pointers let us decouple read()s from tail pointer aging.

The tail pointers are checked and updated at a limited rate within a
hrtimer callback (the same callback that is used for delivering POLLIN
events) and since we're now measuring the wall clock time elapsed since
a given tail pointer was read the mechanism no longer cares about
the OA unit's periodic sampling frequency.

The natural place to handle the tail pointer updates was in
gen7_oa_buffer_is_empty() which is called as part of blocking reads and
the hrtimer callback used for polling, and so this was renamed to
oa_buffer_check() considering the added side effect while checking
whether the buffer contains data.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h  |  60 -
 drivers/gpu/drm/i915/i915_perf.c | 277 ++-
 2 files changed, 241 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 080dcb0c5bd6..22b2ea3ea66f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2000,7 +2000,7 @@ struct i915_oa_ops {
size_t *offset);
 
/**
-* @oa_buffer_is_empty: Check if OA buffer empty (false positives OK)
+* @oa_buffer_check: Check for OA buffer data + update tail
 *
 * This is either called via fops or the poll check hrtimer (atomic
 * ctx) without any locks taken.
@@ -2013,7 +2013,7 @@ struct i915_oa_ops {
 * here, which will be handled gracefully - likely resulting in an
 * %EAGAIN error for userspace.
 */
-   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
+   bool (*oa_buffer_check)(struct drm_i915_private *dev_priv);
 };
 
 struct intel_cdclk_state {
@@ -2356,9 +2356,6 @@ struct drm_i915_private {
 
bool periodic;
int period_exponent;
-   int timestamp_frequency;
-
-   int tail_margin;
 
int metrics_set;
 
@@ -2374,6 +2371,59 @@ struct drm_i915_private {
int format_size;
 
/**
+* Locks reads and writes to all head/tail state
+*
+* Consider: the head and tail pointer state
+* needs to be read consistently from a hrtimer
+* callback (atomic context) and read() fop
+* (user context) with tail pointer updates
+* happening in atomic context and head updates
+* in user context and the (unlikely)
+* possibility of read() errors needing to
+* reset all head/tail state.
+*
+* Note: Contention or performance aren't
+* currently a significant concern here
+* considering the relatively low frequency of
+* hrtimer callbacks (5ms period) and that
+* reads typically only happen in response to a
+* hrtimer event and likely complete before the
+* next callback.
+ 

[Intel-gfx] [PATCH 04/22] drm/i915/perf: no head/tail ref in gen7_oa_read

[Lionel Landwerlin]

From: Robert Bragg 

This avoids redundantly passing an (inout) head and tail pointer to
gen7_append_oa_reports() from gen7_oa_read which doesn't need to
reference either itself.

Moving the head/tail reads and writes into gen7_append_oa_reports should
have no functional effect except to avoid some redundant head pointer
writes in cases where nothing was copied to userspace.

This is a stepping stone towards updating how the head and tail pointer
state is managed to improve the workaround for the OA unit's tail
pointer race. It reduces the number of places we need to read/write the
head and tail pointers.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_perf.c | 51 +++-
 1 file changed, 19 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 838ebc03976f..26e2cc6a2d6e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -420,8 +420,6 @@ static int append_oa_sample(struct i915_perf_stream *stream,
  * @buf: destination buffer given by userspace
  * @count: the number of bytes userspace wants to read
  * @offset: (inout): the current position for writing into @buf
- * @head_ptr: (inout): the current oa buffer cpu read position
- * @tail: the current oa buffer gpu write position
  *
  * Notably any error condition resulting in a short read (-%ENOSPC or
  * -%EFAULT) will be returned even though one or more records may
@@ -439,9 +437,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
 static int gen7_append_oa_reports(struct i915_perf_stream *stream,
  char __user *buf,
  size_t count,
- size_t *offset,
- u32 *head_ptr,
- u32 tail)
+ size_t *offset)
 {
struct drm_i915_private *dev_priv = stream->dev_priv;
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
@@ -449,14 +445,15 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
int tail_margin = dev_priv->perf.oa.tail_margin;
u32 gtt_offset = i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma);
u32 mask = (OA_BUFFER_SIZE - 1);
-   u32 head;
+   size_t start_offset = *offset;
+   u32 head, oastatus1, tail;
u32 taken;
int ret = 0;
 
if (WARN_ON(!stream->enabled))
return -EIO;
 
-   head = *head_ptr - gtt_offset;
+   head = dev_priv->perf.oa.oa_buffer.head - gtt_offset;
 
/* An out of bounds or misaligned head pointer implies a driver bug
 * since we are in full control of head pointer which should only
@@ -467,7 +464,8 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
  "Inconsistent OA buffer head pointer = %u\n", head))
return -EIO;
 
-   tail -= gtt_offset;
+   oastatus1 = I915_READ(GEN7_OASTATUS1);
+   tail = (oastatus1 & GEN7_OASTATUS1_TAIL_MASK) - gtt_offset;
 
/* The OA unit is expected to wrap the tail pointer according to the OA
 * buffer size
@@ -477,8 +475,6 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
  tail);
dev_priv->perf.oa.ops.oa_disable(dev_priv);
dev_priv->perf.oa.ops.oa_enable(dev_priv);
-   *head_ptr = I915_READ(GEN7_OASTATUS2) &
-   GEN7_OASTATUS2_HEAD_MASK;
return -EIO;
}
 
@@ -542,7 +538,18 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
report32[0] = 0;
}
 
-   *head_ptr = gtt_offset + head;
+
+   if (start_offset != *offset) {
+   /* We removed the gtt_offset for the copy loop above, indexing
+* relative to oa_buf_base so put back here...
+*/
+   head += gtt_offset;
+
+   I915_WRITE(GEN7_OASTATUS2,
+  ((head & GEN7_OASTATUS2_HEAD_MASK) |
+   OA_MEM_SELECT_GGTT));
+   dev_priv->perf.oa.oa_buffer.head = head;
+   }
 
return ret;
 }
@@ -570,8 +577,6 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
 {
struct drm_i915_private *dev_priv = stream->dev_priv;
u32 oastatus1;
-   u32 head;
-   u32 tail;
int ret;
 
if (WARN_ON(!dev_priv->perf.oa.oa_buffer.vaddr))
@@ -579,9 +584,6 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
 
oastatus1 = I915_READ(GEN7_OASTATUS1);
 
-   head = dev_priv->perf.oa.oa_buffer.head;
-   tail = oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
-
/* XXX: On Haswell we don't have a safe way to clear oastatus1
 * bits while the OA unit is enabled 

[Intel-gfx] [PATCH 11/22] drm/i915: Record the sseu configuration per-context

[Lionel Landwerlin]

From: Chris Wilson 

In the next patch, we will expose the ability to reconfigure the slices,
subslice and eu per context. To facilitate that, store the current
configuration on the context, which is initially set to the device
default upon creation.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h | 19 ---
 drivers/gpu/drm/i915/i915_gem_context.c |  3 +++
 drivers/gpu/drm/i915/i915_gem_context.h | 22 ++
 drivers/gpu/drm/i915/intel_lrc.c| 23 +--
 4 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 88bf0e25113a..a4c47975d149 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -731,25 +731,6 @@ struct intel_csr {
func(overlay_needs_physical); \
func(supports_tv);
 
-struct sseu_dev_info {
-   u8 slice_mask;
-   u8 subslice_mask;
-   u8 eu_total;
-   u8 min_eu_per_subslice;
-   u8 max_eu_per_subslice;
-   u8 min_eu_in_pool;
-   /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
-   u8 subslice_7eu[3];
-   u8 has_slice_pg:1;
-   u8 has_subslice_pg:1;
-   u8 has_eu_pg:1;
-};
-
-static inline unsigned int sseu_subslice_total(const struct sseu_dev_info 
*sseu)
-{
-   return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
-}
-
 /* Keep in gen based order, and chronological order within a gen */
 enum intel_platform {
INTEL_PLATFORM_UNINITIALIZED = 0,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 31a73c39239f..7b769737383f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -228,6 +228,9 @@ __create_hw_context(struct drm_i915_private *dev_priv,
 * is no remap info, it will be a NOP. */
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
 
+   /* Use the whole device by default */
+   ctx->sseu = INTEL_INFO(dev_priv)->sseu;
+
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 4af2ab94558b..c45d86644b3d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -39,6 +39,25 @@ struct i915_hw_ppgtt;
 struct i915_vma;
 struct intel_ring;
 
+struct sseu_dev_info {
+   u8 slice_mask;
+   u8 subslice_mask;
+   u8 eu_total;
+   u8 min_eu_per_subslice;
+   u8 max_eu_per_subslice;
+   u8 min_eu_in_pool;
+   /* For each slice, which subslice(s) has(have) 7 EUs (bitfield)? */
+   u8 subslice_7eu[3];
+   u8 has_slice_pg:1;
+   u8 has_subslice_pg:1;
+   u8 has_eu_pg:1;
+};
+
+static inline unsigned int sseu_subslice_total(const struct sseu_dev_info 
*sseu)
+{
+   return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
+}
+
 #define DEFAULT_CONTEXT_HANDLE 0
 
 /**
@@ -173,6 +192,9 @@ struct i915_gem_context {
 
/** remap_slice: Bitmask of cache lines that need remapping */
u8 remap_slice;
+
+   /** sseu: Control eu/slice partitioning */
+   struct sseu_dev_info sseu;
 };
 
 static inline bool i915_gem_context_is_closed(const struct i915_gem_context 
*ctx)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 836337836773..b1f586eeced9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1729,8 +1729,7 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
return logical_ring_init(engine);
 }
 
-static u32
-make_rpcs(struct drm_i915_private *dev_priv)
+static u32 make_rpcs(const struct sseu_dev_info *sseu)
 {
u32 rpcs = 0;
 
@@ -1740,25 +1739,21 @@ make_rpcs(struct drm_i915_private *dev_priv)
 * must make an explicit request through RPCS for full
 * enablement.
*/
-   if (INTEL_INFO(dev_priv)->sseu.has_slice_pg) {
+   if (sseu->has_slice_pg) {
rpcs |= GEN8_RPCS_S_CNT_ENABLE;
-   rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask) <<
-   GEN8_RPCS_S_CNT_SHIFT;
+   rpcs |= hweight8(sseu->slice_mask) << GEN8_RPCS_S_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
 
-   if (INTEL_INFO(dev_priv)->sseu.has_subslice_pg) {
+   if (sseu->has_subslice_pg) {
rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
-   rpcs |= hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask) <<
-   GEN8_RPCS_SS_CNT_SHIFT;
+   rpcs |= hweight8(sseu->subslice_mask) << GEN8_RPCS_SS_CNT_SHIFT;
rpcs |= GEN8_RPCS_ENABLE;
}
 
-   if (INTEL_INFO(dev_priv)->sseu.has_eu_pg) {
-   rpcs |= 

[Intel-gfx] [PATCH 02/22] drm/i915/perf: avoid poll, read, EAGAIN busy loops

[Lionel Landwerlin]

From: Robert Bragg 

If the function for checking whether there is OA buffer data available
(during a poll or blocking read) has false positives then we want to
avoid a situation where the subsequent read() returns EAGAIN (after
a more accurate check) followed by a poll() immediately reporting
the same false positive POLLIN event and effectively maintaining a
busy loop until there really is data.

This makes sure that we clear the .pollin event status whenever we
return EAGAIN to userspace which will throttle subsequent POLLIN events
and repeated attempts to read to the 5ms intervals of the hrtimer
callback we have.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_perf.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 6227e487eecd..e1158893c6cb 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1351,7 +1351,15 @@ static ssize_t i915_perf_read(struct file *file,
mutex_unlock(_priv->perf.lock);
}
 
-   if (ret >= 0) {
+   /* We allow the poll checking to sometimes report false positive POLLIN
+* events where we might actually report EAGAIN on read() if there's
+* not really any data available. In this situation though we don't
+* want to enter a busy loop between poll() reporting a POLLIN event
+* and read() returning -EAGAIN. Clearing the oa.pollin state here
+* effectively ensures we back off until the next hrtimer callback
+* before reporting another POLLIN event.
+*/
+   if (ret >= 0 || ret == -EAGAIN) {
/* Maybe make ->pollin per-stream state if we support multiple
 * concurrent streams in the future.
 */
-- 
2.11.0

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

[Intel-gfx] [PATCH 09/22] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

[Lionel Landwerlin]

From: Chris Wilson 

When we query the available eu on each subslice, we currently only
report the max. It would also be useful to report the minimum found as
well.

When we set RPCS (power gating over the EU), we can also specify both
the min and max number of eu to configure on each slice; currently we
just set it to a single value, but the flexibility may be beneficial in
future.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 36 +++-
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/intel_device_info.c | 32 +---
 drivers/gpu/drm/i915/intel_lrc.c |  4 ++--
 4 files changed, 50 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef40c66..a52be296930f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4509,6 +4509,7 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_cache_sharing_fops,
 static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv,
  struct sseu_dev_info *sseu)
 {
+   unsigned int min_eu_per_subslice, max_eu_per_subslice;
int ss_max = 2;
int ss;
u32 sig1[ss_max], sig2[ss_max];
@@ -4518,6 +4519,9 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
sig2[0] = I915_READ(CHV_POWER_SS0_SIG2);
sig2[1] = I915_READ(CHV_POWER_SS1_SIG2);
 
+   min_eu_per_subslice = ~0u;
+   max_eu_per_subslice = 0;
+
for (ss = 0; ss < ss_max; ss++) {
unsigned int eu_cnt;
 
@@ -4532,14 +4536,18 @@ static void cherryview_sseu_device_status(struct 
drm_i915_private *dev_priv,
 ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
 ((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
sseu->eu_total += eu_cnt;
-   sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice, eu_cnt);
+   min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+   max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
+
+   sseu->min_eu_per_subslice = min_eu_per_subslice;
+   sseu->max_eu_per_subslice = max_eu_per_subslice;
 }
 
 static void gen9_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
 {
+   unsigned int min_eu_per_subslice, max_eu_per_subslice;
int s_max = 3, ss_max = 4;
int s, ss;
u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2];
@@ -4565,6 +4573,9 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
 GEN9_PGCTL_SSB_EU210_ACK |
 GEN9_PGCTL_SSB_EU311_ACK;
 
+   min_eu_per_subslice = ~0u;
+   max_eu_per_subslice = 0;
+
for (s = 0; s < s_max; s++) {
if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
/* skip disabled slice */
@@ -4590,11 +4601,14 @@ static void gen9_sseu_device_status(struct 
drm_i915_private *dev_priv,
eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] &
   eu_mask[ss%2]);
sseu->eu_total += eu_cnt;
-   sseu->eu_per_subslice = max_t(unsigned int,
- sseu->eu_per_subslice,
- eu_cnt);
+
+   min_eu_per_subslice = min(min_eu_per_subslice, eu_cnt);
+   max_eu_per_subslice = max(max_eu_per_subslice, eu_cnt);
}
}
+
+   sseu->min_eu_per_subslice = min_eu_per_subslice;
+   sseu->max_eu_per_subslice = max_eu_per_subslice;
 }
 
 static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv,
@@ -4607,9 +4621,11 @@ static void broadwell_sseu_device_status(struct 
drm_i915_private *dev_priv,
 
if (sseu->slice_mask) {
sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask;
-   sseu->eu_per_subslice =
-   INTEL_INFO(dev_priv)->sseu.eu_per_subslice;
-   sseu->eu_total = sseu->eu_per_subslice *
+   sseu->min_eu_per_subslice =
+   INTEL_INFO(dev_priv)->sseu.min_eu_per_subslice;
+   sseu->max_eu_per_subslice =
+   INTEL_INFO(dev_priv)->sseu.max_eu_per_subslice;
+   sseu->eu_total = sseu->max_eu_per_subslice *
 sseu_subslice_total(sseu);
 
/* subtract fused off EU(s) from enabled slice(s) */
@@ -4640,8 +4656,8 @@ static void i915_print_sseu_info(struct seq_file *m, bool 
is_available_info,
   

[Intel-gfx] [PATCH 10/22] drm/i915: Program RPCS for Broadwell

[Lionel Landwerlin]

From: Chris Wilson 

Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may want to
opt out of the "always-enabled" setting.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2d6ef736bc0d..836337836773 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1735,13 +1735,6 @@ make_rpcs(struct drm_i915_private *dev_priv)
u32 rpcs = 0;
 
/*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
-   */
-   if (INTEL_GEN(dev_priv) < 9)
-   return 0;
-
-   /*
 * Starting in Gen9, render power gating can leave
 * slice/subslice/EU in a partially enabled state. We
 * must make an explicit request through RPCS for full
-- 
2.11.0

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

[Intel-gfx] [PATCH 01/22] drm/i915/perf: fix gen7_append_oa_reports comment

[Lionel Landwerlin]

From: Robert Bragg 

If I'm going to complain about a back-to-front convention then the least
I can do is not muddle the comment up too.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index cdac68580cb1..6227e487eecd 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -431,7 +431,7 @@ static int append_oa_sample(struct i915_perf_stream *stream,
  * userspace.
  *
  * Note: reports are consumed from the head, and appended to the
- * tail, so the head chases the tail?... If you think that's mad
+ * tail, so the tail chases the head?... If you think that's mad
  * and back-to-front you're not alone, but this follows the
  * Gen PRM naming convention.
  *
-- 
2.11.0

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

[Intel-gfx] [PATCH v12 00/22] Enable OA unit for Gen 8 and 9 in i915 perf

[Lionel Landwerlin]

Hi all,

Here are the changes from the previous series :

 * Included patches 9, 10 & 11 from Chris to have sseu configuration
   stored per context (but not exposed to userspace)

 * In patches 12 & 13 querying the slice/subslice configuration now
   returns the configuration locked in by the OA unit or if the OA
   unit is not in use, the maximum capabilities of the system.

 * Patch 14 reworks how we query sets of registers to program for a
   given generation & metrics set. We weren't dealing with multiple
   slices turned on properly.

 * In patch 16, the update of context saved registers for programming
   the OA unit has been reworked to make sure we hand back to
   userspace a system where all the context have been properly
   udpated.
   We also take care to lock the sseu configuration using either the
   monitored context or the maximum of the system capabilities (if
   we're doing system wide monitoring).

 * Patches 20, 21 & 22 add support for Kabylake & Geminilake
   generations (still Gen9 based).

Cheers,

Chris Wilson (3):
  drm/i915: Record both min/max eu_per_subslice in sseu_dev_info
  drm/i915: Program RPCS for Broadwell
  drm/i915: Record the sseu configuration per-context

Lionel Landwerlin (4):
  drm/i915/perf: rework mux configurations queries
  drm/i915: add KBL GT2/GT3 check macros
  drm/i915/perf: add KBL support
  drm/i915/perf: add GLK support

Robert Bragg (15):
  drm/i915/perf: fix gen7_append_oa_reports comment
  drm/i915/perf: avoid poll, read, EAGAIN busy loops
  drm/i915/perf: avoid read back of head register
  drm/i915/perf: no head/tail ref in gen7_oa_read
  drm/i915/perf: improve tail race workaround
  drm/i915/perf: improve invalid OA format debug message
  drm/i915/perf: better pipeline aged/aging tail updates
  drm/i915/perf: rate limit spurious oa report notice
  drm/i915: expose _SLICE_MASK GETPARM
  drm/i915: expose _SUBSLICE_MASK GETPARM
  drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
  drm/i915/perf: Add OA unit support for Gen 8+
  drm/i915/perf: Add more OA configs for BDW, CHV, SKL + BXT
  drm/i915/perf: per-gen timebase for checking sample freq
  drm/i915/perf: remove perf.hook_lock

 drivers/gpu/drm/i915/Makefile|   11 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |   36 +-
 drivers/gpu/drm/i915/i915_drv.c  |   24 +
 drivers/gpu/drm/i915/i915_drv.h  |  176 +-
 drivers/gpu/drm/i915/i915_gem_context.c  |3 +
 drivers/gpu/drm/i915/i915_gem_context.h  |   22 +
 drivers/gpu/drm/i915/i915_oa_bdw.c   | 5374 ++
 drivers/gpu/drm/i915/i915_oa_bdw.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_bxt.c   | 2688 +++
 drivers/gpu/drm/i915/i915_oa_bxt.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_chv.c   | 2871 
 drivers/gpu/drm/i915/i915_oa_chv.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_glk.c   | 2600 +++
 drivers/gpu/drm/i915/i915_oa_glk.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_hsw.c   |  259 +-
 drivers/gpu/drm/i915/i915_oa_kblgt2.c| 2989 +
 drivers/gpu/drm/i915/i915_oa_kblgt2.h|   38 +
 drivers/gpu/drm/i915/i915_oa_kblgt3.c| 3038 +
 drivers/gpu/drm/i915/i915_oa_kblgt3.h|   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt2.c| 3477 +++
 drivers/gpu/drm/i915/i915_oa_sklgt2.h|   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.c| 3037 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.h|   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt4.c| 3091 +
 drivers/gpu/drm/i915/i915_oa_sklgt4.h|   38 +
 drivers/gpu/drm/i915/i915_perf.c | 1459 ++--
 drivers/gpu/drm/i915/i915_reg.h  |   22 +
 drivers/gpu/drm/i915/intel_device_info.c |   32 +-
 drivers/gpu/drm/i915/intel_lrc.c |   38 +-
 drivers/gpu/drm/i915/intel_lrc.h |5 +
 include/uapi/drm/i915_drm.h  |   27 +-
 31 files changed, 31249 insertions(+), 372 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_glk.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt2.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt2.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_kblgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
 create mode 100644 

[Intel-gfx] [PATCH 07/22] drm/i915/perf: better pipeline aged/aging tail updates

[Lionel Landwerlin]

From: Robert Bragg 

This updates the tail pointer race workaround handling to updating the
'aged' pointer before looking to start aging a new one. There's the
possibility that there is already new data available and so we can
immediately start aging a new pointer without having to first wait for a
later hrtimer callback (and then another to age).

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_perf.c | 41 ++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 99c9c51c6617..dbed19a5a1b2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -391,6 +391,29 @@ static bool gen7_oa_buffer_check_unlocked(struct 
drm_i915_private *dev_priv)
 
now = ktime_get_mono_fast_ns();
 
+   /* Update the aged tail
+*
+* Flip the tail pointer available for read()s once the aging tail is
+* old enough to trust that the corresponding data will be visible to
+* the CPU...
+*
+* Do this before updating the aging pointer in case we may be able to
+* immediately start aging a new pointer too (if new data has become
+* available) without needing to wait for a later hrtimer callback.
+*/
+   if (aging_tail != INVALID_TAIL_PTR &&
+   ((now - dev_priv->perf.oa.oa_buffer.aging_timestamp) >
+OA_TAIL_MARGIN_NSEC)) {
+   aged_idx ^= 1;
+   dev_priv->perf.oa.oa_buffer.aged_tail_idx = aged_idx;
+
+   aged_tail = aging_tail;
+
+   /* Mark that we need a new pointer to start aging... */
+   dev_priv->perf.oa.oa_buffer.tails[!aged_idx].offset = 
INVALID_TAIL_PTR;
+   aging_tail = INVALID_TAIL_PTR;
+   }
+
/* Update the aging tail
 *
 * We throttle aging tail updates until we have a new tail that
@@ -420,24 +443,6 @@ static bool gen7_oa_buffer_check_unlocked(struct 
drm_i915_private *dev_priv)
}
}
 
-   /* Update the aged tail
-*
-* Flip the tail pointer available for read()s once the aging tail is
-* old enough to trust that the corresponding data will be visible to
-* the CPU...
-*/
-   if (aging_tail != INVALID_TAIL_PTR &&
-   ((now - dev_priv->perf.oa.oa_buffer.aging_timestamp) >
-OA_TAIL_MARGIN_NSEC)) {
-   aged_idx ^= 1;
-   dev_priv->perf.oa.oa_buffer.aged_tail_idx = aged_idx;
-
-   aged_tail = aging_tail;
-
-   /* Mark that we need a new pointer to start aging... */
-   dev_priv->perf.oa.oa_buffer.tails[!aged_idx].offset = 
INVALID_TAIL_PTR;
-   }
-
spin_unlock_irqrestore(_priv->perf.oa.oa_buffer.ptr_lock, flags);
 
return aged_tail == INVALID_TAIL_PTR ?
-- 
2.11.0

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

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Alex Williamson]

On Thu, 11 May 2017 15:27:53 +0200
Gerd Hoffmann  wrote:

>   Hi,
> 
> > While read the framebuffer region we have to tell the vendor driver which 
> > framebuffer we want to read? There are two framebuffers now in KVMGT that 
> > is primary and cursor.
> > There are two methods to implement this:
> > 1) write the plane id first and then read the framebuffer.
> > 2) create 2 vfio regions one for primary and one for cursor.  
> 
> (3) Place information for both planes into one vfio region.
> Which allows to fetch both with a single read() syscall.
> 
> The question is how you'll get the file descriptor then.  If the ioctl
> returns the dma-buf fd only you have a racy interface:  Things can
> change between read(vfio-region) and ioctl(need-dmabuf-fd).
> 
> ioctl(need-dma-buf) could return both dmabuf fd and plane info to fix
> the race, but then it is easier to go with ioctl only interface (simliar
> to the orginal one from dec last year) I think.

If the dmabuf fd is provided by a separate mdev vendor driver specific
ioctl, I don't see how vfio regions should be involved.  Selecting
which framebuffer should be an ioctl parameter.  What sort of
information needs to be conveyed about each plane?  Is it static
information or something that needs to be read repeatedly?  Do we need
it before we get the dmabuf fd or can it be an ioctl on the dmabuf fd?
Thanks,

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Dump the GuC stage descriptor pool in debugfs (rev2)

[Joonas Lahtinen]

On ke, 2017-05-10 at 22:24 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/guc: Dump the GuC stage descriptor pool in debugfs (rev2)
> URL   : https://patchwork.freedesktop.org/series/24051/
> State : success

Fixed the checkpatch.pl complaints and merged the patch, thanks for the
patch!

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

Re: [Intel-gfx] [PATCH] drm/i915: Detect USB-C specific dongles before reducing M and N

[Jani Nikula]

On Wed, 10 May 2017, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
>
> The Analogix 7737 DP to HDMI converter requires reduced N and M values when
> to operate correctly at HBR2. Detect this IC by its OUI value of 0x0022B9.

I'm not happy, but I also see no alternative than to go this
route. Thanks for the patch. I do think we need to start a common drm
quirk database for this stuff though. Added one, and rebased this one on
top:

https://patchwork.freedesktop.org/series/24282/

Please give it a go; I don't have a DA200.


BR,
Jani.

>
> Cc: Jani Nikula 
> Cc: Dhinakaran Pandiyan 
>
> Signed-off-by: Clint Taylor 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
>  drivers/gpu/drm/i915/intel_display.c | 22 ++
>  drivers/gpu/drm/i915/intel_dp.c  | 22 --
>  drivers/gpu/drm/i915/intel_dp_mst.c  |  3 ++-
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  5 files changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 74dffbe..492e47e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -563,7 +563,8 @@ struct intel_link_m_n {
>  
>  void intel_link_compute_m_n(int bpp, int nlanes,
>   int pixel_clock, int link_clock,
> - struct intel_link_m_n *m_n);
> + struct intel_link_m_n *m_n,
> + bool reduce_m_n);
>  
>  /* Interface history:
>   *
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7bcc604..8920a99 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6104,7 +6104,7 @@ static int ironlake_fdi_compute_config(struct 
> intel_crtc *intel_crtc,
>   pipe_config->fdi_lanes = lane;
>  
>   intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> -link_bw, _config->fdi_m_n);
> +link_bw, _config->fdi_m_n, false);
>  
>   ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
>   if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
> @@ -6280,7 +6280,8 @@ static int intel_crtc_compute_config(struct intel_crtc 
> *crtc,
>  }
>  
>  static void compute_m_n(unsigned int m, unsigned int n,
> - uint32_t *ret_m, uint32_t *ret_n)
> + uint32_t *ret_m, uint32_t *ret_n,
> +bool reduce_m_n)
>  {
>   /*
>* Reduce M/N as much as possible without loss in precision. Several DP
> @@ -6288,9 +6289,11 @@ static void compute_m_n(unsigned int m, unsigned int n,
>* values. The passed in values are more likely to have the least
>* significant bits zero than M after rounding below, so do this first.
>*/
> - while ((m & 1) == 0 && (n & 1) == 0) {
> - m >>= 1;
> - n >>= 1;
> + if (reduce_m_n) {
> + while ((m & 1) == 0 && (n & 1) == 0) {
> + m >>= 1;
> + n >>= 1;
> + }
>   }
>  
>   *ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
> @@ -6301,16 +6304,19 @@ static void compute_m_n(unsigned int m, unsigned int 
> n,
>  void
>  intel_link_compute_m_n(int bits_per_pixel, int nlanes,
>  int pixel_clock, int link_clock,
> -struct intel_link_m_n *m_n)
> +struct intel_link_m_n *m_n,
> +   bool reduce_m_n)
>  {
>   m_n->tu = 64;
>  
>   compute_m_n(bits_per_pixel * pixel_clock,
>   link_clock * nlanes * 8,
> - _n->gmch_m, _n->gmch_n);
> + _n->gmch_m, _n->gmch_n,
> + reduce_m_n);
>  
>   compute_m_n(pixel_clock, link_clock,
> - _n->link_m, _n->link_n);
> + _n->link_m, _n->link_n,
> + reduce_m_n);
>  }
>  
>  static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4a6feb6..f4c0582 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1548,6 +1548,20 @@ static void intel_dp_print_rates(struct intel_dp 
> *intel_dp)
>   DRM_DEBUG_KMS("common rates: %s\n", str);
>  }
>  
> +bool __intel_reduced_m_n(struct intel_dp *intel_dp)
> +{
> + struct intel_dp_desc *desc = _dp->desc;
> + bool ret = false;
> +
> + /* Analogix 7737 needs reduced N and M at HBR2 link rates */
> + if (desc->oui[0] == 0x00 &&
> + desc->oui[1] == 0x22 &&
> + desc->oui[2] == 0xb9)
> + ret = true;
> +
> + return ret;
> +}
> +
>  bool
>  __intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: set initialised only when init_context callback is NULL

[Patchwork]

== Series Details ==

Series: drm/i915: set initialised only when init_context callback is NULL
URL   : https://patchwork.freedesktop.org/series/24286/
State : success

== Summary ==

Series 24286v1 drm/i915: set initialised only when init_context callback is NULL
https://patchwork.freedesktop.org/api/1.0/series/24286/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:435s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:582s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:506s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:559s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:491s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:418s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:503s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:576s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:576s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:475s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:498s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:443s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:411s

81dbd44ab4c1331c61a971b05681473a869b3039 drm-tip: 2017y-05m-11d-09h-55m-44s UTC 
integration manifest
5a738b5 drm/i915: set initialised only when init_context callback is NULL

== Logs ==

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

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

[Joonas Lahtinen]

On to, 2017-05-11 at 06:51 +, Li, Weinan Z wrote:
> > 
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Wednesday, May 10, 2017 6:43 PM
> > To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; 
> > intel-
> > gvt-...@lists.freedesktop.org
> > Cc: Chris Wilson 
> > Subject: Re: [PATCH v4] drm/i915/gvt: return the correct usable aperture 
> > size
> > under gvt environment
> > 
> > On ke, 2017-05-10 at 10:59 +0800, Weinan Li wrote:
> > > 
> > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> > userspace.
> > > 
> > > In gvt environment, each vm only use the ballooned part of aperture,
> > > so we should return the correct available aperture size exclude the
> > > reserved part by balloon.
> > > 
> > > v2: add 'reserved' in struct i915_address_space to record the reserved
> > > size in ggtt.
> > > 
> > > v3: remain aper_size as total, adjust aper_available_size exclude
> > > reserved and pinned. UMD driver need to adjust the max allocation size
> > > according to the available aperture size but not total size. KMD
> > > return the correct usable aperture size any time.
> > > 
> > > v4: add onion teardown to balloon and deballoon to make sure the
> > > reserved stays correct. Code style refine.
> > 
> > There's no onion teardown seen yet, please read:
> > 
> > https://www.kernel.org/doc/html/v4.10/process/coding-style.html#central
> > ized-exiting-of-functions
> > 
> > Please incorporate the addition to vgt_balloon_space function to reduce code
> > duplication.
> > 
> > Once the proper teardown is implemented, intel_vgt_deballoon function should
> > unconditionally remove the drm_mm nodes as there's no condition when only
> > one of them would be allocated. And intel_vgt_balloon definitely should not 
> > call
> > intel_vgt_deballoon in error path as per the coding style above.
> 
> Thanks Joonas. A little change is brought in if move the fail checking into 
> balloon_space()
> There are 4 balloon spaces, current policy is if any one fail clean up all 
> the success ones, with
> this change it won't clean up the success ones. It should not impact the 
> driver's behavior.

Please re-read the "Centralized exiting of function", in this case
you'd have three labels for onion teardown if any of the space
reservations fails, you jump to the right one. Please take a look in
the i915 to similar initialization functions for examples.

> @@ -127,9 +130,14 @@ static int vgt_balloon_space(struct i915_ggtt *ggtt,
> 
> DRM_INFO("balloon space: range [ 0x%lx - 0x%lx ] %lu KiB.\n",
>  start, end, size / 1024);
> -   return i915_gem_gtt_reserve(>base, node,
> +   ret = i915_gem_gtt_reserve(>base, node,
> size, start, I915_COLOR_UNEVICTABLE,
> 0);
> +   if (!ret)
> +   ggtt->base.reserved += size;
> +   else
> +   memset(node, 0, sizeof(*node));

This should not be needed. Either all of the nodes have been
successfully initialize or not. The only partial states are in the
intel_vgt_balloon function, which should use different labels to back
off from different stages of initialization.

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

[Intel-gfx] [PATCH v4 11/11] drm/i915/skl+: consider max supported plane pixel rate while scaling

[Mahesh Kumar]

A display resolution is only supported if it meets all the restrictions
below for Maximum Pipe Pixel Rate.

The display resolution must fit within the maximum pixel rate output
from the pipe. Make sure that the display pipe is able to feed pixels at
a rate required to support the desired resolution.
For each enabled plane on the pipe {
If plane scaling enabled {
Horizontal down scale amount = Maximum[1, plane horizontal size /
scaler horizontal window size]
Vertical down scale amount = Maximum[1, plane vertical size /
scaler vertical window size]
Plane down scale amount = Horizontal down scale amount *
Vertical down scale amount
Plane Ratio = 1 / Plane down scale amount
}
Else {
Plane Ratio = 1
}
If plane source pixel format is 64 bits per pixel {
Plane Ratio = Plane Ratio * 8/9
}
}

Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe

If pipe scaling is enabled {
Horizontal down scale amount = Maximum[1, pipe horizontal source size /
scaler horizontal window size]
Vertical down scale amount = Maximum[1, pipe vertical source size /
scaler vertical window size]
Note: The progressive fetch - interlace display mode is equivalent to a
2.0 vertical down scale
Pipe down scale amount = Horizontal down scale amount *
Vertical down scale amount
Pipe Ratio = Pipe Ratio / Pipe down scale amount
}

Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio

Changes since V1:
 - separate out fixed_16_16 wrapper API definition
Changes since V2:
 - Fix buggy crtc !active condition (Maarten)
 - use intel_wm_plane_visible wrapper as per Maarten's suggestion
Changes since V3:
 - Change failure return from ERANGE to EINVAL

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c |  3 ++
 drivers/gpu/drm/i915/intel_drv.h |  2 +
 drivers/gpu/drm/i915/intel_pm.c  | 88 
 3 files changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..d64367e810f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10992,6 +10992,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
ret = skl_update_scaler_crtc(pipe_config);
 
if (!ret)
+   ret = skl_check_pipe_max_pixel_rate(intel_crtc,
+   pipe_config);
+   if (!ret)
ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
 pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54f3ff840812..8323fc2ec4f2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1859,6 +1859,8 @@ bool skl_ddb_allocation_overlaps(const struct 
skl_ddb_entry **entries,
 int ignore);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *cstate);
 static inline int intel_enable_rc6(void)
 {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 041cbca7105e..4f94dd6be8ed 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3397,6 +3397,94 @@ skl_plane_downscale_amount(const struct intel_crtc_state 
*cstate,
return mul_fixed_16_16(downscale_w, downscale_h);
 }
 
+static uint_fixed_16_16_t
+skl_pipe_downscale_amount(const struct intel_crtc_state *config)
+{
+   uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
+
+   if (!config->base.active)
+   return pipe_downscale;
+
+   if (config->pch_pfit.enabled) {
+   uint32_t src_w, src_h, dst_w, dst_h;
+   uint32_t pfit_size = config->pch_pfit.size;
+   uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
+   uint_fixed_16_16_t downscale_h, downscale_w;
+
+   src_w = config->pipe_src_w;
+   src_h = config->pipe_src_h;
+   dst_w = pfit_size >> 16;
+   dst_h = pfit_size & 0x;
+
+   if (!dst_w || !dst_h)
+   return pipe_downscale;
+
+   fp_w_ratio = fixed_16_16_div(src_w, dst_w);
+   fp_h_ratio = fixed_16_16_div(src_h, dst_h);
+   downscale_w = max_fixed_16_16(fp_w_ratio, 
u32_to_fixed_16_16(1));
+   downscale_h = max_fixed_16_16(fp_h_ratio, 
u32_to_fixed_16_16(1));
+
+   pipe_downscale = 

Re: [Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data

[Tvrtko Ursulin]

On 11/05/2017 14:07, Chris Wilson wrote:

On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

For userspace receiving binary data it is easier if all related
request tracepoints emit the binary data in the same order of
dev, ring, ctx, seqno, ...


We decided that dev, ctx, ring, seqno was the right heirachy last time.
After much debate :)
ctx is the logical view of the device for a user
ctx + ring = timeline


I couldn't remember so I thought it must have been what is documented in 
TP_printk. Now I am confused. On one hand it's true, but on the other 
ctx/seqno is also a pair as opposed to engine being stuck in the middle. 
So ring-ctx-seqno is easier for humans I think. Even since per 
ctx/engine seqno space.


Oh and I said I'll rename all those ring= to engine=..

Regards,

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

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Dong, Chuanxiao]

> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Thursday, May 11, 2017 8:50 PM
> To: Dong, Chuanxiao ; intel-gvt-
> d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC
> submission is enabled
> 
> On to, 2017-05-11 at 02:33 +, Dong, Chuanxiao wrote:
> >
> > >
> > > -Original Message-
> > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > > Sent: Wednesday, May 10, 2017 8:48 PM
> > > To: Dong, Chuanxiao ; intel-gvt-
> > > d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if
> > > host GuC submission is enabled
> > >
> > > On ti, 2017-05-09 at 18:11 +0800, Chuanxiao Dong wrote:
> > > >
> > > > Currently GVT-g cannot work properly when host GuC submission is
> > > > enabled, so disable GVT in this case.
> > > >
> > > > v2: update the user message (Joonas)
> > > >
> > > > > > > Cc: Zhenyu Wang 
> > > > > > > Signed-off-by: Chuanxiao Dong 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_gvt.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> > > > b/drivers/gpu/drm/i915/intel_gvt.c
> > > > index e1ab643..d85742c 100644
> > > > --- a/drivers/gpu/drm/i915/intel_gvt.c
> > > > +++ b/drivers/gpu/drm/i915/intel_gvt.c
> > > > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private
> *dev_priv)
> > > >     goto bail;
> > > >     }
> > > >
> > > > +   if (i915.enable_guc_submission) {
> > > > +   DRM_INFO("GPU guest virtualisation [GVT-g] disabled as
> > > Graphics virtualization is not yet supported with GuC submission
> > > [i915.enable_guc_submission module parameter]\n");
> > > >
> > > > +   goto bail;
> > > > +   }
> > >
> > > As discussed earlier, driver loading should fail with -EIO when
> > > incompatible options are specified.
> >
> > Sorry for not getting why should fail with -EIO? By looking into the
> > source, Intel_gvt_init is part of i915 driver loading, and fail with
> > -EIO will make i915 driver failed to load.
> 
> Yes, the user has specified an unsafe kernel configuration option,
> enable_guc_submission and the driver can rightfully stop loading if
> enable_gvt option was passed in the same command line.
> 
Thanks Joonas. If to fail with -EIO, how about for the other two checks: " if 
(!is_supported_device(dev_priv))" and " if (!i915.enable_execlists)"?  
Currently these two cases are failed with 0 instead of -EIO. Looks like should 
also fail with -EIO?

For the gvt init failure case, it is also failed with 0 right now, which means 
that even gvt init is failed, i915 loading will be continue instead of failed 
due to gvt. Right now we also want to fail with -EIO, right?

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Implement DDB algorithm and WM cleanup (rev6)

[Patchwork]

== Series Details ==

Series: Implement DDB algorithm and WM cleanup (rev6)
URL   : https://patchwork.freedesktop.org/series/20376/
State : success

== Summary ==

Series 20376v6 Implement DDB algorithm and WM cleanup
https://patchwork.freedesktop.org/api/1.0/series/20376/revisions/6/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:440s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:434s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:587s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:515s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:484s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:573s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:453s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:575s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:475s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:501s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:416s
fi-bxt-t5700 failed to collect. IGT log at Patchwork_4675/fi-bxt-t5700/igt.log

51350ea90d1a5c8bb7e6532eb61c64a57e83ab9b drm-tip: 2017y-05m-11d-13h-05m-06s UTC 
integration manifest
97bac45 drm/i915/skl+: consider max supported plane pixel rate while scaling
ce02568 drm/i915/skl: New ddb allocation algorithm
1ab634e drm/i915/skl+: use linetime latency if ddb size is not available
d2a7155 drm/i915/skl+: Watermark calculation cleanup
a603680 drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe 
allocation
42ba052 drm/i915/skl+: no need to memset again
1157f1d drm/i915/skl: Fail the flip if no FB for WM calculation
877435c drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed point
002cc23 drm/i915: Use fixed_16_16 wrapper for division operation
71b458f drm/i915: Add more wrapper for fixed_point_16_16 operations
d7c17ff drm/i915: fix naming of fixed_16_16 wrapper.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4675/
___
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: Consistent ordering of tracepoint binary data

[Patchwork]

== Series Details ==

Series: drm/i915: Consistent ordering of tracepoint binary data
URL   : https://patchwork.freedesktop.org/series/24293/
State : success

== Summary ==

Series 24293v1 drm/i915: Consistent ordering of tracepoint binary data
https://patchwork.freedesktop.org/api/1.0/series/24293/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:445s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:437s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:518s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:565s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:484s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:484s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:579s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:461s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:577s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:471s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:496s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:439s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:420s

81dbd44ab4c1331c61a971b05681473a869b3039 drm-tip: 2017y-05m-11d-09h-55m-44s UTC 
integration manifest
9fd2f9d drm/i915: Consistent ordering of tracepoint binary data

== Logs ==

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

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

[Gerd Hoffmann]

  Hi,

> While read the framebuffer region we have to tell the vendor driver which 
> framebuffer we want to read? There are two framebuffers now in KVMGT that is 
> primary and cursor.
> There are two methods to implement this:
> 1) write the plane id first and then read the framebuffer.
> 2) create 2 vfio regions one for primary and one for cursor.

(3) Place information for both planes into one vfio region.
Which allows to fetch both with a single read() syscall.

The question is how you'll get the file descriptor then.  If the ioctl
returns the dma-buf fd only you have a racy interface:  Things can
change between read(vfio-region) and ioctl(need-dmabuf-fd).

ioctl(need-dma-buf) could return both dmabuf fd and plane info to fix
the race, but then it is easier to go with ioctl only interface (simliar
to the orginal one from dec last year) I think.

cheers,
  Gerd

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

Re: [Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data

[Chris Wilson]

On Thu, May 11, 2017 at 02:07:35PM +0100, Chris Wilson wrote:
> On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin 
> > 
> > For userspace receiving binary data it is easier if all related
> > request tracepoints emit the binary data in the same order of
> > dev, ring, ctx, seqno, ...
> 
> We decided that dev, ctx, ring, seqno was the right heirachy last time.
> After much debate :)
> ctx is the logical view of the device for a user
> ctx + ring = timeline

Hmm, we are also mixing ctx->hw_id and fence->context, right?
(Not relevant, just thinking aloud.)
-Chris

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

[Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

For userspace receiving binary data it is easier if all related
request tracepoints emit the binary data in the same order of
dev, ring, ctx, seqno, ...

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_trace.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index b24a83d43559..035c574cc33f 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -678,8 +678,8 @@ DECLARE_EVENT_CLASS(i915_gem_request,
 
TP_STRUCT__entry(
 __field(u32, dev)
-__field(u32, ctx)
 __field(u32, ring)
+__field(u32, ctx)
 __field(u32, seqno)
 __field(u32, global)
 ),
@@ -721,9 +721,9 @@ DECLARE_EVENT_CLASS(i915_gem_request_hw,
TP_STRUCT__entry(
 __field(u32, dev)
 __field(u32, ring)
+__field(u32, ctx)
 __field(u32, seqno)
 __field(u32, global_seqno)
-__field(u32, ctx)
 __field(u32, port)
),
 
-- 
2.9.3

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

Re: [Intel-gfx] [RFC] drm/i915: Allow the UMD to configure their own power clock state

[Joonas Lahtinen]

On ke, 2017-05-10 at 08:33 +, Oscar Mateo wrote:
> 
> 
> On 05/10/2017 01:28 PM, Daniel Vetter wrote:
> > 
> > On Wed, May 10, 2017 at 2:59 PM, Joonas Lahtinen
> >  wrote:
> > > 
> > > > 
> > > > @@ -841,6 +847,11 @@ static int gen9_init_workarounds(struct
> > > > intel_engine_cs *engine)
> > > >    if (ret)
> > > >    return ret;
> > > > 
> > > > + /* Allow the UMD to configure their own power clock state
> > > > */
> > > > + ret = wa_ring_whitelist_reg(engine,
> > > > GEN8_R_PWR_CLK_STATE);
> > > > + if (ret)
> > > > + return ret;
> > > This is not a workaround, so it should be part of the cmd parser
> > > and
> > > have an userspace.
> 
> cmd parser? This is Gen8+, so the cmd parser shouldn't even be
> active. 
> Or am I missing something?

That's correct, my bad.

> 
> > 
> > Yeah, the "This allows userspace ..." start of the commit message
> > should have been a dead giveaway that we do indeed need the
> > userspace
> > patch for this too.
> > -Daniel
> 
> Yes, I got the memo :)
> Dmitry has opened a ticket against intel-vaapi-driver 
> (https://github.com/01org/intel-vaapi-driver/issues/152) so hopefully
> we 
> will have a userspace soon.

So with the userspace, we can merge.

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

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Joonas Lahtinen]

On to, 2017-05-11 at 02:33 +, Dong, Chuanxiao wrote:
> 
> > 
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Wednesday, May 10, 2017 8:48 PM
> > To: Dong, Chuanxiao ; intel-gvt-
> > d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC
> > submission is enabled
> > 
> > On ti, 2017-05-09 at 18:11 +0800, Chuanxiao Dong wrote:
> > > 
> > > Currently GVT-g cannot work properly when host GuC submission is
> > > enabled, so disable GVT in this case.
> > > 
> > > v2: update the user message (Joonas)
> > > 
> > > > > > Cc: Zhenyu Wang 
> > > > > > Signed-off-by: Chuanxiao Dong 
> > > ---
> > >  drivers/gpu/drm/i915/intel_gvt.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> > > b/drivers/gpu/drm/i915/intel_gvt.c
> > > index e1ab643..d85742c 100644
> > > --- a/drivers/gpu/drm/i915/intel_gvt.c
> > > +++ b/drivers/gpu/drm/i915/intel_gvt.c
> > > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> > >   goto bail;
> > >   }
> > > 
> > > + if (i915.enable_guc_submission) {
> > > + DRM_INFO("GPU guest virtualisation [GVT-g] disabled as
> > Graphics virtualization is not yet supported with GuC submission
> > [i915.enable_guc_submission module parameter]\n");
> > > 
> > > + goto bail;
> > > + }
> > 
> > As discussed earlier, driver loading should fail with -EIO when incompatible
> > options are specified.
> 
> Sorry for not getting why should fail with -EIO? By looking into the
> source, Intel_gvt_init is part of i915 driver loading, and fail with
> -EIO will make i915 driver failed to load. 

Yes, the user has specified an unsafe kernel configuration option,
enable_guc_submission and the driver can rightfully stop loading if
enable_gvt option was passed in the same command line.

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

Re: [Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data

[Chris Wilson]

On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> For userspace receiving binary data it is easier if all related
> request tracepoints emit the binary data in the same order of
> dev, ring, ctx, seqno, ...

We decided that dev, ctx, ring, seqno was the right heirachy last time.
After much debate :)
ctx is the logical view of the device for a user
ctx + ring = timeline
-Chris

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Detect USB-C specific dongles before reducing M and N

[Clint Taylor]

On 05/11/2017 02:57 AM, Jani Nikula wrote:

From: Clint Taylor 

The Analogix 7737 DP to HDMI converter requires reduced M and N values
when to operate correctly at HBR2. Detect this IC by its OUI value of
0x0022B9 via the DPCD quirk list.

v2 by Jani: Rebased on the DP quirk database

Fixes: 9a86cda07af2 ("drm/i915/dp: reduce link M/N parameters")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100755
Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 


Tested-by: Clinton Taylor 


Signed-off-by: Clint Taylor 
Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
  drivers/gpu/drm/i915/intel_display.c | 22 ++
  drivers/gpu/drm/i915/intel_dp.c  | 15 +++
  drivers/gpu/drm/i915/intel_dp_mst.c  |  4 +++-
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  5 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff3574a56812..d34412673d61 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -563,7 +563,8 @@ struct intel_link_m_n {
  
  void intel_link_compute_m_n(int bpp, int nlanes,

int pixel_clock, int link_clock,
-   struct intel_link_m_n *m_n);
+   struct intel_link_m_n *m_n,
+   bool reduce_m_n);
  
  /* Interface history:

   *
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bf9020da8b80..46ac46ca976c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6116,7 +6116,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc 
*intel_crtc,
pipe_config->fdi_lanes = lane;
  
  	intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,

-  link_bw, _config->fdi_m_n);
+  link_bw, _config->fdi_m_n, false);
  
  	ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);

if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
@@ -6292,7 +6292,8 @@ intel_reduce_m_n_ratio(uint32_t *num, uint32_t *den)
  }
  
  static void compute_m_n(unsigned int m, unsigned int n,

-   uint32_t *ret_m, uint32_t *ret_n)
+   uint32_t *ret_m, uint32_t *ret_n,
+   bool reduce_m_n)
  {
/*
 * Reduce M/N as much as possible without loss in precision. Several DP
@@ -6300,9 +6301,11 @@ static void compute_m_n(unsigned int m, unsigned int n,
 * values. The passed in values are more likely to have the least
 * significant bits zero than M after rounding below, so do this first.
 */
-   while ((m & 1) == 0 && (n & 1) == 0) {
-   m >>= 1;
-   n >>= 1;
+   if (reduce_m_n) {
+   while ((m & 1) == 0 && (n & 1) == 0) {
+   m >>= 1;
+   n >>= 1;
+   }
}
  
  	*ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);

@@ -6313,16 +6316,19 @@ static void compute_m_n(unsigned int m, unsigned int n,
  void
  intel_link_compute_m_n(int bits_per_pixel, int nlanes,
   int pixel_clock, int link_clock,
-  struct intel_link_m_n *m_n)
+  struct intel_link_m_n *m_n,
+  bool reduce_m_n)
  {
m_n->tu = 64;
  
  	compute_m_n(bits_per_pixel * pixel_clock,

link_clock * nlanes * 8,
-   _n->gmch_m, _n->gmch_n);
+   _n->gmch_m, _n->gmch_n,
+   reduce_m_n);
  
  	compute_m_n(pixel_clock, link_clock,

-   _n->link_m, _n->link_n);
+   _n->link_m, _n->link_n,
+   reduce_m_n);
  }
  
  static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4a6feb6a69bd..59f3dbb242a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1568,13 +1568,17 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
if (!__intel_dp_read_desc(intel_dp, desc))
return false;
  
+	intel_dp->quirks = drm_dp_get_quirks(desc->oui, sizeof(desc->oui),

+drm_dp_is_branch(intel_dp->dpcd));
+
dev_id_len = strnlen(desc->device_id, sizeof(desc->device_id));
-   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev 
%d.%d\n",
+   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev %d.%d 
quirks 0x%04x\n",
  

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable OA unit for Gen 8 and 9 in i915 perf (rev11)

[Patchwork]

== Series Details ==

Series: Enable OA unit for Gen 8 and 9 in i915 perf (rev11)
URL   : https://patchwork.freedesktop.org/series/20084/
State : success

== Summary ==

Series 20084v11 Enable OA unit for Gen 8 and 9 in i915 perf
https://patchwork.freedesktop.org/api/1.0/series/20084/revisions/11/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:436s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:574s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:519s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:540s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:489s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:426s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:501s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:479s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:574s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:466s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:471s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:500s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:438s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:410s

51350ea90d1a5c8bb7e6532eb61c64a57e83ab9b drm-tip: 2017y-05m-11d-13h-05m-06s UTC 
integration manifest
b0fafe5 drm/i915/perf: add GLK support
6eaead6 drm/i915/perf: add KBL support
4f00ec2 drm/i915: add KBL GT2/GT3 check macros
35c1698 drm/i915/perf: remove perf.hook_lock
9e5b48e drm/i915/perf: per-gen timebase for checking sample freq
54958d8 drm/i915/perf: Add more OA configs for BDW, CHV, SKL + BXT
458be04 drm/i915/perf: Add OA unit support for Gen 8+
008a980 drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
7e0448c drm/i915/perf: rework mux configurations queries
926f454 drm/i915: expose _SUBSLICE_MASK GETPARM
ca47843 drm/i915: expose _SLICE_MASK GETPARM
b5bed21 drm/i915: Record the sseu configuration per-context
0fe4e32 drm/i915: Program RPCS for Broadwell
489c81d drm/i915: Record both min/max eu_per_subslice in sseu_dev_info
849b73a drm/i915/perf: rate limit spurious oa report notice
614009e drm/i915/perf: better pipeline aged/aging tail updates
ad18c50 drm/i915/perf: improve invalid OA format debug message
b5be087 drm/i915/perf: improve tail race workaround
195c706 drm/i915/perf: no head/tail ref in gen7_oa_read
e73dda3 drm/i915/perf: avoid read back of head register
dc7efef drm/i915/perf: avoid poll, read, EAGAIN busy loops
b027310 drm/i915/perf: fix gen7_append_oa_reports comment

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

[Clint Taylor]

On 05/11/2017 02:57 AM, Jani Nikula wrote:

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on OUI (with the option of
expanding to device identification string and hardware/firmware
revisions later). At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link M and N attributes properly. Naturally, the workaround of reducing
main link attributes for all devices ended up in regressions for other
devices. So here we are.

Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Clint Taylor 
Cc: Adam Jackson 
Cc: Harry Wentland 


Tested-by: Clinton Taylor 

Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/drm_dp_helper.c | 61 +
  include/drm/drm_dp_helper.h |  7 +
  2 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e5f52110ea1..58b2ced33151 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1208,3 +1208,64 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
return 0;
  }
  EXPORT_SYMBOL(drm_dp_stop_crc);
+
+/*
+ * Display Port sink and branch devices in the wild have a variety of bugs, try
+ * to collect them here. The quirks are shared, but it's up to the drivers to
+ * implement workarounds for them.
+ */
+
+/*
+ * FIXME: Add support for device identification and hardware/firmware revision.
+ */
+struct dpcd_quirk {
+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, DP_DPCD_QUIRK_LIMITED_M_N },
+};
+
+#undef OUI
+
+/**
+ * drm_dp_get_quirks() - get quirks for the sink/branch device
+ * @oui: pointer to len bytes of DPCD at 0x400 (sink) or 0x500 (branch)
+ * @len: 3-12 bytes of DPCD data
+ * @is_branch: true for branch devices, false for sink devices
+ *
+ * Get a bit mask of DPCD quirks for the sink/branch device. The quirk data is
+ * shared but it's up to the drivers to act on the data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   if (WARN_ON_ONCE(len < 3))
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = _quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, oui, 3) != 0)
+   continue;
+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+EXPORT_SYMBOL(drm_dp_get_quirks);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f7007e544f29..8abe9897fe59 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1079,4 +1079,11 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
  int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
  int drm_dp_stop_crc(struct drm_dp_aux *aux);
  
+/* Display Port sink and branch device quirks. */

+
+/* The sink is limited to small link M and N values. */
+#define DP_DPCD_QUIRK_LIMITED_M_N  BIT(0)
+
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch);
+
  #endif /* _DRM_DP_HELPER_H_ */


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

Re: [Intel-gfx] [PATCH] drm/i915: Detect USB-C specific dongles before reducing M and N

[Clint Taylor]

On 05/11/2017 03:03 AM, Jani Nikula wrote:

On Wed, 10 May 2017, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

The Analogix 7737 DP to HDMI converter requires reduced N and M values when
to operate correctly at HBR2. Detect this IC by its OUI value of 0x0022B9.

I'm not happy, but I also see no alternative than to go this
route. Thanks for the patch. I do think we need to start a common drm
quirk database for this stuff though. Added one, and rebased this one on
top:

https://patchwork.freedesktop.org/series/24282/

Please give it a go; I don't have a DA200.


patches work as expected. quirks is set correctly when OUI 0x0022B9 
based DA200 and SlimPort USB-C dongles are used. All other dongles 
tested do not set quirks.


[   64.569833] [drm:intel_dp_read_desc] DP branch: OUI 00-1c-f8 dev-ID 
176GB0 HW-rev 1.0 SW-rev 7.38 quirks 0x


[  111.053902] [drm:intel_dp_read_desc] DP branch: OUI 00-22-b9 dev-ID 
7737 HW-rev 10.12 SW-rev 6.4 quirks 0x0001


-Clint




BR,
Jani.


Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 

Signed-off-by: Clint Taylor 
---
  drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
  drivers/gpu/drm/i915/intel_display.c | 22 ++
  drivers/gpu/drm/i915/intel_dp.c  | 22 --
  drivers/gpu/drm/i915/intel_dp_mst.c  |  3 ++-
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  5 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 74dffbe..492e47e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -563,7 +563,8 @@ struct intel_link_m_n {
  
  void intel_link_compute_m_n(int bpp, int nlanes,

int pixel_clock, int link_clock,
-   struct intel_link_m_n *m_n);
+   struct intel_link_m_n *m_n,
+   bool reduce_m_n);
  
  /* Interface history:

   *
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7bcc604..8920a99 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6104,7 +6104,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc 
*intel_crtc,
pipe_config->fdi_lanes = lane;
  
  	intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,

-  link_bw, _config->fdi_m_n);
+  link_bw, _config->fdi_m_n, false);
  
  	ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);

if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
@@ -6280,7 +6280,8 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
  }
  
  static void compute_m_n(unsigned int m, unsigned int n,

-   uint32_t *ret_m, uint32_t *ret_n)
+   uint32_t *ret_m, uint32_t *ret_n,
+  bool reduce_m_n)
  {
/*
 * Reduce M/N as much as possible without loss in precision. Several DP
@@ -6288,9 +6289,11 @@ static void compute_m_n(unsigned int m, unsigned int n,
 * values. The passed in values are more likely to have the least
 * significant bits zero than M after rounding below, so do this first.
 */
-   while ((m & 1) == 0 && (n & 1) == 0) {
-   m >>= 1;
-   n >>= 1;
+   if (reduce_m_n) {
+   while ((m & 1) == 0 && (n & 1) == 0) {
+   m >>= 1;
+   n >>= 1;
+   }
}
  
  	*ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);

@@ -6301,16 +6304,19 @@ static void compute_m_n(unsigned int m, unsigned int n,
  void
  intel_link_compute_m_n(int bits_per_pixel, int nlanes,
   int pixel_clock, int link_clock,
-  struct intel_link_m_n *m_n)
+  struct intel_link_m_n *m_n,
+ bool reduce_m_n)
  {
m_n->tu = 64;
  
  	compute_m_n(bits_per_pixel * pixel_clock,

link_clock * nlanes * 8,
-   _n->gmch_m, _n->gmch_n);
+   _n->gmch_m, _n->gmch_n,
+   reduce_m_n);
  
  	compute_m_n(pixel_clock, link_clock,

-   _n->link_m, _n->link_n);
+   _n->link_m, _n->link_n,
+   reduce_m_n);
  }
  
  static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4a6feb6..f4c0582 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1548,6 +1548,20 @@ static void intel_dp_print_rates(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("common rates: %s\n", str);
  }
  
+bool __intel_reduced_m_n(struct intel_dp *intel_dp)

+{
+   struct intel_dp_desc *desc = 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/dp: start a DPCD based DP sink/branch 
device quirk database
URL   : https://patchwork.freedesktop.org/series/24282/
State : warning

== Summary ==

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

Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-edid:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-load-detect:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:438s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:582s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:540s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:484s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:422s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:415s
fi-ivb-3520m total:278  pass:256  dwarn:0   dfail:0   fail:0   skip:22  
time:495s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:504s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:460s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:465s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:581s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:470s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:493s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:411s

81dbd44ab4c1331c61a971b05681473a869b3039 drm-tip: 2017y-05m-11d-09h-55m-44s UTC 
integration manifest
4c53183 drm/i915: Detect USB-C specific dongles before reducing M and N
6072b33 drm/dp: start a DPCD based DP sink/branch device quirk database

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix hw state verifier access to crtc->state.

[Daniel Vetter]

On Thu, May 11, 2017 at 10:28:43AM +0200, Maarten Lankhorst wrote:
> We shouldn't inspect crtc->state, instead grab the crtc state.
> At this point the hw state verifier should be able to run even if
> crtc->state has been updated (which cannot currently happen).
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Daniel Vetter 

pll state checking still looks at ->state directly, we might want to port
that to the new private obj helpers perhaps, with the same new/old
iterators?

Just throwing around some ideas.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 295e17d0f272..e5205d338e3c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5893,9 +5893,10 @@ void intel_encoder_destroy(struct drm_encoder *encoder)
>  
>  /* Cross check the actual hw state with our own modeset state tracking (and 
> it's
>   * internal consistency). */
> -static void intel_connector_verify_state(struct intel_connector *connector)
> +static void intel_connector_verify_state(struct drm_crtc_state *crtc_state,
> +  struct drm_connector_state *conn_state)
>  {
> - struct drm_crtc *crtc = connector->base.state->crtc;
> + struct intel_connector *connector = 
> to_intel_connector(conn_state->connector);
>  
>   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.base.id,
> @@ -5903,15 +5904,14 @@ static void intel_connector_verify_state(struct 
> intel_connector *connector)
>  
>   if (connector->get_hw_state(connector)) {
>   struct intel_encoder *encoder = connector->encoder;
> - struct drm_connector_state *conn_state = connector->base.state;
>  
> - I915_STATE_WARN(!crtc,
> + I915_STATE_WARN(!crtc_state,
>"connector enabled without attached crtc\n");
>  
> - if (!crtc)
> + if (!crtc_state)
>   return;
>  
> - I915_STATE_WARN(!crtc->state->active,
> + I915_STATE_WARN(!crtc_state->active,
> "connector is active, but attached crtc isn't\n");
>  
>   if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
> @@ -5923,9 +5923,9 @@ static void intel_connector_verify_state(struct 
> intel_connector *connector)
>   I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
>   "attached encoder crtc differs from connector crtc\n");
>   } else {
> - I915_STATE_WARN(crtc && crtc->state->active,
> + I915_STATE_WARN(crtc_state && crtc_state->active,
>   "attached crtc is active, but connector isn't\n");
> - I915_STATE_WARN(!crtc && connector->base.state->best_encoder,
> + I915_STATE_WARN(!crtc_state && conn_state->best_encoder,
>   "best encoder set without crtc!\n");
>   }
>  }
> @@ -11859,11 +11859,15 @@ verify_connector_state(struct drm_device *dev,
>  
>   for_each_new_connector_in_state(state, connector, new_conn_state, i) {
>   struct drm_encoder *encoder = connector->encoder;
> + struct drm_crtc_state *crtc_state = NULL;
>  
>   if (new_conn_state->crtc != crtc)
>   continue;
>  
> - intel_connector_verify_state(to_intel_connector(connector));
> + if (crtc)
> + crtc_state = drm_atomic_get_new_crtc_state(state, 
> new_conn_state->crtc);
> +
> + intel_connector_verify_state(crtc_state, new_conn_state);
>  
>   I915_STATE_WARN(new_conn_state->best_encoder != encoder,
>"connector's atomic encoder doesn't match legacy 
> encoder\n");
> @@ -11981,7 +11985,7 @@ verify_crtc_state(struct drm_crtc *crtc,
>  
>   intel_pipe_config_sanity_check(dev_priv, pipe_config);
>  
> - sw_config = to_intel_crtc_state(crtc->state);
> + sw_config = to_intel_crtc_state(new_crtc_state);
>   if (!intel_pipe_config_compare(dev_priv, sw_config,
>  pipe_config, false)) {
>   I915_STATE_WARN(1, "pipe state doesn't match!\n");
> -- 
> 2.11.0
> 
> ___
> 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

[Intel-gfx] ✓ Fi.CI.BAT: success for Implement DDB algorithm and WM cleanup (rev5)

[Patchwork]

== Series Details ==

Series: Implement DDB algorithm and WM cleanup (rev5)
URL   : https://patchwork.freedesktop.org/series/20376/
State : success

== Summary ==

Series 20376v5 Implement DDB algorithm and WM cleanup
https://patchwork.freedesktop.org/api/1.0/series/20376/revisions/5/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:437s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:434s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:575s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:516s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:571s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:491s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:416s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:492s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:478s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:675s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:458s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:581s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:469s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:506s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:443s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:417s

4149c7b22164d81960dae0987f497725117b68e6 drm-tip: 2017y-05m-10d-18h-09m-15s UTC 
integration manifest
04c9c80 drm/i915/skl+: consider max supported plane pixel rate while scaling
0257976 drm/i915/skl: New ddb allocation algorithm
e5ddde8 drm/i915/skl+: use linetime latency if ddb size is not available
2879b17 drm/i915/skl+: Watermark calculation cleanup
924111b drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe 
allocation
56c574d drm/i915/skl+: no need to memset again
71f5a11 drm/i915/skl: Fail the flip if no FB for WM calculation
63cc879 drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed point
daee6f3 drm/i915: Use fixed_16_16 wrapper for division operation
2b17d69 drm/i915: Add more wrapper for fixed_point_16_16 operations
78b019d drm/i915: fix naming of fixed_16_16 wrapper.

== Logs ==

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

[Intel-gfx] [PATCH 2/2] drm/i915: Detect USB-C specific dongles before reducing M and N

[Jani Nikula]

From: Clint Taylor 

The Analogix 7737 DP to HDMI converter requires reduced M and N values
when to operate correctly at HBR2. Detect this IC by its OUI value of
0x0022B9 via the DPCD quirk list.

v2 by Jani: Rebased on the DP quirk database

Fixes: 9a86cda07af2 ("drm/i915/dp: reduce link M/N parameters")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100755
Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Signed-off-by: Clint Taylor 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/intel_display.c | 22 ++
 drivers/gpu/drm/i915/intel_dp.c  | 15 +++
 drivers/gpu/drm/i915/intel_dp_mst.c  |  4 +++-
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 5 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff3574a56812..d34412673d61 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -563,7 +563,8 @@ struct intel_link_m_n {
 
 void intel_link_compute_m_n(int bpp, int nlanes,
int pixel_clock, int link_clock,
-   struct intel_link_m_n *m_n);
+   struct intel_link_m_n *m_n,
+   bool reduce_m_n);
 
 /* Interface history:
  *
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bf9020da8b80..46ac46ca976c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6116,7 +6116,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc 
*intel_crtc,
pipe_config->fdi_lanes = lane;
 
intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
-  link_bw, _config->fdi_m_n);
+  link_bw, _config->fdi_m_n, false);
 
ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
if (ret == -EINVAL && pipe_config->pipe_bpp > 6*3) {
@@ -6292,7 +6292,8 @@ intel_reduce_m_n_ratio(uint32_t *num, uint32_t *den)
 }
 
 static void compute_m_n(unsigned int m, unsigned int n,
-   uint32_t *ret_m, uint32_t *ret_n)
+   uint32_t *ret_m, uint32_t *ret_n,
+   bool reduce_m_n)
 {
/*
 * Reduce M/N as much as possible without loss in precision. Several DP
@@ -6300,9 +6301,11 @@ static void compute_m_n(unsigned int m, unsigned int n,
 * values. The passed in values are more likely to have the least
 * significant bits zero than M after rounding below, so do this first.
 */
-   while ((m & 1) == 0 && (n & 1) == 0) {
-   m >>= 1;
-   n >>= 1;
+   if (reduce_m_n) {
+   while ((m & 1) == 0 && (n & 1) == 0) {
+   m >>= 1;
+   n >>= 1;
+   }
}
 
*ret_n = min_t(unsigned int, roundup_pow_of_two(n), DATA_LINK_N_MAX);
@@ -6313,16 +6316,19 @@ static void compute_m_n(unsigned int m, unsigned int n,
 void
 intel_link_compute_m_n(int bits_per_pixel, int nlanes,
   int pixel_clock, int link_clock,
-  struct intel_link_m_n *m_n)
+  struct intel_link_m_n *m_n,
+  bool reduce_m_n)
 {
m_n->tu = 64;
 
compute_m_n(bits_per_pixel * pixel_clock,
link_clock * nlanes * 8,
-   _n->gmch_m, _n->gmch_n);
+   _n->gmch_m, _n->gmch_n,
+   reduce_m_n);
 
compute_m_n(pixel_clock, link_clock,
-   _n->link_m, _n->link_n);
+   _n->link_m, _n->link_n,
+   reduce_m_n);
 }
 
 static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4a6feb6a69bd..59f3dbb242a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1568,13 +1568,17 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
if (!__intel_dp_read_desc(intel_dp, desc))
return false;
 
+   intel_dp->quirks = drm_dp_get_quirks(desc->oui, sizeof(desc->oui),
+drm_dp_is_branch(intel_dp->dpcd));
+
dev_id_len = strnlen(desc->device_id, sizeof(desc->device_id));
-   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev 
%d.%d\n",
+   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %*pE HW-rev %d.%d SW-rev %d.%d 
quirks 0x%04x\n",
  drm_dp_is_branch(intel_dp->dpcd) ? "branch" : "sink",
  (int)sizeof(desc->oui), desc->oui, oui_sup ? "" : 

[Intel-gfx] [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

[Jani Nikula]

Face the fact, there are Display Port sink and branch devices out there
in the wild that don't follow the Display Port specifications, or they
have bugs, or just otherwise require special treatment. Start a common
quirk database the drivers can query based on OUI (with the option of
expanding to device identification string and hardware/firmware
revisions later). At least for now, we leave the workarounds for the
drivers to implement as they see fit.

For starters, add a branch device that can't handle full 24-bit main
link M and N attributes properly. Naturally, the workaround of reducing
main link attributes for all devices ended up in regressions for other
devices. So here we are.

Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Cc: Clint Taylor 
Cc: Adam Jackson 
Cc: Harry Wentland 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_dp_helper.c | 61 +
 include/drm/drm_dp_helper.h |  7 +
 2 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e5f52110ea1..58b2ced33151 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1208,3 +1208,64 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
return 0;
 }
 EXPORT_SYMBOL(drm_dp_stop_crc);
+
+/*
+ * Display Port sink and branch devices in the wild have a variety of bugs, try
+ * to collect them here. The quirks are shared, but it's up to the drivers to
+ * implement workarounds for them.
+ */
+
+/*
+ * FIXME: Add support for device identification and hardware/firmware revision.
+ */
+struct dpcd_quirk {
+   u8 oui[3];
+   bool is_branch;
+   u32 quirks;
+};
+
+#define OUI(first, second, third) { (first), (second), (third) }
+
+static const struct dpcd_quirk dpcd_quirk_list[] = {
+   /* Analogix 7737 needs reduced M and N at HBR2 link rates */
+   { OUI(0x00, 0x22, 0xb9), true, DP_DPCD_QUIRK_LIMITED_M_N },
+};
+
+#undef OUI
+
+/**
+ * drm_dp_get_quirks() - get quirks for the sink/branch device
+ * @oui: pointer to len bytes of DPCD at 0x400 (sink) or 0x500 (branch)
+ * @len: 3-12 bytes of DPCD data
+ * @is_branch: true for branch devices, false for sink devices
+ *
+ * Get a bit mask of DPCD quirks for the sink/branch device. The quirk data is
+ * shared but it's up to the drivers to act on the data.
+ *
+ * For now, only the OUI (first three bytes) is used, but this may be extended
+ * to device identification string and hardware/firmware revisions later.
+ */
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch)
+{
+   const struct dpcd_quirk *quirk;
+   u32 quirks = 0;
+   int i;
+
+   if (WARN_ON_ONCE(len < 3))
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
+   quirk = _quirk_list[i];
+
+   if (quirk->is_branch != is_branch)
+   continue;
+
+   if (memcmp(quirk->oui, oui, 3) != 0)
+   continue;
+
+   quirks |= quirk->quirks;
+   }
+
+   return quirks;
+}
+EXPORT_SYMBOL(drm_dp_get_quirks);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f7007e544f29..8abe9897fe59 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1079,4 +1079,11 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux);
 int drm_dp_start_crc(struct drm_dp_aux *aux, struct drm_crtc *crtc);
 int drm_dp_stop_crc(struct drm_dp_aux *aux);
 
+/* Display Port sink and branch device quirks. */
+
+/* The sink is limited to small link M and N values. */
+#define DP_DPCD_QUIRK_LIMITED_M_N  BIT(0)
+
+u32 drm_dp_get_quirks(const u8 *oui, unsigned int len, bool is_branch);
+
 #endif /* _DRM_DP_HELPER_H_ */
-- 
2.11.0

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

[Intel-gfx] [PATCH] drm/i915: set initialised only when init_context callback is NULL

[Chuanxiao Dong]

initialised is fixup by the GVT shadow context as true to avoid the init
from the host because it cannot take the settings from the host. Add a
check to let host driver only overwrite it when the init callback is NULL

Cc: Chris Wilson 
Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 319d9a8..d0e9b61 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1956,7 +1956,8 @@ static int execlists_context_deferred_alloc(struct 
i915_gem_context *ctx,
 
ce->ring = ring;
ce->state = vma;
-   ce->initialised = engine->init_context == NULL;
+   if (!engine->init_context)
+   ce->initialised = true;
 
return 0;
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 11/11] drm/i915/skl+: consider max supported plane pixel rate while scaling

[Mahesh Kumar]

On Thursday 11 May 2017 03:18 PM, Maarten Lankhorst wrote:

Op 11-05-17 om 10:36 schreef Mahesh Kumar:

Hi,

Thanks for review.

On Wednesday 10 May 2017 06:52 PM, Maarten Lankhorst wrote:

Op 08-05-17 om 13:49 schreef Mahesh Kumar:

A display resolution is only supported if it meets all the restrictions
below for Maximum Pipe Pixel Rate.

The display resolution must fit within the maximum pixel rate output
from the pipe. Make sure that the display pipe is able to feed pixels at
a rate required to support the desired resolution.
For each enabled plane on the pipe {
  If plane scaling enabled {
 Horizontal down scale amount = Maximum[1, plane horizontal size /
 scaler horizontal window size]
 Vertical down scale amount = Maximum[1, plane vertical size /
 scaler vertical window size]
 Plane down scale amount = Horizontal down scale amount *
 Vertical down scale amount
 Plane Ratio = 1 / Plane down scale amount
  }
  Else {
 Plane Ratio = 1
  }
  If plane source pixel format is 64 bits per pixel {
 Plane Ratio = Plane Ratio * 8/9
  }
}

Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe

If pipe scaling is enabled {
  Horizontal down scale amount = Maximum[1, pipe horizontal source size /
 scaler horizontal window size]
  Vertical down scale amount = Maximum[1, pipe vertical source size /
 scaler vertical window size]
  Note: The progressive fetch - interlace display mode is equivalent to a
 2.0 vertical down scale
  Pipe down scale amount = Horizontal down scale amount *
 Vertical down scale amount
  Pipe Ratio = Pipe Ratio / Pipe down scale amount
}

Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio

Signed-off-by: Mahesh Kumar 
---
   drivers/gpu/drm/i915/intel_display.c |  3 ++
   drivers/gpu/drm/i915/intel_drv.h |  2 +
   drivers/gpu/drm/i915/intel_pm.c  | 87 

   3 files changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..d64367e810f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10992,6 +10992,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
   ret = skl_update_scaler_crtc(pipe_config);
 if (!ret)
+ret = skl_check_pipe_max_pixel_rate(intel_crtc,
+pipe_config);
+if (!ret)
   ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
pipe_config);
   }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54f3ff840812..8323fc2ec4f2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1859,6 +1859,8 @@ bool skl_ddb_allocation_overlaps(const struct 
skl_ddb_entry **entries,
int ignore);
   bool ilk_disable_lp_wm(struct drm_device *dev);
   int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
+  struct intel_crtc_state *cstate);
   static inline int intel_enable_rc6(void)
   {
   return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 92600cf42e12..69b1692ffd07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3397,6 +3397,93 @@ skl_plane_downscale_amount(const struct intel_crtc_state 
*cstate,
   return mul_fixed_16_16(downscale_w, downscale_h);
   }
   +static uint_fixed_16_16_t
+skl_pipe_downscale_amount(const struct intel_crtc_state *config)
+{
+uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
+
+if (!config->base.active)
+return pipe_downscale;
+
+if (config->pch_pfit.enabled) {
+uint32_t src_w, src_h, dst_w, dst_h;
+uint32_t pfit_size = config->pch_pfit.size;
+uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
+uint_fixed_16_16_t downscale_h, downscale_w;
+
+src_w = config->pipe_src_w;
+src_h = config->pipe_src_h;
+dst_w = pfit_size >> 16;
+dst_h = pfit_size & 0x;
+
+if (!dst_w || !dst_h)
+return pipe_downscale;
+
+fp_w_ratio = fixed_16_16_div(src_w, dst_w);
+fp_h_ratio = fixed_16_16_div(src_h, dst_h);
+downscale_w = max_fixed_16_16(fp_w_ratio, u32_to_fixed_16_16(1));
+downscale_h = max_fixed_16_16(fp_h_ratio, u32_to_fixed_16_16(1));
+
+pipe_downscale = mul_fixed_16_16(downscale_w, downscale_h);
+}
+
+return pipe_downscale;
+}
+
+int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
+  struct intel_crtc_state *cstate)
+{
+struct drm_crtc_state *crtc_state = >base;
+struct drm_atomic_state *state = crtc_state->state;
+struct 

Re: [Intel-gfx] [PATCH 11/11] drm/i915/skl+: consider max supported plane pixel rate while scaling

[Maarten Lankhorst]

Op 11-05-17 om 10:36 schreef Mahesh Kumar:
> Hi,
>
> Thanks for review.
>
> On Wednesday 10 May 2017 06:52 PM, Maarten Lankhorst wrote:
>> Op 08-05-17 om 13:49 schreef Mahesh Kumar:
>>> A display resolution is only supported if it meets all the restrictions
>>> below for Maximum Pipe Pixel Rate.
>>>
>>> The display resolution must fit within the maximum pixel rate output
>>> from the pipe. Make sure that the display pipe is able to feed pixels at
>>> a rate required to support the desired resolution.
>>> For each enabled plane on the pipe {
>>>  If plane scaling enabled {
>>> Horizontal down scale amount = Maximum[1, plane horizontal size /
>>> scaler horizontal window size]
>>> Vertical down scale amount = Maximum[1, plane vertical size /
>>> scaler vertical window size]
>>> Plane down scale amount = Horizontal down scale amount *
>>> Vertical down scale amount
>>> Plane Ratio = 1 / Plane down scale amount
>>>  }
>>>  Else {
>>> Plane Ratio = 1
>>>  }
>>>  If plane source pixel format is 64 bits per pixel {
>>> Plane Ratio = Plane Ratio * 8/9
>>>  }
>>> }
>>>
>>> Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe
>>>
>>> If pipe scaling is enabled {
>>>  Horizontal down scale amount = Maximum[1, pipe horizontal source size /
>>> scaler horizontal window size]
>>>  Vertical down scale amount = Maximum[1, pipe vertical source size /
>>> scaler vertical window size]
>>>  Note: The progressive fetch - interlace display mode is equivalent to a
>>> 2.0 vertical down scale
>>>  Pipe down scale amount = Horizontal down scale amount *
>>> Vertical down scale amount
>>>  Pipe Ratio = Pipe Ratio / Pipe down scale amount
>>> }
>>>
>>> Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio
>>>
>>> Signed-off-by: Mahesh Kumar 
>>> ---
>>>   drivers/gpu/drm/i915/intel_display.c |  3 ++
>>>   drivers/gpu/drm/i915/intel_drv.h |  2 +
>>>   drivers/gpu/drm/i915/intel_pm.c  | 87 
>>> 
>>>   3 files changed, 92 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 85b9e2f521a0..d64367e810f8 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -10992,6 +10992,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
>>> *crtc,
>>>   ret = skl_update_scaler_crtc(pipe_config);
>>> if (!ret)
>>> +ret = skl_check_pipe_max_pixel_rate(intel_crtc,
>>> +pipe_config);
>>> +if (!ret)
>>>   ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
>>>pipe_config);
>>>   }
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index 54f3ff840812..8323fc2ec4f2 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -1859,6 +1859,8 @@ bool skl_ddb_allocation_overlaps(const struct 
>>> skl_ddb_entry **entries,
>>>int ignore);
>>>   bool ilk_disable_lp_wm(struct drm_device *dev);
>>>   int sanitize_rc6_option(struct drm_i915_private *dev_priv, int 
>>> enable_rc6);
>>> +int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
>>> +  struct intel_crtc_state *cstate);
>>>   static inline int intel_enable_rc6(void)
>>>   {
>>>   return i915.enable_rc6;
>>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>>> b/drivers/gpu/drm/i915/intel_pm.c
>>> index 92600cf42e12..69b1692ffd07 100644
>>> --- a/drivers/gpu/drm/i915/intel_pm.c
>>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>>> @@ -3397,6 +3397,93 @@ skl_plane_downscale_amount(const struct 
>>> intel_crtc_state *cstate,
>>>   return mul_fixed_16_16(downscale_w, downscale_h);
>>>   }
>>>   +static uint_fixed_16_16_t
>>> +skl_pipe_downscale_amount(const struct intel_crtc_state *config)
>>> +{
>>> +uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
>>> +
>>> +if (!config->base.active)
>>> +return pipe_downscale;
>>> +
>>> +if (config->pch_pfit.enabled) {
>>> +uint32_t src_w, src_h, dst_w, dst_h;
>>> +uint32_t pfit_size = config->pch_pfit.size;
>>> +uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
>>> +uint_fixed_16_16_t downscale_h, downscale_w;
>>> +
>>> +src_w = config->pipe_src_w;
>>> +src_h = config->pipe_src_h;
>>> +dst_w = pfit_size >> 16;
>>> +dst_h = pfit_size & 0x;
>>> +
>>> +if (!dst_w || !dst_h)
>>> +return pipe_downscale;
>>> +
>>> +fp_w_ratio = fixed_16_16_div(src_w, dst_w);
>>> +fp_h_ratio = fixed_16_16_div(src_h, dst_h);
>>> +downscale_w = max_fixed_16_16(fp_w_ratio, u32_to_fixed_16_16(1));
>>> +downscale_h = max_fixed_16_16(fp_h_ratio, u32_to_fixed_16_16(1));

Re: [Intel-gfx] [PATCH v1 3/4] drm/i915/gvt: provide full ppgtt capability for guest i915 driver

[Joonas Lahtinen]

On to, 2017-05-11 at 10:33 +0800, Tina Zhang wrote:
> This patch is to provide full ppgtt capability for guest i915 driver.
> 
> Signed-off-by: Tina Zhang 



> @@ -53,6 +53,10 @@ enum vgt_g2v_type {
>   VGT_G2V_MAX,
>  };
>  
> +enum vgt_caps_type {
> + VGT_CAPS_FULL_PPGTT = (1 << 2),
> +};

Please separate this change to the previous patch to keep it separate
from the gvt/ folder changes. Also use #define and BIT(2) notation.

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix hw state verifier access to crtc->state.

[Maarten Lankhorst]

Op 11-05-17 om 11:23 schreef Daniel Vetter:
> On Thu, May 11, 2017 at 10:28:43AM +0200, Maarten Lankhorst wrote:
>> We shouldn't inspect crtc->state, instead grab the crtc state.
>> At this point the hw state verifier should be able to run even if
>> crtc->state has been updated (which cannot currently happen).
>>
>> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Daniel Vetter 
>
> pll state checking still looks at ->state directly, we might want to port
> that to the new private obj helpers perhaps, with the same new/old
> iterators?
That might be an excellent idea to do in the future. :)

If I look at it though it's race safe in the current design,
but not necessarily against multiple nonblocking modesets,
which should probably be addressed at some point.

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

Re: [Intel-gfx] [CI v4 1/3] drm/i915/guc: Move notification code into virtual function

[Joonas Lahtinen]

On ke, 2017-05-10 at 12:59 +, Michal Wajdeczko wrote:
> Prepare for alternate GuC notification mechanism.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Joonas Lahtinen 
> Cc: Daniele Ceraolo Spurio 
> Reviewed-by: Daniele Ceraolo Spurio 



> @@ -233,6 +236,10 @@ static inline int intel_guc_send(struct intel_guc *guc, 
> const u32 *action, u32 l
>  {
>   return guc->send(guc, action, len);
>  }

A newline is needed here. I'll fix it while pushing.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

> +static inline void intel_guc_notify(struct intel_guc *guc)
> +{
> + guc->notify(guc);
> +}
>  
>  /* intel_guc_loader.c */
>  int intel_guc_select_fw(struct intel_guc *guc);
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 6/9] drm/i915: Support dynamic backlight via DPCD register

[Puthikorn Voravootivat]

Fair enough. Will add kernel switch in next version.

On Wed, May 10, 2017 at 6:26 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> > This patch enables dynamic backlight by default for eDP
> > panel that supports this feature via DPCD register and
> > set minimum / maximum brightness to 0% and 100% of the
> > normal brightness.
>
>
> I read the link that you shared last time, should there be a switch for
> a feature like this that can affect image quality? Should this be a
> decision in the kernel with no provision to turn off/on?
>
>
> -DK
>
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 39
> ++-
> >  1 file changed, 33 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index 5ef3ade7c40e..7d323af96636 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector
> *connector, u32 level)
> >   }
> >  }
> >
> > +/*
> > + * Set minimum / maximum dynamic brightness percentage. This value is
> expressed
> > + * as the percentage of normal brightness in 5% increments.
> > + */
> > +static void
> > +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> > +u32 min, u32 max)
> > +{
> > + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5)
> };
> > +
> > + if (drm_dp_dpcd_write(_dp->aux,
> DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> > +   dbc, sizeof(dbc) < 0)) {
> > + DRM_DEBUG_KMS("Failed to write aux DBC brightness
> level\n");
> > + }
> > +}
> > +
> >  static void intel_dp_aux_enable_backlight(struct intel_connector
> *connector)
> >  {
> >   struct intel_dp *intel_dp = enc_to_intel_dp(>
> encoder->base);
> >   uint8_t dpcd_buf = 0;
> > + uint8_t new_dpcd_buf = 0;
> >   uint8_t edp_backlight_mode = 0;
> >
> >   if (drm_dp_dpcd_readb(_dp->aux,
> > @@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct
> intel_connector *connector)
> >   return;
> >   }
> >
> > + new_dpcd_buf = dpcd_buf;
> >   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_
> MASK;
> >
> >   switch (edp_backlight_mode) {
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> >   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> > - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> > - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > - if (drm_dp_dpcd_writeb(_dp->aux,
> > - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) <
> 0) {
> > - DRM_DEBUG_KMS("Failed to write aux backlight
> mode\n");
> > - }
> > + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> > + new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> >   break;
> >
> >   /* Do nothing when it is already DPCD mode */
> > @@ -130,6 +144,19 @@ static void intel_dp_aux_enable_backlight(struct
> intel_connector *connector)
> >   break;
> >   }
> >
> > + if (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP) {
> > + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> > + intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0,
> 100);
> > + DRM_DEBUG_KMS("Enable dynamic brightness.\n");
> > + }
> > +
> > + if (new_dpcd_buf != dpcd_buf) {
> > + if (drm_dp_dpcd_writeb(_dp->aux,
> > + DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf)
> < 0) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight
> mode\n");
> > + }
> > + }
> > +
> >   set_aux_backlight_enable(intel_dp, true);
> >  }
> >
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

On Wed, May 10, 2017 at 5:39 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Tue, 2017-05-09 at 16:40 -0700, Puthikorn Voravootivat wrote:
> > There are some panel that
> > (1) does not support display backlight enable via AUX
> > (2) support display backlight adjustment via AUX
> > (3) support display backlight enable via eDP BL_ENABLE pin
> >
> > The current driver required that (1) must be support to enable (2).
> > This patch drops that requirement.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index 870c03fc0f3a..c22712762957 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp
> *intel_dp, bool enable)
> >  {
> >   uint8_t reg_val = 0;
> >
> > +   /* Early return when display use other mechanism to enable
> backlight. */
> > + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> > + return;
>
> Won't DP_EDP_BACKLIGHT_AUX_ENABLE_CAP be 1 always? The code below, in
> intel_dp_aux_display_control_capable(), makes sure
> DP_EDP_BACKLIGHT_PIN_ENABLE_CAP=0. The spec says at least one of these
> has to be 1.
>
> We will drop the  DP_EDP_BACKLIGHT_PIN_ENABLE_CAP != 0 check in next
patch set.
This patch adds check here to prepare for that.

>
> "BACKLIGHT_AUX_ENABLE_CAPABLE
> 1 = Indicates that the Sink device supports display backlight
> enable through the BACKLIGHT_ENABLE bit in the
> EDP_DISPLAY_CONTROL register (DPCD Address 00720h, bit 0).
> Must be set to 1 if the BACKLIGHT_PIN_ENABLE_CAPABLE bit (bit 1)
> is cleared to 0."
>
> -DK
>
> > +
> >   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_
> REGISTER,
> > _val) < 0) {
> >   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > @@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
> >* the panel can support backlight control over the aux channel
> >*/
> >   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP
> &&
> > - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> >   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)
> &&
> >   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
> > (intel_dp->edp_dpcd[2] & 
> > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP)))
> {
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

[Pavel Machek]

On Mon 2017-01-23 10:39:27, Juergen Gross wrote:
> On 13/01/17 15:41, Juergen Gross wrote:
> > On 12/01/17 10:21, Chris Wilson wrote:
> >> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
> >>> On 11/01/17 18:08, Chris Wilson wrote:
>  On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> > With kernel 4.10rc3 running as Xen dm0 I get at each boot:
> >
> > [   49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
> > [1431], reason: Hang on render ring, action: reset
> > [   49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
> > gfx stack, including userspace.
> > [   49.213700] [drm] Please file a _new_ bug report on
> > bugs.freedesktop.org against DRI -> DRM/Intel
> > [   49.213700] [drm] drm/i915 developers can then reassign to the right
> > component if it's not a kernel issue.
> > [   49.213700] [drm] The gpu crash dump is required to analyze gpu
> > hangs, so please always attach it.
> > [   49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
> > [   49.213755] drm/i915: Resetting chip after gpu hang
> > [   60.213769] drm/i915: Resetting chip after gpu hang
> > [   71.189737] drm/i915: Resetting chip after gpu hang
> > [   82.165747] drm/i915: Resetting chip after gpu hang
> > [   93.205727] drm/i915: Resetting chip after gpu hang
> >
> > The dump is attached.
> 
>  That's a nasty one. The first couple of pages of the batchbuffer appear
>  to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That
>  may be a concurrent write by either the GPU or CPU, or we may have
>  incorrected mapped a set of pages. That it doesn't recovered suggests
>  that the corruption occurs frequently, probably on every request/batch.
> >>>
> >>> I hoped someone would have an idea already.
> >>
> >> Sorry, first report of something like this in a long time (that I can
> >> remember at least). And the problem is that it can be anything from a
> >> coherency to a concurrency issue, so no one patch springs to mind.
> >> Thankfully it appears to be kernel related.
> >> -Chris
> >>
> > 
> > Bisecting took longer than I thought, but I had to cherry pick some
> > patches and rebase one of them multiple times...
> > 
> > Finally I found the commit to blame: 920cf4194954ec ("drm/i915:
> > Introduce an internal allocator for disposable private objects")
> > 
> > In case you need me to produce some more data or test a patch
> > feel free to reach out.
> 
> Anything new for this severe regression?
> 
> Without a fix 4.10 will be unusable with Xen on a machine with i915
> graphics!

Did this get solved?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx