Re: [Intel-gfx] [PATCH v2] drm/i915: Clean up HDMI deep color handling a bit

2019-09-02 Thread Jani Nikula
On Wed, 28 Aug 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Reogranize the HDMI deep color state computation to just
> loop over possible bpc values. Avoids having to maintain
> so many variants of the clock etc.
>
> The current code also looks confused w.r.t. port_clock vs.
> bw_constrained. It would happily update port_clock for
> deep color but then not actually enable deep color due to
> bw_constrained being set. The new logic handles that case
> correctly.
>
> v2: Pull stuff into separate funcs (Jani)
>
> Reviewed-by: Jani Nikula  #v1

Also v2, I think this is neater.

BR,
Jani.

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 134 +-
>  1 file changed, 77 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 0f5a0c618e46..02c5c3811a56 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2261,9 +2261,7 @@ static bool hdmi_deep_color_possible(const struct 
> intel_crtc_state *crtc_state,
>  
>  static bool
>  intel_hdmi_ycbcr420_config(struct drm_connector *connector,
> -struct intel_crtc_state *config,
> -int *clock_12bpc, int *clock_10bpc,
> -int *clock_8bpc)
> +struct intel_crtc_state *config)
>  {
>   struct intel_crtc *intel_crtc = to_intel_crtc(config->base.crtc);
>  
> @@ -2272,11 +2270,6 @@ intel_hdmi_ycbcr420_config(struct drm_connector 
> *connector,
>   return false;
>   }
>  
> - /* YCBCR420 TMDS rate requirement is half the pixel clock */
> - config->port_clock /= 2;
> - *clock_12bpc /= 2;
> - *clock_10bpc /= 2;
> - *clock_8bpc /= 2;
>   config->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>  
>   /* YCBCR 420 output conversion needs a scaler */
> @@ -2291,6 +2284,76 @@ intel_hdmi_ycbcr420_config(struct drm_connector 
> *connector,
>   return true;
>  }
>  
> +static int intel_hdmi_port_clock(int clock, int bpc)
> +{
> + /*
> +  * Need to adjust the port link by:
> +  *  1.5x for 12bpc
> +  *  1.25x for 10bpc
> +  */
> + return clock * bpc / 8;
> +}
> +
> +static int intel_hdmi_compute_bpc(struct intel_encoder *encoder,
> +   struct intel_crtc_state *crtc_state,
> +   int clock, bool force_dvi)
> +{
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
> + int bpc;
> +
> + for (bpc = 12; bpc >= 10; bpc -= 2) {
> + if (hdmi_deep_color_possible(crtc_state, bpc) &&
> + hdmi_port_clock_valid(intel_hdmi,
> +   intel_hdmi_port_clock(clock, bpc),
> +   true, force_dvi) == MODE_OK)
> + return bpc;
> + }
> +
> + return 8;
> +}
> +
> +static int intel_hdmi_compute_clock(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> + bool force_dvi)
> +{
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
> + const struct drm_display_mode *adjusted_mode =
> + &crtc_state->base.adjusted_mode;
> + int bpc, clock = adjusted_mode->crtc_clock;
> +
> + if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> + clock *= 2;
> +
> + /* YCBCR420 TMDS rate requirement is half the pixel clock */
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + clock /= 2;
> +
> + bpc = intel_hdmi_compute_bpc(encoder, crtc_state,
> +  clock, force_dvi);
> +
> + crtc_state->port_clock = intel_hdmi_port_clock(clock, bpc);
> +
> + /*
> +  * pipe_bpp could already be below 8bpc due to
> +  * FDI bandwidth constraints. We shouldn't bump it
> +  * back up to 8bpc in that case.
> +  */
> + if (crtc_state->pipe_bpp > bpc * 3)
> + crtc_state->pipe_bpp = bpc * 3;
> +
> + DRM_DEBUG_KMS("picking %d bpc for HDMI output (pipe bpp: %d)\n",
> +   bpc, crtc_state->pipe_bpp);
> +
> + if (hdmi_port_clock_valid(intel_hdmi, crtc_state->port_clock,
> +   false, force_dvi) != MODE_OK) {
> + DRM_DEBUG_KMS("unsupported HDMI clock (%d kHz), rejecting 
> mode\n",
> +   crtc_state->port_clock);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
>  int intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state)
> @@ -2302,11 +2365,8 @@ int intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   struct drm_scdc *scdc = &connector->display_info.hdmi.scdc;
>   struct inte

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/21] drm/i915: Restrict the aliasing-ppgtt to the size of the ggtt

2019-09-02 Thread Patchwork
== Series Details ==

Series: series starting with [01/21] drm/i915: Restrict the aliasing-ppgtt to 
the size of the ggtt
URL   : https://patchwork.freedesktop.org/series/66109/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6818_full -> Patchwork_14255_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14255_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14255_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_14255_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-snb:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-snb7/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-snb6/igt@gem_b...@close-race.html

  

### Piglit changes ###

 Warnings 

  * spec@ext_texture_norm16@render:
- pig-hsw-4770r:  [CRASH][3] ([fdo#111530]) -> [INCOMPLETE][4] +5 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/pig-hsw-4770r/spec@ext_texture_nor...@render.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/pig-hsw-4770r/spec@ext_texture_nor...@render.html

  
Known issues


  Here are the changes found in Patchwork_14255_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-snb:  [PASS][7] -> [FAIL][8] ([fdo#105957])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-snb6/igt@gem_...@in-flight-contexts-immediate.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-snb4/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) +6 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-iclb5/igt@gem_exec_sched...@reorder-wide-bsd.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / 
[fdo#108686])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-iclb7/igt@gem_tiled_swapp...@non-threaded.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-iclb2/igt@gem_tiled_swapp...@non-threaded.html
- shard-hsw:  [PASS][13] -> [INCOMPLETE][14] ([fdo#103540] / 
[fdo#108686])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-hsw4/igt@gem_tiled_swapp...@non-threaded.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-hsw1/igt@gem_tiled_swapp...@non-threaded.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +7 
similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-apl3/igt@gem_workarou...@suspend-resume-context.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-apl7/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-kbl:  [PASS][17] -> [SKIP][18] ([fdo#109271])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-kbl3/igt@i915_pm_rc6_reside...@rc6-accuracy.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html

  * igt@i915_pm_rpm@gem-execbuf-stress:
- shard-apl:  [PASS][19] -> [INCOMPLETE][20] ([fdo#103927])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-apl6/igt@i915_pm_...@gem-execbuf-stress.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-apl1/igt@i915_pm_...@gem-execbuf-stress.html

  * igt@i915_pm_rps@reset:
- shard-apl:  [PASS][21] -> [FAIL][22] ([fdo#102250])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6818/shard-apl5/igt@i915_pm_...@reset.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14255/shard-apl6/igt@i915_pm_...@reset.html

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103

Re: [Intel-gfx] [RFC PATCH] iommu/vt-d: Fix IOMMU field not populated on device hot re-plug

2019-09-02 Thread Janusz Krzysztofik
Hi Baolu,

On Thursday, August 29, 2019 11:08:18 AM CEST Lu Baolu wrote:
> Hi,
> 
> On 8/29/19 3:58 PM, Janusz Krzysztofik wrote:
> > Hi Baolu,
> > 
> > On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
> >> Hi Janusz,
> >>
> >> On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
>  We should avoid kernel panic when a intel_unmap() is called against
>  a non-existent domain.
> >>> Does that mean you suggest to replace
> >>>   BUG_ON(!domain);
> >>> with something like
> >>>   if (WARN_ON(!domain))
> >>>   return;
> >>> and to not care of orphaned mappings left allocated?  Is there a way to
> > inform
> >>> users that their active DMA mappings are no longer valid and they
> > shouldn't
> >>> call dma_unmap_*()?
> >>>
>  But we shouldn't expect the IOMMU driver not
>  cleaning up the domain info when a device remove notification comes and
>  wait until all file descriptors being closed, right?
> >>> Shouldn't then the IOMMU driver take care of cleaning up resources still
> >>> allocated on device remove before it invalidates and forgets their
> > pointers?
> >>>
> >>
> >> You are right. We need to wait until all allocated resources (iova and
> >> mappings) to be released.
> >>
> >> How about registering a callback for BUS_NOTIFY_UNBOUND_DRIVER, and
> >> removing the domain info when the driver detachment completes?
> > 
> > Device core calls BUS_NOTIFY_UNBOUND_DRIVER on each driver unbind, 
regardless
> > of a device being removed or not.  As long as the device is not unplugged 
and
> > the BUS_NOTIFY_REMOVED_DEVICE notification not generated, an unbound 
driver is
> > not a problem here.
> > Morever, BUS_NOTIFY_UNBOUND_DRIVER  is called even before
> > BUS_NOTIFY_REMOVED_DEVICE so that wouldn't help anyway.
> > Last but not least, bus events are independent of the IOMMU driver use via
> > DMA-API it exposes.
> 
> Fair enough.
> 
> > 
> > If keeping data for unplugged devices and reusing it on device re-plug is 
not
> > acceptable then maybe the IOMMU driver should perform reference counting 
of
> > its internal resources occupied by DMA-API users and perform cleanups on 
last
> > release?
> 
> I am not saying that keeping data is not acceptable. I just want to
> check whether there are any other solutions.

Then reverting 458b7c8e0dde and applying this patch still resolves the issue 
for me.  No errors appear when mappings are unmapped on device close after the 
device has been removed, and domain info preserved on device removal is 
successfully reused on device re-plug.

Is there anything else I can do to help?

Thanks,
Janusz

> 
> Best regards,
> Baolu
> 




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

Re: [Intel-gfx] [PATCH 01/21] drm/i915: Restrict the aliasing-ppgtt to the size of the ggtt

2019-09-02 Thread Matthew Auld
On Mon, 2 Sep 2019 at 05:03, Chris Wilson  wrote:
>
> The aliasing-ppgtt is not allowed to be smaller than the ggtt, nor
> should we advertise it as being any bigger, or else we may get sued for
> false advertisement.
>
> Testcase: igt/gem_exec_big
> Fixes: 0b718ba1e884 ("drm/i915/gtt: Downgrade Cherryview back to 
> aliasing-ppgtt")
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/21] drm/i915: Report aliasing ppgtt size as ggtt size

2019-09-02 Thread Matthew Auld
On Mon, 2 Sep 2019 at 05:03, Chris Wilson  wrote:
>
> The aliasing-ppgtt is constrained to be the same size as the Global GTT
> since it aliases the same address space. Simplifying gtt size reporting
> in this case.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v12 08/11] drm/i915/perf: execute OA configuration from command stream

2019-09-02 Thread Lionel Landwerlin

On 30/08/2019 18:48, Chris Wilson wrote:

Quoting Lionel Landwerlin (2019-08-30 15:47:23)

  err_unpin:
-   __i915_vma_unpin(vma);
+   mutex_lock(&i915->drm.struct_mutex);
+   i915_vma_unpin_and_release(&vma, 0);
+   mutex_unlock(&i915->drm.struct_mutex);

Strangely unpin_and_release() doesn't need the mutex. But I can clean
that up later.

  
  err_unref:

 i915_gem_object_put(bo);
@@ -1947,50 +1961,69 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
 return ret;
  }
  
-static void config_oa_regs(struct drm_i915_private *dev_priv,

-  const struct i915_oa_reg *regs,
-  u32 n_regs)
+static int emit_oa_config(struct drm_i915_private *i915,
+ struct i915_perf_stream *stream)
  {
-   u32 i;
+   struct i915_request *rq;
+   struct i915_vma *vma;
+   u32 *cs;
+   int err;
  
-   for (i = 0; i < n_regs; i++) {

-   const struct i915_oa_reg *reg = regs + i;
+   lockdep_assert_held(&stream->config_mutex);
  
-   I915_WRITE(reg->addr, reg->value);

+   rq = i915_request_create(stream->engine->kernel_context);
+   if (IS_ERR(rq))
+   return PTR_ERR(rq);
+
+   err = i915_active_request_set(&stream->active_config_rq,
+ rq);
+   if (err)
+   goto err_add_request;
+
+   vma = i915_vma_instance(stream->initial_oa_config_bo,
+   &i915->ggtt.vm, NULL);

Safer with stream->engine->gt->ggtt.vm


+   if (unlikely(IS_ERR(vma))) {
+   err = PTR_ERR(vma);
+   goto err_add_request;
 }
-}
  
-static void delay_after_mux(void)

-{
-   /*
-* It apparently takes a fairly long time for a new MUX
-* configuration to be be applied after these register writes.
-* This delay duration was derived empirically based on the
-* render_basic config but hopefully it covers the maximum
-* configuration latency.
-*
-* As a fallback, the checks in _append_oa_reports() to skip
-* invalid OA reports do also seem to work to discard reports
-* generated before this config has completed - albeit not
-* silently.
-*
-* Unfortunately this is essentially a magic number, since we
-* don't currently know of a reliable mechanism for predicting
-* how long the MUX config will take to apply and besides
-* seeing invalid reports we don't know of a reliable way to
-* explicitly check that the MUX config has landed.
-*
-* It's even possible we've miss characterized the underlying
-* problem - it just seems like the simplest explanation why
-* a delay at this location would mitigate any invalid reports.
-*/
-   usleep_range(15000, 2);
+   err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL);
+   if (err)
+   goto err_add_request;

Don't pin inside a request. do the pining before i915_request_create().
One day, we may need to allocate a request to do the pin.

Be safe,

i915_vma_lock(vma);
err = i915_request_await_object(rq, vma->obj, 0);
(yes, we need a better wrapper here)
if (err)

+   err = i915_vma_move_to_active(vma, rq, 0);

i915_vma_unlock(vma);

+   if (err)
+   goto err_vma_unpin;
+



@@ -2658,16 +2684,31 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
 stream->ops = &i915_oa_stream_ops;
 dev_priv->perf.exclusive_stream = stream;
  
+   mutex_lock(&stream->config_mutex);

 ret = dev_priv->perf.ops.enable_metric_set(stream);
 if (ret) {
 DRM_DEBUG("Unable to enable metric set\n");
-   goto err_enable;
+   /*
+* Ignore the return value since we already have an error from
+* the enable vfunc.
+*/
+   i915_active_request_retire(&stream->active_config_rq,
+  &stream->config_mutex);
+   } else {
+   ret = i915_active_request_retire(&stream->active_config_rq,
+&stream->config_mutex);

This function doesn't exist anymore. It's basically just waiting for the
old request. Why do you need it? (Your request flow is otherwise ordered.)



I don't want to enable the OA reports to be written into the OA buffer 
until I know the configuration work has completed.


Otherwise it would write invalid/unconfigured data.





-   DRM_DEBUG("opening stream oa config uuid=%s\n", 
stream->oa_config->uuid);
-
+   mutex_unlock(&stream->config_mutex);
 mutex_unlock(&dev_priv->drm.struct_mutex);
  
+   i915_gem_object_put(stream->initial_oa_config_bo);

+   stream->initial_oa_config_bo = NULL;
+   if (ret)
+   goto err_enable;

Is it because of this err that may end up freei

Re: [Intel-gfx] [PATCH] drm/i915: Replace obj->pin_global with obj->frontbuffer

2019-09-02 Thread Ville Syrjälä
On Fri, Aug 23, 2019 at 06:11:26PM +0100, Chris Wilson wrote:
> obj->pin_global was original used as a means to keep the shrinker off
> the active scanout, but we use the vma->pin_count itself for that and
> the obj->frontbuffer to delay shrinking active framebuffers. The other
> role that obj->pin_global gained was for spotting display objects inside
> GEM and working harder to keep those coherent; for which we can again
> simply inspect obj->frontbuffer directly.
> 
> Coming up next, we will want to manipulate the pin_global counter
> outside of the principle locks, so would need to make pin_global atomic.
> However, since obj->frontbuffer is already managed atomically, it makes
> sense to use that the primary key for display objects instead of having
> pin_global.
> 
> Ville pointed out the principle difference is that obj->frontbuffer is
> set for as long as an intel_frambuffer is attached to an object, but
> obj->pin_global was only raised for as long as the object was active. In
> practice, this means that we consider the object as being on the scanout
> for longer than is strictly required, causing us to be more proactive in
> flushing -- though it should be true that we would have flushed
> eventually when the back became the front, except that on the flip path
> that flush is aync but when hit from another ioctl it will be
> synchronous.
> 
> v2: i915_gem_object_is_framebuffer()
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Ville Syrjälä 

Reviewed-by: Ville Syrjälä 

> ---
>  .../gpu/drm/i915/display/intel_frontbuffer.c  | 13 +--
>  drivers/gpu/drm/i915/gem/i915_gem_domain.c| 34 ++-
>  drivers/gpu/drm/i915/gem/i915_gem_object.h|  3 +-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  2 --
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  | 15 +++-
>  drivers/gpu/drm/i915/i915_debugfs.c   | 12 ++-
>  6 files changed, 29 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c 
> b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> index 719379774fa5..fc40dc1fdbcc 100644
> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> @@ -220,11 +220,18 @@ static void frontbuffer_release(struct kref *ref)
>  {
>   struct intel_frontbuffer *front =
>   container_of(ref, typeof(*front), ref);
> + struct drm_i915_gem_object *obj = front->obj;
> + struct i915_vma *vma;
>  
> - front->obj->frontbuffer = NULL;
> - spin_unlock(&to_i915(front->obj->base.dev)->fb_tracking.lock);
> + spin_lock(&obj->vma.lock);
> + for_each_ggtt_vma(vma, obj)
> + vma->display_alignment = I915_GTT_MIN_ALIGNMENT;
> + spin_unlock(&obj->vma.lock);
>  
> - i915_gem_object_put(front->obj);
> + obj->frontbuffer = NULL;
> + spin_unlock(&to_i915(obj->base.dev)->fb_tracking.lock);
> +
> + i915_gem_object_put(obj);
>   kfree(front);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 9c58e8fac1d9..6af740a5e3db 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -27,7 +27,7 @@ static void __i915_gem_object_flush_for_display(struct 
> drm_i915_gem_object *obj)
>  
>  void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj)
>  {
> - if (!READ_ONCE(obj->pin_global))
> + if (!i915_gem_object_is_framebuffer(obj))
>   return;
>  
>   i915_gem_object_lock(obj);
> @@ -422,12 +422,8 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>  
>   assert_object_held(obj);
>  
> - /* Mark the global pin early so that we account for the
> -  * display coherency whilst setting up the cache domains.
> -  */
> - obj->pin_global++;
> -
> - /* The display engine is not coherent with the LLC cache on gen6.  As
> + /*
> +  * The display engine is not coherent with the LLC cache on gen6.  As
>* a result, we make sure that the pinning that is about to occur is
>* done with uncached PTEs. This is lowest common denominator for all
>* chipsets.
> @@ -439,12 +435,11 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>   ret = i915_gem_object_set_cache_level(obj,
> HAS_WT(to_i915(obj->base.dev)) ?
> I915_CACHE_WT : I915_CACHE_NONE);
> - if (ret) {
> - vma = ERR_PTR(ret);
> - goto err_unpin_global;
> - }
> + if (ret)
> + return ERR_PTR(ret);
>  
> - /* As the user may map the buffer once pinned in the display plane
> + /*
> +  * As the user may map the buffer once pinned in the display plane
>* (e.g. libkms for the bootup splash), we have to ensure that we
>* always use map_and_fenceable for all scanout buffer

[Intel-gfx] [PATCH v13 00/11] drm/i915: Vulkan performance query support

2019-09-02 Thread Lionel Landwerlin
Hi all,

Some missing locks of the VMA that Chris spotted in the review. This
also simplifies a bit the execbuf code, again as recommended by Chris.

Cheers,

Lionel Landwerlin (11):
  drm/i915: introduce a mechanism to extend execbuf2
  drm/i915: add syncobj timeline support
  drm/i915/perf: drop list of streams
  drm/i915/perf: store the associated engine of a stream
  drm/i915/perf: introduce a versioning of the i915-perf uapi
  drm/i915/perf: allow for CS OA configs to be created lazily
  drm/i915/perf: implement active wait for noa configurations
  drm/i915/perf: execute OA configuration from command stream
  drm/i915: add a new perf configuration execbuf parameter
  drm/i915/perf: allow holding preemption on filtered ctx
  drm/i915: add support for perf configuration queries

 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 500 ++--
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  25 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   5 +
 drivers/gpu/drm/i915/i915_debugfs.c   |  31 +
 drivers/gpu/drm/i915/i915_drv.c   |   3 +-
 drivers/gpu/drm/i915/i915_drv.h   |  63 +-
 drivers/gpu/drm/i915/i915_getparam.c  |   9 +
 drivers/gpu/drm/i915/i915_perf.c  | 717 +++---
 drivers/gpu/drm/i915/i915_perf.h  |  27 +
 drivers/gpu/drm/i915/i915_query.c | 283 +++
 drivers/gpu/drm/i915/i915_reg.h   |   4 +-
 include/uapi/drm/i915_drm.h   | 196 -
 12 files changed, 1682 insertions(+), 181 deletions(-)

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

[Intel-gfx] [PATCH v13 10/11] drm/i915/perf: allow holding preemption on filtered ctx

2019-09-02 Thread Lionel Landwerlin
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of command buffer concept meant that
queries' duration could span multiple command buffers.

With that restriction gone in Vulkan, we would like to simplify
measuring performance just by measuring the deltas between the counter
snapshots written by 2 MI_RECORD_PERF_COUNT commands, rather than the
more complex scheme we currently have in the GL driver, using 2
MI_RECORD_PERF_COUNT commands and doing some post processing on the
stream of OA reports, coming from the global OA buffer, to remove any
unrelated deltas in between the 2 MI_RECORD_PERF_COUNT.

Disabling preemption only apply to a single context with which want to
query performance counters for and is considered a privileged
operation, by default protected by CAP_SYS_ADMIN. It is possible to
enable it for a normal user by disabling the paranoid stream setting.

v2: Store preemption setting in intel_context (Chris)

v3: Use priorities to avoid preemption rather than the HW mechanism

v4: Just modify the port priority reporting function

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  8 +
 drivers/gpu/drm/i915/i915_drv.h   |  8 +
 drivers/gpu/drm/i915/i915_perf.c  | 31 +--
 include/uapi/drm/i915_drm.h   | 11 +++
 4 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 17857cf31baf..7a40bdd99192 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2128,6 +2128,14 @@ static int eb_oa_config(struct i915_execbuffer *eb)
if (err)
goto out;
 
+   /*
+* If the perf stream was opened with hold preemption, flag the
+* request properly so that the priority of the request is bumped once
+* it reaches the execlist ports.
+*/
+   if (eb->i915->perf.exclusive_stream->hold_preemption)
+   eb->request->flags |= I915_REQUEST_NOPREEMPT;
+
/*
 * If the config hasn't changed, skip reconfiguring the HW (this is
 * subject to a delay we want to avoid has much as possible).
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 084cdd115d5a..d18e12ada4e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1122,6 +1122,14 @@ struct i915_perf_stream {
 */
bool enabled;
 
+   /**
+* @hold_preemption: Whether preemption is put on hold for command
+* submissions done on the @ctx. This is useful for some drivers that
+* cannot easily post process the OA buffer context to subtract delta
+* of performance counters not associated with @ctx.
+*/
+   bool hold_preemption;
+
/**
 * @ops: The callbacks providing the implementation of this specific
 * type of configured stream.
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 8e811bcbd679..3a2b78b2d2ec 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -343,6 +343,8 @@ static const struct i915_oa_format 
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
  * struct perf_open_properties - for validated properties given to open a 
stream
  * @sample_flags: `DRM_I915_PERF_PROP_SAMPLE_*` properties are tracked as flags
  * @single_context: Whether a single or all gpu contexts should be monitored
+ * @hold_preemption: Whether the preemption is disabled for the filtered
+ *   context
  * @ctx_handle: A gem ctx handle for use with @single_context
  * @metrics_set: An ID for an OA unit metric set advertised via sysfs
  * @oa_format: An OA unit HW report format
@@ -357,6 +359,7 @@ struct perf_open_properties {
u32 sample_flags;
 
u64 single_context:1;
+   u64 hold_preemption:1;
u64 ctx_handle;
 
/* OA sampling state */
@@ -2633,6 +2636,8 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
if (WARN_ON(stream->oa_buffer.format_size == 0))
return -EINVAL;
 
+   stream->hold_preemption = props->hold_preemption;
+
stream->oa_buffer.format =
dev_priv->perf.oa_formats[props->oa_format].format;
 
@@ -3189,6 +3194,15 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
}
}
 
+   if (props->hold_preemption) {
+   if (!props->single_context) {
+   DRM_DEBUG("preemption disable with no context\n");
+   ret = -EINVAL;
+

[Intel-gfx] [PATCH v13 02/11] drm/i915: add syncobj timeline support

2019-09-02 Thread Lionel Landwerlin
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.

v2: Reuse i915_user_extension_fn

v3: Check that the chained extension is only present once (Chris)

v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)

v5: Use BIT_ULL (Chris)

v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)

v7: Report ENOENT with invalid syncobj handle (Lionel)

v8: Check for out of order timeline point insertion (Chris)

v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)

v10: Set first extension enum item to 1 (Jason)

Signed-off-by: Lionel Landwerlin 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 307 ++
 drivers/gpu/drm/i915/i915_drv.c   |   3 +-
 drivers/gpu/drm/i915/i915_getparam.c  |   1 +
 include/uapi/drm/i915_drm.h   |  39 +++
 4 files changed, 293 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4f5fd946ab28..46ad8d9642d1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -214,6 +214,13 @@ enum {
  * the batchbuffer in trusted mode, otherwise the ioctl is rejected.
  */
 
+struct i915_eb_fences {
+   struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+   struct dma_fence *dma_fence;
+   u64 value;
+   struct dma_fence_chain *chain_fence;
+};
+
 struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -276,6 +283,7 @@ struct i915_execbuffer {
 
struct {
u64 flags; /** Available extensions parameters */
+   struct drm_i915_gem_execbuffer_ext_timeline_fences 
timeline_fences;
} extensions;
 };
 
@@ -2320,67 +2328,217 @@ eb_pin_engine(struct i915_execbuffer *eb,
 }
 
 static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fences *fences, unsigned int n)
 {
-   while (n--)
-   drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+   while (n--) {
+   drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+   dma_fence_put(fences[n].dma_fence);
+   kfree(fences[n].chain_fence);
+   }
kvfree(fences);
 }
 
-static struct drm_syncobj **
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
-   struct drm_file *file)
+static struct i915_eb_fences *
+get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
+{
+   struct drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences =
+   &eb->extensions.timeline_fences;
+   struct drm_i915_gem_exec_fence __user *user_fences;
+   struct i915_eb_fences *fences;
+   u64 __user *user_values;
+   u64 num_fences, num_user_fences = timeline_fences->fence_count;
+   unsigned long n;
+   int err;
+
+   /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+   BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+   if (num_user_fences > min_t(unsigned long,
+   ULONG_MAX / sizeof(*user_fences),
+   SIZE_MAX / sizeof(*fences)))
+   return ERR_PTR(-EINVAL);
+
+   user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+   if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+   return ERR_PTR(-EFAULT);
+
+   user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+   if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+   return ERR_PTR(-EFAULT);
+
+   fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+   __GFP_NOWARN | GFP_KERNEL);
+   if (!fences)
+   return ERR_PTR(-ENOMEM);
+
+   BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+   for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+   struct drm_i915_gem_exec_fence user_fence;
+   struct drm_syncobj *syncobj;
+   struct dma_fence *fence = NULL;
+   u64 point;
+
+   if (__copy_from_user(&user_fence, user_fences++, 
sizeof(user_fence))) {
+   err = -EFAULT;
+   goto err;
+   }
+
+   if (user_fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
+   err = -EINVAL;
+   goto err;
+   }
+
+   if (__get_user(point, user_values++)) {
+   err = -EFAULT;
+   goto err;
+   }
+
+   

[Intel-gfx] [PATCH v13 01/11] drm/i915: introduce a mechanism to extend execbuf2

2019-09-02 Thread Lionel Landwerlin
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.

v2: Check for invalid flags in execbuffer2 (Lionel)

v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson  (v1)
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 ++-
 include/uapi/drm/i915_drm.h   | 26 +++--
 2 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 27dbcb508055..4f5fd946ab28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -25,6 +25,7 @@
 #include "i915_gem_context.h"
 #include "i915_gem_ioctls.h"
 #include "i915_trace.h"
+#include "i915_user_extensions.h"
 
 enum {
FORCE_CPU_RELOC = 1,
@@ -272,6 +273,10 @@ struct i915_execbuffer {
 */
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
+
+   struct {
+   u64 flags; /** Available extensions parameters */
+   } extensions;
 };
 
 #define exec_entry(EB, VMA) (&(EB)->exec[(VMA)->exec_flags - (EB)->flags])
@@ -1940,7 +1945,8 @@ static bool i915_gem_check_execbuffer(struct 
drm_i915_gem_execbuffer2 *exec)
return false;
 
/* Kernel clipping was a DRI1 misfeature */
-   if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+   if (!(exec->flags & (I915_EXEC_FENCE_ARRAY |
+I915_EXEC_USE_EXTENSIONS))) {
if (exec->num_cliprects || exec->cliprects_ptr)
return false;
}
@@ -2442,6 +2448,33 @@ signal_fence_array(struct i915_execbuffer *eb,
}
 }
 
+static const i915_user_extension_fn execbuf_extensions[] = {
+};
+
+static int
+parse_execbuf2_extensions(struct drm_i915_gem_execbuffer2 *args,
+ struct i915_execbuffer *eb)
+{
+   eb->extensions.flags = 0;
+
+   if (!(args->flags & I915_EXEC_USE_EXTENSIONS))
+   return 0;
+
+   /* The execbuf2 extension mechanism reuses cliprects_ptr. So we cannot
+* have another flag also using it at the same time.
+*/
+   if (eb->args->flags & I915_EXEC_FENCE_ARRAY)
+   return -EINVAL;
+
+   if (args->num_cliprects != 0)
+   return -EINVAL;
+
+   return i915_user_extensions(u64_to_user_ptr(args->cliprects_ptr),
+   execbuf_extensions,
+   ARRAY_SIZE(execbuf_extensions),
+   eb);
+}
+
 static int
 i915_gem_do_execbuffer(struct drm_device *dev,
   struct drm_file *file,
@@ -2488,6 +2521,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (args->flags & I915_EXEC_IS_PINNED)
eb.batch_flags |= I915_DISPATCH_PINNED;
 
+   err = parse_execbuf2_extensions(args, &eb);
+   if (err)
+   return err;
+
if (args->flags & I915_EXEC_FENCE_IN) {
in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
if (!in_fence)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 469dc512cca3..0a99c26730e1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1007,6 +1007,10 @@ struct drm_i915_gem_exec_fence {
__u32 flags;
 };
 
+enum drm_i915_gem_execbuffer_ext {
+   DRM_I915_GEM_EXECBUFFER_EXT_MAX /* non-ABI */
+};
+
 struct drm_i915_gem_execbuffer2 {
/**
 * List of gem_exec_object2 structs
@@ -1023,8 +1027,15 @@ struct drm_i915_gem_execbuffer2 {
__u32 num_cliprects;
/**
 * This is a struct drm_clip_rect *cliprects if I915_EXEC_FENCE_ARRAY
-* is not set.  If I915_EXEC_FENCE_ARRAY is set, then this is a
-* struct drm_i915_gem_exec_fence *fences.
+* & I915_EXEC_USE_EXTENSIONS are not set.
+*
+* If I915_EXEC_FENCE_ARRAY is set, then this is a pointer to an array
+* of struct drm_i915_gem_exec_fence and num_cliprects is the length
+* of the array.
+*
+* If I915_EXEC_USE_EXTENSIONS is set, then this is a pointer to a
+* single struct drm_i915_gem_base_execbuffer_ext and num_cliprects is
+* 0.
 */
__u64 cliprects_ptr;
 #define I915_EXEC_RING_MASK  (0x3f)
@@ -1142,7 +1153,16 @@ struct drm_i915_gem_execbuffer2 {
  */
 #define I915_EXEC_FENCE_SUBMIT (1 << 20)
 
-#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SUBMIT << 1))
+/*
+ * Setting I915_EXEC_USE_EXTENSIONS implies that
+ * drm_i915_gem_execbuffer2.cliprects_ptr is treated as a pointer to an linked
+ * list of i915_user_extension. Each i915_user_extension node is the base of a
+ * larger structure. The list of supported structures are listed in the
+ * drm_i915_gem_execbuffer_ext enum.
+ */
+#defi

[Intel-gfx] [PATCH v13 05/11] drm/i915/perf: introduce a versioning of the i915-perf uapi

2019-09-02 Thread Lionel Landwerlin
Reporting this version will help application figure out what level of
the support the running kernel provides.

v2: Add i915_perf_ioctl_version() (Chris)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_getparam.c |  4 
 drivers/gpu/drm/i915/i915_perf.c | 10 ++
 drivers/gpu/drm/i915/i915_perf.h |  1 +
 include/uapi/drm/i915_drm.h  | 20 
 4 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index da6faa84e5b8..bd41cc5ce906 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,7 @@
 #include "gt/intel_engine_user.h"
 
 #include "i915_drv.h"
+#include "i915_perf.h"
 
 int i915_getparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -157,6 +158,9 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
case I915_PARAM_MMAP_GTT_COHERENT:
value = INTEL_INFO(i915)->has_coherent_ggtt;
break;
+   case I915_PARAM_PERF_REVISION:
+   value = i915_perf_ioctl_version();
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9d5a3522aa35..40a1ec2bc96b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3697,3 +3697,13 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
 
dev_priv->perf.initialized = false;
 }
+
+/**
+ * i915_perf_ioctl_version - Version of the i915-perf subsystem
+ *
+ * This version number is used by userspace to detect available features.
+ */
+int i915_perf_ioctl_version(void)
+{
+   return 1;
+}
diff --git a/drivers/gpu/drm/i915/i915_perf.h b/drivers/gpu/drm/i915/i915_perf.h
index a412b16d9ffc..95549de65212 100644
--- a/drivers/gpu/drm/i915/i915_perf.h
+++ b/drivers/gpu/drm/i915/i915_perf.h
@@ -18,6 +18,7 @@ void i915_perf_init(struct drm_i915_private *i915);
 void i915_perf_fini(struct drm_i915_private *i915);
 void i915_perf_register(struct drm_i915_private *i915);
 void i915_perf_unregister(struct drm_i915_private *i915);
+int i915_perf_ioctl_version(void);
 
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3d031e81648b..e98c9a7baa91 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -618,6 +618,12 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_HAS_EXEC_TIMELINE_FENCES 54
 
+/*
+ * Revision of the i915-perf uAPI. The value returned helps determine what
+ * i915-perf features are available. See drm_i915_perf_property_id.
+ */
+#define I915_PARAM_PERF_REVISION   55
+
 /* Must be kept compact -- no holes and well documented */
 
 typedef struct drm_i915_getparam {
@@ -1903,23 +1909,31 @@ enum drm_i915_perf_property_id {
 * Open the stream for a specific context handle (as used with
 * execbuffer2). A stream opened for a specific context this way
 * won't typically require root privileges.
+*
+* This property is available in perf revision 1.
 */
DRM_I915_PERF_PROP_CTX_HANDLE = 1,
 
/**
 * A value of 1 requests the inclusion of raw OA unit reports as
 * part of stream samples.
+*
+* This property is available in perf revision 1.
 */
DRM_I915_PERF_PROP_SAMPLE_OA,
 
/**
 * The value specifies which set of OA unit metrics should be
 * be configured, defining the contents of any OA unit reports.
+*
+* This property is available in perf revision 1.
 */
DRM_I915_PERF_PROP_OA_METRICS_SET,
 
/**
 * The value specifies the size and layout of OA unit reports.
+*
+* This property is available in perf revision 1.
 */
DRM_I915_PERF_PROP_OA_FORMAT,
 
@@ -1929,6 +1943,8 @@ enum drm_i915_perf_property_id {
 * from this exponent as follows:
 *
 *   80ns * 2^(period_exponent + 1)
+*
+* This property is available in perf revision 1.
 */
DRM_I915_PERF_PROP_OA_EXPONENT,
 
@@ -1960,6 +1976,8 @@ struct drm_i915_perf_open_param {
  * to close and re-open a stream with the same configuration.
  *
  * It's undefined whether any pending data for the stream will be lost.
+ *
+ * This ioctl is available in perf revision 1.
  */
 #define I915_PERF_IOCTL_ENABLE _IO('i', 0x0)
 
@@ -1967,6 +1985,8 @@ struct drm_i915_perf_open_param {
  * Disable data capture for a stream.
  *
  * It is an error to try and read a stream that is disabled.
+ *
+ * This ioctl is available in perf revision 1.
  */
 #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1

[Intel-gfx] [PATCH v13 03/11] drm/i915/perf: drop list of streams

2019-09-02 Thread Lionel Landwerlin
At some point in time there was the idea that we could have multiple
stream from the same piece of HW but that never materialized and given
the hard time we already have making everything work with the
submission side, there is no real point having this list of 1 element
around.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  6 --
 drivers/gpu/drm/i915/i915_perf.c | 16 +---
 2 files changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db7480831e52..75607450ba00 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1082,11 +1082,6 @@ struct i915_perf_stream {
 */
struct drm_i915_private *dev_priv;
 
-   /**
-* @link: Links the stream into ``&drm_i915_private->streams``
-*/
-   struct list_head link;
-
/**
 * @wakeref: As we keep the device awake while the perf stream is
 * active, we track our runtime pm reference for later release.
@@ -1671,7 +1666,6 @@ struct drm_i915_private {
 * except exclusive_stream.
 */
struct mutex lock;
-   struct list_head streams;
 
/*
 * The stream currently using the OA unit. If accessed
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c1b764233761..d18cd332afb7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1435,9 +1435,6 @@ static void gen7_init_oa_buffer(struct i915_perf_stream 
*stream)
 */
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
 
-   /* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
stream->pollin = false;
 }
 
@@ -1494,10 +1491,6 @@ static void gen8_init_oa_buffer(struct i915_perf_stream 
*stream)
 */
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
 
-   /*
-* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
stream->pollin = false;
 }
 
@@ -2633,8 +2626,6 @@ static void i915_perf_destroy_locked(struct 
i915_perf_stream *stream)
if (stream->ops->destroy)
stream->ops->destroy(stream);
 
-   list_del(&stream->link);
-
if (stream->ctx)
i915_gem_context_put(stream->ctx);
 
@@ -2783,8 +2774,6 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
goto err_flags;
}
 
-   list_add(&stream->link, &dev_priv->perf.streams);
-
if (param->flags & I915_PERF_FLAG_FD_CLOEXEC)
f_flags |= O_CLOEXEC;
if (param->flags & I915_PERF_FLAG_FD_NONBLOCK)
@@ -2793,7 +2782,7 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
stream_fd = anon_inode_getfd("[i915_perf]", &fops, stream, f_flags);
if (stream_fd < 0) {
ret = stream_fd;
-   goto err_open;
+   goto err_flags;
}
 
if (!(param->flags & I915_PERF_FLAG_DISABLED))
@@ -2806,8 +2795,6 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
 
return stream_fd;
 
-err_open:
-   list_del(&stream->link);
 err_flags:
if (stream->ops->destroy)
stream->ops->destroy(stream);
@@ -3643,7 +3630,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
}
 
if (dev_priv->perf.ops.enable_metric_set) {
-   INIT_LIST_HEAD(&dev_priv->perf.streams);
mutex_init(&dev_priv->perf.lock);
 
oa_sample_rate_hard_limit = 1000 *
-- 
2.23.0

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

[Intel-gfx] [PATCH v13 09/11] drm/i915: add a new perf configuration execbuf parameter

2019-09-02 Thread Lionel Landwerlin
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process making the execbuf with this flag to
also own the perf fd at the time of execbuf.

v2: Add a emit_oa_config() vfunc in the intel_engine_cs (Chris)
Move oa_config vma to active (Chris)

v3: Don't drop the lock for engine lookup (Chris)
Move OA config vma to active before writing the ringbuffer (Chris)

v4: Reuse i915_user_extension_fn
Serialize requests with OA config updates

v5: Check that the chained extension is only present once (Chris)
Unpin oa_vma in main path (Chris)

v6: Use BIT_ULL (Chris)

v7: Hold drm.struct_mutex when serializing the request with OA config (Chris)

v8: Remove active request from engine (Lionel)

v9: Move fetching OA configuration pass engine pinning (Lionel)
Lock VMA before moving to active (Chris)

Signed-off-by: Lionel Landwerlin 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 146 +-
 drivers/gpu/drm/i915/i915_getparam.c  |   4 +
 include/uapi/drm/i915_drm.h   |  39 +
 3 files changed, 188 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 46ad8d9642d1..17857cf31baf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -24,6 +24,7 @@
 #include "i915_gem_clflush.h"
 #include "i915_gem_context.h"
 #include "i915_gem_ioctls.h"
+#include "i915_perf.h"
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
 
@@ -284,7 +285,12 @@ struct i915_execbuffer {
struct {
u64 flags; /** Available extensions parameters */
struct drm_i915_gem_execbuffer_ext_timeline_fences 
timeline_fences;
+   struct drm_i915_gem_execbuffer_ext_perf perf_config;
} extensions;
+
+   struct file *perf_file;
+   struct i915_oa_config *oa_config; /** HW configuration for OA, NULL is 
not needed. */
+   struct i915_vma *oa_vma;
 };
 
 #define exec_entry(EB, VMA) (&(EB)->exec[(VMA)->exec_flags - (EB)->flags])
@@ -1152,6 +1158,58 @@ static int reloc_move_to_gpu(struct i915_request *rq, 
struct i915_vma *vma)
return err;
 }
 
+
+static int
+get_execbuf_oa_config(struct i915_execbuffer *eb)
+{
+   struct drm_i915_gem_object *oa_bo;
+   int err = 0;
+
+   eb->perf_file = NULL;
+   eb->oa_config = NULL;
+   eb->oa_vma = NULL;
+
+   if ((eb->extensions.flags & BIT_ULL(DRM_I915_GEM_EXECBUFFER_EXT_PERF)) 
== 0)
+   return 0;
+
+   eb->perf_file = fget(eb->extensions.perf_config.perf_fd);
+   if (!eb->perf_file)
+   return -EINVAL;
+
+   err = i915_mutex_lock_interruptible(&eb->i915->drm);
+   if (err)
+   return err;
+
+   if (eb->perf_file->private_data != eb->i915->perf.exclusive_stream)
+   err = -EINVAL;
+
+   mutex_unlock(&eb->i915->drm.struct_mutex);
+
+   if (err)
+   return err;
+
+   if (eb->i915->perf.exclusive_stream->engine != eb->engine)
+   return -EINVAL;
+
+   err = i915_perf_get_oa_config_and_bo(
+   eb->i915->perf.exclusive_stream,
+   eb->extensions.perf_config.oa_config,
+   &eb->oa_config, &oa_bo);
+   if (err)
+   return err;
+
+   eb->oa_vma = i915_vma_instance(oa_bo,
+  &eb->engine->gt->ggtt->vm, NULL);
+   i915_gem_object_put(oa_bo);
+   if (IS_ERR(eb->oa_vma)) {
+   err = PTR_ERR(eb->oa_vma);
+   eb->oa_vma = NULL;
+   return err;
+   }
+
+   return 0;
+}
+
 static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
 struct i915_vma *vma,
 unsigned int len)
@@ -2051,6 +2109,54 @@ add_to_client(struct i915_request *rq, struct drm_file 
*file)
spin_unlock(&file_priv->mm.lock);
 }
 
+static int eb_oa_config(struct i915_execbuffer *eb)
+{
+   struct i915_perf_stream *perf_stream;
+   int err;
+
+   if (!eb->oa_config)
+   return 0;
+
+   perf_stream = eb->perf_file->private_data;
+
+   err = mutex_lock_interruptible(&perf_stream->config_mutex);
+   if (err)
+   return err;
+
+   err = i915_active_request_set(&perf_stream->active_config_rq,
+ eb->request);
+   if (err)
+   goto out;
+
+   /*
+* If the config hasn't changed, skip reconfiguring the HW (this is
+* subject to a delay we want to avoid has much as possible).
+*/
+   if (eb->oa_config == perf_stream->oa_config)
+   goto out;
+
+   i915_vma_lock(eb->oa_vma);
+

[Intel-gfx] [PATCH v13 06/11] drm/i915/perf: allow for CS OA configs to be created lazily

2019-09-02 Thread Lionel Landwerlin
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.

We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particular user batchbuffer be
executed with a given OA configuration.

This mechanism essentially allows the userspace driver to go through
several OA configuration without having to open/close the i915/perf
stream.

v2: No need for locking on object OA config object creation (Chris)
Flush cpu mapping of OA config (Chris)

v3: Properly deal with the perf_metric lock (Chris/Lionel)

v4: Fix oa config unref/put when not found (Lionel)

v5: Allocate BOs for configurations on the stream instead of globally
(Lionel)

v6: Fix 64bit division (Chris)

v7: Store allocated config BOs into the stream (Lionel)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson  (v4)
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   1 +
 drivers/gpu/drm/i915/i915_drv.h  |  19 +-
 drivers/gpu/drm/i915/i915_perf.c | 270 ---
 drivers/gpu/drm/i915/i915_perf.h |  26 ++
 4 files changed, 274 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 86e00a2db8a4..a7f1377a54a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -133,6 +133,7 @@
  */
 #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
 #define   MI_LRI_FORCE_POSTED  (1<<12)
+#define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
 #define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)
 #define MI_STORE_REGISTER_MEM_GEN8   MI_INSTR(0x24, 2)
 #define   MI_SRM_LRM_GLOBAL_GTT(1<<22)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 274a1193d4f0..c0ff6f0fd33e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -990,6 +990,8 @@ struct i915_oa_reg {
 };
 
 struct i915_oa_config {
+   struct drm_i915_private *i915;
+
char uuid[UUID_STRING_LEN + 1];
int id;
 
@@ -1004,7 +1006,7 @@ struct i915_oa_config {
struct attribute *attrs[2];
struct device_attribute sysfs_metric_id;
 
-   atomic_t ref_count;
+   struct kref ref;
 };
 
 struct i915_perf_stream;
@@ -1126,11 +1128,22 @@ struct i915_perf_stream {
 */
const struct i915_perf_stream_ops *ops;
 
+   /**
+* @active_config_mutex: Protects access to @oa_config & @oa_config_bos.
+*/
+   struct mutex config_mutex;
+
/**
 * @oa_config: The OA configuration used by the stream.
 */
struct i915_oa_config *oa_config;
 
+   /**
+* @oa_config_bos: A list of struct i915_oa_config_bo allocated lazily
+* each time @oa_config changes.
+*/
+   struct list_head oa_config_bos;
+
/**
 * The OA context specific information.
 */
@@ -1661,8 +1674,8 @@ struct drm_i915_private {
struct mutex metrics_lock;
 
/*
-* List of dynamic configurations, you need to hold
-* dev_priv->perf.metrics_lock to access it.
+* List of dynamic configurations (struct i915_oa_config), you
+* need to hold dev_priv->perf.metrics_lock to access it.
 */
struct idr metrics_idr;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 40a1ec2bc96b..f9d946f7a79d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -367,11 +367,19 @@ struct perf_open_properties {
struct intel_engine_cs *engine;
 };
 
+struct i915_oa_config_bo {
+   struct list_head link;
+
+   struct i915_oa_config *oa_config;
+   struct drm_i915_gem_object *bo;
+};
+
 static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer);
 
-static void free_oa_config(struct drm_i915_private *dev_priv,
-  struct i915_oa_config *oa_config)
+void i915_oa_config_release(struct kref *ref)
 {
+   struct i915_oa_config *oa_config = container_of(ref, 
typeof(*oa_config), ref);
+
if (!PTR_ERR(oa_config->flex_regs))
kfree(oa_config->flex_regs);
if (!PTR_ERR(oa_config->b_counter_regs))
@@ -381,40 +389,194 @@ static void free_oa_config(struct drm_i915_private 
*dev_priv,
kfree(oa_config);
 }
 
-static void put_oa_config(struct drm_i915_private *dev_priv,
- struct i915_oa_config *oa_config)
+static u32 *write_cs_mi_lri(u32 *cs, const struct i915_oa_reg *reg_data, u32 
n_regs)
 {
-   if (!atomic_dec_and_test(&oa_config->ref_count))
-   return;
+   u32 i;
+
+   for (i = 0; i < n_regs; i++) {
+   if ((i % MI_LOAD_REGISTER_IMM_MAX_REGS)

[Intel-gfx] [PATCH v13 08/11] drm/i915/perf: execute OA configuration from command stream

2019-09-02 Thread Lionel Landwerlin
We haven't run into issues with programming the global OA/NOA
registers configuration from CPU so far, but HW engineers actually
recommend doing this from the command streamer. On TGL in particular
one of the clock domain in which some of that programming goes might
not be powered when we poke things from the CPU.

Since we have a command buffer prepared for the execbuffer side of
things, we can reuse that approach here too.

This also allows us to significantly reduce the amount of time we hold
the main lock.

v2: Drop the global lock as much as possible

v3: Take global lock to pin global

v4: Create i915 request in emit_oa_config() to avoid deadlocks (Lionel)

v5: Move locking to the stream (Lionel)

v6: Move active reconfiguration request into i915_perf_stream (Lionel)

v7: Pin VMA outside request creation (Chris)
Lock VMA before move to active (Chris)

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  13 ++-
 drivers/gpu/drm/i915/i915_perf.c | 170 ---
 2 files changed, 122 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 20b6a7023097..084cdd115d5a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1129,7 +1129,8 @@ struct i915_perf_stream {
const struct i915_perf_stream_ops *ops;
 
/**
-* @active_config_mutex: Protects access to @oa_config & @oa_config_bos.
+* @active_config_mutex: Protects access to @active_config_rq,
+* @oa_config & @oa_config_bos.
 */
struct mutex config_mutex;
 
@@ -1144,6 +1145,16 @@ struct i915_perf_stream {
 */
struct list_head oa_config_bos;
 
+   /**
+* @active_config_rq: Last request reconfiguring the HW.
+*/
+   struct i915_active_request active_config_rq;
+
+   /**
+* @initial_oa_config_bo: First OA configuration BO to be run.
+*/
+   struct drm_i915_gem_object *initial_oa_config_bo;
+
/**
 * The OA context specific information.
 */
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 74261f2e7480..8e811bcbd679 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1558,18 +1558,23 @@ free_oa_configs(struct i915_perf_stream *stream)
 static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
 {
struct drm_i915_private *dev_priv = stream->dev_priv;
+   int err;
 
BUG_ON(stream != dev_priv->perf.exclusive_stream);
 
-   /*
-* Unset exclusive_stream first, it will be checked while disabling
-* the metric set on gen8+.
-*/
mutex_lock(&dev_priv->drm.struct_mutex);
-   dev_priv->perf.exclusive_stream = NULL;
+   mutex_lock(&stream->config_mutex);
dev_priv->perf.ops.disable_metric_set(stream);
+   err = i915_active_request_retire(&stream->active_config_rq,
+&stream->config_mutex);
+   mutex_unlock(&stream->config_mutex);
+   dev_priv->perf.exclusive_stream = NULL;
mutex_unlock(&dev_priv->drm.struct_mutex);
 
+   if (err)
+   DRM_ERROR("Failed to disable perf stream\n");
+
+
free_oa_buffer(stream);
free_noa_wait(stream);
 
@@ -1795,6 +1800,10 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
return PTR_ERR(bo);
}
 
+   ret = i915_mutex_lock_interruptible(&i915->drm);
+   if (ret)
+   goto err_unref;
+
/*
 * We pin in GGTT because we jump into this buffer now because
 * multiple OA config BOs will have a jump to this address and it
@@ -1802,10 +1811,13 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
 */
vma = i915_gem_object_ggtt_pin(bo, NULL, 0, 4096, 0);
if (IS_ERR(vma)) {
+   mutex_unlock(&i915->drm.struct_mutex);
ret = PTR_ERR(vma);
goto err_unref;
}
 
+   mutex_unlock(&i915->drm.struct_mutex);
+
batch = cs = i915_gem_object_pin_map(bo, I915_MAP_WB);
if (IS_ERR(batch)) {
ret = PTR_ERR(batch);
@@ -1939,7 +1951,9 @@ static int alloc_noa_wait(struct i915_perf_stream *stream)
return 0;
 
 err_unpin:
-   __i915_vma_unpin(vma);
+   mutex_lock(&i915->drm.struct_mutex);
+   i915_vma_unpin_and_release(&vma, 0);
+   mutex_unlock(&i915->drm.struct_mutex);
 
 err_unref:
i915_gem_object_put(bo);
@@ -1947,50 +1961,73 @@ static int alloc_noa_wait(struct i915_perf_stream 
*stream)
return ret;
 }
 
-static void config_oa_regs(struct drm_i915_private *dev_priv,
-  const struct i915_oa_reg *regs,
-  u32 n_regs)
+static int emit_oa_config(struct drm_i915_private *i915,
+ struct i915_perf_stream *stream)
 {
-   u32 i;
+   struct i915_request

[Intel-gfx] [PATCH v13 04/11] drm/i915/perf: store the associated engine of a stream

2019-09-02 Thread Lionel Landwerlin
We'll use this information later to verify that a client trying to
reconfigure the stream does so on the right engine.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h  | 5 +
 drivers/gpu/drm/i915/i915_perf.c | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 75607450ba00..274a1193d4f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1088,6 +1088,11 @@ struct i915_perf_stream {
 */
intel_wakeref_t wakeref;
 
+   /**
+* @engine: Engine associated with this performance stream.
+*/
+   struct intel_engine_cs *engine;
+
/**
 * @sample_flags: Flags representing the `DRM_I915_PERF_PROP_SAMPLE_*`
 * properties given when opening a stream, representing the contents
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d18cd332afb7..9d5a3522aa35 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -363,6 +363,8 @@ struct perf_open_properties {
int oa_format;
bool oa_periodic;
int oa_period_exponent;
+
+   struct intel_engine_cs *engine;
 };
 
 static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer);
@@ -2201,6 +2203,8 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
 
format_size = dev_priv->perf.oa_formats[props->oa_format].size;
 
+   stream->engine = props->engine;
+
stream->sample_flags |= SAMPLE_OA_REPORT;
stream->sample_size += format_size;
 
@@ -2843,6 +2847,9 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}
 
+   /* At the moment we only support using i915-perf on the RCS. */
+   props->engine = dev_priv->engine[RCS0];
+
/* Considering that ID = 0 is reserved and assuming that we don't
 * (currently) expect any configurations to ever specify duplicate
 * values for a particular property ID then the last _PROP_MAX value is
-- 
2.23.0

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

[Intel-gfx] [PATCH v13 11/11] drm/i915: add support for perf configuration queries

2019-09-02 Thread Lionel Landwerlin
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.

This change adds a way to query the number of configurations and their
content through the i915 query uAPI.

v2: Fix sparse warnings (Lionel)
Add support to query configuration using uuid (Lionel)

v3: Fix some inconsistency in uapi header (Lionel)
Fix unlocking when not locked issue (Lionel)
Add debug messages (Lionel)

v4: Fix missing unlock (Dan)

v5: Drop lock when copying config content to userspace (Chris)

v6: Drop lock when copying config list to userspace (Chris)
Fix deadlock when calling i915_perf_get_oa_config() under
perf.metrics_lock (Lionel)
Add i915_oa_config_get() (Chris)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   |   6 +
 drivers/gpu/drm/i915/i915_perf.c  |   3 +
 drivers/gpu/drm/i915/i915_query.c | 283 ++
 include/uapi/drm/i915_drm.h   |  65 ++-
 4 files changed, 354 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d18e12ada4e1..04d538dcc3c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1704,6 +1704,12 @@ struct drm_i915_private {
 */
struct idr metrics_idr;
 
+   /*
+* Number of dynamic configurations, you need to hold
+* dev_priv->perf.metrics_lock to access it.
+*/
+   u32 n_metrics;
+
/*
 * Lock associated with anything below within this structure
 * except exclusive_stream.
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3a2b78b2d2ec..d3d14f2a7595 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3917,6 +3917,8 @@ int i915_perf_add_config_ioctl(struct drm_device *dev, 
void *data,
goto sysfs_err;
}
 
+   dev_priv->perf.n_metrics++;
+
mutex_unlock(&dev_priv->perf.metrics_lock);
 
DRM_DEBUG("Added config %s id=%i\n", oa_config->uuid, oa_config->id);
@@ -3977,6 +3979,7 @@ int i915_perf_remove_config_ioctl(struct drm_device *dev, 
void *data,
   &oa_config->sysfs_metric);
 
idr_remove(&dev_priv->perf.metrics_idr, *arg);
+   dev_priv->perf.n_metrics--;
 
mutex_unlock(&dev_priv->perf.metrics_lock);
 
diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index abac5042da2b..89b2821be4a0 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -7,6 +7,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "i915_perf.h"
 #include "i915_query.h"
 #include 
 
@@ -140,10 +141,292 @@ query_engine_info(struct drm_i915_private *i915,
return len;
 }
 
+static int can_copy_perf_config_registers_or_number(u32 user_n_regs,
+   u64 user_regs_ptr,
+   u32 kernel_n_regs)
+{
+   /*
+* We'll just put the number of registers, and won't copy the
+* register.
+*/
+   if (user_n_regs == 0)
+   return 0;
+
+   if (user_n_regs < kernel_n_regs)
+   return -EINVAL;
+
+   if (!access_ok(u64_to_user_ptr(user_regs_ptr),
+  2 * sizeof(u32) * kernel_n_regs))
+   return -EFAULT;
+
+   return 0;
+}
+
+static int copy_perf_config_registers_or_number(const struct i915_oa_reg 
*kernel_regs,
+   u32 kernel_n_regs,
+   u64 user_regs_ptr,
+   u32 *user_n_regs)
+{
+   u32 r;
+
+   if (*user_n_regs == 0) {
+   *user_n_regs = kernel_n_regs;
+   return 0;
+   }
+
+   *user_n_regs = kernel_n_regs;
+
+   for (r = 0; r < kernel_n_regs; r++) {
+   u32 __user *user_reg_ptr =
+   u64_to_user_ptr(user_regs_ptr + sizeof(u32) * r * 2);
+   u32 __user *user_val_ptr =
+   u64_to_user_ptr(user_regs_ptr + sizeof(u32) * r * 2 +
+   sizeof(u32));
+   int ret;
+
+   ret = __put_user(i915_mmio_reg_offset(kernel_regs[r].addr),
+user_reg_ptr);
+   if (ret)
+   return -EFAULT;
+
+   ret = __put_user(kernel_regs[r].value, user_val_ptr);
+   if (ret)
+   return -EFAULT;
+   }
+
+   return 0;
+}
+
+static int query_perf_config_data(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item,
+ b

[Intel-gfx] [PATCH v13 07/11] drm/i915/perf: implement active wait for noa configurations

2019-09-02 Thread Lionel Landwerlin
NOA configuration take some amount of time to apply. That amount of
time depends on the size of the GT. There is no documented time for
this. For example, past experimentations with powergating
configuration changes seem to indicate a 60~70us delay. We go with
500us as default for now which should be over the required amount of
time (according to HW architects).

v2: Don't forget to save/restore registers used for the wait (Chris)

v3: Name used CS_GPR registers (Chris)
Fix compile issue due to rebase (Lionel)

v4: Fix save/restore helpers (Umesh)

v5: Move noa_wait from drm_i915_private to i915_perf_stream (Lionel)

v6: Add missing struct declarations in i915_perf.h

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Chris Wilson  (v4)
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  24 ++
 drivers/gpu/drm/i915/gt/intel_gt_types.h |   5 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  31 +++
 drivers/gpu/drm/i915/i915_drv.h  |   8 +
 drivers/gpu/drm/i915/i915_perf.c | 234 ++-
 drivers/gpu/drm/i915/i915_reg.h  |   4 +-
 6 files changed, 302 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index a7f1377a54a2..f133f8dbacb1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -158,6 +158,7 @@
 #define   MI_BATCH_GTT (2<<6) /* aliased with (1<<7) on gen4 */
 #define MI_BATCH_BUFFER_START_GEN8 MI_INSTR(0x31, 1)
 #define   MI_BATCH_RESOURCE_STREAMER (1<<10)
+#define   MI_BATCH_PREDICATE (1 << 15) /* HSW+ on RCS only*/
 
 /*
  * 3D instructions used by the kernel
@@ -236,6 +237,29 @@
 #define   PIPE_CONTROL_DEPTH_CACHE_FLUSH   (1<<0)
 #define   PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */
 
+#define MI_MATH(x) MI_INSTR(0x1a, (x)-1)
+#define   MI_ALU_OP(op, src1, src2) (((op) << 20) | ((src1) << 10) | (src2))
+/* operands */
+#define   MI_ALU_OP_NOOP 0
+#define   MI_ALU_OP_LOAD 128
+#define   MI_ALU_OP_LOADINV  1152
+#define   MI_ALU_OP_LOAD0129
+#define   MI_ALU_OP_LOAD11153
+#define   MI_ALU_OP_ADD  256
+#define   MI_ALU_OP_SUB  257
+#define   MI_ALU_OP_AND  258
+#define   MI_ALU_OP_OR   259
+#define   MI_ALU_OP_XOR  260
+#define   MI_ALU_OP_STORE384
+#define   MI_ALU_OP_STOREINV 1408
+/* sources */
+#define   MI_ALU_SRC_REG(x)  (x) /* 0 -> 15 */
+#define   MI_ALU_SRC_SRCA32
+#define   MI_ALU_SRC_SRCB33
+#define   MI_ALU_SRC_ACCU49
+#define   MI_ALU_SRC_ZF  50
+#define   MI_ALU_SRC_CF  51
+
 /*
  * Commands used only by the command parser
  */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index dc295c196d11..f752b6cf9ea1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -97,6 +97,11 @@ enum intel_gt_scratch_field {
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
 
+   /* 6 * 8 bytes */
+   INTEL_GT_SCRATCH_FIELD_PERF_CS_GPR = 2048,
+
+   /* 4 bytes */
+   INTEL_GT_SCRATCH_FIELD_PERF_PREDICATE_RESULT_1 = 2096,
 };
 
 #endif /* __INTEL_GT_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5e81c4fc13ae..4234bf133903 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3577,6 +3577,36 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_wedged_fops,
i915_wedged_get, i915_wedged_set,
"%llu\n");
 
+static int
+i915_perf_noa_delay_set(void *data, u64 val)
+{
+   struct drm_i915_private *i915 = data;
+
+   /* This would lead to infinite waits as we're doing timestamp
+* difference on the CS with only 32bits.
+*/
+   if (val > mul_u32_u32(U32_MAX, 
RUNTIME_INFO(i915)->cs_timestamp_frequency_khz))
+   return -EINVAL;
+
+   atomic64_set(&i915->perf.noa_programming_delay, val);
+   return 0;
+}
+
+static int
+i915_perf_noa_delay_get(void *data, u64 *val)
+{
+   struct drm_i915_private *i915 = data;
+
+   *val = atomic64_read(&i915->perf.noa_programming_delay);
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_perf_noa_delay_fops,
+   i915_perf_noa_delay_get,
+   i915_perf_noa_delay_set,
+   "%llu\n");
+
+
 #define DROP_UNBOUND   BIT(0)
 #define DROP_BOUND BIT(1)
 #define DROP_RETIREBIT(2)
@@ -4353,6 +4383,7 @@ static const struct i915_debugfs_files {
const char *name;
const struct file_operations *fops;
 } i915_debugfs_files[] = {
+   {"i915_perf_noa_delay", &i915_perf_noa_delay_fops},
{"i915_wedged", &i915_wedged_fops},
{"i915_cache_sharing", &i915_cache_sharing_fops},
{"i915_gem_drop_caches", &i915_drop_caches_fops},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i9

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Vulkan performance query support (rev14)

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Vulkan performance query support (rev14)
URL   : https://patchwork.freedesktop.org/series/60916/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  AR  drivers/gpu/drm/i915/built-in.a
  CC  drivers/gpu/drm/i915/i915_gpu_error.h.s
  CC  drivers/gpu/drm/i915/i915_utils.h.s
  CC  drivers/gpu/drm/i915/i915_sw_fence.h.s
  CC  drivers/gpu/drm/i915/i915_query.h.s
  CC  drivers/gpu/drm/i915/i915_gem_gtt.h.s
  CC  drivers/gpu/drm/i915/i915_debugfs.h.s
  CC  drivers/gpu/drm/i915/intel_wakeref.h.s
  CC  drivers/gpu/drm/i915/intel_pch.h.s
  CC  drivers/gpu/drm/i915/intel_csr.h.s
  CC  drivers/gpu/drm/i915/intel_device_info.h.s
  CC  drivers/gpu/drm/i915/i915_syncmap.h.s
  CC  drivers/gpu/drm/i915/i915_request.h.s
  CC  drivers/gpu/drm/i915/i915_vma.h.s
  CC  drivers/gpu/drm/i915/i915_selftest.h.s
  CC  drivers/gpu/drm/i915/i915_irq.h.s
  CC  drivers/gpu/drm/i915/i915_active_types.h.s
  CC  drivers/gpu/drm/i915/i915_perf.h.s
In file included from :0:0:
./drivers/gpu/drm/i915/i915_perf.h: In function ‘i915_oa_config_get’:
./drivers/gpu/drm/i915/i915_perf.h:47:21: error: dereferencing pointer to 
incomplete type ‘struct i915_oa_config’
  kref_get(&oa_config->ref);
 ^~
scripts/Makefile.build:308: recipe for target 
'drivers/gpu/drm/i915/i915_perf.h.s' failed
make[4]: *** [drivers/gpu/drm/i915/i915_perf.h.s] Error 1
scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:497: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1083: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH 2/2] drm/edid: Have cea_db_offsets() zero start/end when the data block collection isn't found

2019-09-02 Thread Ville Syrjala
From: Ville Syrjälä 

Let's make cea_db_offsets() a bit more convenient to use by
setting the start/end offsets to zero whenever the data block
collection isn't present. This makes it safe for the caller
to blindly iterate the data blocks even if there are none.

Cc: Jean Delvare 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7b3072fc550b..e5905dc764c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
 static int
 cea_db_offsets(const u8 *cea, int *start, int *end)
 {
+   *start = 0;
+   *end = 0;
+
if (cea_revision(cea) < 3)
return -ENOTSUPP;
 
@@ -4116,10 +4119,7 @@ static void drm_edid_to_eld(struct drm_connector 
*connector, struct edid *edid)
if (cea_revision(cea) >= 3) {
int i, start, end;
 
-   if (cea_db_offsets(cea, &start, &end)) {
-   start = 0;
-   end = 0;
-   }
+   cea_db_offsets(cea, &start, &end);
 
for_each_cea_db(cea, i, start, end) {
db = &cea[i];
-- 
2.21.0

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

[Intel-gfx] [PATCH 1/2] drm/edid: Don't look for CEA data blocks in CEA ext block rev < 3

2019-09-02 Thread Ville Syrjala
From: Ville Syrjälä 

CEA ext block revisions 1 and 2 do not contain the data block
collection. Instead that section of the extension block is
marked as reserved for 8 byte timing descriptors. Revision 3
changed it to contain the CEA data block collection instead.

Most places that iterate the data blocks already check for
revision >= 3, but drm_detect_hdmi_monitor() and
drm_detect_monitor_audio() do not. So in theory when encountering
rev 1 or 2 CEA extension block they could end up misinterpreting
whatever data is in the reserved section as CEA data blocks.

Let's have cea_db_offsets() do the revision check so that the
callers don't even have worry about it.

Cc: Jean Delvare 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 82a4ceed3fcf..7b3072fc550b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
 static int
 cea_db_offsets(const u8 *cea, int *start, int *end)
 {
+   if (cea_revision(cea) < 3)
+   return -ENOTSUPP;
+
/* DisplayID CTA extension blocks and top-level CEA EDID
 * block header definitions differ in the following bytes:
 *   1) Byte 2 of the header specifies length differently,
-- 
2.21.0

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

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Expand subslice mask

2019-09-02 Thread Tvrtko Ursulin


On 24/07/2019 14:05, Tvrtko Ursulin wrote:


On 23/07/2019 16:49, Stuart Summers wrote:

Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
   slice * subslice stride + subslice index / 8

Signed-off-by: Stuart Summers 
---
  drivers/gpu/drm/i915/gt/intel_sseu.c    | 26 -
  drivers/gpu/drm/i915/gt/intel_sseu.h    |  5 +++-
  drivers/gpu/drm/i915/gt/intel_workarounds.c |  3 +--
  drivers/gpu/drm/i915/i915_debugfs.c |  5 +++-
  drivers/gpu/drm/i915/intel_device_info.c    |  8 +++
  5 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c 
b/drivers/gpu/drm/i915/gt/intel_sseu.c

index 607c1447287c..7abc2487b994 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -30,6 +30,30 @@ intel_sseu_subslice_total(const struct 
sseu_dev_info *sseu)

  return total;
  }
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice)
+{
+    int i, offset = slice * sseu->ss_stride;
+    u32 mask = 0;
+
+    if (slice >= sseu->max_slices) {
+    DRM_ERROR("%s: invalid slice %d, max: %d\n",
+  __func__, slice, sseu->max_slices);
+    return 0;
+    }
+
+    if (sseu->ss_stride > sizeof(mask)) {
+    DRM_ERROR("%s: invalid subslice stride %d, max: %lu\n",
+  __func__, sseu->ss_stride, sizeof(mask));
+    return 0;
+    }
+
+    for (i = 0; i < sseu->ss_stride; i++)
+    mask |= (u32)sseu->subslice_mask[offset + i] <<
+    i * BITS_PER_BYTE;
+
+    return mask;
+}


Why do you actually need these complications when the plan from the 
start was that the driver and user sseu representation structures can be 
different?


I only gave it a quick look so I might be wrong, but why not just expand 
the driver representations of subslice mask up from u8? Userspace API 
should be able to cope with strides already.


I never got an answer to this and the series was merged in the meantime.

Maybe not much harm but I still don't understand why all the 
complications seemingly just to avoid bumping the *internal* ss mask up 
from u8. As long as the internal and abi sseu info struct are well 
separated and access point few and well controlled (I think they are) 
then I don't see why the internal side had to be converted to u8 and 
strides. But maybe I am missing something.


Regards,

Tvrtko



Regards,

Tvrtko


+
  void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
    u32 ss_mask)
  {
@@ -43,7 +67,7 @@ void intel_sseu_set_subslices(struct sseu_dev_info 
*sseu, int slice,

  unsigned int
  intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 
slice)

  {
-    return hweight8(sseu->subslice_mask[slice]);
+    return hweight32(intel_sseu_get_subslices(sseu, slice));
  }
  u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h 
b/drivers/gpu/drm/i915/gt/intel_sseu.h

index 0ecc1c35a7a1..2291764b7db5 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -15,10 +15,11 @@ struct drm_i915_private;
  #define GEN_MAX_SLICES    (6) /* CNL upper bound */
  #define GEN_MAX_SUBSLICES    (8) /* ICL upper bound */
  #define GEN_SSEU_STRIDE(max_entries) DIV_ROUND_UP(max_entries, 
BITS_PER_BYTE)

+#define GEN_MAX_SUBSLICE_STRIDE GEN_SSEU_STRIDE(GEN_MAX_SUBSLICES)
  struct sseu_dev_info {
  u8 slice_mask;
-    u8 subslice_mask[GEN_MAX_SLICES];
+    u8 subslice_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICE_STRIDE];
  u16 eu_total;
  u8 eu_per_subslice;
  u8 min_eu_in_pool;
@@ -85,6 +86,8 @@ intel_sseu_subslice_total(const struct sseu_dev_info 
*sseu);

  unsigned int
  intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 
slice);
+u32  intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 
slice);

+
  void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
    u32 ss_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c

index 704ace01e7f5..7ec60435d871 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -794,8 +794,7 @@ wa_init_mcr(struct drm_i915_private *i915, struct 
i915_wa_list *wal)

  }
  slice = fls(sseu->slice_mask) - 1;
-    GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
-    subslice = fls(l3_en & sseu->subslice_mask[slice]);
+    subslice = fls(l3_en & intel_sseu_get_subslices(sseu, slice));
  if (!subslice) {
  DRM_WARN("No common index found between subslice mask %x and 
L3 bank mask %x!\n",

   sseu->subslice_mask[slice], l3_en);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/driver

Re: [Intel-gfx] [PATCH 09/17] drm/i915: Push the ring creation flags to the backend

2019-09-02 Thread Tvrtko Ursulin


On 05/08/2019 18:08, Andi Shyti wrote:

Hi Chris,

On Tue, Jul 30, 2019 at 02:30:27PM +0100, Chris Wilson wrote:

Push the ring creation flags from the outer GEM context to the inner
intel_cotnext to avoid an unsightly back-reference from inside the
backend.

Signed-off-by: Chris Wilson 


looks nice!

Reviewed-by: Andi Shyti 


I wish my complaints on this patch weren't just ignored.

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 09/17] drm/i915: Push the ring creation flags to the backend

2019-09-02 Thread Tvrtko Ursulin


On 30/07/2019 14:30, Chris Wilson wrote:

Push the ring creation flags from the outer GEM context to the inner
intel_cotnext to avoid an unsightly back-reference from inside the


typo


backend.


No mention of the pointer overload trick.



Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c   | 21 +++--
  .../gpu/drm/i915/gem/i915_gem_context_types.h |  3 ---
  drivers/gpu/drm/i915/gt/intel_context.c   |  1 +
  drivers/gpu/drm/i915/gt/intel_context.h   |  5 
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  2 ++
  drivers/gpu/drm/i915/gt/intel_lrc.c   |  5 ++--
  drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  2 +-
  drivers/gpu/drm/i915/gt/mock_engine.c |  9 ++--
  drivers/gpu/drm/i915/i915_debugfs.c   | 23 ---
  9 files changed, 47 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 1b3dc7258ef2..2e8cedce059f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -434,8 +434,6 @@ __create_context(struct drm_i915_private *i915)
i915_gem_context_set_bannable(ctx);
i915_gem_context_set_recoverable(ctx);
  
-	ctx->ring_size = 4 * PAGE_SIZE;

-
for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
  
@@ -565,8 +563,15 @@ i915_gem_context_create_gvt(struct drm_device *dev)

i915_gem_context_set_closed(ctx); /* not user accessible */
i915_gem_context_clear_bannable(ctx);
i915_gem_context_set_force_single_submission(ctx);
-   if (!USES_GUC_SUBMISSION(to_i915(dev)))
-   ctx->ring_size = 512 * PAGE_SIZE; /* Max ring buffer size */
+   if (!USES_GUC_SUBMISSION(to_i915(dev))) {
+   const unsigned long ring_size = 512 * SZ_4K; /* max */
+   struct i915_gem_engines_iter it;
+   struct intel_context *ce;
+
+   for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it)
+   ce->ring = __intel_context_ring_size(ring_size);
+   i915_gem_context_unlock_engines(ctx);
+   }
  
  	GEM_BUG_ON(i915_gem_context_is_kernel(ctx));

  out:
@@ -605,7 +610,6 @@ i915_gem_context_create_kernel(struct drm_i915_private 
*i915, int prio)
  
  	i915_gem_context_clear_bannable(ctx);

ctx->sched.priority = I915_USER_PRIORITY(prio);
-   ctx->ring_size = PAGE_SIZE;
  
  	GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
  
@@ -1589,6 +1593,7 @@ set_engines(struct i915_gem_context *ctx,

for (n = 0; n < num_engines; n++) {
struct i915_engine_class_instance ci;
struct intel_engine_cs *engine;
+   struct intel_context *ce;
  
  		if (copy_from_user(&ci, &user->engines[n], sizeof(ci))) {

__free_engines(set.engines, n);
@@ -1611,11 +1616,13 @@ set_engines(struct i915_gem_context *ctx,
return -ENOENT;
}
  
-		set.engines->engines[n] = intel_context_create(ctx, engine);

-   if (!set.engines->engines[n]) {
+   ce = intel_context_create(ctx, engine);
+   if (!ce) {
__free_engines(set.engines, n);
return -ENOMEM;
}
+
+   set.engines->engines[n] = ce;
}
set.engines->num_engines = num_engines;
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h

index a02d98494078..260d59cc3de8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -169,9 +169,6 @@ struct i915_gem_context {
  
  	struct i915_sched_attr sched;
  
-	/** ring_size: size for allocating the per-engine ring buffer */

-   u32 ring_size;
-
/** guilty_count: How many times this context has caused a GPU hang. */
atomic_t guilty_count;
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 34c8e37a73b8..db9236570ff5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -214,6 +214,7 @@ intel_context_init(struct intel_context *ce,
ce->engine = engine;
ce->ops = engine->cops;
ce->sseu = engine->sseu;
+   ce->ring = __intel_context_ring_size(SZ_16K);
  
  	INIT_LIST_HEAD(&ce->signal_link);

INIT_LIST_HEAD(&ce->signals);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index 07f9924de48f..13f28dd316bc 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -136,4 +136,9 @@ int intel_context_prepare_remote_request(struct 
intel_context *ce,
  
  struct i915_request *intel_context_create_request(struct 

Re: [Intel-gfx] [PATCH] drm: Add high-precision time to vblank trace event

2019-09-02 Thread Heinrich Fink
Thanks for the review, Daniel. I noticed that my last name was missing
in the initial revision (my git config was messed up). I am sending v2
of this patch to fix this, including your r/b tag.

Cheers, Heinrich


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

[Intel-gfx] [PATCH v2] drm: Add high-precision time to vblank trace event

2019-09-02 Thread Heinrich Fink
Store the timestamp of the current vblank in the new field 'time' of the
vblank trace event. If the timestamp is calculated by a driver that
supports high-precision vblank timing, set the field 'high-prec' to
'true'.

User space can now access actual hardware vblank times via the tracing
infrastructure. Tracing applications (such as GPUVis, see [0] for
related discussion), can use the newly added information to conduct a
more accurate analysis of display timing.

v2 Fix author name (missing last name)

[0] https://github.com/mikesart/gpuvis/issues/30

Reviewed-by: Daniel Vetter 
Signed-off-by: Heinrich Fink 
---
 drivers/gpu/drm/drm_trace.h  | 14 ++
 drivers/gpu/drm/drm_vblank.c |  3 ++-
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 471eb927474b..11c6dd577e8e 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -13,17 +13,23 @@ struct drm_file;
 #define TRACE_INCLUDE_FILE drm_trace
 
 TRACE_EVENT(drm_vblank_event,
-   TP_PROTO(int crtc, unsigned int seq),
-   TP_ARGS(crtc, seq),
+   TP_PROTO(int crtc, unsigned int seq, ktime_t time, bool high_prec),
+   TP_ARGS(crtc, seq, time, high_prec),
TP_STRUCT__entry(
__field(int, crtc)
__field(unsigned int, seq)
+   __field(ktime_t, time)
+   __field(bool, high_prec)
),
TP_fast_assign(
__entry->crtc = crtc;
__entry->seq = seq;
-   ),
-   TP_printk("crtc=%d, seq=%u", __entry->crtc, __entry->seq)
+   __entry->time = time;
+   __entry->high_prec = high_prec;
+   ),
+   TP_printk("crtc=%d, seq=%u, time=%lld, high-prec=%s",
+   __entry->crtc, __entry->seq, __entry->time,
+   __entry->high_prec ? "true" : "false")
 );
 
 TRACE_EVENT(drm_vblank_event_queued,
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index fd1fbc77871f..c99feda25dea 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1731,7 +1731,8 @@ static void drm_handle_vblank_events(struct drm_device 
*dev, unsigned int pipe)
send_vblank_event(dev, e, seq, now);
}
 
-   trace_drm_vblank_event(pipe, seq);
+   trace_drm_vblank_event(pipe, seq, now,
+   dev->driver->get_vblank_timestamp != NULL);
 }
 
 /**
-- 
2.23.0.rc1

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add high-precision time to vblank trace event

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm: Add high-precision time to vblank trace event
URL   : https://patchwork.freedesktop.org/series/66132/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
764d6d8263bc drm: Add high-precision time to vblank trace event
-:50: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#50: FILE: drivers/gpu/drm/drm_trace.h:31:
+   TP_printk("crtc=%d, seq=%u, time=%lld, high-prec=%s",
+   __entry->crtc, __entry->seq, __entry->time,

-:65: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#65: FILE: drivers/gpu/drm/drm_vblank.c:1735:
+   trace_drm_vblank_event(pipe, seq, now,
+   dev->driver->get_vblank_timestamp != NULL);

-:65: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written 
"dev->driver->get_vblank_timestamp"
#65: FILE: drivers/gpu/drm/drm_vblank.c:1735:
+   dev->driver->get_vblank_timestamp != NULL);

total: 0 errors, 0 warnings, 3 checks, 36 lines checked

___
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/edid: Don't look for CEA data blocks in CEA ext block rev < 3

2019-09-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/edid: Don't look for CEA data blocks in 
CEA ext block rev < 3
URL   : https://patchwork.freedesktop.org/series/66131/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6820 -> Patchwork_14257


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/

Known issues


  Here are the changes found in Patchwork_14257 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u2:  [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#108569])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-icl-u2/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2:  [PASS][3] -> [FAIL][4] ([fdo#109483])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html

  
 Possible fixes 

  * igt@gem_basic@create-close:
- fi-icl-u3:  [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u3/igt@gem_ba...@create-close.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-icl-u3/igt@gem_ba...@create-close.html

  * igt@gem_close_race@basic-threads:
- fi-bxt-dsi: [INCOMPLETE][7] ([fdo#103927]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-bxt-dsi/igt@gem_close_r...@basic-threads.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-bxt-dsi/igt@gem_close_r...@basic-threads.html

  * igt@i915_module_load@reload:
- fi-icl-u3:  [DMESG-WARN][9] ([fdo#107724] / [fdo#111214]) -> 
[PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u3/igt@i915_module_l...@reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-icl-u3/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm:  [DMESG-FAIL][11] ([fdo#08]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [FAIL][13] ([fdo#103167]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2:  [FAIL][15] ([fdo#111407]) -> [FAIL][16] ([fdo#109483])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
  [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
  [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407


Participating hosts (54 -> 45)
--

  Missing(9): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6820 -> Patchwork_14257

  CI-20190529: 20190529
  CI_DRM_6820: 2c16f62dc38ed97ab0056219f09d878c9e1c0355 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5162: e62ea305fdba2a9cd0dadfa527b54529cb0d1438 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14257: 1905dca746611ec865b8f99cd6407d815c3cb341 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1905dca74661 drm/edid: Have cea_db_offsets() zero start/end when the data block 
collection isn't found
ae9f56115d1d drm/edid: Don't look for CEA data blocks in CEA ext block rev < 3

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https:

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA

2019-09-02 Thread Ville Syrjälä
On Fri, Aug 23, 2019 at 12:52:28PM +0300, Gwan-gyeong Mun wrote:
> When BT.2020 Colorimetry output is used for DP, we should program BT.2020
> Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> intel_crtc_state struct as a place holder of pipe's output colorspace.
> In order to distinguish needed colorimetry for VSC SDP, it adds
> intel_dp_needs_vsc_colorimetry function.
> If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
> it uses MSA with VSC SDP.
> 
> As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
> Color Encoding Format and Content Color Gamut] while sending
> BT.2020 Colorimetry signals we should program MSA MISC1 fields which
> indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> 
> v2: Remove useless parentheses
> 
> Signed-off-by: Gwan-gyeong Mun 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  8 +++---
>  .../drm/i915/display/intel_display_types.h|  3 +++
>  drivers/gpu/drm/i915/display/intel_dp.c   | 25 ++-
>  drivers/gpu/drm/i915/display/intel_dp.h   |  1 +
>  4 files changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4f7ea0a35976..5c42b58c1c2f 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1737,11 +1737,13 @@ void intel_ddi_set_pipe_settings(const struct 
> intel_crtc_state *crtc_state)
>   /*
>* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
>* of Color Encoding Format and Content Color Gamut] while sending
> -  * YCBCR 420 signals we should program MSA MISC1 fields which
> -  * indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> +  * YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
> +  * which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
>*/
> - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> + intel_dp_needs_vsc_colorimetry(crtc_state->output_colorspace))
>   temp |= TRANS_MSA_USE_VSC_SDP;
> +
>   I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 449abaea619f..9845abcf6f29 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -964,6 +964,9 @@ struct intel_crtc_state {
>   /* Output format RGB/YCBCR etc */
>   enum intel_output_format output_format;
>  
> + /* Output colorspace sRGB/BT.2020 etc */
> + u32 output_colorspace;
> +
>   /* Output down scaling is done in LSPCON device */
>   bool lspcon_downsampling;
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 55d5ab97061c..295d5ed2be96 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2164,6 +2164,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   pipe_config->has_pch_encoder = true;
>  
>   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> + pipe_config->output_colorspace = intel_conn_state->base.colorspace;
> +
>   if (lspcon->active)
>   lspcon_ycbcr420_config(&intel_connector->base, pipe_config);
>   else
> @@ -4408,6 +4410,26 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> +bool
> +intel_dp_needs_vsc_colorimetry(u32 colorspace)

I would pass the entire crtc state here so you handle handle the 4:2:0
case here as well.

> +{
> + bool ret = false;

Pointless variable.

> +
> + switch (colorspace) {
> + case DRM_MODE_COLORIMETRY_SYCC_601:
> + case DRM_MODE_COLORIMETRY_OPYCC_601:
> + case DRM_MODE_COLORIMETRY_BT2020_YCC:
> + case DRM_MODE_COLORIMETRY_BT2020_RGB:
> + case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> + ret = true;
> + break;
> + default:
> + break;
> + }
> +
> + return ret;
> +}
> +
>  static void
>  intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
>  const struct intel_crtc_state *crtc_state,
> @@ -4536,7 +4558,8 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
>const struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)
>  {
> - if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> + if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
> + !intel_dp_needs_vsc_colorimetry(conn_state->colorspace))
>   return;
>  
>   intel_dp_setup_vsc_sdp(intel_dp, crtc_state, conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h 
> b/drivers/gpu/drm/i915/display/intel_

Re: [Intel-gfx] [PATCH v2 3/6] drm: Add DisplayPort colorspace property

2019-09-02 Thread Ville Syrjälä
On Fri, Aug 23, 2019 at 12:52:29PM +0300, Gwan-gyeong Mun wrote:
> In order to use colorspace property to Display Port connectors, it extends
> DRM_MODE_CONNECTOR_DisplayPort connector_type on
> drm_mode_create_colorspace_property function.
> 
> Signed-off-by: Gwan-gyeong Mun 
> ---
>  drivers/gpu/drm/drm_connector.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 4c766624b20d..655ada9d4c16 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1703,7 +1703,9 @@ int drm_mode_create_colorspace_property(struct 
> drm_connector *connector)
>   struct drm_property *prop;
>  
>   if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> - connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB ||
> + connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {

We don't need a separate set of enum values for DP?

>   prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
>   "Colorspace",
>   hdmi_colorspaces,
> -- 
> 2.22.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
___
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: Add high-precision time to vblank trace event

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm: Add high-precision time to vblank trace event
URL   : https://patchwork.freedesktop.org/series/66132/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6820 -> Patchwork_14258


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/

Known issues


  Here are the changes found in Patchwork_14258 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@gem_basic@create-close:
- fi-icl-u3:  [DMESG-WARN][1] ([fdo#107724]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u3/igt@gem_ba...@create-close.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/fi-icl-u3/igt@gem_ba...@create-close.html

  * igt@i915_module_load@reload:
- fi-icl-u3:  [DMESG-WARN][3] ([fdo#107724] / [fdo#111214]) -> 
[PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u3/igt@i915_module_l...@reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/fi-icl-u3/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm:  [DMESG-FAIL][5] ([fdo#08]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [FAIL][7] ([fdo#103167]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html

  
 Warnings 

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [FAIL][9] ([fdo#111407]) -> [FAIL][10] ([fdo#111096])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
  [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407


Participating hosts (54 -> 45)
--

  Missing(9): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6820 -> Patchwork_14258

  CI-20190529: 20190529
  CI_DRM_6820: 2c16f62dc38ed97ab0056219f09d878c9e1c0355 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5162: e62ea305fdba2a9cd0dadfa527b54529cb0d1438 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14258: 764d6d8263bc0efcd66fdab25af1f9767ba686e0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

764d6d8263bc drm: Add high-precision time to vblank trace event

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/edid: Don't look for CEA data blocks in CEA ext block rev < 3

2019-09-02 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/edid: Don't look for CEA data blocks in 
CEA ext block rev < 3
URL   : https://patchwork.freedesktop.org/series/66131/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6820_full -> Patchwork_14257_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14257_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@wide-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +3 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb8/igt@gem_exec_sched...@wide-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-snb:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108686])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-snb5/igt@gem_tiled_swapp...@non-threaded.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-snb1/igt@gem_tiled_swapp...@non-threaded.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +7 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-apl7/igt@gem_workarou...@suspend-resume-context.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-apl4/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-kbl:  [PASS][7] -> [SKIP][8] ([fdo#109271])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-kbl1/igt@i915_pm_rc6_reside...@rc6-accuracy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html

  * igt@i915_pm_rps@reset:
- shard-apl:  [PASS][9] -> [FAIL][10] ([fdo#102250])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-apl4/igt@i915_pm_...@reset.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-apl2/igt@i915_pm_...@reset.html

  * igt@kms_atomic_transition@1x-modeset-transitions:
- shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb3/igt@kms_atomic_transit...@1x-modeset-transitions.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-iclb7/igt@kms_atomic_transit...@1x-modeset-transitions.html

  * igt@kms_cursor_legacy@cursora-vs-flipa-atomic:
- shard-skl:  [PASS][13] -> [DMESG-WARN][14] ([fdo#106107])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-skl4/igt@kms_cursor_leg...@cursora-vs-flipa-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-skl7/igt@kms_cursor_leg...@cursora-vs-flipa-atomic.html

  * igt@kms_flip@dpms-vs-vblank-race-interruptible:
- shard-glk:  [PASS][15] -> [FAIL][16] ([fdo#103060])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-glk8/igt@kms_f...@dpms-vs-vblank-race-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-glk8/igt@kms_f...@dpms-vs-vblank-race-interruptible.html

  * igt@kms_flip@flip-vs-suspend:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([fdo#109507])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-skl7/igt@kms_f...@flip-vs-suspend.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-skl4/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-iclb4/igt@kms_psr@psr2_cursor_mmap_cpu.html

  * igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109276]) +14 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb2/igt@prime_v...@fence-wait-bsd2.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14257/shard-iclb7/igt@prime_v...@fence-wait-bsd2.html

  
 Possible fixes 

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-apl:  [DMESG-WARN][25]

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_panel_fitting: Fix plane scaling avoidance on gen7/gen8

2019-09-02 Thread Ville Syrjälä
On Fri, Aug 30, 2019 at 03:30:23PM -0700, Matt Roper wrote:
> Most gen7 and gen8 platforms can't do plane scaling, so we need to
> ensure the test doesn't try to do plane scaling on those platforms.  The
> legacy non-atomic subtest bakes these platform characteristics into the
> test itself since legacy modesetting interfaces don't provide a way to
> probe platform capabilities like atomic does.
> 
> Maarten previously tried to address this with commit 24c5e0778
> ("tests/kms_panel_fitting: Do not use scaling on gen7 and gen8, v2."),
> but he augmented an existing test for gen9+pipeC which comes too late
> since we've already turned on the plane at that point.  We can fix this
> by moving the test up higher; not only before we enable panel fitting,
> but also before we turn on the sprite.
> 
> Note that this still isn't a great subtest since it's very
> Intel-specific, despite being part of a generic KMS test that's intended
> for all vendors.  A future enhancement might be to try to probe the
> platform capabilities with a TEST_ONLY atomic operation before using the
> legacy interfaces to actually program them.
> 
> While touching the code, I also added some slight restructuring, added
> additional comments, and broke up >80 char lines to add clarity to
> what's going on.
> 
> Cc: Maarten Lankhorst 
> Signed-off-by: Matt Roper 

Reviewed-by: Ville Syrjälä 

> ---
>  tests/kms_panel_fitting.c | 24 +++-
>  1 file changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
> index 491e429f..a942294b 100644
> --- a/tests/kms_panel_fitting.c
> +++ b/tests/kms_panel_fitting.c
> @@ -131,11 +131,10 @@ static void test_panel_fitting(data_t *d)
>   igt_fb_set_position(&d->fb2, d->plane2, 100, 100);
>   igt_fb_set_size(&d->fb2, d->plane2, d->fb2.width-200, 
> d->fb2.height-200);
>   igt_plane_set_position(d->plane2, 100, 100);
> - igt_plane_set_size(d->plane2, mode->hdisplay-200, 
> mode->vdisplay-200);
> - igt_display_commit2(display, COMMIT_UNIVERSAL);
>  
>   /*
> -  * most of gen7 and all of gen8 doesn't support scaling at all.
> +  * Most of gen7 and all of gen8 doesn't support plane scaling
> +  * at all.
>*
>* gen9 pipe C has only 1 scaler shared with the crtc, which
>* means pipe scaling can't work simultaneously with panel
> @@ -144,9 +143,24 @@ static void test_panel_fitting(data_t *d)
>* Since this is the legacy path, userspace has to know about
>* the HW limitations, whereas atomic can ask.
>*/
> - if (IS_GEN8(devid) || (IS_GEN7(devid) && !IS_IVYBRIDGE(devid)) 
> ||
> + if (IS_GEN8(devid) ||
> + (IS_GEN7(devid) && !IS_IVYBRIDGE(devid)) ||
>   (IS_GEN9(devid) && pipe == PIPE_C))
> - igt_plane_set_size(d->plane2, d->fb2.width-200, 
> d->fb2.height-200);
> + /* same as visible area of fb => no scaling */
> + igt_plane_set_size(d->plane2,
> +d->fb2.width-200,
> +d->fb2.height-200);
> + else
> + /*
> +  * different than visible area of fb => plane scaling
> +  * active
> +  */
> + igt_plane_set_size(d->plane2,
> +mode->hdisplay-200,
> +mode->vdisplay-200);
> +
> + /* Plane scaling active (if possible), pfit off */
> + igt_display_commit2(display, COMMIT_UNIVERSAL);
>  
>   /* enable panel fitting along with sprite scaling */
>   mode->hdisplay = 1024;
> -- 
> 2.20.1
> 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Add high-precision time to vblank trace event

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm: Add high-precision time to vblank trace event
URL   : https://patchwork.freedesktop.org/series/66132/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6820_full -> Patchwork_14258_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14258_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14258_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_14258_full:

### IGT changes ###

 Possible regressions 

  * igt@perf@oa-formats:
- shard-hsw:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-hsw6/igt@p...@oa-formats.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-hsw5/igt@p...@oa-formats.html

  
Known issues


  Here are the changes found in Patchwork_14258_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb8/igt@gem_exec_sched...@reorder-wide-bsd.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html

  * igt@i915_pm_rps@min-max-config-loaded:
- shard-apl:  [PASS][5] -> [FAIL][6] ([fdo#102250])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-apl8/igt@i915_pm_...@min-max-config-loaded.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-apl6/igt@i915_pm_...@min-max-config-loaded.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +4 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_fbcon_fbt@fbc-suspend:
- shard-skl:  [PASS][9] -> [INCOMPLETE][10] ([fdo#104108])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-skl8/igt@kms_fbcon_...@fbc-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-skl1/igt@kms_fbcon_...@fbc-suspend.html

  * igt@kms_flip@2x-dpms-vs-vblank-race:
- shard-glk:  [PASS][11] -> [FAIL][12] ([fdo#103060])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-glk4/igt@kms_f...@2x-dpms-vs-vblank-race.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-glk4/igt@kms_f...@2x-dpms-vs-vblank-race.html

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +3 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb5/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-iclb8/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167] / [fdo#110378])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-rte.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [fdo#110403])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb2/igt@kms_plane_low...@pipe-a-tiling-y.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html

  * igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar 
issue
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6820/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14258/shard-iclb4/igt@kms_psr@psr2_cursor_mmap_cpu.html

  * igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [PASS][23] 

[Intel-gfx] [PATCH 4/4] drm/i915: stop conflating HAS_DISPLAY() and disabled display

2019-09-02 Thread Jani Nikula
Stop setting ->pipe_mask to zero when display is disabled, allowing us
to have different code paths for not actually having display hardware,
and having display hardware disabled. This lets us develop those two
avenues independently.

There are no functional changes for when there is no display. However,
all uses of for_each_pipe() and for_each_pipe_masked() will start
running for the disabled display case. Put one of the more significant
ones behind checks for INTEL_DISPLAY_ENABLED(), otherwise the cases
should not be hit with disabled display, or they seem benign. Fingers
crossed.

All in all, this might not be the ideal solution. In fact we may have
had something along the lines of this in the past, but we ended up
conflating the two cases. Possibly even by recommendation by yours
truly; I did not dare dig up that part of the history. But the perfect
is the enemy of the good, this is a straightforward change, and lets us
get actual work done in both fronts without interfering with each other.

Cc: Chris Wilson 
Cc: José Roberto de Souza 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c | 12 +++-
 drivers/gpu/drm/i915/intel_device_info.c |  8 ++--
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index c3bb18afe6d7..15f00dee6368 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16217,11 +16217,13 @@ int intel_modeset_init(struct drm_device *dev)
  INTEL_NUM_PIPES(dev_priv),
  INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
 
-   for_each_pipe(dev_priv, pipe) {
-   ret = intel_crtc_init(dev_priv, pipe);
-   if (ret) {
-   drm_mode_config_cleanup(dev);
-   return ret;
+   if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
+   for_each_pipe(dev_priv, pipe) {
+   ret = intel_crtc_init(dev_priv, pipe);
+   if (ret) {
+   drm_mode_config_cleanup(dev);
+   return ret;
+   }
}
}
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 50b05a5de53b..5d2da7e68a60 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -894,12 +894,8 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
runtime->num_sprites[pipe] = 1;
}
 
-   if (i915_modparams.disable_display) {
-   DRM_INFO("Display disabled (module parameter)\n");
-   info->pipe_mask = 0;
-   } else if (HAS_DISPLAY(dev_priv) &&
-  (IS_GEN_RANGE(dev_priv, 7, 8)) &&
-  HAS_PCH_SPLIT(dev_priv)) {
+   if (HAS_DISPLAY(dev_priv) && IS_GEN_RANGE(dev_priv, 7, 8) &&
+   HAS_PCH_SPLIT(dev_priv)) {
u32 fuse_strap = I915_READ(FUSE_STRAP);
u32 sfuse_strap = I915_READ(SFUSE_STRAP);
 
-- 
2.20.1

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

[Intel-gfx] [PATCH 2/4] drm/i915: convert device info num_pipes to pipe_mask

2019-09-02 Thread Jani Nikula
Replace device info number of pipes with a bit mask of available
pipes. This will prove handy in the future. There's still a bunch of
future work to do to actually allow a non-consecutive mask of pipes, but
it's a start. No functional changes.

Cc: Chris Wilson 
Cc: José Roberto de Souza 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 ++--
 drivers/gpu/drm/i915/i915_pci.c  | 24 
 drivers/gpu/drm/i915/intel_device_info.c | 10 +-
 drivers/gpu/drm/i915/intel_device_info.h |  2 +-
 4 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f4fc72e2118c..6557cd8ddd7a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2182,9 +2182,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define GT_FREQUENCY_MULTIPLIER 50
 #define GEN9_FREQ_SCALER 3
 
-#define INTEL_NUM_PIPES(dev_priv) (INTEL_INFO(dev_priv)->num_pipes)
+#define INTEL_NUM_PIPES(dev_priv) (hweight8(INTEL_INFO(dev_priv)->pipe_mask))
 
-#define HAS_DISPLAY(dev_priv) (INTEL_NUM_PIPES(dev_priv) > 0)
+#define HAS_DISPLAY(dev_priv) (INTEL_INFO(dev_priv)->pipe_mask != 0)
 
 static inline bool intel_vtd_active(void)
 {
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fbe98a2db88e..17ddc03df005 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -147,7 +147,7 @@
 #define I830_FEATURES \
GEN(2), \
.is_mobile = 1, \
-   .num_pipes = 2, \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.display.has_overlay = 1, \
.display.cursor_needs_physical = 1, \
.display.overlay_needs_physical = 1, \
@@ -165,7 +165,7 @@
 
 #define I845_FEATURES \
GEN(2), \
-   .num_pipes = 1, \
+   .pipe_mask = BIT(PIPE_A), \
.display.has_overlay = 1, \
.display.overlay_needs_physical = 1, \
.display.has_gmch = 1, \
@@ -203,7 +203,7 @@ static const struct intel_device_info intel_i865g_info = {
 
 #define GEN3_FEATURES \
GEN(3), \
-   .num_pipes = 2, \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.display.has_gmch = 1, \
.gpu_reset_clobbers_display = true, \
.engine_mask = BIT(RCS0), \
@@ -287,7 +287,7 @@ static const struct intel_device_info intel_pineview_m_info 
= {
 
 #define GEN4_FEATURES \
GEN(4), \
-   .num_pipes = 2, \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.display.has_hotplug = 1, \
.display.has_gmch = 1, \
.gpu_reset_clobbers_display = true, \
@@ -337,7 +337,7 @@ static const struct intel_device_info intel_gm45_info = {
 
 #define GEN5_FEATURES \
GEN(5), \
-   .num_pipes = 2, \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.display.has_hotplug = 1, \
.engine_mask = BIT(RCS0) | BIT(VCS0), \
.has_snoop = true, \
@@ -363,7 +363,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
 
 #define GEN6_FEATURES \
GEN(6), \
-   .num_pipes = 2, \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B), \
.display.has_hotplug = 1, \
.display.has_fbc = 1, \
.engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0), \
@@ -411,7 +411,7 @@ static const struct intel_device_info 
intel_sandybridge_m_gt2_info = {
 
 #define GEN7_FEATURES  \
GEN(7), \
-   .num_pipes = 3, \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C), \
.display.has_hotplug = 1, \
.display.has_fbc = 1, \
.engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0), \
@@ -462,7 +462,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
GEN7_FEATURES,
PLATFORM(INTEL_IVYBRIDGE),
.gt = 2,
-   .num_pipes = 0, /* legal, last one wins */
+   .pipe_mask = 0, /* legal, last one wins */
.has_l3_dpf = 1,
 };
 
@@ -470,7 +470,7 @@ static const struct intel_device_info intel_valleyview_info 
= {
PLATFORM(INTEL_VALLEYVIEW),
GEN(7),
.is_lp = 1,
-   .num_pipes = 2,
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B),
.has_runtime_pm = 1,
.has_rc6 = 1,
.has_rps = true,
@@ -560,7 +560,7 @@ static const struct intel_device_info 
intel_broadwell_gt3_info = {
 static const struct intel_device_info intel_cherryview_info = {
PLATFORM(INTEL_CHERRYVIEW),
GEN(8),
-   .num_pipes = 3,
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C),
.display.has_hotplug = 1,
.is_lp = 1,
.engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) | BIT(VECS0),
@@ -631,7 +631,7 @@ static const struct intel_device_info 
intel_skylake_gt4_info = {
.is_lp = 1, \
.display.has_hotplug = 1, \
.engine_mask = BIT(RCS0) | BIT(VCS0) | BIT(BCS0) | BIT(VECS0), \
-   .num_pipes = 3, \
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C), \
.has_64

[Intel-gfx] [PATCH 1/4] drm/i915: add INTEL_NUM_PIPES() and use it

2019-09-02 Thread Jani Nikula
Abstract away direct access to ->num_pipes to allow further
refactoring. No functional changes.

Cc: Chris Wilson 
Cc: José Roberto de Souza 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_display.c   | 12 ++--
 drivers/gpu/drm/i915/display/intel_display.h   |  4 ++--
 drivers/gpu/drm/i915/display/intel_lpe_audio.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  4 +++-
 drivers/gpu/drm/i915/intel_pm.c|  6 +++---
 6 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e661e2099118..e480ffe0ae6e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7188,7 +7188,7 @@ static int ironlake_check_fdi_lanes(struct drm_device 
*dev, enum pipe pipe,
}
}
 
-   if (INTEL_INFO(dev_priv)->num_pipes == 2)
+   if (INTEL_NUM_PIPES(dev_priv) == 2)
return 0;
 
/* Ivybridge 3 pipe is really complicated */
@@ -9572,7 +9572,7 @@ static void ironlake_compute_dpll(struct intel_crtc *crtc,
 * clear if it''s a win or loss power wise. No point in doing
 * this on ILK at all since it has a fixed DPLL<->pipe mapping.
 */
-   if (INTEL_INFO(dev_priv)->num_pipes == 3 &&
+   if (INTEL_NUM_PIPES(dev_priv) == 3 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG))
dpll |= DPLL_SDVO_HIGH_SPEED;
 
@@ -13863,7 +13863,7 @@ static void skl_commit_modeset_enables(struct 
intel_atomic_state *state)
 
if 
(skl_ddb_allocation_overlaps(&new_crtc_state->wm.skl.ddb,
entries,
-   
INTEL_INFO(dev_priv)->num_pipes, i))
+   
INTEL_NUM_PIPES(dev_priv), i))
continue;
 
updated |= cmask;
@@ -16214,8 +16214,8 @@ int intel_modeset_init(struct drm_device *dev)
}
 
DRM_DEBUG_KMS("%d display pipe%s available.\n",
- INTEL_INFO(dev_priv)->num_pipes,
- INTEL_INFO(dev_priv)->num_pipes > 1 ? "s" : "");
+ INTEL_NUM_PIPES(dev_priv),
+ INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
 
for_each_pipe(dev_priv, pipe) {
ret = intel_crtc_init(dev_priv, pipe);
@@ -17306,7 +17306,7 @@ intel_display_print_error_state(struct 
drm_i915_error_state_buf *m,
if (!error)
return;
 
-   err_printf(m, "Num Pipes: %d\n", INTEL_INFO(dev_priv)->num_pipes);
+   err_printf(m, "Num Pipes: %d\n", INTEL_NUM_PIPES(dev_priv));
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
err_printf(m, "PWR_WELL_CTL2: %08x\n",
   error->power_well_driver);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index 33fd523c4622..f4ddde171655 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -307,10 +307,10 @@ enum phy_fia {
 };
 
 #define for_each_pipe(__dev_priv, __p) \
-   for ((__p) = 0; (__p) < INTEL_INFO(__dev_priv)->num_pipes; (__p)++)
+   for ((__p) = 0; (__p) < INTEL_NUM_PIPES(__dev_priv); (__p)++)
 
 #define for_each_pipe_masked(__dev_priv, __p, __mask) \
-   for ((__p) = 0; (__p) < INTEL_INFO(__dev_priv)->num_pipes; (__p)++) \
+   for ((__p) = 0; (__p) < INTEL_NUM_PIPES(__dev_priv); (__p)++) \
for_each_if((__mask) & BIT(__p))
 
 #define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
diff --git a/drivers/gpu/drm/i915/display/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
index b19800b58442..0b67f7887cd0 100644
--- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
@@ -114,7 +114,7 @@ lpe_audio_platdev_create(struct drm_i915_private *dev_priv)
pinfo.size_data = sizeof(*pdata);
pinfo.dma_mask = DMA_BIT_MASK(32);
 
-   pdata->num_pipes = INTEL_INFO(dev_priv)->num_pipes;
+   pdata->num_pipes = INTEL_NUM_PIPES(dev_priv);
pdata->num_ports = IS_CHERRYVIEW(dev_priv) ? 3 : 2; /* B,C,D or B,C */
pdata->port[0].pipe = -1;
pdata->port[1].pipe = -1;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bec25942d77d..cad4d6ba2d2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -340,7 +340,7 @@ static int i915_driver_modeset_probe(struct drm_device *dev)
 
if (HAS_DISPLAY(dev_priv)) {
ret = drm_vblank_init(&dev_priv->drm,
- INTEL_INFO(dev_priv)->num_pipes);
+ 

[Intel-gfx] [PATCH 3/4] drm/i915: introduce INTEL_DISPLAY_ENABLED()

2019-09-02 Thread Jani Nikula
Prepare for making a distinction between not having display and having
disabled display. Add INTEL_DISPLAY_ENABLED() and use it where
HAS_DISPLAY() is used. This is initially duplication, as disabling
display still leads to ->pipe_mask = 0 and HAS_DISPLAY() being false.

Since INTEL_DISPLAY_ENABLED() will not make sense unless HAS_DISPLAY()
is true, include a warning for catching misuses making decisions on
INTEL_DISPLAY_ENABLED() when HAS_DISPLAY() is false.

Cc: Chris Wilson 
Cc: José Roberto de Souza 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_bios.c| 2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/display/intel_fbdev.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c   | 2 +-
 drivers/gpu/drm/i915/i915_drv.c  | 8 
 drivers/gpu/drm/i915/i915_drv.h  | 3 +++
 drivers/gpu/drm/i915/intel_pch.c | 2 +-
 7 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index efb39f350b19..1def550c68c8 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1833,7 +1833,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
const struct bdb_header *bdb;
u8 __iomem *bios = NULL;
 
-   if (!HAS_DISPLAY(dev_priv)) {
+   if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv)) {
DRM_DEBUG_KMS("Skipping VBT init due to disabled display.\n");
return;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e480ffe0ae6e..c3bb18afe6d7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15324,7 +15324,7 @@ static void intel_setup_outputs(struct drm_i915_private 
*dev_priv)
 
intel_pps_init(dev_priv);
 
-   if (!HAS_DISPLAY(dev_priv))
+   if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
return;
 
if (INTEL_GEN(dev_priv) >= 12) {
@@ -17227,7 +17227,7 @@ intel_display_capture_error_state(struct 
drm_i915_private *dev_priv)
 
BUILD_BUG_ON(ARRAY_SIZE(transcoders) != ARRAY_SIZE(error->transcoder));
 
-   if (!HAS_DISPLAY(dev_priv))
+   if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
return NULL;
 
error = kzalloc(sizeof(*error), GFP_ATOMIC);
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index d59eee5c5d9c..68338669f054 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -444,7 +444,7 @@ int intel_fbdev_init(struct drm_device *dev)
struct intel_fbdev *ifbdev;
int ret;
 
-   if (WARN_ON(!HAS_DISPLAY(dev_priv)))
+   if (WARN_ON(!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv)))
return -ENODEV;
 
ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c 
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index d6775a005726..3d4d19ac1d14 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -836,7 +836,7 @@ int intel_gmbus_setup(struct drm_i915_private *dev_priv)
unsigned int pin;
int ret;
 
-   if (!HAS_DISPLAY(dev_priv))
+   if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
return 0;
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cad4d6ba2d2c..f7266d405978 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -338,7 +338,7 @@ static int i915_driver_modeset_probe(struct drm_device *dev)
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
 
-   if (HAS_DISPLAY(dev_priv)) {
+   if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
ret = drm_vblank_init(&dev_priv->drm,
  INTEL_NUM_PIPES(dev_priv));
if (ret)
@@ -389,7 +389,7 @@ static int i915_driver_modeset_probe(struct drm_device *dev)
 
intel_overlay_setup(dev_priv);
 
-   if (!HAS_DISPLAY(dev_priv))
+   if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
return 0;
 
ret = intel_fbdev_init(dev);
@@ -1381,7 +1381,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
} else
DRM_ERROR("Failed to register driver for userspace access!\n");
 
-   if (HAS_DISPLAY(dev_priv)) {
+   if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
/* Must be done after probing outputs */
intel_opregion_register(dev_priv);
   

[Intel-gfx] [PATCH 0/4] drm/i915: deconflate display disable from no display

2019-09-02 Thread Jani Nikula
Deconflate not having display hardware from having disabled display
hardware, with some collateral improvements.

This doesn't actually fix any of the issues resulting from the two being
conflated, but unblocks fixing both independently.

Read the commit messages for details.

BR,
Jani.

Cc: Chris Wilson 
Cc: José Roberto de Souza 
Cc: Ville Syrjälä 

Jani Nikula (4):
  drm/i915: add INTEL_NUM_PIPES() and use it
  drm/i915: convert device info num_pipes to pipe_mask
  drm/i915: introduce INTEL_DISPLAY_ENABLED()
  drm/i915: stop conflating HAS_DISPLAY() and disabled display

 drivers/gpu/drm/i915/display/intel_bios.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c  | 30 ++-
 drivers/gpu/drm/i915/display/intel_display.h  |  4 +--
 drivers/gpu/drm/i915/display/intel_fbdev.c|  2 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|  2 +-
 .../gpu/drm/i915/display/intel_lpe_audio.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.c   | 10 +++
 drivers/gpu/drm/i915/i915_drv.h   |  7 -
 drivers/gpu/drm/i915/i915_pci.c   | 24 +++
 drivers/gpu/drm/i915/intel_device_info.c  | 16 --
 drivers/gpu/drm/i915/intel_device_info.h  |  2 +-
 drivers/gpu/drm/i915/intel_pch.c  |  2 +-
 drivers/gpu/drm/i915/intel_pm.c   |  6 ++--
 13 files changed, 56 insertions(+), 53 deletions(-)

-- 
2.20.1

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: deconflate display disable from no display

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915: deconflate display disable from no display
URL   : https://patchwork.freedesktop.org/series/66135/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a903450383fb drm/i915: add INTEL_NUM_PIPES() and use it
f3f10b13127d drm/i915: convert device info num_pipes to pipe_mask
70a2a78c083a drm/i915: introduce INTEL_DISPLAY_ENABLED()
-:133: WARNING:LONG_LINE: line over 100 characters
#133: FILE: drivers/gpu/drm/i915/i915_drv.h:2190:
+#define INTEL_DISPLAY_ENABLED(dev_priv) (WARN_ON(!HAS_DISPLAY(dev_priv)), 
!i915_modparams.disable_display)

total: 0 errors, 1 warnings, 0 checks, 89 lines checked
442ed634ab9f drm/i915: stop conflating HAS_DISPLAY() and disabled display

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

[Intel-gfx] [PATCH] drm/i915: add plural() helper for logging plurals

2019-09-02 Thread Jani Nikula
Add a helper instead of open coding the plurals in debug logs. Also
fixes the case for "0 display pipes available."

Signed-off-by: Jani Nikula 

---

I stumbled upon the pipes one while working on ->num_pipes. I honestly
thought we'd have more users than this, but to my surprise couldn't find
any. Perhaps this is not worth it after all.
---
 drivers/gpu/drm/i915/display/intel_display.c | 2 +-
 drivers/gpu/drm/i915/i915_utils.h| 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e661e2099118..c4bfd80a1cfa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16215,7 +16215,7 @@ int intel_modeset_init(struct drm_device *dev)
 
DRM_DEBUG_KMS("%d display pipe%s available.\n",
  INTEL_INFO(dev_priv)->num_pipes,
- INTEL_INFO(dev_priv)->num_pipes > 1 ? "s" : "");
+ plural(INTEL_INFO(dev_priv)->num_pipes));
 
for_each_pipe(dev_priv, pipe) {
ret = intel_crtc_init(dev_priv, pipe);
diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 562f756da421..dc34dfe18a1e 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -410,6 +410,11 @@ static inline const char *enableddisabled(bool v)
return v ? "enabled" : "disabled";
 }
 
+static inline const char *plural(long v)
+{
+   return v == 1 ? "" : "s";
+}
+
 static inline void add_taint_for_CI(unsigned int taint)
 {
/*
-- 
2.20.1

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

[Intel-gfx] [RFC PATCH] drm/i915: Hook up GT power management

2019-09-02 Thread Andi Shyti
Refactor the GT power management interface to work through the GT now
that it is under the control of gt/

Based on a patch by Chris Wilson.

Signed-off-by: Andi Shyti 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c |  1 +
 drivers/gpu/drm/i915/gt/intel_gt.c | 46 --
 drivers/gpu/drm/i915/gt/intel_gt.h |  9 +++--
 drivers/gpu/drm/i915/gt/intel_gt_pm.c  | 36 
 drivers/gpu/drm/i915/gt/intel_gt_pm.h  |  2 ++
 drivers/gpu/drm/i915/i915_drv.c| 22 
 drivers/gpu/drm/i915/i915_gem.c| 29 +++-
 7 files changed, 99 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 92e53c25424c..b3993d24b83d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -137,6 +137,7 @@ static bool switch_to_kernel_context_sync(struct intel_gt 
*gt)
 
 bool i915_gem_load_power_context(struct drm_i915_private *i915)
 {
+   intel_gt_pm_enable(&i915->gt);
return switch_to_kernel_context_sync(&i915->gt);
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index d48ec9a76ed1..080e6d74ff56 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -7,6 +7,7 @@
 #include "intel_gt.h"
 #include "intel_gt_pm.h"
 #include "intel_uncore.h"
+#include "intel_pm.h"
 
 void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
 {
@@ -27,6 +28,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct 
drm_i915_private *i915)
 void intel_gt_init_hw(struct drm_i915_private *i915)
 {
i915->gt.ggtt = &i915->ggtt;
+
+   /* BIOS often leaves RC6 enabled, but disable it for hw init */
+   intel_gt_pm_disable(&i915->gt);
 }
 
 static void rmw_set(struct intel_uncore *uncore, i915_reg_t reg, u32 set)
@@ -222,7 +226,14 @@ void intel_gt_chipset_flush(struct intel_gt *gt)
intel_gtt_chipset_flush();
 }
 
-int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
+void intel_gt_driver_register(struct intel_gt *gt)
+{
+   if (IS_GEN(gt->i915, 5))
+   intel_gpu_ips_init(gt->i915);
+
+}
+
+static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
 {
struct drm_i915_private *i915 = gt->i915;
struct drm_i915_gem_object *obj;
@@ -256,11 +267,42 @@ int intel_gt_init_scratch(struct intel_gt *gt, unsigned 
int size)
return ret;
 }
 
-void intel_gt_fini_scratch(struct intel_gt *gt)
+static void intel_gt_fini_scratch(struct intel_gt *gt)
 {
i915_vma_unpin_and_release(>->scratch, 0);
 }
 
+int intel_gt_init(struct intel_gt *gt)
+{
+   int err;
+
+   err = intel_gt_init_scratch(gt, IS_GEN(gt->i915, 2) ? SZ_256K : SZ_4K);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+void intel_gt_driver_remove(struct intel_gt *gt)
+{
+   GEM_BUG_ON(gt->awake);
+   intel_gt_pm_disable(gt);
+}
+
+void intel_gt_driver_unregister(struct intel_gt *gt)
+{
+   intel_gpu_ips_teardown();
+}
+
+void intel_gt_driver_release(struct intel_gt *gt)
+{
+   /* Paranoia: make sure we have disabled everything before we exit. */
+   intel_gt_pm_disable(gt);
+
+   intel_cleanup_gt_powersave(gt->i915);
+   intel_gt_fini_scratch(gt);
+}
+
 void intel_gt_driver_late_release(struct intel_gt *gt)
 {
intel_uc_driver_late_release(>->uc);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 4920cb351f10..17af21cb7ed3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -29,6 +29,12 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc 
*huc)
 
 void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
 void intel_gt_init_hw(struct drm_i915_private *i915);
+int intel_gt_init(struct intel_gt *gt);
+void intel_gt_driver_register(struct intel_gt *gt);
+
+void intel_gt_driver_unregister(struct intel_gt *gt);
+void intel_gt_driver_remove(struct intel_gt *gt);
+void intel_gt_driver_release(struct intel_gt *gt);
 
 void intel_gt_driver_late_release(struct intel_gt *gt);
 
@@ -41,9 +47,6 @@ void intel_gt_chipset_flush(struct intel_gt *gt);
 
 void intel_gt_init_hangcheck(struct intel_gt *gt);
 
-int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size);
-void intel_gt_fini_scratch(struct intel_gt *gt);
-
 static inline u32 intel_gt_scratch_offset(const struct intel_gt *gt,
  enum intel_gt_scratch_field field)
 {
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index aa6cf0152ce7..6ba0d2069f87 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -124,6 +124,42 @@ void intel_gt_sanitize(struct intel_gt *gt, bool force)
__intel_engine_reset(engine, false);
 }
 
+static bool is_mock_device(con

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: deconflate display disable from no display

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915: deconflate display disable from no display
URL   : https://patchwork.freedesktop.org/series/66135/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6821 -> Patchwork_14259


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14259 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14259, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14259:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@module-reload:
- fi-cfl-8700k:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-cfl-8700k/igt@i915_pm_...@module-reload.html
- fi-kbl-x1275:   [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-guc/igt@i915_pm_...@module-reload.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-skl-guc/igt@i915_pm_...@module-reload.html
- fi-cfl-guc: [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-cfl-guc/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-cfl-guc/igt@i915_pm_...@module-reload.html
- fi-skl-iommu:   [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-iommu/igt@i915_pm_...@module-reload.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-skl-iommu/igt@i915_pm_...@module-reload.html
- fi-whl-u:   [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-whl-u/igt@i915_pm_...@module-reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-whl-u/igt@i915_pm_...@module-reload.html
- fi-skl-6260u:   [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-6260u/igt@i915_pm_...@module-reload.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-skl-6260u/igt@i915_pm_...@module-reload.html
- fi-skl-6770hq:  [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
- fi-bdw-5557u:   [PASS][17] -> [DMESG-WARN][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-bdw-5557u/igt@i915_pm_...@module-reload.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-bdw-5557u/igt@i915_pm_...@module-reload.html
- fi-kbl-r:   [PASS][19] -> [DMESG-WARN][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-kbl-r/igt@i915_pm_...@module-reload.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-kbl-r/igt@i915_pm_...@module-reload.html
- fi-skl-lmem:[PASS][21] -> [DMESG-WARN][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-lmem/igt@i915_pm_...@module-reload.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-skl-lmem/igt@i915_pm_...@module-reload.html
- fi-hsw-peppy:   [PASS][23] -> [DMESG-WARN][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-hsw-peppy/igt@i915_pm_...@module-reload.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-hsw-peppy/igt@i915_pm_...@module-reload.html
- fi-cfl-8109u:   [PASS][25] -> [DMESG-WARN][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
- fi-skl-6600u:   [PASS][27] -> [DMESG-WARN][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-6600u/igt@i915_pm_...@module-reload.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14259/fi-skl-6600u/igt@i915_pm_...@module-reload.html
- fi-skl-6700k2:  [PASS][29] -> [DMESG-WARN][30]
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-6700k2/igt@i915_pm_...@mod

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add plural() helper for logging plurals

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915: add plural() helper for logging plurals
URL   : https://patchwork.freedesktop.org/series/66136/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6821 -> Patchwork_14260


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/

Known issues


  Here are the changes found in Patchwork_14260 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_switch@rcs0:
- fi-icl-u2:  [PASS][1] -> [INCOMPLETE][2] ([fdo#107713])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/fi-icl-u2/igt@gem_ctx_swi...@rcs0.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@gem_flink_basic@bad-flink:
- fi-icl-u3:  [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  [PASS][7] -> [FAIL][8] ([fdo#103167])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_ringfill@basic-default:
- fi-icl-u3:  [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u3/igt@gem_ringf...@basic-default.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/fi-icl-u3/igt@gem_ringf...@basic-default.html

  * igt@i915_module_load@reload:
- fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724] / [fdo#111214]) -> 
[PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u3/igt@i915_module_l...@reload.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/fi-icl-u3/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm:  [DMESG-FAIL][13] ([fdo#08]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
  [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
  [fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381


Participating hosts (53 -> 45)
--

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-apl-guc fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6821 -> Patchwork_14260

  CI-20190529: 20190529
  CI_DRM_6821: 62659d8a3af61190f79ceca1be30f0d7e7582ade @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5162: e62ea305fdba2a9cd0dadfa527b54529cb0d1438 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14260: 57e9d06ea5260f464bada711a9c1facd47866abd @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

57e9d06ea526 drm/i915: add plural() helper for logging plurals

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Hook up GT power management

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Hook up GT power management
URL   : https://patchwork.freedesktop.org/series/66137/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a6b2b3196efe drm/i915: Hook up GT power management
-:58: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#58: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:234:
+
+}

total: 0 errors, 0 warnings, 1 checks, 289 lines checked

___
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: Hook up GT power management

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915: Hook up GT power management
URL   : https://patchwork.freedesktop.org/series/66137/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6821 -> Patchwork_14261


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14261 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14261, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14261:

### IGT changes ###

 Possible regressions 

  * igt@i915_module_load@reload-with-fault-injection:
- fi-elk-e7500:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-elk-e7500/igt@i915_module_l...@reload-with-fault-injection.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-elk-e7500/igt@i915_module_l...@reload-with-fault-injection.html
- fi-blb-e6850:   [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-blb-e6850/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-blb-e6850/igt@i915_module_l...@reload-with-fault-injection.html
- fi-bwr-2160:[PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-bwr-2160/igt@i915_module_l...@reload-with-fault-injection.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-bwr-2160/igt@i915_module_l...@reload-with-fault-injection.html
- fi-gdg-551: [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-gdg-551/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-gdg-551/igt@i915_module_l...@reload-with-fault-injection.html
- fi-ilk-650: [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-ilk-650/igt@i915_module_l...@reload-with-fault-injection.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-ilk-650/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@runner@aborted:
- fi-ilk-650: NOTRUN -> [FAIL][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-ilk-650/igt@run...@aborted.html
- fi-gdg-551: NOTRUN -> [FAIL][12]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-gdg-551/igt@run...@aborted.html
- fi-blb-e6850:   NOTRUN -> [FAIL][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-blb-e6850/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_14261 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_render_tiled_blits@basic:
- fi-icl-u3:  [PASS][14] -> [DMESG-WARN][15] ([fdo#107724])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [PASS][16] -> [DMESG-WARN][17] ([fdo#102614])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_ringfill@basic-default:
- fi-icl-u3:  [DMESG-WARN][18] ([fdo#107724]) -> [PASS][19]
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u3/igt@gem_ringf...@basic-default.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-icl-u3/igt@gem_ringf...@basic-default.html

  * igt@i915_module_load@reload:
- fi-icl-u3:  [DMESG-WARN][20] ([fdo#107724] / [fdo#111214]) -> 
[PASS][21]
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-icl-u3/igt@i915_module_l...@reload.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-icl-u3/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm:  [DMESG-FAIL][22] ([fdo#08]) -> [PASS][23]
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14261/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html

  * igt@kms_chamelium@dp-crc-fast:
- {fi-icl-u4}:[FAIL][24] ([fdo#111045]) -> [PASS][25]
   [24]: 
https://intel-gfx-ci.01.or

Re: [Intel-gfx] [PATCH v12 11/11] drm/i915: add support for perf configuration queries

2019-09-02 Thread Dan Carpenter
Hi Lionel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.3-rc7 next-20190902]
[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/Lionel-Landwerlin/drm-i915-Vulkan-performance-query-support/20190831-033234
base:   git://anongit.freedesktop.org/drm-intel for-linux-next

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 
Reported-by: Dan Carpenter 

New smatch warnings:
drivers/gpu/drm/i915/i915_query.c:405 query_perf_config_list() warn: maybe 
return -EFAULT instead of the bytes remaining?

Old smatch warnings:
drivers/gpu/drm/i915/i915_query.c:138 query_engine_info() warn: check that 
'query.num_engines' doesn't leak information

# 
https://github.com/0day-ci/linux/commit/1c566ee2d38f4e7ece15ee33fef205b1088e79bb
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 1c566ee2d38f4e7ece15ee33fef205b1088e79bb
vim +405 drivers/gpu/drm/i915/i915_query.c

1c566ee2d38f4e Lionel Landwerlin 2019-08-30  336  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  337  static int 
query_perf_config_list(struct drm_i915_private *i915,
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  338
  struct drm_i915_query_item *query_item)
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  339  {
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  340struct 
drm_i915_query_perf_config __user *user_query_config_ptr =
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  341
u64_to_user_ptr(query_item->data_ptr);
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  342struct i915_oa_config 
*oa_config;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  343u32 flags, total_size;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  344u64 i, n_configs, 
*oa_config_ids;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  345int ret, id;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  346  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  347if 
(!i915->perf.initialized)
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  348return -ENODEV;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  349  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  350/* Count the default 
test configuration */
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  351n_configs = 
i915->perf.n_metrics + 1;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  352total_size = 
sizeof(struct drm_i915_query_perf_config) +
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  353sizeof(u64) * 
n_configs;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  354  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  355if (query_item->length 
== 0)
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  356return 
total_size;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  357  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  358if (query_item->length 
< total_size) {
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  359
DRM_DEBUG("Invalid query config list item size=%u expected=%u\n",
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  360  
query_item->length, total_size);
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  361return -EINVAL;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  362}
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  363  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  364if 
(!access_ok(user_query_config_ptr, total_size))
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  365return -EFAULT;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  366  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  367if (__get_user(flags, 
&user_query_config_ptr->flags))
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  368return -EFAULT;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  369  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  370if (flags != 0)
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  371return -EINVAL;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  372  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  373if 
(__put_user(n_configs, &user_query_config_ptr->config))
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  374return -EFAULT;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  375  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  376ret = 
mutex_lock_interruptible(&i915->perf.metrics_lock);
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  377if (ret)
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  378return ret;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  379  
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  380/* Count the configs. */
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  381n_configs = 1;
1c566ee2d38f4e Lionel Landwerlin 2019-08-30  38

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add plural() helper for logging plurals

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915: add plural() helper for logging plurals
URL   : https://patchwork.freedesktop.org/series/66136/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6821_full -> Patchwork_14260_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_14260_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +5 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +14 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb5/igt@gem_exec_sched...@preempt-queue-bsd2.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-snb:  [PASS][5] -> [SKIP][6] ([fdo#109271])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-snb4/igt@i915_pm_rc6_reside...@rc6-accuracy.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +5 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-apl7/igt@i915_susp...@sysfs-reader.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-apl2/igt@i915_susp...@sysfs-reader.html

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb2/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb7/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt:
- shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html

  * igt@kms_plane_cursor@pipe-b-viewport-size-256:
- shard-hsw:  [PASS][13] -> [DMESG-WARN][14] ([fdo#102614])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-hsw7/igt@kms_plane_cur...@pipe-b-viewport-size-256.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-hsw5/igt@kms_plane_cur...@pipe-b-viewport-size-256.html

  * igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb7/igt@kms_psr@psr2_cursor_plane_move.html

  
 Possible fixes 

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [SKIP][17] ([fdo#110841]) -> [PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [SKIP][19] ([fdo#109276]) -> [PASS][20] +20 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [SKIP][21] ([fdo#111325]) -> [PASS][22] +5 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-iclb5/igt@gem_exec_sched...@preemptive-hang-bsd.html

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  [INCOMPLETE][23] ([fdo#104108]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6821/shard-skl1/igt@gem_soft...@noreloc-s3.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14260/shard-skl5/igt@gem_soft...@noreloc-s3.html

  * igt@i915_pm_rpm@system-su

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_panel_fitting: Fix plane scaling avoidance on gen7/gen8

2019-09-02 Thread Matt Roper
On Mon, Sep 02, 2019 at 07:51:41PM +0300, Ville Syrjälä wrote:
> On Fri, Aug 30, 2019 at 03:30:23PM -0700, Matt Roper wrote:
> > Most gen7 and gen8 platforms can't do plane scaling, so we need to
> > ensure the test doesn't try to do plane scaling on those platforms.  The
> > legacy non-atomic subtest bakes these platform characteristics into the
> > test itself since legacy modesetting interfaces don't provide a way to
> > probe platform capabilities like atomic does.
> > 
> > Maarten previously tried to address this with commit 24c5e0778
> > ("tests/kms_panel_fitting: Do not use scaling on gen7 and gen8, v2."),
> > but he augmented an existing test for gen9+pipeC which comes too late
> > since we've already turned on the plane at that point.  We can fix this
> > by moving the test up higher; not only before we enable panel fitting,
> > but also before we turn on the sprite.
> > 
> > Note that this still isn't a great subtest since it's very
> > Intel-specific, despite being part of a generic KMS test that's intended
> > for all vendors.  A future enhancement might be to try to probe the
> > platform capabilities with a TEST_ONLY atomic operation before using the
> > legacy interfaces to actually program them.
> > 
> > While touching the code, I also added some slight restructuring, added
> > additional comments, and broke up >80 char lines to add clarity to
> > what's going on.
> > 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Matt Roper 
> 
> Reviewed-by: Ville Syrjälä 

Pushed, thanks for the review.


Matt

> 
> > ---
> >  tests/kms_panel_fitting.c | 24 +++-
> >  1 file changed, 19 insertions(+), 5 deletions(-)
> > 
> > diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
> > index 491e429f..a942294b 100644
> > --- a/tests/kms_panel_fitting.c
> > +++ b/tests/kms_panel_fitting.c
> > @@ -131,11 +131,10 @@ static void test_panel_fitting(data_t *d)
> > igt_fb_set_position(&d->fb2, d->plane2, 100, 100);
> > igt_fb_set_size(&d->fb2, d->plane2, d->fb2.width-200, 
> > d->fb2.height-200);
> > igt_plane_set_position(d->plane2, 100, 100);
> > -   igt_plane_set_size(d->plane2, mode->hdisplay-200, 
> > mode->vdisplay-200);
> > -   igt_display_commit2(display, COMMIT_UNIVERSAL);
> >  
> > /*
> > -* most of gen7 and all of gen8 doesn't support scaling at all.
> > +* Most of gen7 and all of gen8 doesn't support plane scaling
> > +* at all.
> >  *
> >  * gen9 pipe C has only 1 scaler shared with the crtc, which
> >  * means pipe scaling can't work simultaneously with panel
> > @@ -144,9 +143,24 @@ static void test_panel_fitting(data_t *d)
> >  * Since this is the legacy path, userspace has to know about
> >  * the HW limitations, whereas atomic can ask.
> >  */
> > -   if (IS_GEN8(devid) || (IS_GEN7(devid) && !IS_IVYBRIDGE(devid)) 
> > ||
> > +   if (IS_GEN8(devid) ||
> > +   (IS_GEN7(devid) && !IS_IVYBRIDGE(devid)) ||
> > (IS_GEN9(devid) && pipe == PIPE_C))
> > -   igt_plane_set_size(d->plane2, d->fb2.width-200, 
> > d->fb2.height-200);
> > +   /* same as visible area of fb => no scaling */
> > +   igt_plane_set_size(d->plane2,
> > +  d->fb2.width-200,
> > +  d->fb2.height-200);
> > +   else
> > +   /*
> > +* different than visible area of fb => plane scaling
> > +* active
> > +*/
> > +   igt_plane_set_size(d->plane2,
> > +  mode->hdisplay-200,
> > +  mode->vdisplay-200);
> > +
> > +   /* Plane scaling active (if possible), pfit off */
> > +   igt_display_commit2(display, COMMIT_UNIVERSAL);
> >  
> > /* enable panel fitting along with sprite scaling */
> > mode->hdisplay = 1024;
> > -- 
> > 2.20.1
> > 
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> 
> -- 
> Ville Syrjälä
> Intel

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

Re: [RFC PATCH] iommu/vt-d: Fix IOMMU field not populated on device hot re-plug

2019-09-02 Thread Lu Baolu

Hi Janusz,

On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:

I am not saying that keeping data is not acceptable. I just want to
check whether there are any other solutions.

Then reverting 458b7c8e0dde and applying this patch still resolves the issue
for me.  No errors appear when mappings are unmapped on device close after the
device has been removed, and domain info preserved on device removal is
successfully reused on device re-plug.


This patch doesn't look good to me although I agree that keeping data is
acceptable. It updates dev->archdata.iommu, but leaves the hardware
context/pasid table unchanged. This might cause problems somewhere.



Is there anything else I can do to help?


Can you please tell me how to reproduce the problem? Keeping the per
device domain info while device is unplugged is a bit dangerous because
info->dev might be a wild pointer. We need to work out a clean fix.



Thanks,
Janusz



Best regards,
Baolu


Re: [Intel-gfx] [PATCH v4 02/10] drm/i915/dsb: DSB context creation.

2019-09-02 Thread Sharma, Shashank


> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Jani
> Nikula
> Sent: Friday, August 30, 2019 7:06 PM
> To: Manna, Animesh ; intel-gfx@lists.freedesktop.org
> Cc: Thierry, Michel 
> Subject: Re: [Intel-gfx] [PATCH v4 02/10] drm/i915/dsb: DSB context creation.
> 
> On Fri, 30 Aug 2019, Animesh Manna  wrote:
> > This patch adds a function, which will internally get the gem buffer
> > for DSB engine. The GEM buffer is from global GTT, and is mapped into
> > CPU domain, contains the data + opcode to be feed to DSB engine.
> >
> > v1: Initial version.
> >
> > v2:
> > - removed some unwanted code. (Chris)
> > - Used i915_gem_object_create_internal instead of _shmem. (Chris)
> > - cmd_buf_tail removed and can be derived through vma object. (Chris)
> >
> > v3: vma realeased if i915_gem_object_pin_map() failed. (Shashank)
> >
> > Cc: Imre Deak 
> > Cc: Michel Thierry 
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Animesh Manna 
> > ---
> >  drivers/gpu/drm/i915/Makefile |  1 +
> >  .../drm/i915/display/intel_display_types.h|  3 +
> >  drivers/gpu/drm/i915/display/intel_dsb.c  | 83 +++
> >  drivers/gpu/drm/i915/display/intel_dsb.h  | 31 +++
> >  drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >  5 files changed, 119 insertions(+)
> >  create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c
> >  create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile index 658b930d34a8..6313e7b4bd78
> > 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -172,6 +172,7 @@ i915-y += \
> > display/intel_display_power.o \
> > display/intel_dpio_phy.o \
> > display/intel_dpll_mgr.o \
> > +   display/intel_dsb.o \
> > display/intel_fbc.o \
> > display/intel_fifo_underrun.o \
> > display/intel_frontbuffer.o \
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 61277a87dbe7..da36867189cb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1033,6 +1033,9 @@ struct intel_crtc {
> >
> > /* scalers available on this crtc */
> > int num_scalers;
> > +
> > +   /* per pipe DSB related info */
> > +   struct intel_dsb dsb[MAX_DSB_PER_PIPE];
> >  };
> >
> >  struct intel_plane {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > new file mode 100644
> > index ..007ef13481d5
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > @@ -0,0 +1,83 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2019 Intel Corporation
> > + *
> > + */
> > +
> > +#include "i915_drv.h"
> > +#include "intel_display_types.h"
> > +
> > +#define DSB_BUF_SIZE(2 * PAGE_SIZE)
> > +
> > +struct intel_dsb *
> > +intel_dsb_get(struct intel_crtc *crtc) {
> > +   struct drm_device *dev = crtc->base.dev;
> > +   struct drm_i915_private *i915 = to_i915(dev);
> > +   struct drm_i915_gem_object *obj;
> > +   struct i915_vma *vma;
> > +   struct intel_dsb *dsb;
> > +   intel_wakeref_t wakeref;
> > +   int i;
> > +
> > +   for (i = 0; i < MAX_DSB_PER_PIPE; i++)
> > +   if (!crtc->dsb[i].cmd_buf)
> > +   break;
> > +
> > +   if (WARN_ON(i == MAX_DSB_PER_PIPE))
> > +   return NULL;
> > +
> > +   dsb = &crtc->dsb[i];
> > +   dsb->id = i;
> > +   dsb->crtc = crtc;
> > +   if (!HAS_DSB(i915))
> > +   return dsb;
> 
> Why do you go through any of the trouble if there is no DSB? Just early 
> return NULL,
> and make the write functions handle NULL dsb pointer.
> 
I agree on this. Even I thought it would be better if we populate the DSB ptr 
only when we find a valid DSB support on the platform. And the caller of get() 
can understand this and act accordingly. 
> > +
> > +   wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> > +
> > +   obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
> > +   if (IS_ERR(obj))
> > +   goto err;
> > +
> > +   mutex_lock(&i915->drm.struct_mutex);
> > +   vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
> > +   mutex_unlock(&i915->drm.struct_mutex);
> > +   if (IS_ERR(vma)) {
> > +   DRM_ERROR("Vma creation failed.\n");
> > +   i915_gem_object_put(obj);
> > +   goto err;
> > +   }
> > +
> > +   dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
> > +   if (IS_ERR(dsb->cmd_buf)) {
> > +   DRM_ERROR("Command buffer creation failed.\n");
> > +   i915_vma_unpin_and_release(&vma, 0);
> > +   dsb->cmd_buf = NULL;
> > +   goto err;
> > +   }
> > +   dsb->vma = vma;
> > +
> > +err:
> > +   intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> > +   return dsb;
> > +}

Re: [Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut programming using DSB.

2019-09-02 Thread Sharma, Shashank


> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Jani
> Nikula
> Sent: Friday, August 30, 2019 7:02 PM
> To: Manna, Animesh ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 08/10] drm/i915/dsb: Enable gamma lut
> programming using DSB.
> 
> On Fri, 30 Aug 2019, Animesh Manna  wrote:
> > Gamma lut programming can be programmed using DSB where bulk register
> > programming can be done using indexed register write which takes
> > number of data and the mmio offset to be written.
> >
> > v1: Initial version.
> > v2: Directly call dsb-api at callsites. (Jani)
> >
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Animesh Manna 
> > ---
> >  drivers/gpu/drm/i915/display/intel_color.c | 64 ++
> >  drivers/gpu/drm/i915/i915_drv.h|  2 +
> >  2 files changed, 43 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index 71a0201437a9..e4090d8e4547 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -589,34 +589,38 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
> > const struct drm_color_lut *lut = blob->data;
> > int i, lut_size = drm_color_lut_size(blob);
> > enum pipe pipe = crtc->pipe;
> > +   struct intel_dsb *dsb = dev_priv->dsb;
> 
> No. Don't put dsb in dev_priv. You have 12 DSB engines, 3 per pipe. You have
> intel_crtc for that.
> 
> Was this not clear from my previous review?
> 
> You have tons of functions here that will never have a DSB engine, it makes 
> no sense
> to convert all of them to use the DSB.
> 
Jani, 
I was thinking even among the 3 engines available per pipe, would it make more 
sense to keep them reserve on the basis of user ? like DSB0 for all pipe 
operations, DSB1 for all plane, and DSB2 for all encoder related stuff. We can 
create a DSB user (like we have for scaler) and index these engines based on 
that. Do you think so ?

> >
> > -   I915_WRITE(PREC_PAL_INDEX(pipe), prec_index |
> > -  PAL_PREC_AUTO_INCREMENT);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_INDEX(pipe),
> > +   prec_index | PAL_PREC_AUTO_INCREMENT);
> >
> > for (i = 0; i < hw_lut_size; i++) {
> > /* We discard half the user entries in split gamma mode */
> > const struct drm_color_lut *entry =
> > &lut[i * (lut_size - 1) / (hw_lut_size - 1)];
> >
> > -   I915_WRITE(PREC_PAL_DATA(pipe), ilk_lut_10(entry));
> > +   intel_dsb_indexed_reg_write(dsb, PREC_PAL_DATA(pipe),
> > +   ilk_lut_10(entry));
> > }
> >
> > /*
> >  * Reset the index, otherwise it prevents the legacy palette to be
> >  * written properly.
> >  */
> > -   I915_WRITE(PREC_PAL_INDEX(pipe), 0);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_INDEX(pipe), 0);
> >  }
> >
> >  static void ivb_load_lut_ext_max(struct intel_crtc *crtc)  {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +   struct intel_dsb *dsb = dev_priv->dsb;
> > enum pipe pipe = crtc->pipe;
> >
> > /* Program the max register to clamp values > 1.0. */
> > -   I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
> > -   I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
> > -   I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 0), 1 << 16);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 1), 1 << 16);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_EXT_GC_MAX(pipe, 2), 1 << 16);
> > +
> >
> > /*
> >  * Program the gc max 2 register to clamp values > 1.0.
> > @@ -624,9 +628,12 @@ static void ivb_load_lut_ext_max(struct intel_crtc 
> > *crtc)
> >  * from 3.0 to 7.0
> >  */
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> > -   I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 0), 1 << 16);
> > -   I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 1), 1 << 16);
> > -   I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 2), 1 << 16);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 0),
> > +   1 << 16);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 1),
> > +   1 << 16);
> > +   intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 2),
> > +   1 << 16);
> > }
> >  }
> >
> > @@ -788,12 +795,13 @@ icl_load_gcmax(const struct intel_crtc_state
> > *crtc_state,  {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +   struct intel_dsb *dsb = dev_priv->dsb;
> > enum pipe pipe = crtc->pipe;
> >
> > /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
> > -   I915_WRITE(PREC_PAL_GC_MAX(pipe,

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA

2019-09-02 Thread Mun, Gwan-gyeong
On Mon, 2019-09-02 at 17:43 +0300, Ville Syrjälä wrote:
> On Fri, Aug 23, 2019 at 12:52:28PM +0300, Gwan-gyeong Mun wrote:
> > When BT.2020 Colorimetry output is used for DP, we should program
> > BT.2020
> > Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> > intel_crtc_state struct as a place holder of pipe's output
> > colorspace.
> > In order to distinguish needed colorimetry for VSC SDP, it adds
> > intel_dp_needs_vsc_colorimetry function.
> > If the output colorspace requires vsc sdp or output format is YCbCr
> > 4:2:0,
> > it uses MSA with VSC SDP.
> > 
> > As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
> > Color Encoding Format and Content Color Gamut] while sending
> > BT.2020 Colorimetry signals we should program MSA MISC1 fields
> > which
> > indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> > 
> > v2: Remove useless parentheses
> > 
> > Signed-off-by: Gwan-gyeong Mun 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c  |  8 +++---
> >  .../drm/i915/display/intel_display_types.h|  3 +++
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 25
> > ++-
> >  drivers/gpu/drm/i915/display/intel_dp.h   |  1 +
> >  4 files changed, 33 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4f7ea0a35976..5c42b58c1c2f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1737,11 +1737,13 @@ void intel_ddi_set_pipe_settings(const
> > struct intel_crtc_state *crtc_state)
> > /*
> >  * As per DP 1.4a spec section 2.2.4.3 [MSA Field for
> > Indication
> >  * of Color Encoding Format and Content Color Gamut] while
> > sending
> > -* YCBCR 420 signals we should program MSA MISC1 fields which
> > -* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> > +* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1
> > fields
> > +* which indicate VSC SDP for the Pixel Encoding/Colorimetry
> > Format.
> >  */
> > -   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > +   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420
> > ||
> > +   intel_dp_needs_vsc_colorimetry(crtc_state-
> > >output_colorspace))
> > temp |= TRANS_MSA_USE_VSC_SDP;
> > +
> > I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 449abaea619f..9845abcf6f29 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -964,6 +964,9 @@ struct intel_crtc_state {
> > /* Output format RGB/YCBCR etc */
> > enum intel_output_format output_format;
> >  
> > +   /* Output colorspace sRGB/BT.2020 etc */
> > +   u32 output_colorspace;
> > +
> > /* Output down scaling is done in LSPCON device */
> > bool lspcon_downsampling;
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 55d5ab97061c..295d5ed2be96 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -2164,6 +2164,8 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> > pipe_config->has_pch_encoder = true;
> >  
> > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > +   pipe_config->output_colorspace = intel_conn_state-
> > >base.colorspace;
> > +
> > if (lspcon->active)
> > lspcon_ycbcr420_config(&intel_connector->base,
> > pipe_config);
> > else
> > @@ -4408,6 +4410,26 @@ u8 intel_dp_dsc_get_slice_count(struct
> > intel_dp *intel_dp,
> > return 0;
> >  }
> >  
> > +bool
> > +intel_dp_needs_vsc_colorimetry(u32 colorspace)
> 
> I would pass the entire crtc state here so you handle handle the
> 4:2:0
> case here as well.
> 
Okay, I'll pass the entire intel_crtc_state stucture value to
intel_dp_needs_vsc_colorimetry() for checking output format (YCbCr
4:2:0)  and output colorspace here. And I'll change the fuction name to
intel_dp_needs_vsc_sdp().
> > +{
> > +   bool ret = false;
> 
> Pointless variable.
> 
I'll remove pointless variables.
> > +
> > +   switch (colorspace) {
> > +   case DRM_MODE_COLORIMETRY_SYCC_601:
> > +   case DRM_MODE_COLORIMETRY_OPYCC_601:
> > +   case DRM_MODE_COLORIMETRY_BT2020_YCC:
> > +   case DRM_MODE_COLORIMETRY_BT2020_RGB:
> > +   case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> > +   ret = true;
> > +   break;
> > +   default:
> > +   break;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static void
> >  intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
> >const struct intel_crtc_state *crtc_state,
> > @@ -4536,7 +4558,8 @@ void intel_dp_vsc_enable(struct intel_dp
> > *intel_dp,
> >  co

Re: [Intel-gfx] [PATCH v2 3/6] drm: Add DisplayPort colorspace property

2019-09-02 Thread Mun, Gwan-gyeong
On Mon, 2019-09-02 at 17:44 +0300, Ville Syrjälä wrote:
> On Fri, Aug 23, 2019 at 12:52:29PM +0300, Gwan-gyeong Mun wrote:
> > In order to use colorspace property to Display Port connectors, it
> > extends
> > DRM_MODE_CONNECTOR_DisplayPort connector_type on
> > drm_mode_create_colorspace_property function.
> > 
> > Signed-off-by: Gwan-gyeong Mun 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 4c766624b20d..655ada9d4c16 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1703,7 +1703,9 @@ int
> > drm_mode_create_colorspace_property(struct drm_connector
> > *connector)
> > struct drm_property *prop;
> >  
> > if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > -   connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> > +   connector->connector_type == DRM_MODE_CONNECTOR_HDMIB ||
> > +   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
> > ||
> > +   connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> 
> We don't need a separate set of enum values for DP?
> 
I checked DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry again,
Followed your comments, the spec requires more new colorimetry options
for DP 1.4a colorimetry format.
I'll add missed colorimetry options and will separate set of
colorimetry enum values for DP.

> > prop = drm_property_create_enum(dev,
> > DRM_MODE_PROP_ENUM,
> > "Colorspace",
> > hdmi_colorspaces,
> > -- 
> > 2.22.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: add plural() helper for logging plurals

2019-09-02 Thread Joonas Lahtinen
Quoting Jani Nikula (2019-09-02 21:29:16)
> Add a helper instead of open coding the plurals in debug logs. Also
> fixes the case for "0 display pipes available."
> 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> I stumbled upon the pipes one while working on ->num_pipes. I honestly
> thought we'd have more users than this, but to my surprise couldn't find
> any. Perhaps this is not worth it after all.

Just a debug string, less hassle with "display pipes available: %d"?

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

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata

2019-09-02 Thread Mun, Gwan-gyeong
On Tue, 2019-08-27 at 01:14 +0530, Shankar, Uma wrote:
> > -Original Message-
> > From: Mun, Gwan-gyeong
> > Sent: Friday, August 23, 2019 3:23 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Shankar, Uma <
> > uma.shan...@intel.com>;
> > Sharma, Shashank 
> > Subject: [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP
> > Header and DB for
> > HDR Static Metadata
> > 
> > Function intel_dp_setup_hdr_metadata_infoframe_sdp handles
> > Infoframe SDP
> > header and data block setup for HDR Static Metadata. It enables
> > writing of HDR
> > metadata infoframe SDP to panel. Support for HDR video was
> > introduced in
> > DisplayPort 1.4. It implements the CTA-861-G standard for transport
> > of static HDR
> > metadata. The HDR Metadata will be provided by userspace
> > compositors, based on
> > blending policies and passed to the driver through a blob property.
> > 
> > Because each of GEN11 and prior GEN11 have different register size
> > for HDR
> > Metadata Infoframe SDP packet, it adds and uses different register
> > size.
> > 
> > Setup Infoframe SDP header and data block in function
> > intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata
> > as per dp 1.4
> > spec and CTA-861-F spec.
> > As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range
> > and Mastering
> > Infoframe for HDR content, which is defined in CTA-861-F spec.
> > According to DP 1.4 spec and CEA-861-F spec Table 5, in order to
> > transmit static HDR
> > metadata, we have to use Non-audio INFOFRAME SDP v1.3.
> > 
> > ++---+
> > >  [ Packet Type Value ] |   [ Packet Type ] |
> > ++---+
> > > 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
> > ++---+
> > >  [Transmission Timing] |
> > ++
> > > As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
> > > which Dynamic Range and Mastering INFOFRAME are defined|
> > ++
> > 
> > v2: Add a missed blank line after function declaration.
> > 
> > Signed-off-by: Gwan-gyeong Mun 
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c |  1 +
> > drivers/gpu/drm/i915/display/intel_dp.c  | 91
> > 
> > drivers/gpu/drm/i915/display/intel_dp.h  |  3 +
> > drivers/gpu/drm/i915/i915_reg.h  |  1 +
> > 4 files changed, 96 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 5c42b58c1c2f..9f5bea941bcd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3478,6 +3478,7 @@ static void intel_enable_ddi_dp(struct
> > intel_encoder
> > *encoder,
> > intel_edp_backlight_on(crtc_state, conn_state);
> > intel_psr_enable(intel_dp, crtc_state);
> > intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
> > +   intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
> > intel_edp_drrs_enable(intel_dp, crtc_state);
> > 
> > if (crtc_state->has_audio)
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 7218e159f55d..00da8221eaba 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4554,6 +4554,85 @@ intel_dp_setup_vsc_sdp(struct intel_dp
> > *intel_dp,
> > crtc_state, DP_SDP_VSC, &vsc_sdp,
> > sizeof(vsc_sdp));  }
> > 
> > +static int
> > +intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp
> > *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + const struct
> > drm_connector_state
> 
> The return value is not handled, you may convert it as void.
> 
Okay, I'll remove the return values which is not handled from
intel_dp_setup_hdr_metadata_infoframe_sdp().

> > *conn_state) {
> > +   struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv = to_i915(intel_dig_port-
> > >base.base.dev);
> > +   struct dp_sdp infoframe_sdp = {};
> > +   struct hdmi_drm_infoframe drm_infoframe = {};
> > +   const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
> > HDMI_DRM_INFOFRAME_SIZE;
> > +   unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
> > HDMI_DRM_INFOFRAME_SIZE];
> > +   ssize_t len;
> > +   int ret;
> > +
> > +   ret = drm_hdmi_infoframe_set_hdr_metadata(&drm_infoframe,
> > conn_state);
> > +   if (ret) {
> > +   DRM_DEBUG_KMS("couldn't set HDR metadata in
> > infoframe\n");
> > +   return ret;
> > +   }
> > +
> > +   len = hdmi_drm_infoframe_pack_only(&drm_info

[Intel-gfx] [PATCH v3 0/6] drm/i915/dp: Support for DP HDR outputs

2019-09-02 Thread Gwan-gyeong Mun
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe SDP to the panel.
The HDR Metadata will be provided by userspace compositors, based on
blending policies and passed to the driver through a blob property.
And It refactors, renames and extends a function which handled vsc sdp
header and data block setup for supporting colorimetry format.
And It attaches the colorspace connector property and HDR metadata property
to a DisplayPort connector.

These patches tested on below test environment.
Test Environment:
 - Tested System: GLK and Gen11 platform.
 - Monitor: Dell UP2718Q 4K HDR Monitor.
 - In order to test DP HDR10, test environment uses patched Kodi-gbm,
   patched Media driver and HDR10 video.

   You can find these on below.
   [patched Kodi-gbm]
- repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr 
   [download 4K HDR video file]
- link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/
   [Media Driver for GLK]
- repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver
  master branch
   [Media Driver for ICL]
- repo: https://github.com/harishkrupo/media-driver/tree/p010_composite

v2:
 - Add a missed blank line after function declaration.
 - Remove useless parentheses.
 - Minor style fix.

v3:
 - Remove not handled return values from
   intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]
 - Add handling of different register size for
   HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
   platforms [Uma]
 - Add new colorimetry options for DP 1.4a spec. [Ville]
 - Separate set of colorimetry enum values for DP. [Ville]
 - In order to checking output format and output colorspace on
   intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.[Ville]
 - Remove a pointless variable. [Ville]

Gwan-gyeong Mun (7):
  drm/i915/dp: Extend program of VSC Header and DB for Colorimetry
Format
  drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
  drm: Add DisplayPort colorspace property
  drm/i915/dp: Attach colorspace property
  drm/i915: Add new GMP register size for GEN11
  drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static
Metadata
  drm/i915/dp: Attach HDR metadata property to DP connector

 drivers/gpu/drm/drm_connector.c   |  43 
 drivers/gpu/drm/i915/display/intel_ddi.c  |  10 +-
 drivers/gpu/drm/i915/display/intel_display.h  |   2 -
 .../drm/i915/display/intel_display_types.h|   3 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 193 --
 drivers/gpu/drm/i915/display/intel_dp.h   |   7 +
 drivers/gpu/drm/i915/display/intel_hdmi.c |  10 +-
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 include/drm/drm_connector.h   |   8 +
 9 files changed, 256 insertions(+), 21 deletions(-)

-- 
2.23.0

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

[Intel-gfx] [PATCH v3 3/7] drm: Add DisplayPort colorspace property

2019-09-02 Thread Gwan-gyeong Mun
In order to use colorspace property to Display Port connectors, it extends
DRM_MODE_CONNECTOR_DisplayPort connector_type on
drm_mode_create_colorspace_property function.

v3: Addressed review comments from Ville
- Add new colorimetry options for DP 1.4a spec.
- Separate set of colorimetry enum values for DP.

Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/drm_connector.c | 43 +
 include/drm/drm_connector.h |  8 ++
 2 files changed, 51 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..013cf96e3012 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -882,6 +882,41 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] 
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
 };
 
+/*
+ * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel 
Encoding/Colorimetry
+ * Format Table 2-120
+ */
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+   /* For Default case, driver will set the colorspace */
+   { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+   /* Colorimetry based on IEC 61966-2-1 */
+   { DRM_MODE_COLORIMETRY_SRGB, "sRGB" },
+   { DRM_MODE_COLORIMETRY_WIDE_GAMUT_FIXED_POINT_RGB, 
"RGB_wide_gamut_fixed_point" },
+   /* Colorimetry based on IEC 61966-2-2 */
+   { DRM_MODE_COLORIMETRY_SCRGB, "scRGB" },
+   { DRM_MODE_COLORIMETRY_ADOBE_RGB, "Adobe_RGB" },
+   /* Colorimetry based on SMPTE RP 431-2 */
+   { DRM_MODE_COLORIMETRY_DCP_P3_RGB, "DCI-P3_RGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+   { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
+   { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+   /* Colorumetry for Y Only */
+   { DRM_MODE_COLORIMETRY_DICOM_PART_14_GRAYSCALE, 
"DICOM_Part_14_Grayscale_Display_Function" },
+};
+
 /**
  * DOC: standard connector properties
  *
@@ -1710,6 +1745,14 @@ int drm_mode_create_colorspace_property(struct 
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspaces));
if (!prop)
return -ENOMEM;
+   } else if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort 
||
+  connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+   "Colorspace",
+   dp_colorspaces,
+   ARRAY_SIZE(dp_colorspaces));
+   if (!prop)
+   return -ENOMEM;
} else {
DRM_DEBUG_KMS("Colorspace property not supported\n");
return 0;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 681cb590f952..8848e5d6b0c4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -281,6 +281,14 @@ enum drm_panel_orientation {
 /* Additional Colorimetry extension added as part of CTA 861.G */
 #define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D6511
 #define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER12
+/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
+#define DRM_MODE_COLORIMETRY_SRGB  13
+#define DRM_MODE_COLORIMETRY_WIDE_GAMUT_FIXED_POINT_RGB14
+#define DRM_MODE_COLORIMETRY_SCRGB 15
+#define DRM_MODE_COLORIMETRY_ADOBE_RGB 16
+#define DRM_MODE_COLORIMETRY_DCP_P3_RGB17
+#define DRM_MODE_COLORIMETRY_BT601_YCC 18
+#define DRM_MODE_COLORIMETRY_DICOM_PART_14_GRAYSCALE   19
 
 /**
  * enum drm_bus_flags - bus_flags info for &drm_display_info
-- 
2.23.0

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

[Intel-gfx] [PATCH v3 1/7] drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format

2019-09-02 Thread Gwan-gyeong Mun
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it adds an argument
of drm_connector_state type.

Setup VSC header and data block in function intel_dp_setup_vsc_sdp for
pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1,
table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120: VSC SDP Payload for DB16 through DB18.

Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.h |  2 -
 drivers/gpu/drm/i915/display/intel_dp.c  | 68 
 drivers/gpu/drm/i915/display/intel_dp.h  |  3 +
 4 files changed, 60 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1fe0bf01e580..49c35af583f9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3610,7 +3610,7 @@ static void intel_enable_ddi_dp(struct intel_encoder 
*encoder,
 
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
-   intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
+   intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
 
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index 33fd523c4622..8de63be75620 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -526,8 +526,6 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
  struct intel_crtc_state *pipe_config);
 void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
  enum link_m_n_set m_n);
-void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
-  const struct intel_crtc_state *crtc_state);
 int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
 bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5673ed75e428..776be3e16ac6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4446,8 +4446,9 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
 }
 
 static void
-intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
-  const struct intel_crtc_state *crtc_state)
+intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct dp_sdp vsc_sdp = {};
@@ -4468,13 +4469,55 @@ intel_pixel_encoding_setup_vsc(struct intel_dp 
*intel_dp,
 */
vsc_sdp.sdp_header.HB3 = 0x13;
 
-   /*
-* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
-* DB16[3:0] DP 1.4a spec, Table 2-120
-*/
-   vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
-   /* RGB->YCBCR color conversion uses the BT.709 color space. */
-   vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+   /* DP 1.4a spec, Table 2-120 */
+   switch (crtc_state->output_format) {
+   case INTEL_OUTPUT_FORMAT_YCBCR444:
+   vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
+   break;
+   case INTEL_OUTPUT_FORMAT_YCBCR420:
+   vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
+   break;
+   case INTEL_OUTPUT_FORMAT_RGB:
+   default:
+   /* RGB: DB16[7:4] = 0h */
+   break;
+   }
+
+   switch (conn_state->colorspace) {
+   case DRM_MODE_COLORIMETRY_BT709_YCC:
+   vsc_sdp.db[16] |= 0x1;
+   break;
+   case DRM_MODE_COLORIMETRY_XVYCC_601:
+   vsc_sdp.db[16] |= 0x2;
+   break;
+   case DRM_MODE_COLORIMETRY_XVYCC_709:
+   vsc_sdp.db[16] |= 0x3;
+   break;
+   case DRM_MODE_COLORIMETRY_SYCC_601:
+   vsc_sdp.db[16] |= 0x4;
+   break;
+   case DRM_MODE_COLORIMETRY_OPYCC_601:
+   vsc_sdp.db[16] |= 0x5;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+   case DRM_MODE_COLORIMETRY_BT2020_RGB:
+   vsc_sdp.db[16] |= 0x6;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_YCC:
+   vsc_sdp.db[16] |= 0x7;
+   break;
+   case DRM_MODE_COLORIMETRY_DCI_

[Intel-gfx] [PATCH v3 6/7] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata

2019-09-02 Thread Gwan-gyeong Mun
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
static HDR metadata. The HDR Metadata will be provided by userspace
compositors, based on blending policies and passed to the driver through
a blob property.

Because each of GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet, it adds and uses different register
size.

Setup Infoframe SDP header and data block in function
intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per
dp 1.4 spec and CTA-861-F spec.
As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and
Mastering Infoframe for HDR content, which is defined in CTA-861-F spec.
According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.

++---+
|  [ Packet Type Value ] |   [ Packet Type ] |
++---+
| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
++---+
|  [Transmission Timing] |
++
| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
| which Dynamic Range and Mastering INFOFRAME are defined|
++

v2: Add a missed blank line after function declaration.
v3: Remove not handled return values from
intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_ddi.c |  1 +
 drivers/gpu/drm/i915/display/intel_dp.c  | 89 
 drivers/gpu/drm/i915/display/intel_dp.h  |  3 +
 3 files changed, 93 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 87dc5a19cb7b..111a5c95be85 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3612,6 +3612,7 @@ static void intel_enable_ddi_dp(struct intel_encoder 
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
+   intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
 
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9fa107d720ee..7fcc9f28d2e7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4596,6 +4596,83 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
crtc_state, DP_SDP_VSC, &vsc_sdp, sizeof(vsc_sdp));
 }
 
+static void
+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state 
*crtc_state,
+ const struct drm_connector_state 
*conn_state)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = 
to_i915(intel_dig_port->base.base.dev);
+   struct dp_sdp infoframe_sdp = {};
+   struct hdmi_drm_infoframe drm_infoframe = {};
+   const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE + 
HDMI_DRM_INFOFRAME_SIZE;
+   unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
+   ssize_t len;
+   int ret;
+
+   ret = drm_hdmi_infoframe_set_hdr_metadata(&drm_infoframe, conn_state);
+   if (ret) {
+   DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+   return;
+   }
+
+   len = hdmi_drm_infoframe_pack_only(&drm_infoframe, buf, sizeof(buf));
+   if (len < 0) {
+   DRM_DEBUG_KMS("buffer size is smaller than hdr metadata 
infoframe\n");
+   return;
+   }
+
+   if (len != infoframe_size) {
+   DRM_DEBUG_KMS("wrong static hdr metadata size\n");
+   return;
+   }
+
+   /*
+* Set up the infoframe sdp packet for HDR static metadata.
+* Prepare VSC Header for SU as per DP 1.4a spec,
+* Table 2-100 and Table 2-101
+*/
+
+   /* Packet ID, 00h for non-Audio INFOFRAME */
+   infoframe_sdp.sdp_header.HB0 = 0;
+   /*
+* Packet Type 80h + Non-audio INFOFRAME Type value
+* HDMI_INFOFRAME_TYPE_DRM: 0x87,
+*/
+   infoframe_sdp.sdp_header.HB1 = drm_infoframe.type;
+   /*
+* Least Significant Eight Bits of (Data Byte Count – 1)
+ 

[Intel-gfx] [PATCH v3 5/7] drm/i915: Add new GMP register size for GEN11

2019-09-02 Thread Gwan-gyeong Mun
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Uma's review comments.

Signed-off-by: Gwan-gyeong Mun 
---
 drivers/gpu/drm/i915/display/intel_hdmi.c | 10 --
 drivers/gpu/drm/i915/i915_reg.h   |  1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c500fc9154c8..287999b31217 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -189,13 +189,19 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
}
 }
 
-static int hsw_dip_data_size(unsigned int type)
+static int hsw_dip_data_size(struct drm_i915_private *dev_priv,
+unsigned int type)
 {
switch (type) {
case DP_SDP_VSC:
return VIDEO_DIP_VSC_DATA_SIZE;
case DP_SDP_PPS:
return VIDEO_DIP_PPS_DATA_SIZE;
+   case HDMI_PACKET_TYPE_GAMUT_METADATA:
+   if (INTEL_GEN(dev_priv) >= 11)
+   return VIDEO_DIP_GMP_DATA_SIZE;
+   else
+   return VIDEO_DIP_DATA_SIZE;
default:
return VIDEO_DIP_DATA_SIZE;
}
@@ -514,7 +520,7 @@ static void hsw_write_infoframe(struct intel_encoder 
*encoder,
int i;
u32 val = I915_READ(ctl_reg);
 
-   data_size = hsw_dip_data_size(type);
+   data_size = hsw_dip_data_size(dev_priv, type);
 
val &= ~hsw_infoframe_enable(type);
I915_WRITE(ctl_reg, val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6c43b8c583bb..8b31ad7426d6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4667,6 +4667,7 @@ enum {
  * (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each 
byte
  * of the infoframe structure specified by CEA-861. */
 #define   VIDEO_DIP_DATA_SIZE  32
+#define   VIDEO_DIP_GMP_DATA_SIZE  36
 #define   VIDEO_DIP_VSC_DATA_SIZE  36
 #define   VIDEO_DIP_PPS_DATA_SIZE  132
 #define VIDEO_DIP_CTL  _MMIO(0x61170)
-- 
2.23.0

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

[Intel-gfx] [PATCH v3 7/7] drm/i915/dp: Attach HDR metadata property to DP connector

2019-09-02 Thread Gwan-gyeong Mun
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.

v2: Minor style fix

Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7fcc9f28d2e7..2466d7aff670 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6536,6 +6536,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
 
intel_attach_colorspace_property(connector);
 
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+   drm_object_attach_property(&connector->base,
+  
connector->dev->mode_config.hdr_output_metadata_property,
+  0);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
 
-- 
2.23.0

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

[Intel-gfx] [PATCH v3 2/7] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA

2019-09-02 Thread Gwan-gyeong Mun
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_sdp function.
If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
it uses MSA with VSC SDP.

As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
Color Encoding Format and Content Color Gamut] while sending
BT.2020 Colorimetry signals we should program MSA MISC1 fields which
indicate VSC SDP for the Pixel Encoding/Colorimetry Format.

v2: Remove useless parentheses
v3: Addressed review comments from Ville
- In order to checking output format and output colorspace on
  intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.
- Remove a pointless variable.

Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_ddi.c  |  7 +++--
 .../drm/i915/display/intel_display_types.h|  3 ++
 drivers/gpu/drm/i915/display/intel_dp.c   | 29 ++-
 drivers/gpu/drm/i915/display/intel_dp.h   |  1 +
 4 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 49c35af583f9..87dc5a19cb7b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1737,11 +1737,12 @@ void intel_ddi_set_pipe_settings(const struct 
intel_crtc_state *crtc_state)
/*
 * As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
 * of Color Encoding Format and Content Color Gamut] while sending
-* YCBCR 420 signals we should program MSA MISC1 fields which
-* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
+* which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
 */
-   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   if (intel_dp_needs_vsc_sdp(crtc_state))
temp |= TRANS_MSA_USE_VSC_SDP;
+
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 61277a87dbe7..c62bad369c8e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -971,6 +971,9 @@ struct intel_crtc_state {
/* Output format RGB/YCBCR etc */
enum intel_output_format output_format;
 
+   /* Output colorspace sRGB/BT.2020 etc */
+   u32 output_colorspace;
+
/* Output down scaling is done in LSPCON device */
bool lspcon_downsampling;
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 776be3e16ac6..6b7587c71e49 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2187,6 +2187,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
 
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+   pipe_config->output_colorspace = intel_conn_state->base.colorspace;
+
if (lspcon->active)
lspcon_ycbcr420_config(&intel_connector->base, pipe_config);
else
@@ -4445,6 +4447,31 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp 
*intel_dp,
return 0;
 }
 
+bool
+intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state)
+{
+   /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut], in order to
+* sending YCBCR 420 or HDR BT.2020 signals we should use DP VSC SDP.
+*/
+   if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+   return true;
+
+   switch (crtc_state->output_colorspace) {
+   case DRM_MODE_COLORIMETRY_SYCC_601:
+   case DRM_MODE_COLORIMETRY_OPYCC_601:
+   case DRM_MODE_COLORIMETRY_BT2020_YCC:
+   case DRM_MODE_COLORIMETRY_BT2020_RGB:
+   case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+   return true;
+   default:
+   break;
+   }
+
+   return false;
+}
+
 static void
 intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
   const struct intel_crtc_state *crtc_state,
@@ -4573,7 +4600,7 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
 const struct intel_crtc_state *crtc_state,
 const struct drm_connector_state *conn_state)
 {
-   if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+   if (!intel_dp_needs_vsc_sdp(crtc_state))
return;
 
intel_dp_setup_vsc_sdp(intel_dp, crtc_state, conn_state);
diff --git a/drivers/gpu/

[Intel-gfx] [PATCH v3 4/7] drm/i915/dp: Attach colorspace property

2019-09-02 Thread Gwan-gyeong Mun
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.

Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT2020 on a
sink device.

Signed-off-by: Gwan-gyeong Mun 
Reviewed-by: Uma Shankar 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6b7587c71e49..9fa107d720ee 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6445,6 +6445,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
 
+   intel_attach_colorspace_property(connector);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
 
-- 
2.23.0

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Support for DP HDR outputs (rev3)

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: Support for DP HDR outputs (rev3)
URL   : https://patchwork.freedesktop.org/series/65656/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
28f17eec1ca7 drm/i915/dp: Extend program of VSC Header and DB for Colorimetry 
Format
103f5c27ed40 drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
-:22: WARNING:TYPO_SPELLING: 'stucture' may be misspelled - perhaps 'structure'?
#22: 
  intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.

total: 0 errors, 1 warnings, 0 checks, 78 lines checked
2e38249baa8a drm: Add DisplayPort colorspace property
-:57: WARNING:LONG_LINE: line over 100 characters
#57: FILE: drivers/gpu/drm/drm_connector.c:917:
+   { DRM_MODE_COLORIMETRY_DICOM_PART_14_GRAYSCALE, 
"DICOM_Part_14_Grayscale_Display_Function" },

total: 0 errors, 1 warnings, 0 checks, 69 lines checked
ff741deda5d7 drm/i915/dp: Attach colorspace property
64406618c61b drm/i915: Add new GMP register size for GEN11
f26a6477df16 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static 
Metadata
832ec8e38954 drm/i915/dp: Attach HDR metadata property to DP connector

___
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/dp: Support for DP HDR outputs (rev3)

2019-09-02 Thread Patchwork
== Series Details ==

Series: drm/i915/dp: Support for DP HDR outputs (rev3)
URL   : https://patchwork.freedesktop.org/series/65656/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6823 -> Patchwork_14262


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_14262 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_14262, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_14262:

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-ilk-650: NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-ilk-650/igt@run...@aborted.html
- fi-bdw-gvtdvm:  NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-bdw-gvtdvm/igt@run...@aborted.html
- fi-snb-2520m:   NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-snb-2520m/igt@run...@aborted.html
- fi-whl-u:   NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-whl-u/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-ivb-3770/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-bxt-dsi/igt@run...@aborted.html
- fi-byt-j1900:   NOTRUN -> [FAIL][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-byt-j1900/igt@run...@aborted.html
- fi-bsw-n3050:   NOTRUN -> [FAIL][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-bsw-n3050/igt@run...@aborted.html
- fi-apl-guc: NOTRUN -> [FAIL][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-apl-guc/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-bdw-5557u/igt@run...@aborted.html
- fi-byt-n2820:   NOTRUN -> [FAIL][11]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-byt-n2820/igt@run...@aborted.html
- fi-elk-e7500:   NOTRUN -> [FAIL][12]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-elk-e7500/igt@run...@aborted.html

  
 Warnings 

  * igt@runner@aborted:
- fi-bsw-kefka:   [FAIL][13] ([fdo#110446]) -> [FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6823/fi-bsw-kefka/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-bsw-kefka/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_14262 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [PASS][15] -> [INCOMPLETE][16] ([fdo#107718])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6823/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#110446]: https://bugs.freedesktop.org/show_bug.cgi?id=110446


Participating hosts (52 -> 46)
--

  Additional (1): fi-byt-j1900 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_6823 -> Patchwork_14262

  CI-20190529: 20190529
  CI_DRM_6823: 8f0a4755577623776cfb9e1a52eb8e873562bce5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5163: 9bd37d5e307748a5b43e92a5b0ea9be8fc60b339 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_14262: 832ec8e38954d4f756eb4eb9538a51934869f1e3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

832ec8e38954 drm/i915/dp: Attach HDR metadata property to DP connector
f26a6477df16 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static 
Metadata
64406618c61b drm/i915: Add new GMP register size for GEN11
ff741deda5d7 drm/i915/dp: Attach colorspace property
2e38249baa8a drm: Add DisplayPort colorspace property
103f5c27ed40 drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
28f17eec1ca7 drm/i915/dp: Extend program of VSC Header and DB for Colorimetry 
Format

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14262/
___
Intel-gfx mailing list
Intel-gfx@lists.f

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Remove unused __engines_name()

2019-09-02 Thread Joonas Lahtinen
Quoting Chris Wilson (2019-09-01 14:04:31)
> This function was never used and probably will never be used, so remove
> it.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] [PATCH] drm/i915: Protect debugfs per_file_stats with RCU lock

2019-09-02 Thread Chris Wilson
If we make sure we grab a strong reference to each object as we dump it,
we can reduce the locks outside of our iterators to an rcu_read_lock.

This should prevent errors like:
[ 2138.371911] BUG: KASAN: use-after-free in per_file_stats+0x43/0x380 [i915]
[ 2138.371924] Read of size 8 at addr 888223651000 by task cat/8293

[ 2138.371947] CPU: 0 PID: 8293 Comm: cat Not tainted 5.3.0-rc6-CI-Custom_4352+ 
#1
[ 2138.371953] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./J4205-ITX, BIOS P1.40 07/14/2017
[ 2138.371959] Call Trace:
[ 2138.371974]  dump_stack+0x7c/0xbb
[ 2138.372099]  ? per_file_stats+0x43/0x380 [i915]
[ 2138.372108]  print_address_description+0x73/0x3a0
[ 2138.372231]  ? per_file_stats+0x43/0x380 [i915]
[ 2138.372352]  ? per_file_stats+0x43/0x380 [i915]
[ 2138.372362]  __kasan_report+0x14e/0x192
[ 2138.372489]  ? per_file_stats+0x43/0x380 [i915]
[ 2138.372502]  kasan_report+0xe/0x20
[ 2138.372625]  per_file_stats+0x43/0x380 [i915]
[ 2138.372751]  ? i915_panel_show+0x110/0x110 [i915]
[ 2138.372761]  idr_for_each+0xa7/0x160
[ 2138.372773]  ? idr_get_next_ul+0x110/0x110
[ 2138.372782]  ? do_raw_spin_lock+0x10a/0x1d0
[ 2138.372923]  print_context_stats+0x264/0x510 [i915]

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9798f27a697a..708855e051b5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -237,6 +237,9 @@ static int per_file_stats(int id, void *ptr, void *data)
struct file_stats *stats = data;
struct i915_vma *vma;
 
+   if (!kref_get_unless_zero(&obj->base.refcount))
+   return 0;
+
stats->count++;
stats->total += obj->base.size;
if (!atomic_read(&obj->bind_count))
@@ -284,6 +287,7 @@ static int per_file_stats(int id, void *ptr, void *data)
}
spin_unlock(&obj->vma.lock);
 
+   i915_gem_object_put(obj);
return 0;
 }
 
@@ -313,10 +317,12 @@ static void print_context_stats(struct seq_file *m,
i915_gem_context_lock_engines(ctx), it) {
intel_context_lock_pinned(ce);
if (intel_context_is_pinned(ce)) {
+   rcu_read_lock();
if (ce->state)
per_file_stats(0,
   ce->state->obj, &kstats);
per_file_stats(0, ce->ring->vma->obj, &kstats);
+   rcu_read_unlock();
}
intel_context_unlock_pinned(ce);
}
@@ -328,9 +334,9 @@ static void print_context_stats(struct seq_file *m,
struct task_struct *task;
char name[80];
 
-   spin_lock(&file->table_lock);
+   rcu_read_lock();
idr_for_each(&file->object_idr, per_file_stats, &stats);
-   spin_unlock(&file->table_lock);
+   rcu_read_unlock();
 
rcu_read_lock();
task = pid_task(ctx->pid ?: file->pid, PIDTYPE_PID);
-- 
2.23.0

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