Re: [Intel-gfx] [PATCH] Implement Limited Video Range

[Daniel Vetter]

On Mon, Nov 30, 2015 at 08:08:48AM +0100, Peter Frühberger wrote:
> (Resent cause of moderation)
> 
> This implements a highly needed feature in a minimal non instructive way.
> Consider a Limited Range display (like most TVs) where you want to watch a
> decoded video. The TV is set to limited range and the intel driver also
> uses full scaling Limited 16:235 mode, e.g. if you display the gray value
> 16 - the driver will postprocess it to something like ~ 22.
> 
> The following happens currently in linux intel video world:
> Video is decoded with e.g. vaapi, the decoded surface is either used via
> EGL directly in Limited Range. Limited Range processing takes place and at
> the end while rendering the intel driver will scale down the limited range
> data again as it cannot distunguish of the data it gets when e.g. rendering
> with OpenGL like we succesfully do in kodi.
> 
> Another use case is vaapi when using the old vaCopySurfaceGLX
> (vaPutSurface) which would automatically use BT601 / BT709 matrix to
> upscale the content without any dithering to Full Range RGB. Later on this
> is scaled down again with the Limited 16:235 setting and output. Quality
> degrades two times.
> 
> Users and applications widely used want to make sure that colors appear on
> screen like they were processed after the last processing step. In video
> case two use cases make sense:
> 
> a) scaling limited range to full range with dithering applied when you need
> to output fullrange
> b) already having limited range and outputting that without any further
> touching by the driver
> 
> Use case a) is already possible. Usecase b) will be possible with the
> attached patch. It is a possibility to get Limited Range on screen in
> perfect quality in 2k15.
> 
> For the future a userspace api to provide info frames and so on in a
> generic way should be considered but until we have this I bet we have 2
> years to go. This solution also works on X11 (without wayland) and is
> useful for existing applications.
> 
> Thanks much for consideration.
> 
> ---
> From deaa9d730c08aefefe3671d073d93d970bb39a31 Mon Sep 17 00:00:00 2001
> From: fritsch 
> Date: Sun, 29 Nov 2015 16:38:14 +0100
> Subject: [PATCH] Intel: Implement Video Color Range
> 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_display.c |  4 ++--
>  drivers/gpu/drm/i915/intel_drv.h |  8 
>  drivers/gpu/drm/i915/intel_hdmi.c| 17 +++--
>  drivers/gpu/drm/i915/intel_modes.c   |  1 +
>  5 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 95bb27d..e453461 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3449,6 +3449,7 @@ int intel_freq_opcode(struct drm_i915_private
> *dev_priv, int val);
>  #define INTEL_BROADCAST_RGB_AUTO 0
>  #define INTEL_BROADCAST_RGB_FULL 1
>  #define INTEL_BROADCAST_RGB_LIMITED 2
> +#define INTEL_BROADCAST_RGB_VIDEO 3
> 
>  static inline uint32_t i915_vgacntrl_reg(struct drm_device *dev)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 71860f8..ea40d81 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8605,7 +8605,7 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
>* consideration.
>*/
> 
> - if (intel_crtc->config->limited_color_range)
> + if (intel_crtc->config->limited_color_range &&
> !intel_crtc->config->video_color_range)
>   coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
> 
>   /*
> @@ -8629,7 +8629,7 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
>   if (INTEL_INFO(dev)->gen > 6) {
>   uint16_t postoff = 0;
> 
> - if (intel_crtc->config->limited_color_range)
> + if (intel_crtc->config->limited_color_range &&
> !intel_crtc->config->video_color_range)
>   postoff = (16 * (1 << 12) / 255) & 0x1fff;
> 
>   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), postoff);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0598932..6940243 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -372,6 +372,13 @@ struct intel_crtc_state {
>*/
>   bool limited_color_range;
> 
> + /*
> +  *
> +  * Use reduced/limited/broadcast rgb range without compressing.
> +  *
> +  */
> + bool video_color_range;

I think the names and semantics are confusion, resulting in hard-to-read
if conditions. What about:

bool limit_color_range; /* should we limit from full->16:235 in
the encoder/csc? */

bool limited_color_range_output; /* set the infoframe or not? */

Names aren't great yet I think, coffee's not yet working ;-)

Thanks, Daniel

> +
>   /* DP has a bunch of special case unfortunately, so mark the pipe
>* accordingly. */
>   bool has_dp_encoder;
> @@ -682,6 +689,7 @@ struct intel_hdmi {
>   int 

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Calculate watermark related members in the crtc_state, v3.

[Maarten Lankhorst]

Op 25-11-15 om 10:22 schreef Ander Conselvan De Oliveira:
> On Tue, 2015-11-24 at 15:55 +0100, Maarten Lankhorst wrote:
>> Op 24-11-15 om 15:03 schreef Ander Conselvan De Oliveira:
>>> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
 This removes pre/post_wm_update from intel_crtc->atomic, and
 creates atomic state for it in intel_crtc.

 Changes since v1:
 - Rebase on top of wm changes.
 Changes since v2:
 - Split disable_cxsr into a separate patch.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
  drivers/gpu/drm/i915/intel_display.c | 31 +--
  drivers/gpu/drm/i915/intel_drv.h |  2 +-
  3 files changed, 15 insertions(+), 19 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_atomic.c
 b/drivers/gpu/drm/i915/intel_atomic.c
 index 9f0638a37b6d..4625f8a9ba12 100644
 --- a/drivers/gpu/drm/i915/intel_atomic.c
 +++ b/drivers/gpu/drm/i915/intel_atomic.c
 @@ -96,6 +96,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
crtc_state->disable_cxsr = false;
 +  crtc_state->wm_changed = false;
  
return _state->base;
  }
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index 5ee64e67ad8a..db4995406277 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -4741,6 +4741,8 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
  static void intel_post_plane_update(struct intel_crtc *crtc)
  {
struct intel_crtc_atomic_commit *atomic = >atomic;
 +  struct intel_crtc_state *pipe_config =
 +  to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
  
 @@ -4751,7 +4753,7 @@ static void intel_post_plane_update(struct
 intel_crtc
 *crtc)
  
crtc->wm.cxsr_allowed = true;
  
 -  if (crtc->atomic.update_wm_post)
 +  if (pipe_config->wm_changed)
intel_update_watermarks(>base);
>>> This adds an extra call to intel_update_watermarks() for the case where
>>> previously update_wm_pre would be set. This won't cause extra register
>>> writes
>>> because of the dirty check, but I think it deserves a note in the commit
>>> message.
>> I think intel_update_watermarks needs to be fixed to take a crtc_state and
>> whether pre/post commit is used.
>>
>> It looks to me like doing anything else could bug if watermarks are changed
>> with 1 plane becoming visible and the other invisible..
  
if (atomic->update_fbc)
 @@ -4784,6 +4786,9 @@ static void intel_pre_plane_update(struct intel_crtc
 *crtc)
crtc->wm.cxsr_allowed = false;
intel_set_memory_cxsr(dev_priv, false);
}
 +
 +  if (!needs_modeset(_config->base) && pipe_config
 ->wm_changed)
 +  intel_update_watermarks(>base);
  }
  
  static void intel_crtc_disable_planes(struct drm_crtc *crtc, unsigned
 plane_mask)
 @@ -11706,25 +11711,18 @@ int intel_plane_atomic_calc_changes(struct
 drm_crtc_state *crtc_state,
 plane->base.id, was_visible, visible,
 turn_off, turn_on, mode_changed);
  
 -  if (turn_on) {
 -  intel_crtc->atomic.update_wm_pre = true;
 -  /* must disable cxsr around plane enable/disable */
 -  if (plane->type != DRM_PLANE_TYPE_CURSOR) {
 -  pipe_config->disable_cxsr = true;
 -  /* to potentially re-enable cxsr */
 -  intel_crtc->atomic.wait_vblank = true;
 -  intel_crtc->atomic.update_wm_post = true;
 -  }
 -  } else if (turn_off) {
 -  intel_crtc->atomic.update_wm_post = true;
 +  if (turn_on || turn_off) {
 +  pipe_config->wm_changed = true;
 +
/* must disable cxsr around plane enable/disable */
if (plane->type != DRM_PLANE_TYPE_CURSOR) {
if (is_crtc_enabled)
intel_crtc->atomic.wait_vblank = true;
pipe_config->disable_cxsr = true;
}
 -  } else if (intel_wm_need_update(plane, plane_state)) {
 -  intel_crtc->atomic.update_wm_pre = true;
 +  } else if ((was_visible || visible) &&
>>> So this avoids watermark changes when the plane is not visible before or
>>> after
>>> the update. Wouldn't it be better to fix intel_wm_need_update() instead if
>>> returns true in that case?
>> If visible is changed wm_changed = true is always set. It would go through 
>> the
>> (turn_on || turn_off) case.
>>
>> I guess checking 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Perform dpll commit first.

[Maarten Lankhorst]

Op 26-11-15 om 15:41 schreef Ander Conselvan De Oliveira:
> On Tue, 2015-11-24 at 10:44 +0100, Maarten Lankhorst wrote:
>> Warn for the wrong mask in enable only. Disable will have the wrong mask
>> now because the new state is committed before disabling the old state.
> Why?
>
> Ander
>
This is required for async commit. In that case the state has to be committed 
while
still holding the connection_mutex, but the modeset itself is run 
asynchronously.
This also means that any modeset has to wait for previous modesets to complete,
otherwise the pll state may be updated incorrectly.

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

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Break busywaiting for requests on pending signals

[Tvrtko Ursulin]

On 29/11/15 08:47, Chris Wilson wrote:

The busywait in __i915_spin_request() does not respect pending signals
and so may consume the entire timeslice for the task instead of
returning to userspace to handle the signal.

In the worst case this could cause a delay in signal processing of 20ms,
which would be a noticeable jitter in cursor tracking. If a higher
resolution signal was being used, for example to provide fairness of a
server timeslices between clients, we could expect to detect some
unfairness between clients (i.e. some windows not updating as fast as
others). This issue was noticed when inspecting a report of poor
interactivity resulting from excessively high __i915_spin_request usage.

Fixes regression from
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
Author: Chris Wilson 
Date:   Tue Apr 7 16:20:41 2015 +0100

  drm/i915: Optimistically spin for the request completion

v2: Try to assess the impact of the bug

Signed-off-by: Chris Wilson 
Cc: Jens Axboe 
Cc; "Rogozhkin, Dmitry V" 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Eero Tamminen 
Cc: "Rantala, Valtteri" 
Cc: sta...@kernel.vger.org
---
  drivers/gpu/drm/i915/i915_gem.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)


One more time,

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko



diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33adc8f8ab20..87fc34f5899f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1146,7 +1146,7 @@ static bool missed_irq(struct drm_i915_private *dev_priv,
return test_bit(ring->id, _priv->gpu_error.missed_irq_rings);
  }

-static int __i915_spin_request(struct drm_i915_gem_request *req)
+static int __i915_spin_request(struct drm_i915_gem_request *req, int state)
  {
unsigned long timeout;

@@ -1158,6 +1158,9 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req)
if (i915_gem_request_completed(req, true))
return 0;

+   if (signal_pending_state(state, current))
+   break;
+
if (time_after_eq(jiffies, timeout))
break;

@@ -1197,6 +1200,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
struct drm_i915_private *dev_priv = dev->dev_private;
const bool irq_test_in_progress =
ACCESS_ONCE(dev_priv->gpu_error.test_irq_rings) & 
intel_ring_flag(ring);
+   int state = interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
DEFINE_WAIT(wait);
unsigned long timeout_expire;
s64 before, now;
@@ -1221,7 +1225,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
before = ktime_get_raw_ns();

/* Optimistic spin for the next jiffie before touching IRQs */
-   ret = __i915_spin_request(req);
+   ret = __i915_spin_request(req, state);
if (ret == 0)
goto out;

@@ -1233,8 +1237,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
for (;;) {
struct timer_list timer;

-   prepare_to_wait(>irq_queue, ,
-   interruptible ? TASK_INTERRUPTIBLE : 
TASK_UNINTERRUPTIBLE);
+   prepare_to_wait(>irq_queue, , state);

/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
@@ -1252,7 +1255,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
break;
}

-   if (interruptible && signal_pending(current)) {
+   if (signal_pending_state(state, current)) {
ret = -ERESTARTSYS;
break;
}


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

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Only spin whilst waiting on the current request

[Tvrtko Ursulin]

On 29/11/15 08:48, Chris Wilson wrote:

Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
spin timeout and so we will just be wasting CPU cycles.

v2: Check for logical inversion when rebasing - we were incorrectly
checking for this request being active, and instead busywaiting for
when the GPU was not yet processing the request of interest.

v3: Try another colour for the seqno names.
v4: Another colour for the function names.

Signed-off-by: Chris Wilson 
Cc: "Rogozhkin, Dmitry V" 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Eero Tamminen 
Cc: "Rantala, Valtteri" 
Cc: sta...@kernel.vger.org
---
  drivers/gpu/drm/i915/i915_drv.h | 27 +++
  drivers/gpu/drm/i915/i915_gem.c |  8 +++-
  2 files changed, 26 insertions(+), 9 deletions(-)


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bc865e234df2..d07041c1729d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2182,8 +2182,17 @@ struct drm_i915_gem_request {
struct drm_i915_private *i915;
struct intel_engine_cs *ring;

-   /** GEM sequence number associated with this request. */
-   uint32_t seqno;
+/** GEM sequence number associated with the previous request,
+ * when the HWS breadcrumb is equal to this the GPU is processing
+ * this request.
+ */
+   u32 previous_seqno;
+
+/** GEM sequence number associated with this request,
+ * when the HWS breadcrumb is equal or greater than this the GPU
+ * has finished processing this request.
+ */
+   u32 seqno;

/** Position in the ringbuffer of the start of the request */
u32 head;
@@ -2945,15 +2954,17 @@ i915_seqno_passed(uint32_t seq1, uint32_t seq2)
return (int32_t)(seq1 - seq2) >= 0;
  }

+static inline bool i915_gem_request_started(struct drm_i915_gem_request *req,
+  bool lazy_coherency)
+{
+   u32 seqno = req->ring->get_seqno(req->ring, lazy_coherency);
+   return i915_seqno_passed(seqno, req->previous_seqno);
+}
+
  static inline bool i915_gem_request_completed(struct drm_i915_gem_request 
*req,
  bool lazy_coherency)
  {
-   u32 seqno;
-
-   BUG_ON(req == NULL);
-
-   seqno = req->ring->get_seqno(req->ring, lazy_coherency);
-
+   u32 seqno = req->ring->get_seqno(req->ring, lazy_coherency);
return i915_seqno_passed(seqno, req->seqno);
  }

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bad112abb16b..ada461e02718 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1193,9 +1193,13 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
 * takes to sleep on a request, on the order of a microsecond.
 */

-   if (i915_gem_request_get_ring(req)->irq_refcount)
+   if (req->ring->irq_refcount)
return -EBUSY;

+   /* Only spin if we know the GPU is processing this request */
+   if (!i915_gem_request_started(req, false))
+   return -EAGAIN;
+
timeout = local_clock_us() + 10;
while (!need_resched()) {
if (i915_gem_request_completed(req, true))
@@ -1209,6 +1213,7 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)

cpu_relax_lowlatency();
}
+
if (i915_gem_request_completed(req, false))
return 0;

@@ -2592,6 +2597,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request,
request->batch_obj = obj;

request->emitted_jiffies = jiffies;
+   request->previous_seqno = ring->last_submitted_seqno;
ring->last_submitted_seqno = request->seqno;
list_add_tail(>list, >request_list);



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

Re: [Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl

[Chris Wilson]

On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote:
> So there's 3 competing proposals for what wait_ioctl should do wrt
> -EIO:
> 
> - return -EIO when the gpu is wedged. Not terribly useful for
>   userspace since it might race with a hang and then there's no
>   guarantee that a subsequent execbuf won't end up in an -EIO.
>   Terminally wedge really can only be reliably signalled at execbuf
>   time, and userspace needs to cope with that (or decide not to
>   bother).
> 
> - EIO for any obj that suffered from a reset. This means big internal
>   reorginazation in the kernel since currently we track reset stats
>   per-ctx and not on the obj. That's also what arb robustness wants.
>   We could do this, but this feels like new ABI territory with the
>   usual userspace requirements and high hurdles.
> 
> - No -EIO at all. Consistent with set_domain_ioctl and simplest to
>   implement. Which is what this patch does.

Since no one else is weighing into the ABI discussion, I'm happy with
losing EIO here. I thought it could be useful, but as no one is using or
seems likely to start using it, begone.

> We can always opt to change this later on if there's a real need.
> 
> To make the test really exercise this do a full wedged gpu hang, to
> make sure -EIO doesn't leak out at all.
> 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 
> ---
>  tests/gem_eio.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> index a24c8f1c53b5..8345d1a7a429 100644
> --- a/tests/gem_eio.c
> +++ b/tests/gem_eio.c
> @@ -161,10 +161,14 @@ static void test_wait(int fd)
>  {
>   igt_hang_ring_t hang;
>  
> + igt_require(i915_reset_control(false));

However, this is not required to test the ABI change above as the wait
itself will still hang, whether or not it wedges the GPU.
-Chris

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

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Check the timeout passed to i915_wait_request

[Tvrtko Ursulin]

On 29/11/15 08:48, Chris Wilson wrote:

We have relied upon the sole caller (wait_ioctl) validating the timeout
argument. However, when waiting for multiple requests I forgot to ensure
that the timeout was still positive on the later requests. This is more
simply done inside __i915_wait_request.


As discussed on IRC please mention that the extra jiffie happens because 
nsecs_to_jiffies_timeout adds it. Otherwise it is not immediately clear 
why would it wait an extra one since __i915_wait_request has explicit 
code to ensure timeout does not go negative already.


With that clarified,

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


Fixes a minor regression introduced in

commit b47161858ba13c9c7e0132230d66e008dd55
Author: Chris Wilson 
Date:   Mon Apr 27 13:41:17 2015 +0100

 drm/i915: Implement inter-engine read-read optimisations

where we may end up waiting for an extra jiffie for each active ring
after consuming all of the user's timeout.

Signed-off-by: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/i915/i915_gem.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f33c35c6130f..65d101b47d8e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1251,8 +1251,16 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
if (i915_gem_request_completed(req, true))
return 0;

-   timeout_expire = timeout ?
-   jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
+   timeout_expire = 0;
+   if (timeout) {
+   if (WARN_ON(*timeout < 0))
+   return -EINVAL;
+
+   if (*timeout == 0)
+   return -ETIME;
+
+   timeout_expire = jiffies + nsecs_to_jiffies_timeout(*timeout);
+   }

if (INTEL_INFO(dev_priv)->gen >= 6)
gen6_rps_boost(dev_priv, rps, req->emitted_jiffies);


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

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Only query timestamp when measuring elapsed time

[Tvrtko Ursulin]

On 29/11/15 08:48, Chris Wilson wrote:

Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as
we only need to compute the elapsed time for a timed wait.

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

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2c3e36e19cb0..871201713c73 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1227,7 +1227,6 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
int state = interruptible ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
DEFINE_WAIT(wait);
unsigned long timeout_remain;
-   s64 before, now;
int ret;

if (list_empty(>list))
@@ -1244,13 +1243,12 @@ int __i915_wait_request(struct drm_i915_gem_request 
*req,
if (*timeout == 0)
return -ETIME;

+   /* Record current time in case interrupted, or wedged */
timeout_remain = nsecs_to_jiffies_timeout(*timeout);
+   *timeout += ktime_get_raw_ns();


Don't really like this one, how you use the passed in pointer to store 
the intermediate local state.


It works etc but just feels too hacky.

Regards,

Tvrtko



}

-   /* Record current time in case interrupted by signal, or wedged */
trace_i915_gem_request_wait_begin(req);
-   before = ktime_get_raw_ns();
-
if (INTEL_INFO(req->i915)->gen >= 6)
gen6_rps_boost(req->i915, rps, req->emitted_jiffies);

@@ -1286,14 +1284,13 @@ int __i915_wait_request(struct drm_i915_gem_request 
*req,
}
finish_wait(>wait, );
  out:
-   now = ktime_get_raw_ns();
intel_breadcrumbs_remove_waiter(req);
trace_i915_gem_request_wait_end(req);

if (timeout) {
-   s64 tres = *timeout - (now - before);
-
-   *timeout = tres < 0 ? 0 : tres;
+   *timeout -= ktime_get_raw_ns();
+   if (*timeout < 0)
+   *timeout = 0;

/*
 * Apparently ktime isn't accurate enough and occasionally has a


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

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Check the timeout passed to i915_wait_request

[Chris Wilson]

On Mon, Nov 30, 2015 at 10:14:04AM +, Tvrtko Ursulin wrote:
> 
> On 29/11/15 08:48, Chris Wilson wrote:
> >We have relied upon the sole caller (wait_ioctl) validating the timeout
> >argument. However, when waiting for multiple requests I forgot to ensure
> >that the timeout was still positive on the later requests. This is more
> >simply done inside __i915_wait_request.
> 
> As discussed on IRC please mention that the extra jiffie happens
> because nsecs_to_jiffies_timeout adds it. Otherwise it is not
> immediately clear why would it wait an extra one since
> __i915_wait_request has explicit code to ensure timeout does not go
> negative already.

Sorry, I was under the impression that everyone knew the history of our
*to_jiffies_timeout function variants.
-Chris

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

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Check the timeout passed to i915_wait_request

[Chris Wilson]

On Sun, Nov 29, 2015 at 08:48:05AM +, Chris Wilson wrote:
> We have relied upon the sole caller (wait_ioctl) validating the timeout
> argument. However, when waiting for multiple requests I forgot to ensure
> that the timeout was still positive on the later requests. This is more
> simply done inside __i915_wait_request.
> 
> Fixes a minor regression introduced in
> 
> commit b47161858ba13c9c7e0132230d66e008dd55
> Author: Chris Wilson 
> Date:   Mon Apr 27 13:41:17 2015 +0100
> 
> drm/i915: Implement inter-engine read-read optimisations
> 
> where we may end up waiting for an extra jiffie for each active ring
> after consuming all of the user's timeout.

where we may end up waiting for an extra jiffie (added by
nsecs_to_jiffie_timeout to guarantee minimum duration) for each active
ring after consuming all of the user's timeout
-Chris

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

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)

[Maarten Lankhorst]

Op 25-11-15 om 17:48 schreef Matt Roper:
> Although we can do a good job of reading out hardware state, the
> graphics firmware may have programmed the watermarks in a creative way
> that doesn't match how i915 would have chosen to program them.  We
> shouldn't trust the firmware's watermark programming, but should rather
> re-calculate how we think WM's should be programmed and then shove those
> values into the hardware.
>
> We can do this pretty easily by creating a dummy top-level state,
> running it through the check process to calculate all the values, and
> then just programming the watermarks for each CRTC.
>
> v2:  Move watermark sanitization after our BIOS fb reconstruction; the
>  watermark calculations that we do here need to look at pstate->fb,
>  which isn't setup yet in intel_modeset_setup_hw_state(), even
>  though we have an enabled & visible plane.
>
> Cc: Maarten Lankhorst 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c  |  1 +
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_display.c | 58 
> 
>  drivers/gpu/drm/i915/intel_pm.c  | 14 +
>  4 files changed, 68 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3731a26..8a98e0c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2478,6 +2478,7 @@ drm_atomic_helper_duplicate_state(struct drm_device 
> *dev,
>   }
>   }
>  
> + drm_modeset_lock(>mode_config.connection_mutex, ctx);
>   drm_for_each_connector(conn, dev) {
>   struct drm_connector_state *conn_state;
Seems this hunk doesn't belong to this patch?
Also that locking is already taken care of by drm_atomic_get_connector_state,
and it doesn't check for drm_modeset_lock returning an error code..

> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 11ae5a5..5172604 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
> struct dpll *best_clock);
>   int (*compute_pipe_wm)(struct intel_crtc *crtc,
>  struct drm_atomic_state *state);
> + void (*program_watermarks)(struct intel_crtc_state *cstate);
>   void (*update_wm)(struct drm_crtc *crtc);
>   int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
>   void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 00e4c37..eb52afa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
>   intel_enable_gt_powersave(dev);
>  }
>  
> +/*
> + * Calculate what we think the watermarks should be for the state we've read
> + * out of the hardware and then immediately program those watermarks so that
> + * we ensure the hardware settings match our internal state.
> + */
> +static void sanitize_watermarks(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_atomic_state *state;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> + int i;
> +
> + /* Only supported on platforms that use atomic watermark design */
> + if (!dev_priv->display.program_watermarks)
> + return;
> +
> + /*
> +  * Calculate what we think WM's should be by creating a dummy state and
> +  * running it through the atomic check code.
> +  */
> + drm_modeset_acquire_init(, 0);
> + state = drm_atomic_helper_duplicate_state(dev, );
> + if (WARN_ON(IS_ERR(state)))
> + return;
> +
> + ret = intel_atomic_check(dev, state);
> + if (ret) {
> + /*
> +  * Just give up and leave watermarks untouched if we get an
> +  * error back from 'check'
> +  */
> + DRM_DEBUG_KMS("Could not determine valid watermarks for 
> inherited state\n");
> + return;
> + }
> +
> + /* Write calculated watermark values back */
> + to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
> + for_each_crtc_in_state(state, crtc, cstate, i) {
> + struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
> +
> + dev_priv->display.program_watermarks(cs);
> + }
> +
> + drm_atomic_state_free(state);
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +}
> +
>  void intel_modeset_init(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -15243,6 +15294,13 @@ void 

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Limit the busy wait on requests to 10us not 10ms!

[Tvrtko Ursulin]

On 29/11/15 08:48, Chris Wilson wrote:

When waiting for high frequency requests, the finite amount of time
required to set up the irq and wait upon it limits the response rate. By
busywaiting on the request completion for a short while we can service
the high frequency waits as quick as possible. However, if it is a slow
request, we want to sleep as quickly as possible. The tradeoff between
waiting and sleeping is roughly the time it takes to sleep on a request,
on the order of a microsecond. Based on measurements of synchronous
workloads from across big core and little atom, I have set the limit for
busywaiting as 10 microseconds. In most of the synchronous cases, we can
reduce the limit down to as little as 2 miscroseconds, but that leaves
quite a few test cases regressing by factors of 3 and more.

The code currently uses the jiffie clock, but that is far too coarse (on
the order of 10 milliseconds) and results in poor interactivity as the
CPU ends up being hogged by slow requests. To get microsecond resolution
we need to use a high resolution timer. The cheapest of which is polling
local_clock(), but that is only valid on the same CPU. If we switch CPUs
because the task was preempted, we can also use that as an indicator that
  the system is too busy to waste cycles on spinning and we should sleep
instead.

__i915_spin_request was introduced in
commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
Author: Chris Wilson 
Date:   Tue Apr 7 16:20:41 2015 +0100

  drm/i915: Optimistically spin for the request completion

v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe,
so we can use native register sizes on smaller architectures. Mention
the approximate microseconds units for elapsed time and add some extra
comments describing the reason for busywaiting.

v3: Raise the limit to 10us

Reported-by: Jens Axboe 
Link: https://lkml.org/lkml/2015/11/12/621
Cc; "Rogozhkin, Dmitry V" 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Eero Tamminen 
Cc: "Rantala, Valtteri" 
Cc: sta...@kernel.vger.org
---
  drivers/gpu/drm/i915/i915_gem.c | 47 +++--
  1 file changed, 45 insertions(+), 2 deletions(-)


Again,

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 87fc34f5899f..bad112abb16b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1146,14 +1146,57 @@ static bool missed_irq(struct drm_i915_private 
*dev_priv,
return test_bit(ring->id, _priv->gpu_error.missed_irq_rings);
  }

+static unsigned long local_clock_us(unsigned *cpu)
+{
+   unsigned long t;
+
+   /* Cheaply and approximately convert from nanoseconds to microseconds.
+* The result and subsequent calculations are also defined in the same
+* approximate microseconds units. The principal source of timing
+* error here is from the simple truncation.
+*
+* Note that local_clock() is only defined wrt to the current CPU;
+* the comparisons are no longer valid if we switch CPUs. Instead of
+* blocking preemption for the entire busywait, we can detect the CPU
+* switch and use that as indicator of system load and a reason to
+* stop busywaiting, see busywait_stop().
+*/
+   *cpu = get_cpu();
+   t = local_clock() >> 10;
+   put_cpu();
+
+   return t;
+}
+
+static bool busywait_stop(unsigned long timeout, unsigned cpu)
+{
+   unsigned this_cpu;
+
+   if (time_after(local_clock_us(_cpu), timeout))
+   return true;
+
+   return this_cpu != cpu;
+}
+
  static int __i915_spin_request(struct drm_i915_gem_request *req, int state)
  {
unsigned long timeout;
+   unsigned cpu;
+
+   /* When waiting for high frequency requests, e.g. during synchronous
+* rendering split between the CPU and GPU, the finite amount of time
+* required to set up the irq and wait upon it limits the response
+* rate. By busywaiting on the request completion for a short while we
+* can service the high frequency waits as quick as possible. However,
+* if it is a slow request, we want to sleep as quickly as possible.
+* The tradeoff between waiting and sleeping is roughly the time it
+* takes to sleep on a request, on the order of a microsecond.
+*/

if (i915_gem_request_get_ring(req)->irq_refcount)
return -EBUSY;

-   timeout = jiffies + 1;
+   timeout = local_clock_us() + 10;
while (!need_resched()) {
if (i915_gem_request_completed(req, true))
return 0;
@@ -1161,7 +1204,7 @@ static int __i915_spin_request(struct 

Re: [Intel-gfx] [PATCH 02/15] drm/i915: Limit the busy wait on requests to 10us not 10ms!

[Chris Wilson]

On Mon, Nov 30, 2015 at 10:02:30AM +, Tvrtko Ursulin wrote:
> 
> 
> On 29/11/15 08:48, Chris Wilson wrote:
> >When waiting for high frequency requests, the finite amount of time
> >required to set up the irq and wait upon it limits the response rate. By
> >busywaiting on the request completion for a short while we can service
> >the high frequency waits as quick as possible. However, if it is a slow
> >request, we want to sleep as quickly as possible. The tradeoff between
> >waiting and sleeping is roughly the time it takes to sleep on a request,
> >on the order of a microsecond. Based on measurements of synchronous
> >workloads from across big core and little atom, I have set the limit for
> >busywaiting as 10 microseconds. In most of the synchronous cases, we can
> >reduce the limit down to as little as 2 miscroseconds, but that leaves
> >quite a few test cases regressing by factors of 3 and more.
> >
> >The code currently uses the jiffie clock, but that is far too coarse (on
> >the order of 10 milliseconds) and results in poor interactivity as the
> >CPU ends up being hogged by slow requests. To get microsecond resolution
> >we need to use a high resolution timer. The cheapest of which is polling
> >local_clock(), but that is only valid on the same CPU. If we switch CPUs
> >because the task was preempted, we can also use that as an indicator that
> >  the system is too busy to waste cycles on spinning and we should sleep
> >instead.
> >
> >__i915_spin_request was introduced in
> >commit 2def4ad99befa25775dd2f714fdd4d92faec6e34 [v4.2]
> >Author: Chris Wilson 
> >Date:   Tue Apr 7 16:20:41 2015 +0100
> >
> >  drm/i915: Optimistically spin for the request completion
> >
> >v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe,
> >so we can use native register sizes on smaller architectures. Mention
> >the approximate microseconds units for elapsed time and add some extra
> >comments describing the reason for busywaiting.
> >
> >v3: Raise the limit to 10us
> >
> >Reported-by: Jens Axboe 
> >Link: https://lkml.org/lkml/2015/11/12/621
> >Cc; "Rogozhkin, Dmitry V" 
> >Cc: Daniel Vetter 
> >Cc: Tvrtko Ursulin 
> >Cc: Eero Tamminen 
> >Cc: "Rantala, Valtteri" 
> >Cc: sta...@kernel.vger.org
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 47 
> > +++--
> >  1 file changed, 45 insertions(+), 2 deletions(-)
> 
> Again,
> 
> Reviewed-by: Tvrtko Ursulin 

Sorry, I was just including these patches here so that anyone who wanted
to look at the wait-request patches only had one series to pull :)
-Chris

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

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Check the timeout passed to i915_wait_request

[Tvrtko Ursulin]

On 30/11/15 10:19, Chris Wilson wrote:

On Mon, Nov 30, 2015 at 10:14:04AM +, Tvrtko Ursulin wrote:


On 29/11/15 08:48, Chris Wilson wrote:

We have relied upon the sole caller (wait_ioctl) validating the timeout
argument. However, when waiting for multiple requests I forgot to ensure
that the timeout was still positive on the later requests. This is more
simply done inside __i915_wait_request.


As discussed on IRC please mention that the extra jiffie happens
because nsecs_to_jiffies_timeout adds it. Otherwise it is not
immediately clear why would it wait an extra one since
__i915_wait_request has explicit code to ensure timeout does not go
negative already.


Sorry, I was under the impression that everyone knew the history of our
*to_jiffies_timeout function variants.


I don't know if I am the only one who didn't, but when I ask or suggest 
for more or specific comments, or commit message additions during 
review, it is always genuinely for things which I think would have 
helped me with the review.  Which means I also think they would help 
anyone else getting up to speed with the code base.


Regards,

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

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Check the timeout passed to i915_wait_request

[Tvrtko Ursulin]

On 30/11/15 10:22, Chris Wilson wrote:

On Sun, Nov 29, 2015 at 08:48:05AM +, Chris Wilson wrote:

We have relied upon the sole caller (wait_ioctl) validating the timeout
argument. However, when waiting for multiple requests I forgot to ensure
that the timeout was still positive on the later requests. This is more
simply done inside __i915_wait_request.

Fixes a minor regression introduced in

commit b47161858ba13c9c7e0132230d66e008dd55
Author: Chris Wilson 
Date:   Mon Apr 27 13:41:17 2015 +0100

 drm/i915: Implement inter-engine read-read optimisations

where we may end up waiting for an extra jiffie for each active ring
after consuming all of the user's timeout.


where we may end up waiting for an extra jiffie (added by
nsecs_to_jiffie_timeout to guarantee minimum duration) for each active
ring after consuming all of the user's timeout


Sounds good! R-b given previously can be applied. :)

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Teach hangcheck about long operations on rings

[Chris Wilson]

On Mon, Nov 30, 2015 at 06:53:06PM +0200, Mika Kuoppala wrote:
> Some operations that happen in ringbuffer, like flushing,
> can take significant amounts of time. After some intense
> shader tests, the PIPE_CONTROL with flush can apparently last
> longer time than what is our hangcheck tick (1500ms). If
> this happens twice in a row, even with subsequent batches,
> the hangcheck score decaying mechanism can't cope and
> hang is declared.
> 
> Strip out actual head checking to a separate function and if
> actual head has not moved, check if it is lingering inside the
> ringbuffer as opposed to batch. If so, treat it as if it would be
> inside loop to only slightly increment the hangcheck score.

The PIPE_CONTROL in the ring after the batch, is equivalent to the batch
performing its own PIPE_CONTROL as the last instruction. It does not
make sense to distinguish the two.
-Chris

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Let hangcheck score decay faster than loop increment

[Chris Wilson]

On Mon, Nov 30, 2015 at 06:53:07PM +0200, Mika Kuoppala wrote:
> We decay hangcheck score, instead of setting it to zero,
> when seqno moves forward. This was added as mechanism to
> detect batches full of invalid waits.

And slow DoS. So no.
-Chris

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Clear hangcheck score if engine is idle

[Chris Wilson]

On Mon, Nov 30, 2015 at 06:53:08PM +0200, Mika Kuoppala wrote:
> If we have accumulated hangcheck score before reaching
> engine idle, that score will remain and is transferred to
> the next set of batches. This is wrong as idle is a quite clear
> boundary to prevent hangcheck score manipulation across batches.
> 
> Fix this by clearing the score if engine reaches idle.

The hangcheck accumulation is to detect denial of service by a
sequence of batches that each take more than a hangcheck interval, being
idle doesn't mean anything with respect to the slow dos. The only
question is whether trying to do that at all is sensible.
-Chris

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

Re: [Intel-gfx] [PATCH i-g-t] tests: Rename drm_auth to core_auth

[Daniel Stone]

Hi,

On 30 November 2015 at 15:14, Daniel Vetter  wrote:
> It really is a core drm testcase and not a libdrm testcase. While at it
> also make it generic, since it is.
>
> Cc: Daniel Stone 
> Signed-off-by: Daniel Vetter 

Currently in the middle of recabling my ARM farm, so can't test there, but:
Acked-by: Daniel Stone 

Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Slaughter the thundering i915_wait_request herd

[Chris Wilson]

On Mon, Nov 30, 2015 at 02:34:40PM +, Chris Wilson wrote:
> +bool intel_breadcrumbs_add_waiter(struct drm_i915_gem_request *request)
> +{
> + struct intel_breadcrumbs *b = >i915->breadcrumbs;
> + struct intel_breadcrumbs_engine *be = >engine[request->ring->id];
> + bool first = false;
> +
> + spin_lock(>lock);
> + if (request->waiters_count++ == 0) {
> + struct rb_node **p, *parent;
> +
> + if (be->first_waiter == NULL)
> + wake_up_process(b->task);

Oh, the irony.

Converting the other side to a lockless READ_ONCE() means that I do know
have to kick after setting be->first_waiter and not rely on the spinlock
serialising the reads.
-Chris

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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Daniel Vetter]

On Mon, Nov 30, 2015 at 04:55:50PM +0100, Takashi Iwai wrote:
> On Mon, 30 Nov 2015 15:17:05 +0100,
> Daniel Vetter wrote:
> > 
> > On Mon, Nov 30, 2015 at 03:11:16PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> > > > index 30d89e0da2c6..058d39e8d57f 100644
> > > > --- a/include/drm/i915_component.h
> > > > +++ b/include/drm/i915_component.h
> > > > @@ -38,6 +38,7 @@
> > > >   * @codec_wake_override: Enable/Disable generating the codec wake 
> > > > signal
> > > >   * @get_cdclk_freq: get the Core Display Clock in KHz
> > > >   * @sync_audio_rate: set n/cts based on the sample rate
> > > > + * @get_eld: fill the audio state and ELD bytes for the given port
> > > 
> > > In 4.4 kerneldoc supports extended in-line comments for struct members
> > > like this:
> > > 
> > > >   */
> > > >  struct i915_audio_component_ops {
> > > > struct module *owner;
> > > > @@ -46,6 +47,8 @@ struct i915_audio_component_ops {
> > > > void (*codec_wake_override)(struct device *, bool enable);
> > > > int (*get_cdclk_freq)(struct device *);
> > > > int (*sync_audio_rate)(struct device *, int port, int rate);
> > > 
> > >   /**
> > >* @get_eld:
> > >*
> > >* lots of blabla, possibly in multiple paragraphs.
> > >*/
> > > 
> > > Please use that layout and put a copy of the more detailed description you
> > > put into the commit message of how ->get_eld exactly works.
> > > 
> > > I did ask for this to get done as part of some of the previous, and it was
> > > partially done but not exactly how kerneldoc wants it :( But I think we
> > > need to start somewhere ...
> > 
> > Strike that, I looked at the wrong tree ;-) linux-next should have all the
> > patches using the new extended style.
> 
> OK, so this is a post-4.4 change.  I can rebase on it.  Could you
> point a steady branch suitable for it?

Dave's drm-next would be it, if Dave opens it up and pulls in the 2 pull
requests I've sent out earlier. Dave?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Ville Syrjälä]

On Mon, Nov 30, 2015 at 05:34:45PM +0100, Daniel Vetter wrote:
> On Mon, Nov 30, 2015 at 06:09:33PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 30, 2015 at 05:24:41PM +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > > > Implement a new i915_audio_component_ops, get_eld().  It's called by
> > > > the audio driver to fetch the current ELD of the given HDMI/DP port.
> > > > It returns the size of ELD bytes if it's valid, or zero if the audio
> > > > is disabled or unplugged, or a negative error code.
> > > 
> > > Why do we need this? Isn't it something the eld notify hook should
> > > pass from i915 to the audio driver?
> > > 
> > > At least with the locking you have for this, the audio driver can not
> > > call this from the eld notify hook since it would deadlock.
> > 
> > Hmm. Actually the locking isn't perhaps quite like that atm. But I guess
> > the mode_config.mutex will make it so.
> 
> If we need this we could create a substruct in dev_priv with copies of
> everything, which would only be protected by av_mutex. That's the usual
> approach we use when faced with this kind of locking inversion:
> Copy/update relevant data in the modeset ->enable/disable hooks, then just
> use these local locks to access those copies. Usually that's enough to
> untangle things, with no need to resort to workers.

Yeah, IIRC I suggested just that originally.

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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Takashi Iwai]

On Mon, 30 Nov 2015 17:09:33 +0100,
Ville Syrjälä wrote:
> 
> On Mon, Nov 30, 2015 at 05:24:41PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > > Implement a new i915_audio_component_ops, get_eld().  It's called by
> > > the audio driver to fetch the current ELD of the given HDMI/DP port.
> > > It returns the size of ELD bytes if it's valid, or zero if the audio
> > > is disabled or unplugged, or a negative error code.
> > 
> > Why do we need this? Isn't it something the eld notify hook should
> > pass from i915 to the audio driver?
> > 
> > At least with the locking you have for this, the audio driver can not
> > call this from the eld notify hook since it would deadlock.
> 
> Hmm. Actually the locking isn't perhaps quite like that atm. But I guess
> the mode_config.mutex will make it so.
> 
> Apart from that it seesm to me that you should pull the av_mutex
> lock/unlock from the .audio_code_eanble/disable hooks into
> intel_audio_codec_enable/disable, so that it protects the audio_enabled
> flag as well. Not sure if the eld_notify should be called while holding
> that lock or not. If we need to avoid calling it from the eld_notify
> anywya due to other locks then maybe it can be under av_mutex as well.

Currently I'm thinking of:

- not allow to call get_eld directly from eld_notify;
  I found that the existing eld_repoll work in the HDA can be reused
  easily, so let's follow Daniel's advice.

- drm_select_eld() seems requring mode_config.mutex and
  connection_mutex modeset lock in anyway; so let get_eld taking
  both.

  Is it OK to call drm_modeset_lock_all() for simplicity?

- Get rid of av_mutex from get_eld instead;
  get_eld doesn't conflict with other ops

In that way, audio_enabled flag is protected in both places via
modeset lock, I suppose.


thanks,

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

[Intel-gfx] [MIPI SEQ PARSING v3 09/13] drm/i915: Added the generic gpio sequence support and gpio table

[Deepak M]

The generic gpio is sequence is parsed from the VBT and the
GPIO table is updated with the North core, South core and
SUS core elements.

v2: Move changes in sideband.c file to new patch(Jani), rebase
v3: Moved the Macro`s to intel_dsi_panel_vbt.c (Jani)

Cc: Jani Nikula 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 589 +++--
 1 file changed, 553 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index bc33e3a..13f0fb7 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -59,30 +59,356 @@ static inline struct vbt_panel *to_vbt_panel(struct 
drm_panel *panel)
 
 #define NS_KHZ_RATIO 100
 
-#define GPI0_NC_0_HV_DDI0_HPD   0x4130
-#define GPIO_NC_0_HV_DDI0_PAD   0x4138
-#define GPIO_NC_1_HV_DDI0_DDC_SDA   0x4120
-#define GPIO_NC_1_HV_DDI0_DDC_SDA_PAD   0x4128
-#define GPIO_NC_2_HV_DDI0_DDC_SCL   0x4110
-#define GPIO_NC_2_HV_DDI0_DDC_SCL_PAD   0x4118
-#define GPIO_NC_3_PANEL0_VDDEN  0x4140
-#define GPIO_NC_3_PANEL0_VDDEN_PAD  0x4148
-#define GPIO_NC_4_PANEL0_BLKEN  0x4150
-#define GPIO_NC_4_PANEL0_BLKEN_PAD  0x4158
-#define GPIO_NC_5_PANEL0_BLKCTL 0x4160
-#define GPIO_NC_5_PANEL0_BLKCTL_PAD 0x4168
-#define GPIO_NC_6_PCONF00x4180
-#define GPIO_NC_6_PAD   0x4188
-#define GPIO_NC_7_PCONF00x4190
-#define GPIO_NC_7_PAD   0x4198
-#define GPIO_NC_8_PCONF00x4170
-#define GPIO_NC_8_PAD   0x4178
-#define GPIO_NC_9_PCONF00x4100
-#define GPIO_NC_9_PAD   0x4108
-#define GPIO_NC_10_PCONF0   0x40E0
-#define GPIO_NC_10_PAD  0x40E8
-#define GPIO_NC_11_PCONF0   0x40F0
-#define GPIO_NC_11_PAD  0x40F8
+#define HV_DDI0_HPD_GPIONC_0_PCONF0 0x4130
+#define HV_DDI0_HPD_GPIONC_0_PAD0x4138
+#define HV_DDI0_DDC_SDA_GPIONC_1_PCONF0 0x4120
+#define HV_DDI0_DDC_SDA_GPIONC_1_PAD0x4128
+#define HV_DDI0_DDC_SCL_GPIONC_2_PCONF0 0x4110
+#define HV_DDI0_DDC_SCL_GPIONC_2_PAD0x4118
+#define PANEL0_VDDEN_GPIONC_3_PCONF00x4140
+#define PANEL0_VDDEN_GPIONC_3_PAD   0x4148
+#define PANEL0_BKLTEN_GPIONC_4_PCONF0   0x4150
+#define PANEL0_BKLTEN_GPIONC_4_PAD  0x4158
+#define PANEL0_BKLTCTL_GPIONC_5_PCONF0  0x4160
+#define PANEL0_BKLTCTL_GPIONC_5_PAD 0x4168
+#define HV_DDI1_HPD_GPIONC_6_PCONF0 0x4180
+#define HV_DDI1_HPD_GPIONC_6_PAD0x4188
+#define HV_DDI1_DDC_SDA_GPIONC_7_PCONF0 0x4190
+#define HV_DDI1_DDC_SDA_GPIONC_7_PAD0x4198
+#define HV_DDI1_DDC_SCL_GPIONC_8_PCONF0 0x4170
+#define HV_DDI1_DDC_SCL_GPIONC_8_PAD0x4178
+#define PANEL1_VDDEN_GPIONC_9_PCONF00x4100
+#define PANEL1_VDDEN_GPIONC_9_PAD   0x4108
+#define PANEL1_BKLTEN_GPIONC_10_PCONF0  0x40E0
+#define PANEL1_BKLTEN_GPIONC_10_PAD 0x40E8
+#define PANEL1_BKLTCTL_GPIONC_11_PCONF0 0x40F0
+#define PANEL1_BKLTCTL_GPIONC_11_PAD0x40F8
+#define GP_INTD_DSI_TE1_GPIONC_12_PCONF00x40C0
+#define GP_INTD_DSI_TE1_GPIONC_12_PAD   0x40C8
+#define HV_DDI2_DDC_SDA_GPIONC_13_PCONF00x41A0
+#define HV_DDI2_DDC_SDA_GPIONC_13_PAD   0x41A8
+#define HV_DDI2_DDC_SCL_GPIONC_14_PCONF00x41B0
+#define HV_DDI2_DDC_SCL_GPIONC_14_PAD   0x41B8
+#define GP_CAMERASB00_GPIONC_15_PCONF0  0x4010
+#define GP_CAMERASB00_GPIONC_15_PAD 0x4018
+#define GP_CAMERASB01_GPIONC_16_PCONF0  0x4040
+#define GP_CAMERASB01_GPIONC_16_PAD 0x4048
+#define GP_CAMERASB02_GPIONC_17_PCONF0  0x4080
+#define GP_CAMERASB02_GPIONC_17_PAD 0x4088
+#define GP_CAMERASB03_GPIONC_18_PCONF0  0x40B0
+#define GP_CAMERASB03_GPIONC_18_PAD 0x40B8
+#define GP_CAMERASB04_GPIONC_19_PCONF0  0x4000
+#define GP_CAMERASB04_GPIONC_19_PAD 0x4008
+#define GP_CAMERASB05_GPIONC_20_PCONF0  0x4030
+#define GP_CAMERASB05_GPIONC_20_PAD 0x4038
+#define GP_CAMERASB06_GPIONC_21_PCONF0  0x4060
+#define GP_CAMERASB06_GPIONC_21_PAD 0x4068
+#define GP_CAMERASB07_GPIONC_22_PCONF0  0x40A0
+#define GP_CAMERASB07_GPIONC_22_PAD 0x40A8
+#define GP_CAMERASB08_GPIONC_23_PCONF0  0x40D0
+#define GP_CAMERASB08_GPIONC_23_PAD 0x40D8
+#define GP_CAMERASB09_GPIONC_24_PCONF0  0x4020
+#define GP_CAMERASB09_GPIONC_24_PAD 0x4028
+#define GP_CAMERASB10_GPIONC_25_PCONF0  0x4050
+#define GP_CAMERASB10_GPIONC_25_PAD 0x4058
+#define GP_CAMERASB11_GPIONC_26_PCONF0  0x4090
+#define GP_CAMERASB11_GPIONC_26_PAD 

[Intel-gfx] [MIPI SEQ PARSING v3 08/13] drm/i915: Extend gpio read/write to other cores

[Deepak M]

Adding a argument to the gpio read/write functions
which accepts the block name.

v2: rebase
v3: rebase

Cc: Jani Nikula 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_drv.h| 5 +++--
 drivers/gpu/drm/i915/i915_reg.h| 5 +
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 4 ++--
 drivers/gpu/drm/i915/intel_sideband.c  | 9 +
 4 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 59a39d1..ca865f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3379,8 +3379,9 @@ int sandybridge_pcode_write(struct drm_i915_private 
*dev_priv, u32 mbox, u32 val
 u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
 void vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
 u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32 reg);
+void vlv_gpio_write(struct drm_i915_private *dev_priv, u8 core_offset,
+   u32 reg, u32 val);
 u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8bd2699..e29f7ef 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -572,6 +572,11 @@
 #define   IOSF_PORT_DPIO   0x12
 #define   IOSF_PORT_DPIO_2 0x1a
 #define   IOSF_PORT_GPIO_NC0x13
+#define   IOSF_PORT_GPIO_SC0x48
+#define   IOSF_PORT_GPIO_SUS   0xA8
+#define   MAX_GPIO_NUM_NC  26
+#define   MAX_GPIO_NUM_SC  128
+#define   MAX_GPIO_NUM 172
 #define   IOSF_PORT_CCK0x14
 #define   IOSF_PORT_CCU0xA9
 #define   IOSF_PORT_GPS_CORE   0x48
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index eb0697b..bc33e3a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -275,14 +275,14 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
if (!gtable[gpio].init) {
/* program the function */
/* FIXME: remove constant below */
-   vlv_gpio_nc_write(dev_priv, function, 0x2000CC00);
+   vlv_gpio_write(dev_priv, IOSF_PORT_GPIO_NC, function, 
0x2000CC00);
gtable[gpio].init = 1;
}
 
val = 0x4 | action;
 
/* pull up/down */
-   vlv_gpio_nc_write(dev_priv, pad, val);
+   vlv_gpio_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
mutex_unlock(_priv->sb_lock);
 
return data;
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 8831fc5..3e0cbe6 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -129,17 +129,18 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 
addr)
return val;
 }
 
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
+u32 vlv_gpio_read(struct drm_i915_private *dev_priv, u8 core_offset, u32 reg)
 {
u32 val = 0;
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), core_offset,
SB_CRRDDA_NP, reg, );
return val;
 }
 
-void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+void vlv_gpio_write(struct drm_i915_private *dev_priv, u8 core_offset,
+   u32 reg, u32 val)
 {
-   vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_GPIO_NC,
+   vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), core_offset,
SB_CRWRDA_NP, reg, );
 }
 
-- 
1.9.1

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

[Intel-gfx] [MIPI SEQ PARSING v3 00/13] Patches to support the version 3 of MIPI sequence in VBT.

[Deepak M]

Currently in our kernel we ioremap 8KB of memory for the
opregion and holds a maximum of 6KB sized RAW vbt data.

As per the latest opregion spec when the VBT size exceeds
6KB it cant be placed in the mailbox4 of the opregion, so
the physical address of the buffer where the Raw VBT is
stored will be mentioned in the mailbox3 with the VBT size
in the opregion version 2 and above.
A non-zero value here is an indication to driver that a
valid Raw VBT is stored here and driver should not refer
to mailbox4 for getting VBT. This is implemented in one
of the patches in this series.

link for the opregion spec : 
https://securewiki.ith.intel.com/pages/viewpage.action?pageId=48147378
(spec is under intel firewall)

In the version 3 of the MIPI sequence block, the size
field is 4 bytes so that it can support block size of
more than 64KB, but the vbt size field in the bdb header is only
2 bytes. Based on the below points this issue can be handled.
1. When the VBT is not present in the mailbox4 then VBT size
needs to be read from the mailbox3 and this VBT size field
is of 4 bytes which implies that it can be more than 64KB also.
2. If the VBT size is more than 64KB then the VBT size field
in the bdb header cant be relied. So its better to consider
the vbt size from the mailbox3 when the VBT is not present in
mailbox4.

Other patches implements the parsing of the new sequence type
which are added in the block 53.

v2: Addressed Jani`s review comments.
v3: Addressed Jani`s review comments.

Deepak M (8):
  drm/i915: Updating asle structure with new fields
  drm/i915: Add Intel opregion mailbox 5 structure
  drm/i915: Do opregion VBT validation during opregion setup
  drm/i915: Add debug entry to get the opregion VBT blob
  drm/i915: Parsing VBT if size of VBT exceeds 6KB
  drm/i915: Extend gpio read/write to other cores
  drm/i915: Added the generic gpio sequence support and gpio table
  drm: Add few more wrapper functions for drm panel

Gaurav K Singh (1):
  drm/i915: Add functions to execute the new sequences from VBT

Uma Shankar (1):
  drm/i915: BXT GPIO support for backlight and panel control

Yogesh Mohan Marimuthu (1):
  drm/i915: GPIO for CHT generic MIPI

vkorjani (2):
  drm/i915: Adding the parsing logic for the i2c element
  drm/i915: Added support the v3 mipi sequence block

 drivers/gpu/drm/i915/i915_debugfs.c|  29 +
 drivers/gpu/drm/i915/i915_drv.h|  10 +-
 drivers/gpu/drm/i915/i915_reg.h|  28 +
 drivers/gpu/drm/i915/intel_bios.c  | 175 --
 drivers/gpu/drm/i915/intel_bios.h  |  10 +-
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 887 +++--
 drivers/gpu/drm/i915/intel_opregion.c  |  72 ++-
 drivers/gpu/drm/i915/intel_sideband.c  |   9 +-
 include/drm/drm_panel.h|  47 ++
 9 files changed, 1170 insertions(+), 97 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [MIPI SEQ PARSING v3 05/13] drm/i915: Add debug entry to get the opregion VBT blob

[Deepak M]

Currently there is a entry to get the complete opregion
dump, this patch adds entry to get the VBT alone from
the opregion.

Adding this entry helps developer to get the VBT easily,
instead of following the old way where we get the complete
opregion dump and pick the VBT from the dump wrt to
the VBT offset.

Cc: Jani Nikula 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_debugfs.c   | 29 +
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c |  1 +
 drivers/gpu/drm/i915/intel_opregion.c |  3 +++
 4 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d6d69f4..9b7fb00 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1865,6 +1865,34 @@ out:
return 0;
 }
 
+static int i915_opregion_vbt(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_opregion *opregion = _priv->opregion;
+   void *data = kmalloc(opregion->vbt_size, GFP_KERNEL);
+   int ret;
+
+   if (data == NULL)
+   return -ENOMEM;
+
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   goto out;
+
+   if (opregion->vbt) {
+   memcpy(data, opregion->vbt, opregion->vbt_size);
+   seq_write(m, data, opregion->vbt_size);
+   }
+
+   mutex_unlock(>struct_mutex);
+
+out:
+   kfree(data);
+   return 0;
+}
+
 static int i915_gem_framebuffer_info(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m->private;
@@ -5383,6 +5411,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_ips_status", i915_ips_status, 0},
{"i915_sr_status", i915_sr_status, 0},
{"i915_opregion", i915_opregion, 0},
+   {"i915_opregion_vbt", i915_opregion_vbt, 0},
{"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
{"i915_context_status", i915_context_status, 0},
{"i915_dump_lrc", i915_dump_lrc, 0},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cf8375..59a39d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -457,6 +457,7 @@ struct intel_opregion {
u32 swsci_sbcb_sub_functions;
struct opregion_asle *asle;
void *vbt;
+   u32 vbt_size;
struct opregion_asle_ext *asle_ext;
u32 *lid_state;
struct work_struct asle_work;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 57a77aa..98b0e2a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1338,6 +1338,7 @@ intel_parse_bios(struct drm_device *dev)
return -1;
}
 
+   dev_priv->opregion.vbt_size = vbt->vbt_size;
bdb = (const void *)vbt + vbt->bdb_offset;
}
 
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 4a78282..7908a1d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -971,6 +971,9 @@ int intel_opregion_setup(struct drm_device *dev)
goto err_out;
}
 
+   vbt = (const struct vbt_header *)(base + OPREGION_VBT_OFFSET);
+   dev_priv->opregion.vbt_size = vbt->vbt_size;
+
opregion->header = base;
opregion->vbt = base + OPREGION_VBT_OFFSET;
 
-- 
1.9.1

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

[Intel-gfx] [MIPI SEQ PARSING v3 07/13] drm/i915: Added support the v3 mipi sequence block

[Deepak M]

From: vkorjani 

The Block 53 of the VBT, which is the MIPI sequence block
has undergone a design change because of which the parsing
logic has to be changed.

The current code will handle the parsing of v3 and other
lower versions of the MIPI sequence block.

v2: rebase
v3: minor comments fixed.

Cc: Jani Nikula 
Signed-off-by: vkorjani 
Signed-off-by: Deepak M 
---

Addressed most of the minor comments in this version,
except the one where Jani had suggested to change the
logic in the goto_next_sequence(), Thought of handling
this as a new patch after this series.

http://lists.freedesktop.org/archives/intel-gfx/2015-September/076273.html

 drivers/gpu/drm/i915/intel_bios.c  | 125 -
 drivers/gpu/drm/i915/intel_bios.h  |   9 ++-
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |   7 ++
 3 files changed, 120 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 98b0e2a..5cfb862 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -745,6 +745,72 @@ static u8 *goto_next_sequence(u8 *data, int *size)
return data;
 }
 
+
+/*
+ * Structure of single sequence in v3 version.
+ *  ___ _ __   _
+ * |   | | First|Size of |Payload ||End of |
+ * | Sequence  | Size of | Opreation|First Op|First Op||Current|
+ * | byte  | Sequence| byte |byte|byte||Seq(00)|
+ * |___|_|__||| ...|___|
+ * |  1 byte   | 4 Bytes | 1 byte   |1 bytes | Y byte ||1 byte |
+ * |   |   (X)   |  |  (Y)   |||   |
+ * |___|_|__||||___|
+ *
+ *   |<--Y--->|
+ *   |<---X--->|
+ */
+
+static u8 *goto_next_sequence_v3(u8 *data, int *size)
+{
+   int tmp = *size;
+   int op_size;
+
+   if (--tmp < 0)
+   return NULL;
+
+   /* Skip the panel id and the sequence byte */
+   data = data + 5;
+   tmp = tmp - 5;
+   while (*data != 0) {
+   u8 operation_type = *data++;
+
+   switch (operation_type) {
+   default:
+   DRM_ERROR("Unknown operation type %d\n", 
operation_type);
+   case MIPI_SEQ_ELEM_SEND_PKT:
+   case MIPI_SEQ_ELEM_DELAY:
+   case MIPI_SEQ_ELEM_GPIO:
+   case MIPI_SEQ_ELEM_I2C:
+   case MIPI_SEQ_ELEM_SPI:
+   case MIPI_SEQ_ELEM_PMIC:
+   /*
+* skip by this element payload size
+* skip elem id, command flag and data type
+*/
+   op_size = *data++;
+   tmp = tmp - (op_size + 1);
+   if (tmp < 0)
+   return NULL;
+
+   /* skip by len */
+   data += op_size;
+   break;
+   }
+   }
+
+   /* goto next sequence or end of block byte */
+   if (--tmp < 0)
+   return NULL;
+
+   /* Skip the end element marker */
+   data++;
+
+   /* update amount of data left for the sequence block to be parsed */
+   *size = tmp;
+   return data;
+}
+
 static void
 parse_mipi(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
 {
@@ -754,8 +820,8 @@ parse_mipi(struct drm_i915_private *dev_priv, const struct 
bdb_header *bdb)
const struct mipi_pps_data *pps;
u8 *data;
const u8 *seq_data;
-   int i, panel_id, seq_size;
-   u16 block_size;
+   int i, panel_id, panel_seq_size;
+   u32 block_size;
 
/* parse MIPI blocks only if LFP type is MIPI */
if (!dev_priv->vbt.has_mipi)
@@ -817,29 +883,40 @@ parse_mipi(struct drm_i915_private *dev_priv, const 
struct bdb_header *bdb)
 
DRM_DEBUG_DRIVER("Found MIPI sequence block\n");
 
-   block_size = get_blocksize(sequence);
-
/*
 * parse the sequence block for individual sequences
 */
dev_priv->vbt.dsi.seq_version = sequence->version;
 
seq_data = >data[0];
+   if (dev_priv->vbt.dsi.seq_version >= 3) {
+   block_size = *((unsigned int *)seq_data);
+   seq_data = seq_data + 4;
+   } else
+   block_size = get_blocksize(sequence);
 
/*
 * sequence block is variable length and hence we need to parse and
 * get the sequence data for specific panel id
 */
for (i = 0; i < MAX_MIPI_CONFIGURATIONS; i++) {
-   panel_id = *seq_data;
-   seq_size = *((u16 *) 

[Intel-gfx] [MIPI SEQ PARSING v3 06/13] drm/i915: Parsing VBT if size of VBT exceeds 6KB

[Deepak M]

Currently the iomap for VBT works only if the size of the
VBT is less than 6KB, but if the size of the VBT exceeds
6KB than the physical address and the size of the VBT to
be iomapped is specified in the mailbox3 and is iomapped
accordingly.

v3: -Splitted the patch into small ones
-Handeled memory unmap in intel_opregion_fini
-removed the new file created for opregion macro`s

Cc: Jani Nikula 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_opregion.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 7908a1d..b3a5709 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -856,6 +856,8 @@ void intel_opregion_fini(struct drm_device *dev)
}
 
/* just clear all opregion memory pointers now */
+   if (opregion->header->opregion_ver >= 2 && opregion->asle->rvda)
+   memunmap(opregion->vbt);
memunmap(opregion->header);
opregion->header = NULL;
opregion->acpi = NULL;
@@ -933,7 +935,8 @@ int intel_opregion_setup(struct drm_device *dev)
char buf[sizeof(OPREGION_SIGNATURE)];
const struct vbt_header *vbt = NULL;
int err = 0;
-   void *base;
+   void *base, *vbt_base;
+   size_t size;
 
BUILD_BUG_ON(sizeof(struct opregion_header) != 0x100);
BUILD_BUG_ON(sizeof(struct opregion_acpi) != 0x100);
@@ -963,19 +966,37 @@ int intel_opregion_setup(struct drm_device *dev)
goto err_out;
}
 
-   vbt = validate_vbt(base + OPREGION_VBT_OFFSET,
-   MAILBOX_4_SIZE, "OpRegion");
+   /*
+* Non-zero value in rvda field is an indication to driver that a
+* valid Raw VBT is stored in that address and driver should not refer
+* to mailbox4 for getting VBT.
+*/
+   if (opregion->header->opregion_ver >= 2 && opregion->asle->rvda) {
+   size = opregion->asle->rvds;
+   vbt_base = memremap(opregion->asle->rvda,
+   size, MEMREMAP_WB);
+   } else {
+   size = MAILBOX_4_SIZE;
+   vbt_base = base + OPREGION_VBT_OFFSET;
+   }
+
+   vbt = validate_vbt(vbt_base, size, "OpRegion");
 
if (vbt == NULL) {
err = -EINVAL;
goto err_out;
}
 
-   vbt = (const struct vbt_header *)(base + OPREGION_VBT_OFFSET);
-   dev_priv->opregion.vbt_size = vbt->vbt_size;
+   /* Assigning the vbt_size based on the VBT location */
+   if (opregion->header->opregion_ver >= 2 && opregion->asle->rvda)
+   dev_priv->opregion.vbt_size = opregion->asle->rvds;
+   else {
+   vbt = (const struct vbt_header *)(base + OPREGION_VBT_OFFSET);
+   dev_priv->opregion.vbt_size = vbt->vbt_size;
+   }
 
opregion->header = base;
-   opregion->vbt = base + OPREGION_VBT_OFFSET;
+   opregion->vbt = vbt_base;
 
opregion->lid_state = base + ACPI_CLID;
opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
-- 
1.9.1

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

[Intel-gfx] [MIPI SEQ PARSING v3 02/13] drm/i915: Updating asle structure with new fields

[Deepak M]

v3: rebase

Cc: Jani Nikula 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_opregion.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index e362a30..64efedf 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -120,7 +120,9 @@ struct opregion_asle {
u64 fdss;
u32 fdsp;
u32 stat;
-   u8 rsvd[70];
+   u64 rvda;   /* Physical address of raw vbt data */
+   u32 rvds;   /* Size of raw vbt data */
+   u8 rsvd[58];
 } __packed;
 
 /* Driver readiness indicator */
-- 
1.9.1

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

[Intel-gfx] [MIPI SEQ PARSING v3 01/13] drm/i915: Adding the parsing logic for the i2c element

[Deepak M]

From: vkorjani 

New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.

v2: Add i2c_put_adapter call(Jani), rebase
v3: corrected the retry loop(Jani), rebase

Cc: Jani Nikula 
Signed-off-by: vkorjani 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/intel_bios.c  |  6 +++
 drivers/gpu/drm/i915/intel_bios.h  |  1 +
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 60 ++
 3 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index ce82f9c..6756a1c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -718,6 +718,12 @@ static u8 *goto_next_sequence(u8 *data, int *size)
 
data += 3;
break;
+   case MIPI_SEQ_ELEM_I2C:
+   /* skip by this element payload size */
+   data += 7;
+   len = *data;
+   data += len + 1;
+   break;
default:
DRM_ERROR("Unknown element\n");
return NULL;
diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 7ec8c9a..4ec73f5 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -954,6 +954,7 @@ enum mipi_seq_element {
MIPI_SEQ_ELEM_SEND_PKT,
MIPI_SEQ_ELEM_DELAY,
MIPI_SEQ_ELEM_GPIO,
+   MIPI_SEQ_ELEM_I2C,
MIPI_SEQ_ELEM_STATUS,
MIPI_SEQ_ELEM_MAX
 };
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac..92d619a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
@@ -104,6 +105,64 @@ static struct gpio_table gtable[] = {
{ GPIO_NC_11_PCONF0, GPIO_NC_11_PAD, 0}
 };
 
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   struct i2c_adapter *adapter;
+   int ret;
+   u8 reg_offset, payload_size, retries = 5;
+   struct i2c_msg msg;
+   u8 *transmit_buffer = NULL;
+   u8 flag = *data++;
+   u8 index = *data++;
+   u8 bus_number = *data++;
+   u16 slave_add = *(u16 *)(data);
+
+   data = data + 2;
+   reg_offset = *data++;
+   payload_size = *data++;
+
+   adapter = i2c_get_adapter(bus_number);
+
+   if (!adapter) {
+   DRM_ERROR("i2c_get_adapter(%u)\n", bus_number);
+   goto out;
+   }
+
+   transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
+
+   if (!transmit_buffer)
+   goto out;
+
+   transmit_buffer[0] = reg_offset;
+   memcpy(_buffer[1], data, payload_size);
+
+   msg.addr   = slave_add;
+   msg.flags  = 0;
+   msg.len= payload_size + 1;
+   msg.buf= _buffer[0];
+
+   do {
+   ret =  i2c_transfer(adapter, , 1);
+   if (ret == 1)
+   goto out;
+   else if (ret == -EAGAIN)
+   usleep_range(1000, 2500);
+   else {
+   DRM_ERROR("i2c transfer failed, error code:%d\n", ret);
+   goto out;
+   }
+   } while (retries--);
+
+   if (retries == 0)
+   DRM_ERROR("i2c transfer failed, error code:%d\n", ret);
+out:
+   kfree(transmit_buffer);
+   i2c_put_adapter(adapter);
+
+   data = data + payload_size;
+   return data;
+}
+
 static inline enum port intel_dsi_seq_port_to_port(u8 port)
 {
return port ? PORT_C : PORT_A;
@@ -236,6 +295,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
mipi_exec_send_packet,
mipi_exec_delay,
mipi_exec_gpio,
+   mipi_exec_i2c,
NULL, /* status read; later */
 };
 
-- 
1.9.1

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

[Intel-gfx] [MIPI SEQ PARSING v3 04/13] drm/i915: Do opregion VBT validation during opregion setup

[Deepak M]

Calling the validate_vbt before assiging the opregion vbt blob.
Size of the VBT blob cant be more than 6KB when VBT is present
in mailbox 4.

Cc: Jani Nikula 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_drv.h   |  3 +++
 drivers/gpu/drm/i915/intel_bios.c | 43 +++
 drivers/gpu/drm/i915/intel_opregion.c | 31 +
 3 files changed, 57 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 135d32a..8cf8375 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3324,6 +3324,9 @@ intel_opregion_notify_adapter(struct drm_device *dev, 
pci_power_t state)
 }
 #endif
 
+const struct vbt_header *validate_vbt(const void *_vbt, size_t size,
+   const char *source);
+
 /* intel_acpi.c */
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 6756a1c..57a77aa 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1237,16 +1237,15 @@ static const struct dmi_system_id 
intel_no_opregion_vbt[] = {
{ }
 };
 
-static const struct bdb_header *validate_vbt(const void *base,
+const struct vbt_header *validate_vbt(const void *_vbt,
 size_t size,
-const void *_vbt,
 const char *source)
 {
-   size_t offset = _vbt - base;
-   const struct vbt_header *vbt = _vbt;
+   const struct vbt_header *vbt = (const struct vbt_header *)_vbt;
const struct bdb_header *bdb;
+   size_t offset;
 
-   if (offset + sizeof(struct vbt_header) > size) {
+   if (sizeof(struct vbt_header) > size) {
DRM_DEBUG_DRIVER("VBT header incomplete\n");
return NULL;
}
@@ -1256,26 +1255,26 @@ static const struct bdb_header *validate_vbt(const void 
*base,
return NULL;
}
 
-   offset += vbt->bdb_offset;
+   offset = vbt->bdb_offset;
if (offset + sizeof(struct bdb_header) > size) {
DRM_DEBUG_DRIVER("BDB header incomplete\n");
return NULL;
}
 
-   bdb = base + offset;
+   bdb = (const void *)_vbt + offset;
if (offset + bdb->bdb_size > size) {
DRM_DEBUG_DRIVER("BDB incomplete\n");
return NULL;
}
 
DRM_DEBUG_KMS("Using VBT from %s: %20s\n",
- source, vbt->signature);
-   return bdb;
+   source, vbt->signature);
+   return vbt;
 }
 
-static const struct bdb_header *find_vbt(void __iomem *bios, size_t size)
+static const struct vbt_header *find_vbt(void __iomem *bios, size_t size)
 {
-   const struct bdb_header *bdb = NULL;
+   const struct vbt_header *vbt = NULL;
size_t i;
 
/* Scour memory looking for the VBT signature. */
@@ -1289,12 +1288,12 @@ static const struct bdb_header *find_vbt(void __iomem 
*bios, size_t size)
 */
void *_bios = (void __force *) bios;
 
-   bdb = validate_vbt(_bios, size, _bios + i, "PCI ROM");
+   vbt = validate_vbt(_bios + i, size - i, "PCI ROM");
break;
}
}
 
-   return bdb;
+   return vbt;
 }
 
 /**
@@ -1311,6 +1310,7 @@ intel_parse_bios(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
+   const struct vbt_header *vbt = NULL;
const struct bdb_header *bdb = NULL;
u8 __iomem *bios = NULL;
 
@@ -1319,23 +1319,26 @@ intel_parse_bios(struct drm_device *dev)
 
init_vbt_defaults(dev_priv);
 
-   /* XXX Should this validation be moved to intel_opregion.c? */
-   if (!dmi_check_system(intel_no_opregion_vbt) && dev_priv->opregion.vbt)
-   bdb = validate_vbt(dev_priv->opregion.header, OPREGION_SIZE,
-  dev_priv->opregion.vbt, "OpRegion");
+   if (!dmi_check_system(intel_no_opregion_vbt) &&
+   dev_priv->opregion.vbt) {
+   vbt = (const struct vbt_header *)dev_priv->opregion.vbt;
+   bdb = (const void *)dev_priv->opregion.vbt + vbt->bdb_offset;
+   }
 
-   if (bdb == NULL) {
+   if (vbt == NULL) {
size_t size;
 
bios = pci_map_rom(pdev, );
if (!bios)
return -1;
 
-   bdb = find_vbt(bios, size);
-   if (!bdb) {
+   vbt = find_vbt(bios, size);
+   if (!vbt) {
pci_unmap_rom(pdev, bios);
return -1;

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Daniel Vetter]

On Mon, Nov 30, 2015 at 06:09:33PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 30, 2015 at 05:24:41PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > > Implement a new i915_audio_component_ops, get_eld().  It's called by
> > > the audio driver to fetch the current ELD of the given HDMI/DP port.
> > > It returns the size of ELD bytes if it's valid, or zero if the audio
> > > is disabled or unplugged, or a negative error code.
> > 
> > Why do we need this? Isn't it something the eld notify hook should
> > pass from i915 to the audio driver?
> > 
> > At least with the locking you have for this, the audio driver can not
> > call this from the eld notify hook since it would deadlock.
> 
> Hmm. Actually the locking isn't perhaps quite like that atm. But I guess
> the mode_config.mutex will make it so.

If we need this we could create a substruct in dev_priv with copies of
everything, which would only be protected by av_mutex. That's the usual
approach we use when faced with this kind of locking inversion:
Copy/update relevant data in the modeset ->enable/disable hooks, then just
use these local locks to access those copies. Usually that's enough to
untangle things, with no need to resort to workers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling

[Vinod Koul]

On Mon, Nov 30, 2015 at 02:37:49PM +0100, Takashi Iwai wrote:
> Since we have a new audio component ops to fetch the current ELD and
> state now, we can reduce the usage of unsol event of HDMI/DP pins.
> The unsol event isn't only unreliable, but it also needs the power
> up/down of the codec and link at each time, which is a significant
> power and time loss.
> 
> In this patch, the jack creation and unsol/jack event handling are
> modified to use the audio component for the dedicated Intel chips.
> 
> The jack handling got slightly more codes than a simple usage of
> hda_jack layer since we need to deal directly with snd_jack object;
> the hda_jack layer is basically designed for the pin sense read and
> unsol events, both of which aren't used any longer in our case.
> 
> Signed-off-by: Takashi Iwai 
> ---
>  sound/pci/hda/patch_hdmi.c | 84 
> --
>  1 file changed, 82 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index 28684aa86408..8378c31e0b4f 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -83,6 +83,7 @@ struct hdmi_spec_per_pin {
>   struct mutex lock;
>   struct delayed_work work;
>   struct snd_kcontrol *eld_ctl;
> + struct snd_jack *acomp_jack; /* jack via audio component */
>   int repoll_count;
>   bool setup; /* the stream has been set up by prepare callback */
>   int channels; /* current number of channels */
> @@ -141,6 +142,7 @@ struct hdmi_spec {
>   struct hdmi_ops ops;
>  
>   bool dyn_pin_out;
> + bool use_acomp; /* use audio component for ELD notify/update */
>  
>   /*
>* Non-generic VIA/NVIDIA specific
> @@ -1580,6 +1582,9 @@ static void update_eld(struct hda_codec *codec,
>  _pin->eld_ctl->id);
>  }
>  
> +static void sync_eld_via_acomp(struct hda_codec *codec,
> +struct hdmi_spec_per_pin *per_pin);
> +
>  static bool hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int repoll)
>  {
>   struct hda_jack_tbl *jack;
> @@ -1599,6 +1604,11 @@ static bool hdmi_present_sense(struct 
> hdmi_spec_per_pin *per_pin, int repoll)
>   int present;
>   bool ret;
>  
> + if (spec->use_acomp) {
> + sync_eld_via_acomp(codec, per_pin);
> + return false; /* don't call snd_hda_jack_report_sync() */
> + }
> +
>   snd_hda_power_up_pm(codec);
>   present = snd_hda_pin_sense(codec, pin_nid);
>  
> @@ -2091,6 +2101,68 @@ static int generic_hdmi_build_pcms(struct hda_codec 
> *codec)
>   return 0;
>  }
>  
> +/* update ELD and jack state via audio component */
> +static void sync_eld_via_acomp(struct hda_codec *codec,
> +struct hdmi_spec_per_pin *per_pin)
> +{
> + struct i915_audio_component *acomp = codec->bus->core.audio_component;
> + struct hdmi_spec *spec = codec->spec;
> + struct hdmi_eld *eld = >temp_eld;
> + int size;
> +
> + if (acomp && acomp->ops && acomp->ops->get_eld) {
> + mutex_lock(_pin->lock);
> + size = acomp->ops->get_eld(acomp->dev,
> +intel_pin2port(per_pin->pin_nid),
> +>monitor_present,
> +eld->eld_buffer,
> +ELD_MAX_SIZE);
> + if (size > 0) {
> + memset(>info, 0, sizeof(eld->info));
> + if (snd_hdmi_parse_eld(codec, >info,
> +eld->eld_buffer, size) < 0)
> + size = -EINVAL;
> + }
> +
> + if (size > 0) {
> + eld->eld_valid = true;
> + eld->eld_size = size;
> + } else {
> + eld->eld_valid = false;
> + eld->eld_size = 0;
> + }
> +
> + update_eld(codec, per_pin, eld);
> + snd_jack_report(per_pin->acomp_jack,
> + eld->monitor_present ? SND_JACK_AVOUT : 0);
> + mutex_unlock(_pin->lock);
> + }
> +}

IMO This and the rest can be moved to sound/hda/ so that other can reuse
this code, as the code will be same for other users too..

-- 
~Vinod
> +
> +static void free_acomp_jack_priv(struct snd_jack *jack)
> +{
> + struct hdmi_spec_per_pin *per_pin = jack->private_data;
> +
> + per_pin->acomp_jack = NULL;
> +}
> +
> +static int add_acomp_jack_kctl(struct hda_codec *codec,
> +struct hdmi_spec_per_pin *per_pin,
> +const char *name)
> +{
> + struct snd_jack *jack;
> + int err;
> +
> + err = snd_jack_new(codec->card, name, SND_JACK_AVOUT, ,
> +true, false);
> + if (err < 0)
> + return err;
> + per_pin->acomp_jack = jack;
> +   

Re: [Intel-gfx] [PATCH v4] drm/i915: Slaughter the thundering i915_wait_request herd

[Chris Wilson]

On Mon, Nov 30, 2015 at 04:30:57PM +, Chris Wilson wrote:
> On Mon, Nov 30, 2015 at 02:34:40PM +, Chris Wilson wrote:
> > +bool intel_breadcrumbs_add_waiter(struct drm_i915_gem_request *request)
> > +{
> > +   struct intel_breadcrumbs *b = >i915->breadcrumbs;
> > +   struct intel_breadcrumbs_engine *be = >engine[request->ring->id];
> > +   bool first = false;
> > +
> > +   spin_lock(>lock);
> > +   if (request->waiters_count++ == 0) {
> > +   struct rb_node **p, *parent;
> > +
> > +   if (be->first_waiter == NULL)
> > +   wake_up_process(b->task);
> 
> Oh, the irony.
> 
> Converting the other side to a lockless READ_ONCE() means that I do know

And that's the second mispelling of "now" today!
-Chris

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

Re: [Intel-gfx] [PATCH 5/7] ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling

[Takashi Iwai]

On Mon, 30 Nov 2015 17:42:33 +0100,
Vinod Koul wrote:
> 
> On Mon, Nov 30, 2015 at 02:37:49PM +0100, Takashi Iwai wrote:
> > Since we have a new audio component ops to fetch the current ELD and
> > state now, we can reduce the usage of unsol event of HDMI/DP pins.
> > The unsol event isn't only unreliable, but it also needs the power
> > up/down of the codec and link at each time, which is a significant
> > power and time loss.
> > 
> > In this patch, the jack creation and unsol/jack event handling are
> > modified to use the audio component for the dedicated Intel chips.
> > 
> > The jack handling got slightly more codes than a simple usage of
> > hda_jack layer since we need to deal directly with snd_jack object;
> > the hda_jack layer is basically designed for the pin sense read and
> > unsol events, both of which aren't used any longer in our case.
> > 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  sound/pci/hda/patch_hdmi.c | 84 
> > --
> >  1 file changed, 82 insertions(+), 2 deletions(-)
> > 
> > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> > index 28684aa86408..8378c31e0b4f 100644
> > --- a/sound/pci/hda/patch_hdmi.c
> > +++ b/sound/pci/hda/patch_hdmi.c
> > @@ -83,6 +83,7 @@ struct hdmi_spec_per_pin {
> > struct mutex lock;
> > struct delayed_work work;
> > struct snd_kcontrol *eld_ctl;
> > +   struct snd_jack *acomp_jack; /* jack via audio component */
> > int repoll_count;
> > bool setup; /* the stream has been set up by prepare callback */
> > int channels; /* current number of channels */
> > @@ -141,6 +142,7 @@ struct hdmi_spec {
> > struct hdmi_ops ops;
> >  
> > bool dyn_pin_out;
> > +   bool use_acomp; /* use audio component for ELD notify/update */
> >  
> > /*
> >  * Non-generic VIA/NVIDIA specific
> > @@ -1580,6 +1582,9 @@ static void update_eld(struct hda_codec *codec,
> >_pin->eld_ctl->id);
> >  }
> >  
> > +static void sync_eld_via_acomp(struct hda_codec *codec,
> > +  struct hdmi_spec_per_pin *per_pin);
> > +
> >  static bool hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, int 
> > repoll)
> >  {
> > struct hda_jack_tbl *jack;
> > @@ -1599,6 +1604,11 @@ static bool hdmi_present_sense(struct 
> > hdmi_spec_per_pin *per_pin, int repoll)
> > int present;
> > bool ret;
> >  
> > +   if (spec->use_acomp) {
> > +   sync_eld_via_acomp(codec, per_pin);
> > +   return false; /* don't call snd_hda_jack_report_sync() */
> > +   }
> > +
> > snd_hda_power_up_pm(codec);
> > present = snd_hda_pin_sense(codec, pin_nid);
> >  
> > @@ -2091,6 +2101,68 @@ static int generic_hdmi_build_pcms(struct hda_codec 
> > *codec)
> > return 0;
> >  }
> >  
> > +/* update ELD and jack state via audio component */
> > +static void sync_eld_via_acomp(struct hda_codec *codec,
> > +  struct hdmi_spec_per_pin *per_pin)
> > +{
> > +   struct i915_audio_component *acomp = codec->bus->core.audio_component;
> > +   struct hdmi_spec *spec = codec->spec;
> > +   struct hdmi_eld *eld = >temp_eld;
> > +   int size;
> > +
> > +   if (acomp && acomp->ops && acomp->ops->get_eld) {
> > +   mutex_lock(_pin->lock);
> > +   size = acomp->ops->get_eld(acomp->dev,
> > +  intel_pin2port(per_pin->pin_nid),
> > +  >monitor_present,
> > +  eld->eld_buffer,
> > +  ELD_MAX_SIZE);
> > +   if (size > 0) {
> > +   memset(>info, 0, sizeof(eld->info));
> > +   if (snd_hdmi_parse_eld(codec, >info,
> > +  eld->eld_buffer, size) < 0)
> > +   size = -EINVAL;
> > +   }
> > +
> > +   if (size > 0) {
> > +   eld->eld_valid = true;
> > +   eld->eld_size = size;
> > +   } else {
> > +   eld->eld_valid = false;
> > +   eld->eld_size = 0;
> > +   }
> > +
> > +   update_eld(codec, per_pin, eld);
> > +   snd_jack_report(per_pin->acomp_jack,
> > +   eld->monitor_present ? SND_JACK_AVOUT : 0);
> > +   mutex_unlock(_pin->lock);
> > +   }
> > +}
> 
> IMO This and the rest can be moved to sound/hda/ so that other can reuse
> this code, as the code will be same for other users too..

We have no per_pin or HDMI specific stuff there yet.
What we can reuse at most is only the acomp->ops... call itself, so
far.  hdac_i915.c is a thin wrapper, and it doesn't handle anything
deep wrt HDMI/DP by itself.


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

[Intel-gfx] [PATCH 2/4] drm/i915: Let hangcheck score decay faster than loop increment

[Mika Kuoppala]

We decay hangcheck score, instead of setting it to zero,
when seqno moves forward. This was added as mechanism to
detect batches full of invalid waits. But with multiple runs of
very intensive batches (shader tests), the score accumulates
even without wait/kick pairs only by engine being active inside
shader loops multiple times in succession.

Prevent this mechanism to falsely trigger on loops by
decaying faster than we accumulate during active looping.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6ed6571..3507269 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3009,6 +3009,7 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
 #define BUSY 1
 #define KICK 5
 #define HUNG 20
+#define BUSY_DECAY (2*BUSY)
 
if (!i915.enable_hangcheck)
return;
@@ -3084,8 +3085,8 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
/* Gradually reduce the count so that we catch DoS
 * attempts across multiple batches.
 */
-   if (ring->hangcheck.score > 0)
-   ring->hangcheck.score--;
+   if (ring->hangcheck.score > BUSY_DECAY)
+   ring->hangcheck.score -= BUSY_DECAY;
 
ring->hangcheck.acthd = ring->hangcheck.max_acthd = 0;
}
-- 
2.5.0

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

[Intel-gfx] [PATCH 1/4] drm/i915: Teach hangcheck about long operations on rings

[Mika Kuoppala]

Some operations that happen in ringbuffer, like flushing,
can take significant amounts of time. After some intense
shader tests, the PIPE_CONTROL with flush can apparently last
longer time than what is our hangcheck tick (1500ms). If
this happens twice in a row, even with subsequent batches,
the hangcheck score decaying mechanism can't cope and
hang is declared.

Strip out actual head checking to a separate function and if
actual head has not moved, check if it is lingering inside the
ringbuffer as opposed to batch. If so, treat it as if it would be
inside loop to only slightly increment the hangcheck score.

References: https://bugs.freedesktop.org/show_bug.cgi?id=93029
Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e88d692..6ed6571 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2914,11 +2914,11 @@ static void semaphore_clear_deadlocks(struct 
drm_i915_private *dev_priv)
 }
 
 static enum intel_ring_hangcheck_action
-ring_stuck(struct intel_engine_cs *ring, u64 acthd)
+head_stuck(struct intel_engine_cs *ring, u64 acthd)
 {
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 tmp;
+   u32 head;
 
if (acthd != ring->hangcheck.acthd) {
if (acthd > ring->hangcheck.max_acthd) {
@@ -2929,6 +2929,30 @@ ring_stuck(struct intel_engine_cs *ring, u64 acthd)
return HANGCHECK_ACTIVE_LOOP;
}
 
+   head = I915_READ_HEAD(ring) & HEAD_ADDR;
+
+   /* Some operations, like pipe flush, can take a long time.
+* Detect if we are inside ringbuffer and treat these as if
+* the ring would be busy.
+*/
+   if (lower_32_bits(acthd) == head)
+   return HANGCHECK_ACTIVE_LOOP;
+
+   return HANGCHECK_HUNG;
+}
+
+static enum intel_ring_hangcheck_action
+ring_stuck(struct intel_engine_cs *ring, u64 acthd)
+{
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   enum intel_ring_hangcheck_action ha;
+   u32 tmp;
+
+   ha = head_stuck(ring, acthd);
+   if (ha != HANGCHECK_HUNG)
+   return ha;
+
if (IS_GEN2(dev))
return HANGCHECK_HUNG;
 
-- 
2.5.0

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

[Intel-gfx] [PATCH 3/4] drm/i915: Clear hangcheck score if engine is idle

[Mika Kuoppala]

If we have accumulated hangcheck score before reaching
engine idle, that score will remain and is transferred to
the next set of batches. This is wrong as idle is a quite clear
boundary to prevent hangcheck score manipulation across batches.

Fix this by clearing the score if engine reaches idle.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3507269..c1d1400 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3091,6 +3091,9 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
ring->hangcheck.acthd = ring->hangcheck.max_acthd = 0;
}
 
+   if (!busy)
+   ring->hangcheck.score = 0;
+
ring->hangcheck.seqno = seqno;
ring->hangcheck.acthd = acthd;
busy_count += busy;
-- 
2.5.0

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

[Intel-gfx] [PATCH 4/4] drm/i915: Detect small loops in hangcheck

[Mika Kuoppala]

If there is very small loop in batch, the chances are quite high
that we sample the same head value twice in a row leading the
hangcheck score to be incremented with hung engine status, instead of
active loop which would have been more correct.

Try to resample the actual head few times to detect small loops
instead of jumping into conclusions.

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c1d1400..7c1168b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2914,12 +2914,8 @@ static void semaphore_clear_deadlocks(struct 
drm_i915_private *dev_priv)
 }
 
 static enum intel_ring_hangcheck_action
-head_stuck(struct intel_engine_cs *ring, u64 acthd)
+head_action(struct intel_engine_cs *ring, u64 acthd)
 {
-   struct drm_device *dev = ring->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 head;
-
if (acthd != ring->hangcheck.acthd) {
if (acthd > ring->hangcheck.max_acthd) {
ring->hangcheck.max_acthd = acthd;
@@ -2929,6 +2925,21 @@ head_stuck(struct intel_engine_cs *ring, u64 acthd)
return HANGCHECK_ACTIVE_LOOP;
}
 
+   return HANGCHECK_HUNG;
+}
+
+static enum intel_ring_hangcheck_action
+head_stuck(struct intel_engine_cs *ring, u64 acthd)
+{
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   static enum intel_ring_hangcheck_action ha;
+   u32 head, retries = 5;
+
+   ha = head_action(ring, acthd);
+   if (ha != HANGCHECK_HUNG)
+   return ha;
+
head = I915_READ_HEAD(ring) & HEAD_ADDR;
 
/* Some operations, like pipe flush, can take a long time.
@@ -2938,6 +2949,17 @@ head_stuck(struct intel_engine_cs *ring, u64 acthd)
if (lower_32_bits(acthd) == head)
return HANGCHECK_ACTIVE_LOOP;
 
+   do {
+   msleep(20);
+
+   ring->hangcheck.acthd = acthd;
+   acthd = intel_ring_get_active_head(ring);
+
+   ha = head_action(ring, acthd);
+   if (ha != HANGCHECK_HUNG)
+   return ha;
+   } while (retries--);
+
return HANGCHECK_HUNG;
 }
 
-- 
2.5.0

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

[Intel-gfx] [MIPI SEQ PARSING v3 03/13] drm/i915: Add Intel opregion mailbox 5 structure

[Deepak M]

Mailbox 5 is BIOS to Driver Notification mailbox is intended
to support BIOS to Driver event notification or data storage
for BIOS to Driver data synchronization purpose. Mailbox 5 is
the extension of mailbox 3.

Cc: Jani Nikula 
Signed-off-by: Deepak M 
---
 drivers/gpu/drm/i915/i915_drv.h   | 1 +
 drivers/gpu/drm/i915/intel_opregion.c | 9 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 71bd1dc..135d32a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -457,6 +457,7 @@ struct intel_opregion {
u32 swsci_sbcb_sub_functions;
struct opregion_asle *asle;
void *vbt;
+   struct opregion_asle_ext *asle_ext;
u32 *lid_state;
struct work_struct asle_work;
 };
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 64efedf..43b7c3b 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -46,6 +46,7 @@
 #define OPREGION_SWSCI_OFFSET  0x200
 #define OPREGION_ASLE_OFFSET   0x300
 #define OPREGION_VBT_OFFSET0x400
+#define OPREGION_ASLE_EXT_OFFSET   0x1C00
 
 #define OPREGION_SIGNATURE "IntelGraphicsMem"
 #define MBOX_ACPI  (1<<0)
@@ -125,6 +126,13 @@ struct opregion_asle {
u8 rsvd[58];
 } __packed;
 
+/* OpRegion mailbox #5: ASLE ext */
+struct opregion_asle_ext {
+   u32 phed;   /* Panel Header */
+   u32 bddc[64];   /* Panel EDID */
+   u32 rsvd[191];
+} __packed;
+
 /* Driver readiness indicator */
 #define ASLE_ARDY_READY(1 << 0)
 #define ASLE_ARDY_NOT_READY(0 << 0)
@@ -936,6 +944,7 @@ int intel_opregion_setup(struct drm_device *dev)
opregion->vbt = base + OPREGION_VBT_OFFSET;
 
opregion->lid_state = base + ACPI_CLID;
+   opregion->asle_ext = base + OPREGION_ASLE_EXT_OFFSET;
 
mboxes = opregion->header->mboxes;
if (mboxes & MBOX_ACPI) {
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Takashi Iwai]

On Mon, 30 Nov 2015 16:24:41 +0100,
Ville Syrjälä wrote:
> 
> On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > Implement a new i915_audio_component_ops, get_eld().  It's called by
> > the audio driver to fetch the current ELD of the given HDMI/DP port.
> > It returns the size of ELD bytes if it's valid, or zero if the audio
> > is disabled or unplugged, or a negative error code.
> 
> Why do we need this? Isn't it something the eld notify hook should
> pass from i915 to the audio driver?

We need this at least in two situations:
- when the audio driver is probed
- when the audio driver is resumed

> At least with the locking you have for this, the audio driver can not
> call this from the eld notify hook since it would deadlock.

OK, then we may change the eld_notify to pass the values in the
arguments, and also add the new op with a lock to be called from other
places from other places.


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

Re: [Intel-gfx] [PATCH 4/7] ALSA: hda - Split ELD update code from hdmi_present_sense()

[Vinod Koul]

On Mon, Nov 30, 2015 at 02:37:48PM +0100, Takashi Iwai wrote:
>  
> +/* update per_pin ELD from the given new ELD;
> + * setup info frame and notification accordingly
> + */

nitpick, comment style

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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Ville Syrjälä]

On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> Implement a new i915_audio_component_ops, get_eld().  It's called by
> the audio driver to fetch the current ELD of the given HDMI/DP port.
> It returns the size of ELD bytes if it's valid, or zero if the audio
> is disabled or unplugged, or a negative error code.

Why do we need this? Isn't it something the eld notify hook should
pass from i915 to the audio driver?

At least with the locking you have for this, the audio driver can not
call this from the eld notify hook since it would deadlock.

> 
> For achieving this, a new field audio_enabled is added to struct
> intel_digital_port.  This is set/reset at each audio enable/disable
> call in intel_audio.c.
> 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 40 
> ++
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  include/drm/i915_component.h   |  3 +++
>  3 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 0c38cc6c82ae..6b318a8d5dc9 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>  
>   connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
>  
> + intel_dig_port->audio_enabled = true;
>   if (dev_priv->display.audio_codec_enable)
>   dev_priv->display.audio_codec_enable(connector, intel_encoder,
>adjusted_mode);
> @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder 
> *intel_encoder)
>   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_dig_port->port;
>  
> + intel_dig_port->audio_enabled = false;
>   if (dev_priv->display.audio_codec_disable)
>   dev_priv->display.audio_codec_disable(intel_encoder);
>  
> @@ -702,6 +704,43 @@ static int i915_audio_component_sync_audio_rate(struct 
> device *dev,
>   return 0;
>  }
>  
> +static int i915_audio_component_get_eld(struct device *dev, int port,
> + bool *enabled,
> + unsigned char *buf, int max_bytes)
> +{
> + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> + struct drm_device *drm_dev = dev_priv->dev;
> + struct intel_encoder *intel_encoder;
> + struct intel_digital_port *intel_dig_port;
> + struct drm_connector *connector;
> + unsigned char *eld;
> + int ret = -EINVAL;
> +
> + mutex_lock(_priv->av_mutex);
> + for_each_intel_encoder(drm_dev, intel_encoder) {
> + if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
> + intel_encoder->type != INTEL_OUTPUT_HDMI)
> + continue;
> + intel_dig_port = enc_to_dig_port(_encoder->base);
> + if (port == intel_dig_port->port) {
> + ret = 0;
> + *enabled = intel_dig_port->audio_enabled;
> + if (!*enabled)
> + break;
> + connector = drm_select_eld(_encoder->base);
> + if (!connector)
> + break;
> + eld = connector->eld;
> + ret = min(max_bytes, drm_eld_size(eld));
> + memcpy(buf, eld, ret);
> + break;
> + }
> + }
> +
> + mutex_unlock(_priv->av_mutex);
> + return ret;
> +}
> +
>  static const struct i915_audio_component_ops i915_audio_component_ops = {
>   .owner  = THIS_MODULE,
>   .get_power  = i915_audio_component_get_power,
> @@ -709,6 +748,7 @@ static const struct i915_audio_component_ops 
> i915_audio_component_ops = {
>   .codec_wake_override = i915_audio_component_codec_wake_override,
>   .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
>   .sync_audio_rate = i915_audio_component_sync_audio_rate,
> + .get_eld= i915_audio_component_get_eld,
>  };
>  
>  static int i915_audio_component_bind(struct device *i915_dev,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0598932ce623..4afc7560be04 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -798,6 +798,7 @@ struct intel_digital_port {
>   u32 saved_port_bits;
>   struct intel_dp dp;
>   struct intel_hdmi hdmi;
> + bool audio_enabled;
>   enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
>   bool release_cl2_override;
>  };
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index 30d89e0da2c6..058d39e8d57f 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -38,6 +38,7 @@
>   * 

[Intel-gfx] [PATCH] drm/i915: Convert trace-irq to the breadcrumb waiter

[Chris Wilson]

If we convert the tracing over from direct use of ring->irq_get() and
over to the breadcrumb infrastructure, we only have a single user of the
ring->irq_get and so can simplify the driver routines (eliminating the
redundant validation and irq refcounting).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |   4 +-
 drivers/gpu/drm/i915/i915_gem.c  |   2 +-
 drivers/gpu/drm/i915/intel_breadcrumbs.c |   3 +-
 drivers/gpu/drm/i915/intel_lrc.c |  24 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 210 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   3 +-
 6 files changed, 87 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f50aa580e0b5..e4d3abe24950 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3639,8 +3639,10 @@ wait_remaining_ms_from_jiffies(unsigned long 
timestamp_jiffies, int to_wait_ms)
 static inline void i915_trace_irq_get(struct intel_engine_cs *ring,
  struct drm_i915_gem_request *req)
 {
-   if (ring->trace_irq_req == NULL && ring->irq_get(ring))
+   if (ring->trace_irq_req == NULL) {
i915_gem_request_assign(>trace_irq_req, req);
+   intel_breadcrumbs_add_waiter(req);
+   }
 }
 
 #endif
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0afcbef7ff5f..5902bcd87178 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2876,7 +2876,7 @@ i915_gem_retire_requests_ring(struct intel_engine_cs 
*ring)
 
if (unlikely(ring->trace_irq_req &&
 i915_gem_request_completed(ring->trace_irq_req))) {
-   ring->irq_put(ring);
+   intel_breadcrumbs_remove_waiter(ring->trace_irq_req);
i915_gem_request_assign(>trace_irq_req, NULL);
}
 
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 69091f5ae0f5..5f659079ac1c 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -34,7 +34,8 @@ static bool __irq_enable(struct intel_engine_cs *engine)
if (!intel_irqs_enabled(engine->i915))
return false;
 
-   return engine->irq_get(engine);
+   engine->irq_get(engine);
+   return true;
 }
 
 static struct drm_i915_gem_request *to_request(struct rb_node *rb)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c457dd035900..8842ea0b53fe 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1620,23 +1620,15 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
return 0;
 }
 
-static bool gen8_logical_ring_get_irq(struct intel_engine_cs *ring)
+static void gen8_logical_ring_get_irq(struct intel_engine_cs *ring)
 {
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long flags;
-
-   if (WARN_ON(!intel_irqs_enabled(dev_priv)))
-   return false;
-
-   spin_lock_irqsave(_priv->irq_lock, flags);
-   if (ring->irq_refcount++ == 0) {
-   I915_WRITE_IMR(ring, ~(ring->irq_enable_mask | 
ring->irq_keep_mask));
-   POSTING_READ(RING_IMR(ring->mmio_base));
-   }
-   spin_unlock_irqrestore(_priv->irq_lock, flags);
 
-   return true;
+   spin_lock_irq(_priv->irq_lock);
+   I915_WRITE_IMR(ring, ~(ring->irq_enable_mask | ring->irq_keep_mask));
+   POSTING_READ(RING_IMR(ring->mmio_base));
+   spin_unlock_irq(_priv->irq_lock);
 }
 
 static void gen8_logical_ring_put_irq(struct intel_engine_cs *ring)
@@ -1646,10 +1638,8 @@ static void gen8_logical_ring_put_irq(struct 
intel_engine_cs *ring)
unsigned long flags;
 
spin_lock_irqsave(_priv->irq_lock, flags);
-   if (--ring->irq_refcount == 0) {
-   I915_WRITE_IMR(ring, ~ring->irq_keep_mask);
-   POSTING_READ(RING_IMR(ring->mmio_base));
-   }
+   I915_WRITE_IMR(ring, ~ring->irq_keep_mask);
+   POSTING_READ(RING_IMR(ring->mmio_base));
spin_unlock_irqrestore(_priv->irq_lock, flags);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ccceb43f14ac..2c6f74c004cb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1504,22 +1504,15 @@ gen6_seqno_barrier(struct intel_engine_cs *ring)
intel_flush_status_page(ring, I915_GEM_HWS_INDEX);
 }
 
-static bool
+static void
 gen5_ring_get_irq(struct intel_engine_cs *ring)
 {
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   unsigned long flags;
-
-   if (WARN_ON(!intel_irqs_enabled(dev_priv)))
-   return false;
-
-   

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Takashi Iwai]

On Mon, 30 Nov 2015 16:34:22 +0100,
David Henningsson wrote:
> 
> 
> 
> On 2015-11-30 16:29, Takashi Iwai wrote:
> > On Mon, 30 Nov 2015 16:24:41 +0100,
> > Ville Syrjälä wrote:
> >>
> >> On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> >>> Implement a new i915_audio_component_ops, get_eld().  It's called by
> >>> the audio driver to fetch the current ELD of the given HDMI/DP port.
> >>> It returns the size of ELD bytes if it's valid, or zero if the audio
> >>> is disabled or unplugged, or a negative error code.
> >>
> >> Why do we need this? Isn't it something the eld notify hook should
> >> pass from i915 to the audio driver?
> >
> > We need this at least in two situations:
> > - when the audio driver is probed
> > - when the audio driver is resumed
> >
> >> At least with the locking you have for this, the audio driver can not
> >> call this from the eld notify hook since it would deadlock.
> >
> > OK, then we may change the eld_notify to pass the values in the
> > arguments, and also add the new op with a lock to be called from other
> > places from other places.
> 
> Maybe we have to make eld_notify not do anything except to call 
> schedule_work then? And that work in turn will ask for updated eld from 
> the i915 driver, and handle the result.

Yes, it would work, too -- though, this would need a bit more code
reorganization.


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

Re: [Intel-gfx] [PATCH 4/7] ALSA: hda - Split ELD update code from hdmi_present_sense()

[Takashi Iwai]

On Mon, 30 Nov 2015 17:00:33 +0100,
Vinod Koul wrote:
> 
> On Mon, Nov 30, 2015 at 02:37:48PM +0100, Takashi Iwai wrote:
> >  
> > +/* update per_pin ELD from the given new ELD;
> > + * setup info frame and notification accordingly
> > + */
> 
> nitpick, comment style

There is no preference in sound/* about this, and I myself prefer
without the extra line :)


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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Takashi Iwai]

On Mon, 30 Nov 2015 15:11:16 +0100,
Daniel Vetter wrote:
> 
> On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > Implement a new i915_audio_component_ops, get_eld().  It's called by
> > the audio driver to fetch the current ELD of the given HDMI/DP port.
> > It returns the size of ELD bytes if it's valid, or zero if the audio
> > is disabled or unplugged, or a negative error code.
> > 
> > For achieving this, a new field audio_enabled is added to struct
> > intel_digital_port.  This is set/reset at each audio enable/disable
> > call in intel_audio.c.
> > 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 40 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h   |  1 +
> >  include/drm/i915_component.h   |  3 +++
> >  3 files changed, 44 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 0c38cc6c82ae..6b318a8d5dc9 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  
> > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> >  
> > +   intel_dig_port->audio_enabled = true;
> > if (dev_priv->display.audio_codec_enable)
> > dev_priv->display.audio_codec_enable(connector, intel_encoder,
> >  adjusted_mode);
> > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder 
> > *intel_encoder)
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> >  
> > +   intel_dig_port->audio_enabled = false;
> > if (dev_priv->display.audio_codec_disable)
> > dev_priv->display.audio_codec_disable(intel_encoder);
> >  
> > @@ -702,6 +704,43 @@ static int i915_audio_component_sync_audio_rate(struct 
> > device *dev,
> > return 0;
> >  }
> >  
> > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > +   bool *enabled,
> > +   unsigned char *buf, int max_bytes)
> > +{
> > +   struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > +   struct drm_device *drm_dev = dev_priv->dev;
> > +   struct intel_encoder *intel_encoder;
> > +   struct intel_digital_port *intel_dig_port;
> > +   struct drm_connector *connector;
> > +   unsigned char *eld;
> > +   int ret = -EINVAL;
> > +
> 
> Locking is a bit in-flux atm with atomic, but needs
> dev_priv->dev->mode_config->mutex here to protect against the eld
> changing.

Noted, I'll add it in the next respin.

> > +   mutex_lock(_priv->av_mutex);
> > +   for_each_intel_encoder(drm_dev, intel_encoder) {
> > +   if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
> > +   intel_encoder->type != INTEL_OUTPUT_HDMI)
> 
> MST? Not that I have a clue how that should work ;-)

Well, I supposed that MST entry doesn't actually serve for the digital
port, but I'm not entirely sure.  In anyway, the whole MST audio
support shall be added / handled by other Intel people soon later, so
let's keep this as is -- which is the same condition as the current
i915 code.

> > +   continue;
> > +   intel_dig_port = enc_to_dig_port(_encoder->base);
> > +   if (port == intel_dig_port->port) {
> > +   ret = 0;
> > +   *enabled = intel_dig_port->audio_enabled;
> > +   if (!*enabled)
> > +   break;
> > +   connector = drm_select_eld(_encoder->base);
> > +   if (!connector)
> > +   break;
> > +   eld = connector->eld;
> > +   ret = min(max_bytes, drm_eld_size(eld));
> 
> How can the caller figure out what the eld size is if you use min here? At
> least in drm we just return the size we want if it's too small.

A good point.  The function should return the size "to be written
all", indeed.

> > +   memcpy(buf, eld, ret);
> > +   break;
> > +   }
> > +   }
> > +
> > +   mutex_unlock(_priv->av_mutex);
> > +   return ret;
> > +}
> > +
> >  static const struct i915_audio_component_ops i915_audio_component_ops = {
> > .owner  = THIS_MODULE,
> > .get_power  = i915_audio_component_get_power,
> > @@ -709,6 +748,7 @@ static const struct i915_audio_component_ops 
> > i915_audio_component_ops = {
> > .codec_wake_override = i915_audio_component_codec_wake_override,
> > .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
> > .sync_audio_rate = i915_audio_component_sync_audio_rate,
> > +   .get_eld= i915_audio_component_get_eld,
> >  };
> >  
> >  static int i915_audio_component_bind(struct device *i915_dev,
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Ville Syrjälä]

On Mon, Nov 30, 2015 at 05:24:41PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > Implement a new i915_audio_component_ops, get_eld().  It's called by
> > the audio driver to fetch the current ELD of the given HDMI/DP port.
> > It returns the size of ELD bytes if it's valid, or zero if the audio
> > is disabled or unplugged, or a negative error code.
> 
> Why do we need this? Isn't it something the eld notify hook should
> pass from i915 to the audio driver?
> 
> At least with the locking you have for this, the audio driver can not
> call this from the eld notify hook since it would deadlock.

Hmm. Actually the locking isn't perhaps quite like that atm. But I guess
the mode_config.mutex will make it so.

Apart from that it seesm to me that you should pull the av_mutex
lock/unlock from the .audio_code_eanble/disable hooks into
intel_audio_codec_enable/disable, so that it protects the audio_enabled
flag as well. Not sure if the eld_notify should be called while holding
that lock or not. If we need to avoid calling it from the eld_notify
anywya due to other locks then maybe it can be under av_mutex as well.

> 
> > 
> > For achieving this, a new field audio_enabled is added to struct
> > intel_digital_port.  This is set/reset at each audio enable/disable
> > call in intel_audio.c.
> > 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 40 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h   |  1 +
> >  include/drm/i915_component.h   |  3 +++
> >  3 files changed, 44 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 0c38cc6c82ae..6b318a8d5dc9 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  
> > connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
> >  
> > +   intel_dig_port->audio_enabled = true;
> > if (dev_priv->display.audio_codec_enable)
> > dev_priv->display.audio_codec_enable(connector, intel_encoder,
> >  adjusted_mode);
> > @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder 
> > *intel_encoder)
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> >  
> > +   intel_dig_port->audio_enabled = false;
> > if (dev_priv->display.audio_codec_disable)
> > dev_priv->display.audio_codec_disable(intel_encoder);
> >  
> > @@ -702,6 +704,43 @@ static int i915_audio_component_sync_audio_rate(struct 
> > device *dev,
> > return 0;
> >  }
> >  
> > +static int i915_audio_component_get_eld(struct device *dev, int port,
> > +   bool *enabled,
> > +   unsigned char *buf, int max_bytes)
> > +{
> > +   struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > +   struct drm_device *drm_dev = dev_priv->dev;
> > +   struct intel_encoder *intel_encoder;
> > +   struct intel_digital_port *intel_dig_port;
> > +   struct drm_connector *connector;
> > +   unsigned char *eld;
> > +   int ret = -EINVAL;
> > +
> > +   mutex_lock(_priv->av_mutex);
> > +   for_each_intel_encoder(drm_dev, intel_encoder) {
> > +   if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
> > +   intel_encoder->type != INTEL_OUTPUT_HDMI)
> > +   continue;
> > +   intel_dig_port = enc_to_dig_port(_encoder->base);
> > +   if (port == intel_dig_port->port) {
> > +   ret = 0;
> > +   *enabled = intel_dig_port->audio_enabled;
> > +   if (!*enabled)
> > +   break;
> > +   connector = drm_select_eld(_encoder->base);
> > +   if (!connector)
> > +   break;
> > +   eld = connector->eld;
> > +   ret = min(max_bytes, drm_eld_size(eld));
> > +   memcpy(buf, eld, ret);
> > +   break;
> > +   }
> > +   }
> > +
> > +   mutex_unlock(_priv->av_mutex);
> > +   return ret;
> > +}
> > +
> >  static const struct i915_audio_component_ops i915_audio_component_ops = {
> > .owner  = THIS_MODULE,
> > .get_power  = i915_audio_component_get_power,
> > @@ -709,6 +748,7 @@ static const struct i915_audio_component_ops 
> > i915_audio_component_ops = {
> > .codec_wake_override = i915_audio_component_codec_wake_override,
> > .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
> > .sync_audio_rate = i915_audio_component_sync_audio_rate,
> > +   .get_eld= i915_audio_component_get_eld,
> >  };
> >  
> >  static int i915_audio_component_bind(struct device *i915_dev,
> > diff --git 

Re: [Intel-gfx] [PATCH 3/7] drm/i915: refactoring audio component functions

[Takashi Iwai]

On Mon, 30 Nov 2015 15:14:03 +0100,
Daniel Vetter wrote:
> 
> On Mon, Nov 30, 2015 at 02:37:47PM +0100, Takashi Iwai wrote:
> > We have a common loop of encoder to look for the given audio port in
> > two audio component functions.  Split out a local helper function to
> > do it for the code simplification.
> > 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 61 
> > --
> >  1 file changed, 32 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 6b318a8d5dc9..024e88ae6305 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -630,17 +630,33 @@ static int i915_audio_component_get_cdclk_freq(struct 
> > device *dev)
> > return ret;
> >  }
> >  
> > +static struct intel_encoder *audio_port_to_encoder(struct drm_device 
> > *drm_dev,
> > +  int port)
> > +{
> > +   struct intel_encoder *intel_encoder;
> > +   struct intel_digital_port *intel_dig_port;
> > +
> > +   for_each_intel_encoder(drm_dev, intel_encoder) {
> > +   if (intel_encoder->type != INTEL_OUTPUT_HDMI &&
> > +   intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
> > +   continue;
> > +   intel_dig_port = enc_to_dig_port(_encoder->base);
> > +   if (port == intel_dig_port->port)
> 
> If this is static, maybe just maintain a snd_pin_to_port mapping in
> dev_priv? That's the approach we're usually taking, and it has the benefit
> of making it clear(er) that the binding is static ... Or is it not?

Yes, I *guess* this is static, but need a double-check.  The current
patchset just derives from the existing code.


thanks,

Takashi

> Makes sense otherwise.
> -Daniel
> 
> > +   return intel_encoder;
> > +   }
> > +   return NULL;
> > +}
> > +
> >  static int i915_audio_component_sync_audio_rate(struct device *dev,
> > int port, int rate)
> >  {
> > struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > struct drm_device *drm_dev = dev_priv->dev;
> > struct intel_encoder *intel_encoder;
> > -   struct intel_digital_port *intel_dig_port;
> > struct intel_crtc *crtc;
> > struct drm_display_mode *mode;
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > -   enum pipe pipe = -1;
> > +   enum pipe pipe;
> > u32 tmp;
> > int n;
> >  
> > @@ -652,22 +668,14 @@ static int 
> > i915_audio_component_sync_audio_rate(struct device *dev,
> >  
> > mutex_lock(_priv->av_mutex);
> > /* 1. get the pipe */
> > -   for_each_intel_encoder(drm_dev, intel_encoder) {
> > -   if (intel_encoder->type != INTEL_OUTPUT_HDMI)
> > -   continue;
> > -   intel_dig_port = enc_to_dig_port(_encoder->base);
> > -   if (port == intel_dig_port->port) {
> > -   crtc = to_intel_crtc(intel_encoder->base.crtc);
> > -   pipe = crtc->pipe;
> > -   break;
> > -   }
> > -   }
> > -
> > -   if (pipe == INVALID_PIPE) {
> > +   intel_encoder = audio_port_to_encoder(drm_dev, port);
> > +   if (!intel_encoder || intel_encoder->type != INTEL_OUTPUT_HDMI) {
> > DRM_DEBUG_KMS("no pipe for the port %c\n", port_name(port));
> > mutex_unlock(_priv->av_mutex);
> > return -ENODEV;
> > }
> > +   crtc = to_intel_crtc(intel_encoder->base.crtc);
> > +   pipe = crtc->pipe;
> > DRM_DEBUG_KMS("pipe %c connects port %c\n",
> >   pipe_name(pipe), port_name(port));
> > mode = >config->base.adjusted_mode;
> > @@ -717,23 +725,18 @@ static int i915_audio_component_get_eld(struct device 
> > *dev, int port,
> > int ret = -EINVAL;
> >  
> > mutex_lock(_priv->av_mutex);
> > -   for_each_intel_encoder(drm_dev, intel_encoder) {
> > -   if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
> > -   intel_encoder->type != INTEL_OUTPUT_HDMI)
> > -   continue;
> > +   intel_encoder = audio_port_to_encoder(drm_dev, port);
> > +   if (intel_encoder) {
> > +   ret = 0;
> > intel_dig_port = enc_to_dig_port(_encoder->base);
> > -   if (port == intel_dig_port->port) {
> > -   ret = 0;
> > -   *enabled = intel_dig_port->audio_enabled;
> > -   if (!*enabled)
> > -   break;
> > +   *enabled = intel_dig_port->audio_enabled;
> > +   if (*enabled) {
> > connector = drm_select_eld(_encoder->base);
> > -   if (!connector)
> > -   break;
> > -   eld = connector->eld;
> > -   ret = min(max_bytes, drm_eld_size(eld));
> > -   memcpy(buf, eld, ret);
> > -   break;
> > 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[David Henningsson]

On 2015-11-30 16:29, Takashi Iwai wrote:

On Mon, 30 Nov 2015 16:24:41 +0100,
Ville Syrjälä wrote:


On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:

Implement a new i915_audio_component_ops, get_eld().  It's called by
the audio driver to fetch the current ELD of the given HDMI/DP port.
It returns the size of ELD bytes if it's valid, or zero if the audio
is disabled or unplugged, or a negative error code.


Why do we need this? Isn't it something the eld notify hook should
pass from i915 to the audio driver?


We need this at least in two situations:
- when the audio driver is probed
- when the audio driver is resumed


At least with the locking you have for this, the audio driver can not
call this from the eld notify hook since it would deadlock.


OK, then we may change the eld_notify to pass the values in the
arguments, and also add the new op with a lock to be called from other
places from other places.


Maybe we have to make eld_notify not do anything except to call 
schedule_work then? And that work in turn will ask for updated eld from 
the i915 driver, and handle the result.


--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/gem_request_retire: add test description

[Thomas Wood]

Cc: Tvrtko Ursulin 
Signed-off-by: Thomas Wood 
---
 tests/gem_request_retire.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/gem_request_retire.c b/tests/gem_request_retire.c
index 0c7c45e..545a245 100644
--- a/tests/gem_request_retire.c
+++ b/tests/gem_request_retire.c
@@ -49,6 +49,9 @@
 
 #include "intel_bufmgr.h"
 
+IGT_TEST_DESCRIPTION("Collection of tests targeting request retirement code"
+" paths.");
+
 #define WIDTH 4096
 #define HEIGHT 4096
 #define BO_SIZE (WIDTH * HEIGHT * sizeof(uint32_t))
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Takashi Iwai]

On Mon, 30 Nov 2015 15:17:05 +0100,
Daniel Vetter wrote:
> 
> On Mon, Nov 30, 2015 at 03:11:16PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> > > index 30d89e0da2c6..058d39e8d57f 100644
> > > --- a/include/drm/i915_component.h
> > > +++ b/include/drm/i915_component.h
> > > @@ -38,6 +38,7 @@
> > >   * @codec_wake_override: Enable/Disable generating the codec wake signal
> > >   * @get_cdclk_freq: get the Core Display Clock in KHz
> > >   * @sync_audio_rate: set n/cts based on the sample rate
> > > + * @get_eld: fill the audio state and ELD bytes for the given port
> > 
> > In 4.4 kerneldoc supports extended in-line comments for struct members
> > like this:
> > 
> > >   */
> > >  struct i915_audio_component_ops {
> > >   struct module *owner;
> > > @@ -46,6 +47,8 @@ struct i915_audio_component_ops {
> > >   void (*codec_wake_override)(struct device *, bool enable);
> > >   int (*get_cdclk_freq)(struct device *);
> > >   int (*sync_audio_rate)(struct device *, int port, int rate);
> > 
> > /**
> >  * @get_eld:
> >  *
> >  * lots of blabla, possibly in multiple paragraphs.
> >  */
> > 
> > Please use that layout and put a copy of the more detailed description you
> > put into the commit message of how ->get_eld exactly works.
> > 
> > I did ask for this to get done as part of some of the previous, and it was
> > partially done but not exactly how kerneldoc wants it :( But I think we
> > need to start somewhere ...
> 
> Strike that, I looked at the wrong tree ;-) linux-next should have all the
> patches using the new extended style.

OK, so this is a post-4.4 change.  I can rebase on it.  Could you
point a steady branch suitable for it?


thanks,

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Teach hangcheck about long operations on rings

[Chris Wilson]

On Mon, Nov 30, 2015 at 06:04:54PM +, Dave Gordon wrote:
> On 30/11/15 17:11, Chris Wilson wrote:
> >On Mon, Nov 30, 2015 at 06:53:06PM +0200, Mika Kuoppala wrote:
> >>Some operations that happen in ringbuffer, like flushing,
> >>can take significant amounts of time. After some intense
> >>shader tests, the PIPE_CONTROL with flush can apparently last
> >>longer time than what is our hangcheck tick (1500ms). If
> >>this happens twice in a row, even with subsequent batches,
> >>the hangcheck score decaying mechanism can't cope and
> >>hang is declared.
> >>
> >>Strip out actual head checking to a separate function and if
> >>actual head has not moved, check if it is lingering inside the
> >>ringbuffer as opposed to batch. If so, treat it as if it would be
> >>inside loop to only slightly increment the hangcheck score.
> >
> >The PIPE_CONTROL in the ring after the batch, is equivalent to the batch
> >performing its own PIPE_CONTROL as the last instruction. It does not
> >make sense to distinguish the two.
> >-Chris
> 
> It's equivalent in terms of outcome, but not when checking what's
> happening. The driver controls insertion of PIPE_CONTROLs in the
> ring, but not in batches. If execution is at the ring level, we know
> it's running instructions that the driver put there, and we know
> that it *will* then progress to the next batch (assuming the
> hardware's not stuck). OTOH if execution is inside a batch then we
> don't know what sequence of instructions it's running, and we can't
> guarantee that the batch will ever terminate. So, a reduced penalty
> if executing driver-supplied code makes sense.

Not exactly. If it is executing an infinite loop in the shader, it will
hang indefinitely at whatever pipecontrol comes next. The pipecontrol
following the batch is a forced operation in the user context to ensure
correctness between batches.
-Chris

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

[Intel-gfx] [PATCH v5] PCI / PM: Tune down retryable runtime suspend error messages

[Imre Deak]

The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
suspend hooks as errors, but they still show up as errors in dmesg. Tune
them down. See rpm_suspend() for details of handling these return values.

Note that we use dev_dbg() for the retryable retvals, so after this
change you'll need either CONFIG_DYNAMIC_DEBUG or CONFIG_PCI_DEBUG
for them to show up in the log.

One problem caused by this was noticed by Daniel: the i915 driver
returns EAGAIN to signal a temporary failure to suspend and as a request
towards the RPM core for scheduling a suspend again. This is a normal
event, but the resulting error message flags a breakage during the
driver's automated testing which parses dmesg and picks up the error.

Reported-by: Daniel Vetter 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
CC: Bjorn Helgaas 
CC: Rafael J. Wysocki 
Signed-off-by: Imre Deak 

---

v2:
- fix compile breake when CONFIG_PM_SLEEP=n (0-day builder)
v3:
- instead of modifying the suspend_report_result() helper to disinguish
  between the runtime and system suspend case, inline the error
  printing, it's not used anywhere else (Rafael)
v4:
- don't refer to log levels as flags in code comment (Rafael)
- use pr_debug(), pr_err() instead of the corresponding printk() (Rafael)
v5:
- clarify commit message (Bjorn)
- use dev_dbg, dev_err instead of pr_debug, pr_err (Bjorn)
- use %pf in printk format instead of %pF (Bjorn)
- make the debug/error messages more meaningful (Bjorn)
---
 drivers/pci/pci-driver.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 4446fcb..d7ffd66 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1146,9 +1146,21 @@ static int pci_pm_runtime_suspend(struct device *dev)
pci_dev->state_saved = false;
pci_dev->no_d3cold = false;
error = pm->runtime_suspend(dev);
-   suspend_report_result(pm->runtime_suspend, error);
-   if (error)
+   if (error) {
+   /*
+* -EBUSY and -EAGAIN is used to request the runtime PM core
+* to schedule a new suspend, so log the event only with debug
+* log level.
+*/
+   if (error == -EBUSY || error == -EAGAIN)
+   dev_dbg(dev, "can't suspend now (%pf returned %d)\n",
+   pm->runtime_suspend, error);
+   else
+   dev_err(dev, "can't suspend (%pf returned %d)\n",
+   pm->runtime_suspend, error);
+
return error;
+   }
if (!pci_dev->d3cold_allowed)
pci_dev->no_d3cold = true;
 
-- 
2.5.0

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

Re: [Intel-gfx] [git pull] drm fixes

[Linus Torvalds]

On Sun, Nov 29, 2015 at 11:33 PM, Daniel Vetter  wrote:
>
> Yeah I just hunted down a test infrastructure failure on my Haswell the
> past few days with various loads and output configs. Seemed very happy.
> And not aware of anything else blowing up (bdw/skl would be less
> surprising).

So I'm currently suspecting that we may have had a power-brownout
situation. We ended up actually having a complete (but short) power
loss a bit after I saw two consecutive lockup events, and it hasn't
happened since.

I used to have a UPS on the machine, but our power has been stable
enough the last few years that when the battery gave out I just
stopped using it. I guess that next time I rebuild that machine (I'm
planning on upgrading to skylake some time), I'll just make sure to
replace the power supply too. It's probably ten years old by now (the
disks, motherboard and CPU's have all been replaced multiple times,
but the nice silent case and power supply I've just continually
re-used), so I could imagine that a brown-out together with a
weakening power supply might start to be an issue.

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Teach hangcheck about long operations on rings

[Dave Gordon]

On 30/11/15 17:11, Chris Wilson wrote:

On Mon, Nov 30, 2015 at 06:53:06PM +0200, Mika Kuoppala wrote:

Some operations that happen in ringbuffer, like flushing,
can take significant amounts of time. After some intense
shader tests, the PIPE_CONTROL with flush can apparently last
longer time than what is our hangcheck tick (1500ms). If
this happens twice in a row, even with subsequent batches,
the hangcheck score decaying mechanism can't cope and
hang is declared.

Strip out actual head checking to a separate function and if
actual head has not moved, check if it is lingering inside the
ringbuffer as opposed to batch. If so, treat it as if it would be
inside loop to only slightly increment the hangcheck score.


The PIPE_CONTROL in the ring after the batch, is equivalent to the batch
performing its own PIPE_CONTROL as the last instruction. It does not
make sense to distinguish the two.
-Chris


It's equivalent in terms of outcome, but not when checking what's 
happening. The driver controls insertion of PIPE_CONTROLs in the ring, 
but not in batches. If execution is at the ring level, we know it's 
running instructions that the driver put there, and we know that it 
*will* then progress to the next batch (assuming the hardware's not 
stuck). OTOH if execution is inside a batch then we don't know what 
sequence of instructions it's running, and we can't guarantee that the 
batch will ever terminate. So, a reduced penalty if executing 
driver-supplied code makes sense.


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

Re: [Intel-gfx] [PATCH v4] PCI / PM: tune down RPM suspend error message with EBUSY and EAGAIN retval

[Bjorn Helgaas]

Hi Imre,

> PCI / PM: tune down RPM suspend error message with EBUSY and EAGAIN retval

Please capitalize the first word, e.g., "Tune ..."

Maybe "Tune down non-fatal runtime suspend error messages" would be
more to the point.  Or maybe "retryable," since it sounds like that's
what's supposed to happen.


On Sat, Nov 28, 2015 at 10:34:24AM +0200, Imre Deak wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down.

I looked briefly for the place in the runtime PM core where we handle
EBUSY and EAGAIN specially, but I didn't find it.  A pointer would be
helpful.

> One problem caused by this was noticed by Daniel: the i915 driver
> returns EAGAIN to signal a temporary failure to suspend and as a request
> towards the RPM core for scheduling a suspend again. This is a normal
> event, but the resulting error message flags a breakage during the
> driver's automated testing which parses dmesg and picks up the error.
> 
> v2:
> - fix compile breake when CONFIG_PM_SLEEP=n (0-day builder)
> v3:
> - instead of modifying the suspend_report_result() helper to disinguish
>   between the runtime and system suspend case, inline the error
>   printing, it's not used anywhere else (Rafael)
> v4:
> - don't refer to log levels as flags in code comment (Rafael)
> - use pr_debug(), pr_err() instead of the corresponding printk() (Rafael)

The version history is very useful during development but not after
merging, so I prefer it to go after the "---" marker so it doesn't get
included in the permanent changelog.

> Reported-by: Daniel Vetter 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> CC: Bjorn Helgaas 
> CC: Rafael J. Wysocki 
> Signed-off-by: Imre Deak 
> ---
>  drivers/pci/pci-driver.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 4446fcb..32a9947 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1146,9 +1146,21 @@ static int pci_pm_runtime_suspend(struct device *dev)
>   pci_dev->state_saved = false;
>   pci_dev->no_d3cold = false;
>   error = pm->runtime_suspend(dev);
> - suspend_report_result(pm->runtime_suspend, error);
> - if (error)
> + if (error) {
> + /*
> +  * -EBUSY and -EAGAIN is used to request the runtime PM core
> +  * to schedule a new suspend, so log the event only with debug
> +  * log level.
> +  */
> + if (error == -EBUSY || error == -EAGAIN)
> + pr_debug("%s(): %pF returns %d\n", __func__,
> +  pm->runtime_suspend, error);
> + else
> + pr_err("%s(): %pF returns %d\n", __func__,
> +pm->runtime_suspend, error);

This looks fine to me in principle.

We have the device pointer, so please use dev_printk(KERN_DEBUG) and
dev_err().  If you're OK with changing the semantics so the debug
message is only emitted when dynamically enabled, you could use
dev_dbg().

I don't know what a user is supposed to do with a message like:

  pci_pm_runtime_suspend(): ata_port_runtime_suspend+0x0/0x200 returns -12

It feels a little bit ... internal.  Using dev_err() will help anchor
it to a specific device.  It's not related to a specific PC in the
function, so maybe use %pf instead of %pF to get rid of the function
offset and size.  And the message doesn't say anything about what the
return code *means*; maybe something like:

  ata_piix :00:14.0: can't suspend now (ata_port_runtime_suspend returned 
-11)
  ata_piix :00:14.0: can't suspend (ata_port_runtime_suspend returned -12)

> +
>   return error;
> + }
>   if (!pci_dev->d3cold_allowed)
>   pci_dev->no_d3cold = true;
>  
> -- 
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

[Vinay Belgaumkar]

These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.

Caveat: These tests were designed to run on 64-bit system. Future work
includes adding logic to ensure these tests can run on 32-bit systems with
PPGTT support. Some tests are currently disabled for 32-bit systems for that
reason.

v2: Added cc and signed-off-by fields

v3: Fixed review comments, added helper functions. Removed userptr error
scenarios covered by existing userptr tests. Modified stress test to have
100K buffers, it now runs for ~30 mins, checks every element has been written
to correctly, and pins buffers at different VMAs.

v4: Changed name to gem_softpin

v5: More fixes. Removed the file based tests, will move them to userptr tests.
Added a function that validates appropriate PPGTT support before running tests.
Optimized stack space and memory footprint in stress test. Removed the eviction
test, will add it back after verifying proper functionality.

v6: Split basic test into userptr and bo
Fixed some coding style issues.

v7: Enhanced invalid vma pinning test to verify 32-bit PPGTT functionality.
Enabled the test for 32-bit PPGTT systems, and verify pinning fails above
32-bit addresses. Enhanced the high adress pinning test to ensure pinning
fails when EXEC_OBJECT_PINNED flag is not used. Some more cosmetic fixes to
close buffer handles. Changed userptr function to used synchronized operations.

Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Signed-off-by: Vinay Belgaumkar 
---
 tests/.gitignore   |1 +
 tests/Makefile.sources |1 +
 tests/gem_softpin.c| 1050 
 3 files changed, 1052 insertions(+)
 create mode 100644 tests/gem_softpin.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 80af9a7..424870b 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -21,6 +21,7 @@ gem_bad_blit
 gem_bad_length
 gem_bad_reloc
 gem_basic
+gem_softpin
 gem_caching
 gem_close_race
 gem_concurrent_all
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 8fb2de8..2008d4a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -11,6 +11,7 @@ TESTS_progs_M = \
drv_hangman \
gem_bad_reloc \
gem_basic \
+   gem_softpin \
gem_caching \
gem_close_race \
gem_concurrent_blit \
diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
new file mode 100644
index 000..86cfaf8
--- /dev/null
+++ b/tests/gem_softpin.c
@@ -0,0 +1,1050 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Vinay Belgaumkar 
+ *Thomas Daniel 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "drm.h"
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_chipset.h"
+#include "intel_io.h"
+#include "i915_drm.h"
+#include 
+#include 
+#include 
+#include 
+#include "igt_kms.h"
+#include 
+#include 
+#include 
+
+#define BO_SIZE 4096
+#define MULTIPAGE_BO_SIZE 2 * BO_SIZE
+#define STORE_BATCH_BUFFER_SIZE 4
+#define EXEC_OBJECT_PINNED (1<<4)
+#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
+#define SHARED_BUFFER_SIZE 4096
+
+typedef struct drm_i915_gem_userptr i915_gem_userptr;
+
+static uint32_t init_userptr(int fd, i915_gem_userptr *, void *ptr, uint64_t 
size);
+static void *create_mem_buffer(uint64_t size);
+static int gem_call_userptr_ioctl(int fd, i915_gem_userptr *userptr);
+static void gem_pin_userptr_test(void);
+static void 

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7)

[Matt Roper]

On Wed, Nov 25, 2015 at 07:08:53PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 25, 2015 at 08:48:35AM -0800, Matt Roper wrote:
> > In addition to calculating final watermarks, let's also pre-calculate a
> > set of intermediate watermark values at atomic check time.  These
> > intermediate watermarks are a combination of the watermarks for the old
> > state and the new state; they should satisfy the requirements of both
> > states which means they can be programmed immediately when we commit the
> > atomic state (without waiting for a vblank).  Once the vblank does
> > happen, we can then re-program watermarks to the more optimal final
> > value.
> > 
> > v2: Significant rebasing/rewriting.
> > 
> > v3:
> >  - Move 'need_postvbl_update' flag to CRTC state (Daniel)
> >  - Don't forget to check intermediate watermark values for validity
> >(Maarten)
> >  - Don't due async watermark optimization; just do it at the end of the
> >atomic transaction, after waiting for vblanks.  We do want it to be
> >async eventually, but adding that now will cause more trouble for
> >Maarten's in-progress work.  (Maarten)
> >  - Don't allocate space in crtc_state for intermediate watermarks on
> >platforms that don't need it (gen9+).
> >  - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
> >now that ilk_update_wm is gone.
> > 
> > v4:
> >  - Add a wm_mutex to cover updates to intel_crtc->active and the
> >need_postvbl_update flag.  Since we don't have async yet it isn't
> >terribly important yet, but might as well add it now.
> >  - Change interface to program watermarks.  Platforms will now expose
> >.initial_watermarks() and .optimize_watermarks() functions to do
> >watermark programming.  These should lock wm_mutex, copy the
> >appropriate state values into intel_crtc->active, and then call
> >the internal program watermarks function.
> > 
> > v5:
> >  - Skip intermediate watermark calculation/check during initial hardware
> >readout since we don't trust the existing HW values (and don't have
> >valid values of our own yet).
> >  - Don't try to call .optimize_watermarks() on platforms that don't have
> >atomic watermarks yet.  (Maarten)
> > 
> > v6:
> >  - Rebase
> > 
> > v7:
> >  - Further rebase
> > 
> > Signed-off-by: Matt Roper 
> > Reviewed-by(v5): Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |   6 +-
> >  drivers/gpu/drm/i915/intel_atomic.c  |   1 +
> >  drivers/gpu/drm/i915/intel_display.c |  90 +++-
> >  drivers/gpu/drm/i915/intel_drv.h |  31 ++-
> >  drivers/gpu/drm/i915/intel_pm.c  | 160 
> > ---
> >  5 files changed, 232 insertions(+), 56 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5172604..427b488 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -630,7 +630,11 @@ struct drm_i915_display_funcs {
> >   struct dpll *best_clock);
> > int (*compute_pipe_wm)(struct intel_crtc *crtc,
> >struct drm_atomic_state *state);
> > -   void (*program_watermarks)(struct intel_crtc_state *cstate);
> > +   int (*compute_intermediate_wm)(struct drm_device *dev,
> > +  struct intel_crtc *intel_crtc,
> > +  struct intel_crtc_state *newstate);
> > +   void (*initial_watermarks)(struct intel_crtc_state *cstate);
> > +   void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> > void (*update_wm)(struct drm_crtc *crtc);
> > int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> > void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index 643f342..b91e166 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -95,6 +95,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> >  
> > crtc_state->update_pipe = false;
> > crtc_state->disable_lp_wm = false;
> > +   crtc_state->wm.need_postvbl_update = false;
> >  
> > return _state->base;
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index eb52afa..8db0486 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11801,6 +11801,12 @@ int intel_plane_atomic_calc_changes(struct 
> > drm_crtc_state *crtc_state,
> > intel_crtc->atomic.update_wm_pre = true;
> > }
> >  
> > +   /* Pre-gen9 platforms need two-step watermark updates */
> > +   if ((intel_crtc->atomic.update_wm_pre || 
> > intel_crtc->atomic.update_wm_post) &&
> > +   INTEL_INFO(dev)->gen < 9 &&
> > +   dev_priv->display.optimize_watermarks)
> > +   

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)

[Matt Roper]

On Mon, Nov 30, 2015 at 10:50:26AM +0100, Maarten Lankhorst wrote:
> Op 25-11-15 om 17:48 schreef Matt Roper:
> > Although we can do a good job of reading out hardware state, the
> > graphics firmware may have programmed the watermarks in a creative way
> > that doesn't match how i915 would have chosen to program them.  We
> > shouldn't trust the firmware's watermark programming, but should rather
> > re-calculate how we think WM's should be programmed and then shove those
> > values into the hardware.
> >
> > We can do this pretty easily by creating a dummy top-level state,
> > running it through the check process to calculate all the values, and
> > then just programming the watermarks for each CRTC.
> >
> > v2:  Move watermark sanitization after our BIOS fb reconstruction; the
> >  watermark calculations that we do here need to look at pstate->fb,
> >  which isn't setup yet in intel_modeset_setup_hw_state(), even
> >  though we have an enabled & visible plane.
> >
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  |  1 +
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_display.c | 58 
> > 
> >  drivers/gpu/drm/i915/intel_pm.c  | 14 +
> >  4 files changed, 68 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 3731a26..8a98e0c 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2478,6 +2478,7 @@ drm_atomic_helper_duplicate_state(struct drm_device 
> > *dev,
> > }
> > }
> >  
> > +   drm_modeset_lock(>mode_config.connection_mutex, ctx);
> > drm_for_each_connector(conn, dev) {
> > struct drm_connector_state *conn_state;
> Seems this hunk doesn't belong to this patch?
> Also that locking is already taken care of by drm_atomic_get_connector_state,
> and it doesn't check for drm_modeset_lock returning an error code..

This should be a separate patch, but it is indeed necessary.  We hit the
locking error before we call drm_atomic_get_connector_state...the loop
iterator itself (drm_for_each_connector) will throw a warning if we're
not already holding connection_mutex as of

commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
Author: Daniel Vetter 
Date:   Thu Jul 9 23:44:28 2015 +0200

drm: Check locking in drm_for_each_connector

I'll pull this out and send it separately.


Matt

> 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 11ae5a5..5172604 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
> >   struct dpll *best_clock);
> > int (*compute_pipe_wm)(struct intel_crtc *crtc,
> >struct drm_atomic_state *state);
> > +   void (*program_watermarks)(struct intel_crtc_state *cstate);
> > void (*update_wm)(struct drm_crtc *crtc);
> > int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> > void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 00e4c37..eb52afa 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
> > intel_enable_gt_powersave(dev);
> >  }
> >  
> > +/*
> > + * Calculate what we think the watermarks should be for the state we've 
> > read
> > + * out of the hardware and then immediately program those watermarks so 
> > that
> > + * we ensure the hardware settings match our internal state.
> > + */
> > +static void sanitize_watermarks(struct drm_device *dev)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(dev);
> > +   struct drm_atomic_state *state;
> > +   struct drm_crtc *crtc;
> > +   struct drm_crtc_state *cstate;
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   int ret;
> > +   int i;
> > +
> > +   /* Only supported on platforms that use atomic watermark design */
> > +   if (!dev_priv->display.program_watermarks)
> > +   return;
> > +
> > +   /*
> > +* Calculate what we think WM's should be by creating a dummy state and
> > +* running it through the atomic check code.
> > +*/
> > +   drm_modeset_acquire_init(, 0);
> > +   state = drm_atomic_helper_duplicate_state(dev, );
> > +   if (WARN_ON(IS_ERR(state)))
> > +   return;
> > +
> > +   ret = intel_atomic_check(dev, state);
> > +   if (ret) {
> > +   /*
> > +* Just give up and leave watermarks untouched if we get an
> > +* error back from 'check'
> > +*/
> > +   

[Intel-gfx] [PATCH v3] drm/i915/guc: Clean up locks in GuC

[yu . dai]

From: Alex Dai 

When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
due to irq is disabled. The unnecessary locks has been cleared.
dev->struct_mutex is used instead where needed.

Issue is found in igt/gem_close_race.

v3: Remove unnecessary whitespace churn
v2: Clean up wq_lock too
v1: Clean up host2guc lock as well

Signed-off-by: Alex Dai 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 12 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c | 31 ++
 drivers/gpu/drm/i915/intel_guc.h   |  4 
 3 files changed, 12 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a728ff1..d6b7817 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2473,15 +2473,15 @@ static int i915_guc_info(struct seq_file *m, void *data)
if (!HAS_GUC_SCHED(dev_priv->dev))
return 0;
 
+   if (mutex_lock_interruptible(>struct_mutex))
+   return 0;
+
/* Take a local copy of the GuC data, so we can dump it at leisure */
-   spin_lock(_priv->guc.host2guc_lock);
guc = dev_priv->guc;
-   if (guc.execbuf_client) {
-   spin_lock(_client->wq_lock);
+   if (guc.execbuf_client)
client = *guc.execbuf_client;
-   spin_unlock(_client->wq_lock);
-   }
-   spin_unlock(_priv->guc.host2guc_lock);
+
+   mutex_unlock(>struct_mutex);
 
seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ed9f100..a7f9785 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -86,7 +86,6 @@ static int host2guc_action(struct intel_guc *guc, u32 *data, 
u32 len)
return -EINVAL;
 
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
-   spin_lock(_priv->guc.host2guc_lock);
 
dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = data[0];
@@ -119,7 +118,6 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
}
dev_priv->guc.action_status = status;
 
-   spin_unlock(_priv->guc.host2guc_lock);
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 
return ret;
@@ -292,16 +290,12 @@ static uint32_t select_doorbell_cacheline(struct 
intel_guc *guc)
const uint32_t cacheline_size = cache_line_size();
uint32_t offset;
 
-   spin_lock(>host2guc_lock);
-
/* Doorbell uses a single cache line within a page */
offset = offset_in_page(guc->db_cacheline);
 
/* Moving to next cache line to reduce contention */
guc->db_cacheline += cacheline_size;
 
-   spin_unlock(>host2guc_lock);
-
DRM_DEBUG_DRIVER("selected doorbell cacheline 0x%x, next 0x%x, linesize 
%u\n",
offset, guc->db_cacheline, cacheline_size);
 
@@ -322,13 +316,11 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
const uint16_t end = start + half;
uint16_t id;
 
-   spin_lock(>host2guc_lock);
id = find_next_zero_bit(guc->doorbell_bitmap, end, start);
if (id == end)
id = GUC_INVALID_DOORBELL_ID;
else
bitmap_set(guc->doorbell_bitmap, id, 1);
-   spin_unlock(>host2guc_lock);
 
DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
hi_pri ? "high" : "normal", id);
@@ -338,9 +330,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
 
 static void release_doorbell(struct intel_guc *guc, uint16_t id)
 {
-   spin_lock(>host2guc_lock);
bitmap_clear(guc->doorbell_bitmap, id, 1);
-   spin_unlock(>host2guc_lock);
 }
 
 /*
@@ -487,16 +477,13 @@ static int guc_get_workqueue_space(struct i915_guc_client 
*gc, u32 *offset)
struct guc_process_desc *desc;
void *base;
u32 size = sizeof(struct guc_wq_item);
-   int ret = 0, timeout_counter = 200;
+   int ret = -ETIMEDOUT, timeout_counter = 200;
 
base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, 0));
desc = base + gc->proc_desc_offset;
 
while (timeout_counter-- > 0) {
-   ret = wait_for_atomic(CIRC_SPACE(gc->wq_tail, desc->head,
-   gc->wq_size) >= size, 1);
-
-   if (!ret) {
+   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
*offset = gc->wq_tail;
 
/* advance the tail for next workqueue item */
@@ -505,7 +492,11 @@ static int 

[Intel-gfx] [PATCH] drm/atomic-helper: Grab connection_mutex while duplicating state

[Matt Roper]

Callers of drm_atomic_helper_duplicate_state() may not have grabbed
locks before calling this function.  We're not supposed to iterate over
connectors without holding connection_mutex (since MST allows new
connectors to be spawned at hotplug), so make sure we grab that
ourselves before invoking drm_for_each_connector().  Failure to grab
this lock would cause us to stumble over the assertion added in commit:

commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
Author: Daniel Vetter 
Date:   Thu Jul 9 23:44:28 2015 +0200

drm: Check locking in drm_for_each_connector

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_atomic_helper.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3731a26..e5d0b21 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2478,6 +2478,10 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
}
}
 
+   err = drm_modeset_lock(>mode_config.connection_mutex, ctx);
+   if (err)
+   goto free;
+
drm_for_each_connector(conn, dev) {
struct drm_connector_state *conn_state;
 
-- 
2.1.4

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

[Intel-gfx] [PATCH] drm/i915: Sanitize watermarks after hardware state readout (v3)

[Matt Roper]

Although we can do a good job of reading out hardware state, the
graphics firmware may have programmed the watermarks in a creative way
that doesn't match how i915 would have chosen to program them.  We
shouldn't trust the firmware's watermark programming, but should rather
re-calculate how we think WM's should be programmed and then shove those
values into the hardware.

We can do this pretty easily by creating a dummy top-level state,
running it through the check process to calculate all the values, and
then just programming the watermarks for each CRTC.

v2:  Move watermark sanitization after our BIOS fb reconstruction; the
 watermark calculations that we do here need to look at pstate->fb,
 which isn't setup yet in intel_modeset_setup_hw_state(), even
 though we have an enabled & visible plane.

v3:
 - Don't move 'active = optimal' watermark assignment; we just undo
   that change in the next patch anyway.  (Ville)
 - Move atomic helper locking fix to separate patch.  (Maarten)

Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
The call to drm_atomic_helper_duplicate_state() in this patch will throw a
warning; atomic helper patch "drm/atomic-helper: Grab connection_mutex while
duplicating state" is necessary to fix that.

 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 58 
 drivers/gpu/drm/i915/intel_pm.c  | 10 ---
 3 files changed, 65 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11ae5a5..5172604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
  struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
   struct drm_atomic_state *state);
+   void (*program_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 00e4c37..eb52afa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
intel_enable_gt_powersave(dev);
 }
 
+/*
+ * Calculate what we think the watermarks should be for the state we've read
+ * out of the hardware and then immediately program those watermarks so that
+ * we ensure the hardware settings match our internal state.
+ */
+static void sanitize_watermarks(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_atomic_state *state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *cstate;
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+   int i;
+
+   /* Only supported on platforms that use atomic watermark design */
+   if (!dev_priv->display.program_watermarks)
+   return;
+
+   /*
+* Calculate what we think WM's should be by creating a dummy state and
+* running it through the atomic check code.
+*/
+   drm_modeset_acquire_init(, 0);
+   state = drm_atomic_helper_duplicate_state(dev, );
+   if (WARN_ON(IS_ERR(state)))
+   return;
+
+   ret = intel_atomic_check(dev, state);
+   if (ret) {
+   /*
+* Just give up and leave watermarks untouched if we get an
+* error back from 'check'
+*/
+   DRM_DEBUG_KMS("Could not determine valid watermarks for 
inherited state\n");
+   return;
+   }
+
+   /* Write calculated watermark values back */
+   to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
+
+   dev_priv->display.program_watermarks(cs);
+   }
+
+   drm_atomic_state_free(state);
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+}
+
 void intel_modeset_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -15243,6 +15294,13 @@ void intel_modeset_init(struct drm_device *dev)
intel_dump_pipe_config(crtc, crtc->config,
   "[state after init fb reconstruction]");
}
+
+   /*
+* Make sure hardware watermarks really match the state we read out.
+* Note that we need to do this after reconstructing the BIOS fb's
+* since the watermark calculation done here will use pstate->fb.
+*/
+   

[Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.

[Bob Paauwe]

Now that the frequency can drop below the user specified minimum when
the gpu is idle, add some checking to verify that it really does drop
down to the RPn frequency in specific cases.

To do this, modify the main test flow to take two 'check' routines
instead of one. When running the config-min-max-idle subtest make
use of the second check routine to verify that the frequency drops
to RPn instead of simply <= user min frequency.  For all other
subtests, use the original check routines for both checks.

Signed-off-by: Bob Paauwe 
---
 tests/pm_rps.c | 47 ++-
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index f919625..96225ce 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -364,7 +364,7 @@ static int get_hw_rounded_freq(int target)
return ret;
 }
 
-static void min_max_config(void (*check)(void), bool load_gpu)
+static void min_max_config(void (*check)(void), void (*check2)(void), bool 
load_gpu)
 {
int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
 
@@ -384,7 +384,7 @@ static void min_max_config(void (*check)(void), bool 
load_gpu)
writeval(stuff[MAX].filp, origfreqs[RP0]);
if (load_gpu)
do_load_gpu();
-   check();
+   check2();
 
igt_debug("\nIncrease min to midpoint...\n");
writeval(stuff[MIN].filp, fmid);
@@ -412,7 +412,7 @@ static void min_max_config(void (*check)(void), bool 
load_gpu)
writeval(stuff[MIN].filp, origfreqs[RPn]);
if (load_gpu)
do_load_gpu();
-   check();
+   check2();
 
igt_debug("\nDecrease min below RPn (invalid)...\n");
writeval_inval(stuff[MIN].filp, 0);
@@ -420,11 +420,11 @@ static void min_max_config(void (*check)(void), bool 
load_gpu)
 
igt_debug("\nDecrease max to midpoint...\n");
writeval(stuff[MAX].filp, fmid);
-   check();
+   check2();
 
igt_debug("\nDecrease max to RPn...\n");
writeval(stuff[MAX].filp, origfreqs[RPn]);
-   check();
+   check2();
 
igt_debug("\nDecrease max below RPn (invalid)...\n");
writeval_inval(stuff[MAX].filp, 0);
@@ -436,11 +436,11 @@ static void min_max_config(void (*check)(void), bool 
load_gpu)
 
igt_debug("\nIncrease max to midpoint...\n");
writeval(stuff[MAX].filp, fmid);
-   check();
+   check2();
 
igt_debug("\nIncrease max to RP0...\n");
writeval(stuff[MAX].filp, origfreqs[RP0]);
-   check();
+   check2();
 
igt_debug("\nIncrease max above RP0 (invalid)...\n");
writeval_inval(stuff[MAX].filp, origfreqs[RP0] + 1000);
@@ -461,7 +461,7 @@ static void basic_check(void)
 
 #define IDLE_WAIT_TIMESTEP_MSEC 100
 #define IDLE_WAIT_TIMEOUT_MSEC 1
-static void idle_check(void)
+static void idle_check_min(void)
 {
int freqs[NUMFREQ];
int wait = 0;
@@ -482,6 +482,27 @@ static void idle_check(void)
igt_debug("Required %d msec to reach cur<=min\n", wait);
 }
 
+static void idle_check_idle(void)
+{
+   int freqs[NUMFREQ];
+   int wait = 0;
+
+   /* Monitor frequencies until cur settles down to min, which should
+* happen within the allotted time */
+   do {
+   read_freqs(freqs);
+   dump(freqs);
+   checkit(freqs);
+   if (freqs[CUR] == freqs[RPn])
+   break;
+   usleep(1000 * IDLE_WAIT_TIMESTEP_MSEC);
+   wait += IDLE_WAIT_TIMESTEP_MSEC;
+   } while (wait < IDLE_WAIT_TIMEOUT_MSEC);
+
+   igt_assert_eq(freqs[CUR], freqs[RPn]);
+   igt_debug("Required %d msec to reach cur=idle\n", wait);
+}
+
 #define LOADED_WAIT_TIMESTEP_MSEC 100
 #define LOADED_WAIT_TIMEOUT_MSEC 3000
 static void loaded_check(void)
@@ -577,7 +598,7 @@ static void reset(void)
 
igt_debug("Removing load...\n");
load_helper_stop();
-   idle_check();
+   idle_check_min();
 }
 
 /*
@@ -635,7 +656,7 @@ static void blocking(void)
matchit(pre_freqs, post_freqs);
 
igt_debug("Removing load...\n");
-   idle_check();
+   idle_check_min();
 }
 
 static void pm_rps_exit_handler(int sig)
@@ -686,14 +707,14 @@ igt_main
}
 
igt_subtest("basic-api")
-   min_max_config(basic_check, false);
+   min_max_config(basic_check, basic_check, false);
 
igt_subtest("min-max-config-idle")
-   min_max_config(idle_check, true);
+   min_max_config(idle_check_min, idle_check_idle, true);
 
igt_subtest("min-max-config-loaded") {
load_helper_run(HIGH);
-   min_max_config(loaded_check, false);
+   min_max_config(loaded_check, loaded_check, false);
load_helper_stop();
}
 
-- 
2.4.3

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

[Intel-gfx] [PATCH 0/2] igt/pm_rps: Handle freq < user min in specific cases.

[Bob Paauwe]

The first patch updates the test to work now that the frequency can drop
below the user specified minimum to the idle frequency. 

The second patch attempts to improve the checking and actually checks
that the frequency has dropped to RPn in some cases.  I'm not real
happy with this patch but didn't want to re-write the entire test program
to make handle these cases more elegantly.  Other ideas welcome.

Bob Paauwe (2):
  igt/pm_rps: current freq < user specified min is not a fail (v2)
  igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.

 tests/pm_rps.c | 55 ++-
 1 file changed, 38 insertions(+), 17 deletions(-)

-- 
2.4.3

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

[Intel-gfx] [PATCH 1/2] igt/pm_rps: current freq < user specified min is not a fail (v2)

[Bob Paauwe]

Since commit

  commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
  Author: Chris Wilson 
  Date:   Wed Mar 18 09:48:21 2015 +

  drm/i915: Relax RPS contraints to allows setting minfreq on idle

it is now possible that the current frequency will drop be the user
specified minimum frequency to the "idle" or RPn frequency. Update the
 pm_rps tests to reflect that droping below the user specified minimum
is no longer considered a failure.

v2: Add check RPn <= current freq. (Me)
Signed-off-by: Bob Paauwe 
---
 tests/pm_rps.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index 74f08f4..f919625 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -146,7 +146,7 @@ static void checkit(const int *freqs)
 {
igt_assert_lte(freqs[MIN], freqs[MAX]);
igt_assert_lte(freqs[CUR], freqs[MAX]);
-   igt_assert_lte(freqs[MIN], freqs[CUR]);
+   igt_assert_lte(freqs[RPn], freqs[CUR]);
igt_assert_lte(freqs[RPn], freqs[MIN]);
igt_assert_lte(freqs[MAX], freqs[RP0]);
igt_assert_lte(freqs[RP1], freqs[RP0]);
@@ -472,14 +472,14 @@ static void idle_check(void)
read_freqs(freqs);
dump(freqs);
checkit(freqs);
-   if (freqs[CUR] == freqs[MIN])
+   if (freqs[CUR] <= freqs[MIN])
break;
usleep(1000 * IDLE_WAIT_TIMESTEP_MSEC);
wait += IDLE_WAIT_TIMESTEP_MSEC;
} while (wait < IDLE_WAIT_TIMEOUT_MSEC);
 
-   igt_assert_eq(freqs[CUR], freqs[MIN]);
-   igt_debug("Required %d msec to reach cur=min\n", wait);
+   igt_assert_lte(freqs[CUR], freqs[MIN]);
+   igt_debug("Required %d msec to reach cur<=min\n", wait);
 }
 
 #define LOADED_WAIT_TIMESTEP_MSEC 100
-- 
2.4.3

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

[Intel-gfx] [PATCH] drm/i915: Fix idle_frames counter.

[Rodrigo Vivi]

'commit 97173eaf5 ("drm/i915: PSR: Increase idle_frames")' was a mistake.
The special case it tried to cover was already being covered by
the DP_PSR_NO_TRAIN_ON_EXIT. So this ended up duplicated.

So, instead of reverting that let's take this opportunity and unify
the idle_frame definition in a single place so we standardize the access
and avoid room for that same mistake again.

Few changes with this patch:

1. Instead of just respecting the VBT we set a
global minumum with max(). So we are sure that we will avoid corner cases
in case VBT is doing something we don't understand.

2. Instead of minimum 5 we use 6. When introducing the idle_frames += 4 case
we considered that minimum was 2. All because the off-by-one issue.

v2: Unified idle_frame definition.

Cc: Paulo Zanoni 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 3a10263..f12fc56 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -267,23 +267,17 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
 
uint32_t max_sleep_time = 0x1f;
-   /* Lately it was identified that depending on panel idle frame count
-* calculated at HW can be off by 1. So let's use what came
-* from VBT + 1.
-* There are also other cases where panel demands at least 4
-* but VBT is not being set. To cover these 2 cases lets use
-* at least 5 when VBT isn't set to be on the safest side.
+   /*
+* Let's respect VBT in case VBT asks a higher idle_frame value.
+* Let's use 6 as the minimum to cover all known cases including
+* the off-by-one issue that HW has in some cases. Also there are
+* cases where sink should be able to train
+* with the 5 or 6 idle patterns.
 */
-   uint32_t idle_frames = dev_priv->vbt.psr.idle_frames ?
-  dev_priv->vbt.psr.idle_frames + 1 : 5;
+   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
uint32_t val = 0x0;
const uint32_t link_entry_time = EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
 
-   if (intel_dp->psr_dpcd[1] & DP_PSR_NO_TRAIN_ON_EXIT) {
-   /* Sink should be able to train with the 5 or 6 idle patterns */
-   idle_frames += 4;
-   }
-
I915_WRITE(EDP_PSR_CTL, val |
   (IS_BROADWELL(dev) ? 0 : link_entry_time) |
   max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT |
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Grab connection_mutex while duplicating state

[Daniel Vetter]

On Mon, Nov 30, 2015 at 03:22:49PM -0800, Matt Roper wrote:
> Callers of drm_atomic_helper_duplicate_state() may not have grabbed
> locks before calling this function.  We're not supposed to iterate over
> connectors without holding connection_mutex (since MST allows new
> connectors to be spawned at hotplug), so make sure we grab that
> ourselves before invoking drm_for_each_connector().  Failure to grab
> this lock would cause us to stumble over the assertion added in commit:
> 
> commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
> Author: Daniel Vetter 
> Date:   Thu Jul 9 23:44:28 2015 +0200
> 
> drm: Check locking in drm_for_each_connector
> 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Signed-off-by: Matt Roper 

These helpers are wip and Thierry is working on some additional
higher-level wrappers for bullet proof save/restore for atomic drivers.
It's very much intentinoal that this function here does _not_ grab any
locks - if it does the higher-level magic would be impossible.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3731a26..e5d0b21 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2478,6 +2478,10 @@ drm_atomic_helper_duplicate_state(struct drm_device 
> *dev,
>   }
>   }
>  
> + err = drm_modeset_lock(>mode_config.connection_mutex, ctx);
> + if (err)
> + goto free;
> +
>   drm_for_each_connector(conn, dev) {
>   struct drm_connector_state *conn_state;
>  
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH i-g-t] tests: add core_setmaster_vs_auth

[Daniel Vetter]

Tests that master state isn't leaked to new masters by checking
that auth magics for the old master don't work any more.

Based upon a simple test program provided by Thomas.

v2: Use correct test stanza ... and I need coffee.

Cc: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
---
 tests/.gitignore   |  1 +
 tests/Makefile.sources |  1 +
 tests/core_setmaster_vs_auth.c | 73 ++
 3 files changed, 75 insertions(+)
 create mode 100644 tests/core_setmaster_vs_auth.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 85936ea45c9f..43d63d3abac9 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -4,6 +4,7 @@ core_getclient
 core_getstats
 core_getversion
 core_prop_blob
+core_setmaster_vs_auth
 drm_auth
 drm_import_export
 drm_read
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ff178f7a2df4..b70bca060253 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -102,6 +102,7 @@ TESTS_progs = \
core_getstats \
core_getversion \
core_prop_blob \
+   core_setmaster_vs_auth \
drm_auth \
drm_import_export \
drm_read \
diff --git a/tests/core_setmaster_vs_auth.c b/tests/core_setmaster_vs_auth.c
new file mode 100644
index ..1d66044f7fe1
--- /dev/null
+++ b/tests/core_setmaster_vs_auth.c
@@ -0,0 +1,73 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Daniel Vetter 
+ *
+ * Based upon a test program provided by Thomas Hellstrom 

+ */
+
+/*
+ * Testcase: Check that drop/setMaster correctly transfer master state
+ *
+ * Test approach is only checking auth state (which is part of master state) by
+ * trying to authenticate a client against the wrong master.
+ */
+
+#define _GNU_SOURCE
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#ifdef __linux__
+# include 
+#else
+# include 
+#endif
+
+igt_simple_main
+{
+   int master1, master2, client;
+   drm_magic_t magic;
+
+   master1 = drm_open_driver(DRIVER_ANY);
+   do_or_die(drmSetMaster(master1));
+
+   /* Get an authentication magic from the first master */
+   client = drm_open_driver(DRIVER_ANY);
+   do_or_die(drmGetMagic(client, ));
+
+   /* Open an fd an make it master */
+   master2 = drm_open_driver(DRIVER_ANY);
+   do_or_die(drmDropMaster(master1));
+   do_or_die(drmSetMaster(master2));
+
+   /* auth shouldn't work any more since the master we have the magic from
+* isn't the current master any more. */
+   igt_assert_neq(drmAuthMagic(master2, magic), 0);
+   igt_assert_eq(errno, EINVAL);
+
+   close(client);
+   close(master2);
+   close(master1);
+}
-- 
2.1.0

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

[Intel-gfx] [Regression report] Weekly regression report WW48

[jairo . daniel . miramontes . caton]

WW48 Regression report.

Last week's Regressions:
+---+---+++
| BugId | Summary   | Created on | Bisect |
+---+---+++
| 93120 | [SNB BAT IGT regression] WARN_ON(was_visible) | 2015-11-26 | No |
| 93122 | [SNB BAT IGT regression] pm_rpm started skipp | 2015-11-26 | No |
+---+---+++


Older regressions:
+---+---+++
| BugId | Summary   | Created on | Bisect |
+---+---+++
| 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | Yes|
| 81537 | [snb dp regression] dp retry forever due to s | 2014-07-19 | No |
| 84855 | [ILK regression]igt kms_rotation_crc/sprite-r | 2014-10-10 | No |
| 84974 | [VLV eDP-LVDS bisected] powerdomains: Screen  | 2014-10-14 | Yes|
| 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | No |
| 87480 | [SNB/IVB/HSW/BYT bisected]igt/kms_force_conne | 2014-12-19 | Yes|
| 87662 | [ALL 3.18 Bisected] DVI --rotation inverted c | 2014-12-24 | Yes|
| 87725 | [BDW Bisected] OglBatch7 performance reduced  | 2014-12-26 | Yes|
| 87726 | [BDW Bisected] OglDrvCtx performance reduced  | 2014-12-26 | Yes|
| 88012 | [bisected BYT] complete freeze after: drm/i91 | 2015-01-04 | Yes|
| 88124 | i915: regression: after DP connected monitor  | 2015-01-06 | No |
| 88439 | [BDW Bisected]igt/gem_reloc_vs_gpu/forked-fau | 2015-01-15 | Yes|
| 89334 | [945 regression] 4.0-rc1 kernel GPU hang:  ec | 2015-02-26 | No |
| 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | No |
| 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | No |
| 89728 | [HSW/BDW/BSW/SKL bisected] igt/pm_rps/ subcas | 2015-03-23 | Yes|
| 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | Yes|
| 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | Yes|
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | Yes|
| 90368 | [SNB BSW SKL] bisected igt/kms_3d has hardcod | 2015-05-08 | Yes|
| 90546 | [HSW/BDW/BSW/SKL bisected]igt/pm_rpm/drm-reso | 2015-05-21 | Yes|
| 90732 | [BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forked | 2015-05-29 | Yes|
| 90808 | [BDW Bisected]igt/gem_ctx_param_basic/invalid | 2015-06-02 | Yes|
| 90994 | [BDW regression] pm_rpm subtests fail and giv | 2015-06-16 | No |
| 91378 | [hsw dp regression] 06ea66b6 (5.4GHz link clo | 2015-07-17 | No |
| 91592 | [pnv regression] OOPS on boot | 2015-08-09 | No |
| 91844 | [HSW Regression] intel_do_flush_locked failed | 2015-09-02 | No |
| 91952 | [Bisected Regression] Blank screen from boot  | 2015-09-10 | Yes|
| 91959 | [865g 3.19 regression] Desktop image is disto | 2015-09-10 | No |
| 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | Yes|
| 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | No |
| 92083 | [regression] [git pull] drm for 4.3   | 2015-09-23 | No |
| 92096 | regression/bug introduced by commit [0e572fe7 | 2015-09-24 | No |
| 92174 | PROBLEM: Intel VGA output busticated on 4.3-r | 2015-09-29 | No |
| 92237 | Horrible noise (audio) via DisplayPort [regre | 2015-10-02 | No |
| 92355 | [SKL Regression] igt/kms_fbc_crc cause DUT cr | 2015-10-09 | No |
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 | Yes|
| 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-ex | 2015-10-16 | No |
| 92575 | [4.2 regression] Massive graphics corruption  | 2015-10-21 | No |
| 92655 | [i915] LVDS screen half garbled. unable to bi | 2015-10-23 | Yes|
| 92718 | [REGRESSION] 4.3.0-rc7 - Multiple identical k | 2015-10-29 | No |
| 92972 | Black screen on Intel NUC hardware (i915) pos | 2015-11-16 | No |
+---+---+++



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

Re: [Intel-gfx] [PATCH] drm/i915: Sanitize watermarks after hardware state readout (v3)

[Maarten Lankhorst]

Op 01-12-15 om 00:56 schreef Matt Roper:
> Although we can do a good job of reading out hardware state, the
> graphics firmware may have programmed the watermarks in a creative way
> that doesn't match how i915 would have chosen to program them.  We
> shouldn't trust the firmware's watermark programming, but should rather
> re-calculate how we think WM's should be programmed and then shove those
> values into the hardware.
>
> We can do this pretty easily by creating a dummy top-level state,
> running it through the check process to calculate all the values, and
> then just programming the watermarks for each CRTC.
>
> v2:  Move watermark sanitization after our BIOS fb reconstruction; the
>  watermark calculations that we do here need to look at pstate->fb,
>  which isn't setup yet in intel_modeset_setup_hw_state(), even
>  though we have an enabled & visible plane.
>
> v3:
>  - Don't move 'active = optimal' watermark assignment; we just undo
>that change in the next patch anyway.  (Ville)
>  - Move atomic helper locking fix to separate patch.  (Maarten)
>
> Cc: Maarten Lankhorst 
> Cc: Ville Syrjälä 
> Signed-off-by: Matt Roper 
> ---
> The call to drm_atomic_helper_duplicate_state() in this patch will throw a
> warning; atomic helper patch "drm/atomic-helper: Grab connection_mutex while
> duplicating state" is necessary to fix that.
>
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_display.c | 58 
> 
>  drivers/gpu/drm/i915/intel_pm.c  | 10 ---
>  3 files changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 11ae5a5..5172604 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
> struct dpll *best_clock);
>   int (*compute_pipe_wm)(struct intel_crtc *crtc,
>  struct drm_atomic_state *state);
> + void (*program_watermarks)(struct intel_crtc_state *cstate);
>   void (*update_wm)(struct drm_crtc *crtc);
>   int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
>   void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 00e4c37..eb52afa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
>   intel_enable_gt_powersave(dev);
>  }
>  
> +/*
> + * Calculate what we think the watermarks should be for the state we've read
> + * out of the hardware and then immediately program those watermarks so that
> + * we ensure the hardware settings match our internal state.
> + */
> +static void sanitize_watermarks(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_atomic_state *state;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> + int i;
> +
> + /* Only supported on platforms that use atomic watermark design */
> + if (!dev_priv->display.program_watermarks)
> + return;
> +
> + /*
> +  * Calculate what we think WM's should be by creating a dummy state and
> +  * running it through the atomic check code.
> +  */
> + drm_modeset_acquire_init(, 0);
> + state = drm_atomic_helper_duplicate_state(dev, );
> + if (WARN_ON(IS_ERR(state)))
> + return;
> +
> + ret = intel_atomic_check(dev, state);
> + if (ret) {
> + /*
> +  * Just give up and leave watermarks untouched if we get an
> +  * error back from 'check'
> +  */
> + DRM_DEBUG_KMS("Could not determine valid watermarks for 
> inherited state\n");
Seems like a serious error that should not be shuffled away, maybe print the 
ret too?
> + return;
> + }
> +
> + /* Write calculated watermark values back */
> + to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
> + for_each_crtc_in_state(state, crtc, cstate, i) {
> + struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
> +
> + dev_priv->display.program_watermarks(cs);
> + }
> +
> + drm_atomic_state_free(state);
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +}
> +
>  void intel_modeset_init(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -15243,6 +15294,13 @@ void intel_modeset_init(struct drm_device *dev)
>   intel_dump_pipe_config(crtc, crtc->config,
>  "[state after init fb reconstruction]");
>   }
> +
> + 

[Intel-gfx] [PATCH i-g-t] tests: add core_setmaster_vs_auth

[Daniel Vetter]

Tests that master state isn't leaked to new masters by checking
that auth magics for the old master don't work any more.

Based upon a simple test program provided by Thomas.

Cc: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
---
 tests/.gitignore   |  1 +
 tests/Makefile.sources |  1 +
 tests/core_setmaster_vs_auth.c | 73 ++
 3 files changed, 75 insertions(+)
 create mode 100644 tests/core_setmaster_vs_auth.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 85936ea45c9f..43d63d3abac9 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -4,6 +4,7 @@ core_getclient
 core_getstats
 core_getversion
 core_prop_blob
+core_setmaster_vs_auth
 drm_auth
 drm_import_export
 drm_read
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ff178f7a2df4..b70bca060253 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -102,6 +102,7 @@ TESTS_progs = \
core_getstats \
core_getversion \
core_prop_blob \
+   core_setmaster_vs_auth \
drm_auth \
drm_import_export \
drm_read \
diff --git a/tests/core_setmaster_vs_auth.c b/tests/core_setmaster_vs_auth.c
new file mode 100644
index ..375b903e2352
--- /dev/null
+++ b/tests/core_setmaster_vs_auth.c
@@ -0,0 +1,73 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Daniel Vetter 
+ *
+ * Based upon a test program provided by Thomas Hellstrom 

+ */
+
+/*
+ * Testcase: Check that drop/setMaster correctly transfer master state
+ *
+ * Test approach is only checking auth state (which is part of master state) by
+ * trying to authenticate a client against the wrong master.
+ */
+
+#define _GNU_SOURCE
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#ifdef __linux__
+# include 
+#else
+# include 
+#endif
+
+igt_main
+{
+   int master1, master2, client;
+   drm_magic_t magic;
+
+   master1 = drm_open_driver(DRIVER_ANY);
+   do_or_die(drmSetMaster(master1));
+
+   /* Get an authentication magic from the first master */
+   client = drm_open_driver(DRIVER_ANY);
+   do_or_die(drmGetMagic(client, ));
+
+   /* Open an fd an make it master */
+   master2 = drm_open_driver(DRIVER_ANY);
+   do_or_die(drmDropMaster(master1));
+   do_or_die(drmSetMaster(master2));
+
+   /* auth shouldn't work any more since the master we have the magic from
+* isn't the current master any more. */
+   igt_assert_neq(drmAuthMagic(master2, magic), 0);
+   igt_assert_eq(errno, EINVAL);
+
+   close(client);
+   close(master2);
+   close(master1);
+}
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Grab connection_mutex while duplicating state

[Maarten Lankhorst]

Op 01-12-15 om 00:22 schreef Matt Roper:
> Callers of drm_atomic_helper_duplicate_state() may not have grabbed
> locks before calling this function.  We're not supposed to iterate over
> connectors without holding connection_mutex (since MST allows new
> connectors to be spawned at hotplug), so make sure we grab that
> ourselves before invoking drm_for_each_connector().  Failure to grab
> this lock would cause us to stumble over the assertion added in commit:
>
> commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
> Author: Daniel Vetter 
> Date:   Thu Jul 9 23:44:28 2015 +0200
>
> drm: Check locking in drm_for_each_connector
>
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3731a26..e5d0b21 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2478,6 +2478,10 @@ drm_atomic_helper_duplicate_state(struct drm_device 
> *dev,
>   }
>   }
>  
> + err = drm_modeset_lock(>mode_config.connection_mutex, ctx);
> + if (err)
> + goto free;
> +
>   drm_for_each_connector(conn, dev) {
>   struct drm_connector_state *conn_state;
>  
Thanks, that's a lot better than just a random hunk without explanation.

Signed-off-by: Maarten Lankhorst 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v4] lib/igt_core: Add kmsg capture and dumping

[Daniel Vetter]

On Fri, Nov 27, 2015 at 01:46:23PM +0200, Joonas Lahtinen wrote:
> On pe, 2015-11-27 at 11:31 +0100, Daniel Vetter wrote:
> > On Thu, Nov 26, 2015 at 05:00:14PM +0200, Joonas Lahtinen wrote:
> > > On to, 2015-11-26 at 15:34 +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 26, 2015 at 02:17:53PM +0200, Joonas Lahtinen wrote:
> 
> > > > > + if (nlines == 1)
> > > > > + fprintf(stderr, " KMSG \n");
> > > > 
> > > > Please use the igt logging functions we have. This holds in
> > > > general,
> > > > please don't use any of the raw output functions and instead use
> > > > the
> > > > igt_warn/info/debug stuff in your entire patch for logging.
> > > > 
> > > 
> > > Actually, if you look at the code I copied;
> > > 
> > > fprintf(stderr, " DEBUG \n");
> > > 
> > > So, I was just trying to make it consistent with the existing
> > > output.
> > > 
> > > Would you like both converted to use igt_warn or igt_debug?
> > 
> > Hm right, we do raw printing there since that dumps the igt log -
> > would
> > recurse otherwise.
> > 
> > > > Also the problem with dumping into stderr is that this is at the
> > > > igt_warn
> > > > level, which means if this happens your test will be considered a
> > > > failure
> > > > in CI.
> > > > 
> > > > And there's plenty of drivers and other stuff that dump random
> > > > crap
> > > > at
> > > > this level into dmesg, especially over system suspend resume.
> > > > Which
> > > > means
> > > > your patch will regress a pile of BAT igts.
> > > > 
> > > > We really, really need to filter dmesg the same way as piglit
> > > > does.
> > > > And I
> > > > mean _exactly_ the same way. Otherwise there's differences in
> > > > test
> > > > status,
> > > > and that means noise in CI and frustration all around.
> > > > 
> > > > Other option is to dump at igt_info or igt_debug level.
> > > > 
> > > 
> > > Should I just make it optional runtime flag --dmesg for the time
> > > being?
> > 
> > One option would be to dump it all with igt_debug() with an
> > IGT_LOG_DOMAIN
> > of "dmesg" right before the (sub)test stops, and before we do the
> > logfile
> > record dumping (in case of failure). With that
> > - You could see it when enabling full debug (fancy version could even
> > dump
> >   dmesg in realtime in a separate thread so that dmesg and igt log
> >   interleave, that would be really useful).
> > - If the test fails we'll also dump dmesg.
> > 
> 
> I wouldn't push dmesg into igt log, because it's just moving same bytes
> from one place to another, kernel already buffers the dmesg for us and
> it doesn't have to be read realtime. The FD's can be thought of as
> glorified pointers, really.

The upside is that the 2 logs get interleaved correctly, which I just so
absolutely wanted to have for debugging some feature last week ;-)

> With my now merged monotonic raw patches, we should be able to
> timestamp each igt_warn and igt_debug call and it can be afterwards
> interleaved with the kernel messages.

Interleaving afterwards is more work. At least manually.
 
> But this functionality as is, is already nice, because you don't have
> to keep track of the kmsg in a separate window when running a single
> test. Maybe we should decide on how to merge this function, and then
> add the timestamping and interleaved output.

Well for the interleaved kmsg capture the design would be entirely
different:

- in common_init launch a thread which captures kmsg in the background
  constantly and prints it using igt_debug with debug domain "dmesg"

- no need any more for dumping the buffer, core igt logging takes care of
  that. Same for dumping when the test failed, filtering or anything else.

- cleanup of that thread is best done with an igt exit handler.

Later on we can follow up with switching between igt_debug and igt_warn
depending upon log level.

Imo the above integrates much nicer into existing igt infrastructure and
has the benefit of giving us interleaving, too.

Cheers, Daniel

> 
> > Only problem is that if there's lots of dmesg spew the dmesg might
> > flush
> > out all the useful log messages from igt itself. We might need to do
> > the
> > interleaving right away.
> > 
> > Aside: IGT_LOG_DOMAIN is kinda meant for testcases, for the library
> > it
> > might be better to use the low-level function:
> > 
> > igt_log("dmesg", IGT_LOG_DEBUG, ...);
> > 
> > > 
> > > > > diff --git a/lib/tests/Makefile.sources
> > > > > b/lib/tests/Makefile.sources
> > > > > index 777b9c1..6506baf 100644
> > > > > --- a/lib/tests/Makefile.sources
> > > > > +++ b/lib/tests/Makefile.sources
> > > > > @@ -1,4 +1,5 @@
> > > > >  check_PROGRAMS = \
> > > > > + igt_capture \
> > > > >   igt_no_exit \
> > > > >   igt_no_exit_list_only \
> > > > >   igt_fork_helper \
> > > > > @@ -32,4 +33,5 @@ XFAIL_TESTS = \
> > > > >   igt_simple_test_subtests \
> > > > >   igt_timeout \
> > > > >   igt_invalid_subtest_name \
> > > > > + igt_capture \
> > > > 

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

[Daniel Vetter]

On Mon, Nov 30, 2015 at 11:54:14AM +0530, Goel, Akash wrote:
> 
> 
> On 11/25/2015 3:30 PM, Daniel Vetter wrote:
> >On Wed, Nov 25, 2015 at 02:57:47PM +0530, Goel, Akash wrote:
> >>
> >>
> >>On 11/25/2015 2:51 PM, Daniel Vetter wrote:
> >>>On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> >>On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> >>>From: Akash Goel 
> >>>
> >>>When the object is moved out of CPU read domain, the cachelines
> >>>are not invalidated immediately. The invalidation is deferred till
> >>>next time the object is brought back into CPU read domain.
> >>>But the invalidation is done unconditionally, i.e. even for the case
> >>>where the cachelines were flushed previously, when the object moved out
> >>>of CPU write domain. This is avoidable and would lead to some 
> >>>optimization.
> >>>Though this is not a hypothetical case, but is unlikely to occur often.
> >>>The aim is to detect changes to the backing storage whilst the
> >>>data is potentially in the CPU cache, and only clflush in those case.
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>Signed-off-by: Akash Goel 
> >>>---
> >>>  drivers/gpu/drm/i915/i915_drv.h | 1 +
> >>>  drivers/gpu/drm/i915/i915_gem.c | 9 -
> >>>  2 files changed, 9 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >>>b/drivers/gpu/drm/i915/i915_drv.h
> >>>index df9316f..fedb71d 100644
> >>>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>>@@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> >>>   unsigned long gt_ro:1;
> >>>   unsigned int cache_level:3;
> >>>   unsigned int cache_dirty:1;
> >>>+  unsigned int cache_clean:1;
> >>
> >>So now we have cache_dirty and cache_clean which seems redundant,
> >>except somehow cache_dirty != !cache_clean?
> 
> Exactly, not entirely redundant. I did think something along MESI lines
> would be useful, but that didn't capture the different meanings we
> employ.
> 
> cache_dirty tracks whether we have been eliding the clflush.
> 
> cache_clean tracks whether we know the cache has been completely
> clflushed.
> 
> (cache_clean implies !cache_dirty, but
> !cache_clean does not imply cache_dirty)
> 
> >We also have read_domains & DOMAIN_CPU. Which is which?
> 
> DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
> clflush elision above).
> 
> DOMAIN_CPU implies !cache_clean
> 
> and even
> 
> cache_clean implies !DOMAIN_CPU
> 
> but
> 
> !DOMAIN_CPU does not imply cache_clean
> >>>
> >>>All the above should be in the kerneldoc (per-struct-member comments
> >>>please) of drm_i915_gem_object. Akash, can you please amend your patch?
> >>>And please make sure we do include that kerneldoc somewhere ... might need
> >>>an upfront patch to do that, for just drm_i915_gem_object.
> >>
> >>I floated the amended patch, earlier today,
> >>http://lists.freedesktop.org/archives/intel-gfx/2015-November/081194.html.
> >>Please kindly check that.
> >
> >Already done and replied here because I think this should be lifted to
> >kerneldoc for the structure itself. That's why I replied here ;-)
> >-Daniel
> Hi Daniel,
> 
> I think the patch to provide a kernel-doc for just the drm_i915_gem_object
> structure can be submitted independently of this patch. The kernel-doc part
> can be done as a follow up patch.

Imo it should be done first, so that your cache optimization can also
correctly update the documentation.
-Daniel

> 
> For the current patch, have added the per-struct-member comments for the
> 'cache_clean' field.
> 
> Best regards
> Akash
> 
> >

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

Re: [Intel-gfx] [PATCH] drm/i915: Don't use crtc->config when reading out infoframe state

[Daniel Vetter]

On Thu, Nov 26, 2015 at 06:27:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The .get_config() hooks should not reference anything in crtc->config,
> everything should be based on the passed in pipe_config instead. So
> don't dig out the cpu_transcoder from crtc->config on ddi platfforms,
> and also avoid using the encoder->crtc link and instead look up the
> pipe via pipe_config->base.crtc.
> 
> I don't think this will actually fix anything since during the initial
> state readout we set up the encoder->crtc link prior to calling
> .get_config(), and during the modeset state check the encoder->crtc
> ought to be correct anyway since it's that state we just programmed.
> But this seems the right thing to do anyway.
> 
> While at it, do some house cleaning on the local variables in the
> .infoframe_enabled() hooks.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c  |  2 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  3 ++-
>  drivers/gpu/drm/i915/intel_hdmi.c | 47 
> +++
>  3 files changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 76ce7c2960b6..7f618cf5289c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3151,7 +3151,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
>   pipe_config->has_hdmi_sink = true;
>   intel_hdmi = enc_to_intel_hdmi(>base);
>  
> - if (intel_hdmi->infoframe_enabled(>base))
> + if (intel_hdmi->infoframe_enabled(>base, pipe_config))
>   pipe_config->has_infoframe = true;
>   break;
>   case TRANS_DDI_MODE_SELECT_DVI:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6ef456427db5..b2e81403c494 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -711,7 +711,8 @@ struct intel_hdmi {
>   void (*set_infoframes)(struct drm_encoder *encoder,
>  bool enable,
>  const struct drm_display_mode *adjusted_mode);
> - bool (*infoframe_enabled)(struct drm_encoder *encoder);
> + bool (*infoframe_enabled)(struct drm_encoder *encoder,
> +   const struct intel_crtc_state *pipe_config);
>  };
>  
>  struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index bdd462e7c690..c3978bad5ca0 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -169,10 +169,10 @@ static void g4x_write_infoframe(struct drm_encoder 
> *encoder,
>   POSTING_READ(VIDEO_DIP_CTL);
>  }
>  
> -static bool g4x_infoframe_enabled(struct drm_encoder *encoder)
> +static bool g4x_infoframe_enabled(struct drm_encoder *encoder,
> +   const struct intel_crtc_state *pipe_config)
>  {
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   u32 val = I915_READ(VIDEO_DIP_CTL);
>  
> @@ -225,13 +225,13 @@ static void ibx_write_infoframe(struct drm_encoder 
> *encoder,
>   POSTING_READ(reg);
>  }
>  
> -static bool ibx_infoframe_enabled(struct drm_encoder *encoder)
> +static bool ibx_infoframe_enabled(struct drm_encoder *encoder,
> +   const struct intel_crtc_state *pipe_config)
>  {
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> + struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> - i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
> + enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
> + i915_reg_t reg = TVIDEO_DIP_CTL(pipe);
>   u32 val = I915_READ(reg);
>  
>   if ((val & VIDEO_DIP_ENABLE) == 0)
> @@ -287,12 +287,12 @@ static void cpt_write_infoframe(struct drm_encoder 
> *encoder,
>   POSTING_READ(reg);
>  }
>  
> -static bool cpt_infoframe_enabled(struct drm_encoder *encoder)
> +static bool cpt_infoframe_enabled(struct drm_encoder *encoder,
> +   const struct intel_crtc_state *pipe_config)
>  {
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> - u32 val = I915_READ(TVIDEO_DIP_CTL(intel_crtc->pipe));
> + struct drm_i915_private *dev_priv = 

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling

[Daniel Vetter]

On Thu, Nov 26, 2015 at 10:55:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
> for transocoder B/C. And more importnatnly we should not consider
> the state of underrun reporting for transcoders B/C when checking
> whether we can enable the south error interrupt.
> 
> The whole thing is a bit of mess since we store the underrun reporting
> state for transcoder A under intel_crtc for pipe A, irrespective of
> which pipe may actually be driving the transcoder. But I figured trying
> to change that would result in more churn.
> 
> Caveat: Still untested
> 
> v2: Use HAS_PCH_LPT_H instead of HAS_DDI
> Use cpt_check_pch_fifo_underruns() on LPT-H/WPT-H too
> 
> Signed-off-by: Ville Syrjälä 

I've battled hsw lpt fifo underrun issues last week and never seen a fifo
underrun on pipe B/C. Have you seen them anywhere really?

If not I think we can skip this patch here, since I think I tracked it all
down.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_fifo_underrun.c | 27 ++-
>  1 file changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
> b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> index bda526660e20..3d3acc8b8367 100644
> --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> @@ -48,6 +48,14 @@
>   * The code also supports underrun detection on the PCH transcoder.
>   */
>  
> +static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
> +   enum transcoder pch_transcoder)
> +{
> + /* LPT-H/WPT-H have only transcoder A */
> + return HAS_PCH_CPT(dev_priv) ||
> + (HAS_PCH_LPT_H(dev_priv) && pch_transcoder == TRANSCODER_A);
> +}
> +
>  static bool ivb_can_enable_err_int(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -69,13 +77,16 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
>  static bool cpt_can_enable_serr_int(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - enum pipe pipe;
> - struct intel_crtc *crtc;
> + enum transcoder pch_transcoder;
>  
>   assert_spin_locked(_priv->irq_lock);
>  
> - for_each_pipe(dev_priv, pipe) {
> - crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> + for_each_pipe(dev_priv, pch_transcoder) {
> + struct intel_crtc *crtc =
> + 
> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
> +
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + continue;
>  
>   if (crtc->pch_fifo_underrun_disabled)
>   return false;
> @@ -206,6 +217,9 @@ static void cpt_check_pch_fifo_underruns(struct 
> intel_crtc *crtc)
>  
>   assert_spin_locked(_priv->irq_lock);
>  
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + return;
> +
>   if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
>   return;
>  
> @@ -222,6 +236,9 @@ static void cpt_set_fifo_underrun_reporting(struct 
> drm_device *dev,
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + return;
> +
>   if (enable) {
>   I915_WRITE(SERR_INT,
>  SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
> @@ -436,7 +453,7 @@ void intel_check_pch_fifo_underruns(struct 
> drm_i915_private *dev_priv)
>   if (crtc->pch_fifo_underrun_disabled)
>   continue;
>  
> - if (HAS_PCH_CPT(dev_priv))
> + if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT_H(dev_priv))
>   cpt_check_pch_fifo_underruns(crtc);
>   }
>  
> -- 
> 2.4.10
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/2] tests/gem_eio: Resilience against "hanging too fast"

[Daniel Vetter]

On Thu, Nov 26, 2015 at 09:10:57PM +, Chris Wilson wrote:
> On Thu, Nov 26, 2015 at 04:51:13PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 26, 2015 at 03:34:05PM +, Chris Wilson wrote:
> > > On Thu, Nov 26, 2015 at 03:46:06PM +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 26, 2015 at 12:59:37PM +, Chris Wilson wrote:
> > > > > On Thu, Nov 26, 2015 at 12:34:35PM +0100, Daniel Vetter wrote:
> > > > > > Since $debugfs/i915_wedged restores a wedged gpu by using a normal 
> > > > > > gpu
> > > > > > hang we need to be careful to not run into the "hanging too fast
> > > > > > check":
> > > > > > 
> > > > > > - don't restore the ban period, but instead keep it at 0.
> > > > > > - make sure we idle the gpu fully before hanging it again (wait
> > > > > >   subtest missted that).
> > > > > > 
> > > > > > With this gem_eio works now reliable even when I don't run the
> > > > > > subtests individually.
> > > > > > 
> > > > > > Of course it's a bit fishy that the default ctx gets blamed for
> > > > > > essentially doing nothing, but until that's figured out in upstream
> > > > > > it's better to make the test work for now.
> > > > > 
> > > > > This used to be reliable. And just disabling all banning in the kernel
> > > > > forever more is silly.
> > > > > 
> > > > > During igt_post_hang_ring:
> > > > > 1. we wait upon the hanging batch
> > > > >  - this returns when hangcheck fires
> > > > > 2. reset the ban period to normal
> > > > >  - this takes mutex_lock_interruptible and so must wait for the reset
> > > > >handler to run before it can make the change,
> > > > >  - ergo the hanging batch never triggers a ban for itself.
> > > > >  - (a subsequent nonsimulated GPU hang may trigger the ban though)
> > > > 
> > > > This isn't where it dies. It dies when we do the echo 1 > i915_wedged.
> > > 
> > > That is not where it dies.
> > 
> > Well at least it happens after we start the hang recover from i915_wedged.
> > 
> > > > I suspect quiescent_gpu or whatever is getting in the way, but I really 
> > > > only
> > > > wanted to get things to run first. And since i915_wedged is a developer
> > > > feature, and it does work perfectly if you don't intend to reuse 
> > > > contexts
> > > > I didn't see any point in first trying to fix it up.
> > > > 
> > > > So I still maintain that this is a good enough approach, at least if
> > > > there's no obvious fix in-flight already.
> > > 
> > > No way. This is a kernel regression since 4.0, having just tested with
> > > v4.0 on snb/ivb/hsw.
> > 
> > Ok, I didn't realize that. I figured since i915_wedged will return -EAGAIN
> > anyway when we are terminally wedged, and that seems to have been the case
> > ever since we started with reset_counter this has been broken forever. I
> > guess I missed something.
> 
> The bug I see is SNB specific, and introduced between v4.0 and v4.1.

The irony, I hacked on gem_eio on snb too ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix possible null dereference in framebuffer_info debugfs function

[Daniel Vetter]

On Fri, Nov 27, 2015 at 01:43:11PM +0530, Namrta Salonie wrote:
> Found by static code analysis tool.
> 
> v2: Inserted block instead of goto & renamed variables (Chris)
> v3: Aligned code as per the opening brace (Chris)
> Rebased on top of nightly (Daniel)
> 
> Signed-off-by: Namrta Salonie 
> Signed-off-by: Deepak S 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |   36 
> ---
>  1 file changed, 16 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a728ff1..bfd57fb 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1869,33 +1869,29 @@ static int i915_gem_framebuffer_info(struct seq_file 
> *m, void *data)
>  {
>   struct drm_info_node *node = m->private;
>   struct drm_device *dev = node->minor->dev;
> - struct intel_fbdev *ifbdev = NULL;
> - struct intel_framebuffer *fb;
> + struct intel_framebuffer *fbdev_fb = NULL;
>   struct drm_framebuffer *drm_fb;
>  
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - ifbdev = dev_priv->fbdev;
> - if (ifbdev) {
> - fb = to_intel_framebuffer(ifbdev->helper.fb);
> -
> - seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier 
> 0x%llx, refcount %d, obj ",
> -fb->base.width,
> -fb->base.height,
> -fb->base.depth,
> -fb->base.bits_per_pixel,
> -fb->base.modifier[0],
> -atomic_read(>base.refcount.refcount));
> - describe_obj(m, fb->obj);
> - seq_putc(m, '\n');
> - }
> +   if (to_i915(dev)->fbdev) {
> +   fbdev_fb = 
> to_intel_framebuffer(to_i915(dev)->fbdev->helper.fb);
> +
> +   seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, 
> modifier 0x%llx, refcount %d, obj ",
> + fbdev_fb->base.width,
> + fbdev_fb->base.height,
> + fbdev_fb->base.depth,
> + fbdev_fb->base.bits_per_pixel,
> + fbdev_fb->base.modifier[0],
> + atomic_read(_fb->base.refcount.refcount));
> +   describe_obj(m, fbdev_fb->obj);
> +   seq_putc(m, '\n');
> +   }
>  #endif
>  
>   mutex_lock(>mode_config.fb_lock);
>   drm_for_each_fb(drm_fb, dev) {
> - fb = to_intel_framebuffer(drm_fb);
> - if (ifbdev && >base == ifbdev->helper.fb)
> + struct intel_framebuffer *fb = to_intel_framebuffer(drm_fb);
> + if (fb == fbdev_fb)
>   continue;
>  
>   seq_printf(m, "user size: %d x %d, depth %d, %d bpp, modifier 
> 0x%llx, refcount %d, obj ",
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] intel_dp_detect redesign

[Daniel Vetter]

On Fri, Nov 27, 2015 at 04:30:21PM +, Daniel Stone wrote:
> Hi,
> +marcheu
> 
> On 26 November 2015 at 10:07, Daniel Vetter  wrote:
> > On Wed, Nov 25, 2015 at 05:09:02PM +0530, Thulasimani, Sivakumar wrote:
> >> however good to explicitly check for this,
> >> following needs to be tested before sending in next patch/merge
> >> 1) MST displays verification (Ander's reported on first set of patches)
> >> 2) check behavior on sleep - resume (dave)
> >> 3) storm handling needs to be handled as well. (i assume this should be
> >> fine,
> >>  but good to check explicitly) (danvet)
> >>
> >
> > Yeah the storm mitigation will keep on working. What I'm worried about is
> > that polling won't work any more: When a storm happens we disable the hpd
> > and switch all affected connectors completely to polling. Polling happens
> > through the probe helpers in drm_probe_helper.c, and that code exclusively
> > uses ->detect callbacks. Which means if we no longer re-probe in detect
> > (since we assume hpd works correctly) then this will break the storm
> > handling code.
> >
> > Simplest fix (but a bit a hack) would be to check whether polling is
> > enabled at the top of intel_hdmi_detect and if so execute a full probe.
> > And not just return the cached values.
> >
> > Note that storms are only a concern for HDMI, not DP (somehow DP hw is
> > less shit).
> 
> Hmm, from what I understand it's a concern on DP as well. Maybe due to
> DP->HDMI converters which just pass HPD through? Google's Type-C -> DP
> cable crushes all short HPD events - breaking MST short pulses - which
> I assume wasn't for no reason:
> https://chromium.googlesource.com/chromiumos/platform/ec/+/master/board/dingdong/board.c#27

Yeah right, we do need to keep polling working for DP too, but only for
long pulse hpd replacement. As long as a DP cable is plugged in I haven't
seen reports of a storm. But indeed hdmi crap can induce a storm on a DP+
connector too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] igt/pm_rps: current freq < user specified min is no longer a fail

[Imre Deak]

On ke, 2015-11-11 at 13:37 -0800, Bob Paauwe wrote:
> Since commit
> 
>   commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
>   Author: Chris Wilson 
>   Date:   Wed Mar 18 09:48:21 2015 +
> 
>   drm/i915: Relax RPS contraints to allows setting minfreq on
> idle
> 
> it is now possible that the current frequency will drop below the
> user
> specified minimum frequency. Update the pm_rps tests to reflect that
> this is no longer considered a failure.
> 
> Signed-off-by: Bob Paauwe 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89728

Bob could you send an updated version of this patch?

> ---
>  tests/pm_rps.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> index 74f08f4..e92ca3b 100644
> --- a/tests/pm_rps.c
> +++ b/tests/pm_rps.c
> @@ -146,7 +146,6 @@ static void checkit(const int *freqs)
>  {
>   igt_assert_lte(freqs[MIN], freqs[MAX]);
>   igt_assert_lte(freqs[CUR], freqs[MAX]);
> - igt_assert_lte(freqs[MIN], freqs[CUR]);
>   igt_assert_lte(freqs[RPn], freqs[MIN]);
>   igt_assert_lte(freqs[MAX], freqs[RP0]);
>   igt_assert_lte(freqs[RP1], freqs[RP0]);
> @@ -472,14 +471,14 @@ static void idle_check(void)
>   read_freqs(freqs);
>   dump(freqs);
>   checkit(freqs);
> - if (freqs[CUR] == freqs[MIN])
> + if (freqs[CUR] <= freqs[MIN])
>   break;
>   usleep(1000 * IDLE_WAIT_TIMESTEP_MSEC);
>   wait += IDLE_WAIT_TIMESTEP_MSEC;
>   } while (wait < IDLE_WAIT_TIMEOUT_MSEC);
>  
> - igt_assert_eq(freqs[CUR], freqs[MIN]);
> - igt_debug("Required %d msec to reach cur=min\n", wait);
> + igt_assert_lte(freqs[CUR], freqs[MIN]);
> + igt_debug("Required %d msec to reach cur<=min\n", wait);
>  }
>  
>  #define LOADED_WAIT_TIMESTEP_MSEC 100
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

Hi Dave, here's a few i915 fixes out of the way, still more to come.

BR,
Jani.

The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4:

  Linux 4.4-rc2 (2015-11-22 16:45:59 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-11-30

for you to fetch changes up to 2540058f7a9d9a843b4d9a28d4f8168dd034d030:

  drm/i915: Don't override output type for DDI HDMI (2015-11-25 17:32:03 +0200)


Chris Wilson (1):
  drm/i915: Mark uneven memory banks on gen4 desktop as unknown swizzling

Takashi Iwai (2):
  drm/i915: Don't compare has_drrs strictly in pipe config
  drm/i915: Don't override output type for DDI HDMI

 drivers/gpu/drm/i915/i915_gem_fence.c | 36 ++-
 drivers/gpu/drm/i915/intel_display.c  |  1 -
 drivers/gpu/drm/i915/intel_dp.c   |  3 ++-
 3 files changed, 29 insertions(+), 11 deletions(-)

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

[Intel-gfx] MST Behavior on BDW

[Shrivastava, Shubhangi]

Hi Dave,

The following behavior is observed on BDW for MST using drm-nightly kernel:

1.   Connected boot: Display comes up on MST panel but the system is driven 
to low graphics mode (command line), i.e. UI doesn't come up.

2.   Hot plug: No display on MST panel.

My top of the tree for drm-nightly is:
Commit ID: 17874a0bd04949ab460431e6017860ab98e0e4d2
Author: Ville Syrjälä 
ville.syrj...@linux.intel.com
drm-intel-nightly: 2015y-11m-26d-16h-57m-42s UTC integration manifest

Request you to kindly confirm this behavior for MST on BDW.

P.S: We are observing the same behavior after applying the reorganization of DP 
HPD handling patches.

Thanks and Regards,
Shubhangi Shrivastava.

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/dsi: merge pre_pll_enable hook to pre_enable

[Jani Nikula]

On Mon, 30 Nov 2015, Daniel Vetter  wrote:
> On Fri, Nov 27, 2015 at 01:26:40PM +0200, Ville Syrjälä wrote:
>> On Fri, Nov 27, 2015 at 12:21:44PM +0200, Jani Nikula wrote:
>> > For DSI, the pre_pll_enable and the pre_enable hooks are called
>> > back-to-back on all platforms that support DSI. The distinction is
>> > artificial for DSI, for which we enable the DSI PLL in the encoder
>> > hooks. Do everything in pre_enable, and remove DSI pre_pll_enable hook.
>> > 
>> > Signed-off-by: Jani Nikula 
>> 
>> I was eyeing this same thing at some point.
>> 
>> For the series:
>> Reviewed-by: Ville Syrjälä 
>
> Yeah, all the pretties in here!
>
> Reviewed-by: Daniel Vetter 
>
> Btw about bxt dsi I wonder whether we should partially merge this with the
> cpu transcoder (since it's only either that or a dsi encoder aparrently).
> At least I remember that we still had some issues with bxt's
> dsi_get_hw_state?

One step at a time, maybe as a follow-up. I'm kind of hesitant to
conflate this with cpu transcoder, in case some new platform changes the
rules.

So for now, I've pushed this to drm-intel-next-queued, thanks for the
reviews.

BR,
Jani.


>
> Cheers, Daniel
>
>> 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dsi.c | 16 +---
>> >  1 file changed, 5 insertions(+), 11 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> > b/drivers/gpu/drm/i915/intel_dsi.c
>> > index efb5a27dd49c..08c46c49c481 100644
>> > --- a/drivers/gpu/drm/i915/intel_dsi.c
>> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> > @@ -462,6 +462,8 @@ static void intel_dsi_enable(struct intel_encoder 
>> > *encoder)
>> >intel_panel_enable_backlight(intel_dsi->attached_connector);
>> >  }
>> >  
>> > +static void intel_dsi_prepare(struct intel_encoder *intel_encoder);
>> > +
>> >  static void intel_dsi_pre_enable(struct intel_encoder *encoder)
>> >  {
>> >struct drm_device *dev = encoder->base.dev;
>> > @@ -474,6 +476,9 @@ static void intel_dsi_pre_enable(struct intel_encoder 
>> > *encoder)
>> >  
>> >DRM_DEBUG_KMS("\n");
>> >  
>> > +  intel_dsi_prepare(encoder);
>> > +  intel_enable_dsi_pll(encoder);
>> > +
>> >/* Panel Enable over CRC PMIC */
>> >if (intel_dsi->gpio_panel)
>> >gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
>> > @@ -1026,15 +1031,6 @@ static void intel_dsi_prepare(struct intel_encoder 
>> > *intel_encoder)
>> >}
>> >  }
>> >  
>> > -static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder)
>> > -{
>> > -  DRM_DEBUG_KMS("\n");
>> > -
>> > -  intel_dsi_prepare(encoder);
>> > -  intel_enable_dsi_pll(encoder);
>> > -
>> > -}
>> > -
>> >  static enum drm_connector_status
>> >  intel_dsi_detect(struct drm_connector *connector, bool force)
>> >  {
>> > @@ -1154,9 +1150,7 @@ void intel_dsi_init(struct drm_device *dev)
>> >  
>> >drm_encoder_init(dev, encoder, _dsi_funcs, DRM_MODE_ENCODER_DSI);
>> >  
>> > -  /* XXX: very likely not all of these are needed */
>> >intel_encoder->compute_config = intel_dsi_compute_config;
>> > -  intel_encoder->pre_pll_enable = intel_dsi_pre_pll_enable;
>> >intel_encoder->pre_enable = intel_dsi_pre_enable;
>> >intel_encoder->enable = intel_dsi_enable_nop;
>> >intel_encoder->disable = intel_dsi_pre_disable;
>> > -- 
>> > 2.1.4
>> > 
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>> -- 
>> Ville Syrjälä
>> Intel OTC
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Slaughter the thundering i915_wait_request herd

[Tvrtko Ursulin]

Hi,

On 29/11/15 08:48, Chris Wilson wrote:

One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results, but every client is woken up after
every batchbuffer - hence the thunder of hooves as then every client must
do its heavyweight dance to read a coherent seqno to see if it is the
lucky one. Alternatively, we can have one kthread responsible for waking
after an interrupt, checking the seqno and only waking up the waiting
clients who are complete. The disadvantage is that in the uncontended
scenario (i.e. only one waiter) we incur an extra context switch in the
wakeup path - though that should be mitigated somewhat by the busy-wait
we do first before sleeping.

v2: Convert from a kworker per engine into a dedicated kthread for the
bottom-half.

Signed-off-by: Chris Wilson 
Cc: "Rogozhkin, Dmitry V" 
Cc: "Gong, Zhipeng" 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/i915_dma.c  |   9 +-
  drivers/gpu/drm/i915/i915_drv.h  |  35 -
  drivers/gpu/drm/i915/i915_gem.c  |  99 +++-
  drivers/gpu/drm/i915/i915_gpu_error.c|   8 +-
  drivers/gpu/drm/i915/i915_irq.c  |  17 +--
  drivers/gpu/drm/i915/intel_breadcrumbs.c | 253 +++
  drivers/gpu/drm/i915/intel_lrc.c |   2 +-
  drivers/gpu/drm/i915/intel_ringbuffer.c  |   3 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h  |   3 +-
  10 files changed, 333 insertions(+), 97 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_breadcrumbs.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07bd13..d3b9d3618719 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -35,6 +35,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_userptr.o \
  i915_gpu_error.o \
  i915_trace_points.o \
+ intel_breadcrumbs.o \
  intel_lrc.o \
  intel_mocs.o \
  intel_ringbuffer.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a81c76603544..93c6762d87b4 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -388,12 +388,16 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_vga_client;

+   ret = intel_breadcrumbs_init(dev_priv);
+   if (ret)
+   goto cleanup_vga_switcheroo;
+
/* Initialise stolen first so that we may reserve preallocated
 * objects for the BIOS to KMS transition.
 */
ret = i915_gem_init_stolen(dev);
if (ret)
-   goto cleanup_vga_switcheroo;
+   goto cleanup_breadcrumbs;

intel_power_domains_init_hw(dev_priv, false);

@@ -454,6 +458,8 @@ cleanup_irq:
drm_irq_uninstall(dev);
  cleanup_gem_stolen:
i915_gem_cleanup_stolen(dev);
+cleanup_breadcrumbs:
+   intel_breadcrumbs_fini(dev_priv);
  cleanup_vga_switcheroo:
vga_switcheroo_unregister_client(dev->pdev);
  cleanup_vga_client:
@@ -1193,6 +1199,7 @@ int i915_driver_unload(struct drm_device *dev)
mutex_unlock(>struct_mutex);
intel_fbc_cleanup_cfb(dev_priv);
i915_gem_cleanup_stolen(dev);
+   intel_breadcrumbs_fini(dev_priv);

intel_csr_ucode_fini(dev_priv);

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1980212ba37..782d08ab6264 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -564,6 +564,7 @@ struct drm_i915_error_state {
long jiffies;
u32 seqno;
u32 tail;
+   u32 waiters;
} *requests;

struct {
@@ -1383,7 +1384,7 @@ struct i915_gpu_error {
  #define I915_STOP_RING_ALLOW_WARN  (1 << 30)

/* For missed irq/seqno simulation. */
-   unsigned int test_irq_rings;
+   unsigned long test_irq_rings;
  };

  enum modeset_restore {
@@ -1695,6 +1696,27 @@ struct drm_i915_private {

struct intel_uncore uncore;

+   /* Rather than have every client wait upon all user interrupts,
+* with the herd waking after every interrupt and each doing the
+* heavyweight seqno dance, we delegate the task to a bottom-half
+* for the user interrupt (one bh handling all engines). Now,
+* just one task is woken up and does the coherent seqno read and
+* then wakes up all the waiters registered with the bottom-half
+* that are complete. This avoid the thundering herd problem
+* with lots of concurrent waiters, at the expense of an extra
+* 

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Slaughter the thundering i915_wait_request herd

[Chris Wilson]

On Sun, Nov 29, 2015 at 08:48:06AM +, Chris Wilson wrote:
> + /* Optimistic spin for the next jiffie before touching IRQs */
> + if (intel_breadcrumbs_add_waiter(req)) {
> + ret = __i915_spin_request(req, state);
> + if (ret == 0)
> + goto out;

There are a couple of interesting side-effects here.  As we know start
up the irq in parallel and keep it running for longer, irq/i915 now
consumes a lot of CPU time (like 50-100%!) for synchronous batches, but
doesn't seem to interfere with latency (as spin_request is still nicely
running and catching the request completion). That should also still
work nicely on single cpu machines as the irq enabling should not
preempt us.  The second interesting side-effect is that the synchronous
loads that regressed with a 2us spin-request timeout are now happy again
at 2us. Also with the active-request and the can-spin check from
add_waiter, running a low fps game with a compositor is not burning the
CPU with any spinning.
-Chris

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

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Slaughter the thundering i915_wait_request herd

[Tvrtko Ursulin]

Hi,

On 30/11/15 10:53, Chris Wilson wrote:

On Sun, Nov 29, 2015 at 08:48:06AM +, Chris Wilson wrote:

+   /* Optimistic spin for the next jiffie before touching IRQs */
+   if (intel_breadcrumbs_add_waiter(req)) {
+   ret = __i915_spin_request(req, state);
+   if (ret == 0)
+   goto out;


There are a couple of interesting side-effects here.  As we know start
up the irq in parallel and keep it running for longer, irq/i915 now
consumes a lot of CPU time (like 50-100%!) for synchronous batches, but
doesn't seem to interfere with latency (as spin_request is still nicely
running and catching the request completion). That should also still
work nicely on single cpu machines as the irq enabling should not
preempt us.  The second interesting side-effect is that the synchronous
loads that regressed with a 2us spin-request timeout are now happy again
at 2us. Also with the active-request and the can-spin check from
add_waiter, running a low fps game with a compositor is not burning the
CPU with any spinning.


Interesting? :) Sounds bad the way you presented it.

Why and where is the thread burning so much CPU? Would per engine req 
tree locks help?


Is this new CPU time or the one which would previously be accounted 
against each waiter, polling in wait request?


Regards,

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

Re: [Intel-gfx] [PATCH i-g-t] scripts: Add support to retest tests wich changed results

[Daniel Vetter]

On Fri, Nov 27, 2015 at 02:53:36PM +, Thomas Wood wrote:
> On 27 November 2015 at 12:40, Gabriel Feceoru  
> wrote:
> > This script takes multiple test results and prints the diffs, useful
> > for detecting noise in subsequent executions.
> > It gives the option to re-run these tests.
> 
> This feature might be useful in Piglit itself. It sounds similar to
> the ideas mentioned in this thread:
> 
> http://lists.freedesktop.org/archives/piglit/2015-November/018197.html

Yeah agreed, imo this should be implemented in piglit proper. We could
have different knobs to retest just regressions, fixes, or all changes
even.
-Daniel

> 
> 
> >
> > Signed-off-by: Gabriel Feceoru 
> > ---
> >  scripts/retest-diff.sh | 72 
> > ++
> >  1 file changed, 72 insertions(+)
> >  create mode 100755 scripts/retest-diff.sh
> >
> > diff --git a/scripts/retest-diff.sh b/scripts/retest-diff.sh
> > new file mode 100755
> > index 000..aee1d05
> > --- /dev/null
> > +++ b/scripts/retest-diff.sh
> > @@ -0,0 +1,72 @@
> > +#!/bin/bash
> > +#
> > +# Copyright © 2015 Intel Corporation
> > +#
> > +# Permission is hereby granted, free of charge, to any person obtaining a
> > +# copy of this software and associated documentation files (the 
> > "Software"),
> > +# to deal in the Software without restriction, including without limitation
> > +# the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > +# and/or sell copies of the Software, and to permit persons to whom the
> > +# Software is furnished to do so, subject to the following conditions:
> > +#
> > +# The above copyright notice and this permission notice (including the next
> > +# paragraph) shall be included in all copies or substantial portions of the
> > +# Software.
> > +#
> > +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > +# IN THE SOFTWARE.
> > +
> > +ROOT="`dirname $0`"
> > +ROOT="`readlink -f $ROOT/..`"
> > +IGT_TEST_ROOT="$ROOT/tests"
> > +RESULTS="$ROOT/results"
> > +PIGLIT="$ROOT/piglit/piglit"
> > +
> > +if [ ! -d "$IGT_TEST_ROOT" ]; then
> > +   echo "Error: could not find tests directory."
> > +   exit 1
> > +fi
> > +
> > +function print_help {
> > +   echo "Usage: $0 [ ...]"
> > +   echo ""
> > +}
> > +
> > +
> > +if [ $# -lt 2 ]; then
> > +   print_help
> > +   exit 1
> > +fi
> > +
> > +RESULT_FILES=$@
> > +
> > +for result in $RESULT_FILES; do
> > +if [ ! -e $result ]; then
> > +echo "Wrong result paths"
> > +exit 1
> > +fi
> > +done
> > +
> > +
> > +TESTS=`$PIGLIT summary console -d $RESULT_FILES | grep igt | cut -d':' -f1`
> > +if [[ -z $TESTS ]]; then
> > +exit 1
> > +else
> > +RED='\033[0;31m'
> > +NC='\033[0m'
> > +printf "$RED $TESTS $NC " | sed -e 's/ /\n/g'
> > +fi
> > +
> > +
> > +read -p "Dow you want to run these tests [y/N]? " -n 2 -r
> > +if [[ $REPLY =~ ^[Yy]$ ]]; then
> > +mkdir -p $RESULTS
> > +TEST_LIST=($TESTS)
> > +TEST_PARAMS=`printf "%s "  "${TEST_LIST[@]/#/-t }"`
> > +sudo IGT_TEST_ROOT=$IGT_TEST_ROOT $PIGLIT run igt $RESULTS $TEST_PARAMS
> > +fi
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3] PCI / PM: tune down RPM suspend error message with EBUSY and EAGAIN retval

[Rafael J. Wysocki]

On Fri, Nov 27, 2015 at 7:17 PM, Imre Deak  wrote:
> The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver
> suspend hooks as errors, but they still show up as errors in dmesg. Tune
> them down.
>
> One problem caused by this was noticed by Daniel: the i915 driver
> returns EAGAIN to signal a temporary failure to suspend and as a request
> towards the RPM core for scheduling a suspend again. This is a normal
> event, but the resulting error message flags a breakage during the
> driver's automated testing which parses dmesg and picks up the error.
>
> v2:
> - fix compile breake when CONFIG_PM_SLEEP=n (0-day builder)
> v3:
> - instead of modifying the suspend_report_result() helper to disinguish
>   between the runtime and system suspend case, inline the error
>   printing, it's not used anywhere else (Rafael)
>
> Reported-by: Daniel Vetter 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> CC: Bjorn Helgaas 
> CC: Rafael J. Wysocki 
> Signed-off-by: Imre Deak 
> ---
>  drivers/pci/pci-driver.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 4446fcb..67eb4ac 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1146,9 +1146,20 @@ static int pci_pm_runtime_suspend(struct device *dev)
> pci_dev->state_saved = false;
> pci_dev->no_d3cold = false;
> error = pm->runtime_suspend(dev);
> -   suspend_report_result(pm->runtime_suspend, error);
> -   if (error)
> +   if (error) {
> +   /*
> +* -EBUSY and -EAGAIN is used to request the runtime PM core
> +* to schedule a new suspend, so don't flag it as an error.
> +*/

KERN_DEBUG and KERN_ERR are log levels, not flags.

Besides, maybe we can use pr_err() and pr_debug() here?

> +   if (error == -EBUSY || error == -EAGAIN)
> +   printk(KERN_DEBUG "%s(): %pF returns %d\n", __func__,
> +  pm->runtime_suspend, error);
> +   else
> +   printk(KERN_ERR "%s(): %pF returns %d\n", __func__,
> +  pm->runtime_suspend, error);
> +
> return error;
> +   }
> if (!pci_dev->d3cold_allowed)
> pci_dev->no_d3cold = true;
>
> --

Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fix fdi related fifo underruns on hsw

[Daniel Vetter]

On Sat, Nov 28, 2015 at 11:05:39AM +0100, Daniel Vetter wrote:
> Similar to
> 
> commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826
> Author: Ville Syrjälä 
> Date:   Fri Oct 30 19:20:27 2015 +0200
> 
> drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB
> 
> we can only enable fifo underrun reporting when using the fdi/lpt
> after everything is set up and after a bit of waiting. The waiting
> is required, enabling it right after enabling encoders will first trigger
> an underrun on the pch and then, 1 frame later, an underrun on the
> cpu. Two vblank waits after encoder enabling seems enough to curb it.
> 
> And similar to
> 
> Author: Ville Syrjälä 
> Date:   Fri Nov 20 22:09:18 2015 +0200
> 
> drm/i915: Suppress spurious CPU FIFO underruns on ILK-IVB
> 
> we also need to make sure cpu fifo underrun reporting is disabled when
> enabling the fdi rx/tx and pch transcoder But somehow this is
> only needed when enabling, not also when disabling.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91578

> ---
>  drivers/gpu/drm/i915/intel_display.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7754db9fa8a4..62097e94996a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4979,7 +4979,11 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
>  
>   intel_crtc->active = true;
>  
> - intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
> + if (intel_crtc->config->has_pch_encoder)
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
> + else
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
> +
>   for_each_encoder_on_crtc(dev, crtc, encoder) {
>   if (encoder->pre_pll_enable)
>   encoder->pre_pll_enable(encoder);
> @@ -5025,9 +5029,13 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
>   intel_opregion_notify_encoder(encoder, true);
>   }
>  
> - if (intel_crtc->config->has_pch_encoder)
> + if (intel_crtc->config->has_pch_encoder) {
> + intel_wait_for_vblank(dev, pipe);
> + intel_wait_for_vblank(dev, pipe);
> + intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
>   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> true);
> + }
>  
>   /* If we change the relative order between pipe/planes enabling, we need
>* to change the workaround. */
> -- 
> 2.1.0
> 

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling

[Ville Syrjälä]

On Mon, Nov 30, 2015 at 09:25:03AM +0100, Daniel Vetter wrote:
> On Thu, Nov 26, 2015 at 10:55:53PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
> > for transocoder B/C. And more importnatnly we should not consider
> > the state of underrun reporting for transcoders B/C when checking
> > whether we can enable the south error interrupt.
> > 
> > The whole thing is a bit of mess since we store the underrun reporting
> > state for transcoder A under intel_crtc for pipe A, irrespective of
> > which pipe may actually be driving the transcoder. But I figured trying
> > to change that would result in more churn.
> > 
> > Caveat: Still untested
> > 
> > v2: Use HAS_PCH_LPT_H instead of HAS_DDI
> > Use cpt_check_pch_fifo_underruns() on LPT-H/WPT-H too
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> I've battled hsw lpt fifo underrun issues last week and never seen a fifo
> underrun on pipe B/C. Have you seen them anywhere really?

No, I've not seen it. We mark underrun detection as disabled for active
pipes in intel_sanitize_crtc(), and we never turn it back on except for
transcoder A, so I'm thinking we'll never actually enable the south
error interrup on LPT if a non-pch port is enabled on boot.

Note that so far I didn't check if that's actually the case, but based
on the code I can't come to any other conclusion.

> 
> If not I think we can skip this patch here, since I think I tracked it all
> down.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_fifo_underrun.c | 27 ++-
> >  1 file changed, 22 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
> > b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > index bda526660e20..3d3acc8b8367 100644
> > --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > @@ -48,6 +48,14 @@
> >   * The code also supports underrun detection on the PCH transcoder.
> >   */
> >  
> > +static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
> > + enum transcoder pch_transcoder)
> > +{
> > +   /* LPT-H/WPT-H have only transcoder A */
> > +   return HAS_PCH_CPT(dev_priv) ||
> > +   (HAS_PCH_LPT_H(dev_priv) && pch_transcoder == TRANSCODER_A);
> > +}
> > +
> >  static bool ivb_can_enable_err_int(struct drm_device *dev)
> >  {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -69,13 +77,16 @@ static bool ivb_can_enable_err_int(struct drm_device 
> > *dev)
> >  static bool cpt_can_enable_serr_int(struct drm_device *dev)
> >  {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > -   enum pipe pipe;
> > -   struct intel_crtc *crtc;
> > +   enum transcoder pch_transcoder;
> >  
> > assert_spin_locked(_priv->irq_lock);
> >  
> > -   for_each_pipe(dev_priv, pipe) {
> > -   crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> > +   for_each_pipe(dev_priv, pch_transcoder) {
> > +   struct intel_crtc *crtc =
> > +   
> > to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
> > +
> > +   if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> > +   continue;
> >  
> > if (crtc->pch_fifo_underrun_disabled)
> > return false;
> > @@ -206,6 +217,9 @@ static void cpt_check_pch_fifo_underruns(struct 
> > intel_crtc *crtc)
> >  
> > assert_spin_locked(_priv->irq_lock);
> >  
> > +   if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> > +   return;
> > +
> > if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
> > return;
> >  
> > @@ -222,6 +236,9 @@ static void cpt_set_fifo_underrun_reporting(struct 
> > drm_device *dev,
> >  {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >  
> > +   if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> > +   return;
> > +
> > if (enable) {
> > I915_WRITE(SERR_INT,
> >SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
> > @@ -436,7 +453,7 @@ void intel_check_pch_fifo_underruns(struct 
> > drm_i915_private *dev_priv)
> > if (crtc->pch_fifo_underrun_disabled)
> > continue;
> >  
> > -   if (HAS_PCH_CPT(dev_priv))
> > +   if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT_H(dev_priv))
> > cpt_check_pch_fifo_underruns(crtc);
> > }
> >  
> > -- 
> > 2.4.10
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH] Implement Limited Video Range

[Ville Syrjälä]

On Mon, Nov 30, 2015 at 09:43:32AM +0100, Daniel Vetter wrote:
> On Mon, Nov 30, 2015 at 08:08:48AM +0100, Peter Frühberger wrote:
> > (Resent cause of moderation)
> > 
> > This implements a highly needed feature in a minimal non instructive way.
> > Consider a Limited Range display (like most TVs) where you want to watch a
> > decoded video. The TV is set to limited range and the intel driver also
> > uses full scaling Limited 16:235 mode, e.g. if you display the gray value
> > 16 - the driver will postprocess it to something like ~ 22.
> > 
> > The following happens currently in linux intel video world:
> > Video is decoded with e.g. vaapi, the decoded surface is either used via
> > EGL directly in Limited Range. Limited Range processing takes place and at
> > the end while rendering the intel driver will scale down the limited range
> > data again as it cannot distunguish of the data it gets when e.g. rendering
> > with OpenGL like we succesfully do in kodi.
> > 
> > Another use case is vaapi when using the old vaCopySurfaceGLX
> > (vaPutSurface) which would automatically use BT601 / BT709 matrix to
> > upscale the content without any dithering to Full Range RGB. Later on this
> > is scaled down again with the Limited 16:235 setting and output. Quality
> > degrades two times.
> > 
> > Users and applications widely used want to make sure that colors appear on
> > screen like they were processed after the last processing step. In video
> > case two use cases make sense:
> > 
> > a) scaling limited range to full range with dithering applied when you need
> > to output fullrange
> > b) already having limited range and outputting that without any further
> > touching by the driver
> > 
> > Use case a) is already possible. Usecase b) will be possible with the
> > attached patch. It is a possibility to get Limited Range on screen in
> > perfect quality in 2k15.
> > 
> > For the future a userspace api to provide info frames and so on in a
> > generic way should be considered but until we have this I bet we have 2
> > years to go. This solution also works on X11 (without wayland) and is
> > useful for existing applications.
> > 
> > Thanks much for consideration.
> > 
> > ---
> > From deaa9d730c08aefefe3671d073d93d970bb39a31 Mon Sep 17 00:00:00 2001
> > From: fritsch 
> > Date: Sun, 29 Nov 2015 16:38:14 +0100
> > Subject: [PATCH] Intel: Implement Video Color Range
> > 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/intel_display.c |  4 ++--
> >  drivers/gpu/drm/i915/intel_drv.h |  8 
> >  drivers/gpu/drm/i915/intel_hdmi.c| 17 +++--
> >  drivers/gpu/drm/i915/intel_modes.c   |  1 +
> >  5 files changed, 27 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 95bb27d..e453461 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3449,6 +3449,7 @@ int intel_freq_opcode(struct drm_i915_private
> > *dev_priv, int val);
> >  #define INTEL_BROADCAST_RGB_AUTO 0
> >  #define INTEL_BROADCAST_RGB_FULL 1
> >  #define INTEL_BROADCAST_RGB_LIMITED 2
> > +#define INTEL_BROADCAST_RGB_VIDEO 3
> > 
> >  static inline uint32_t i915_vgacntrl_reg(struct drm_device *dev)
> >  {
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 71860f8..ea40d81 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8605,7 +8605,7 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
> >* consideration.
> >*/
> > 
> > - if (intel_crtc->config->limited_color_range)
> > + if (intel_crtc->config->limited_color_range &&
> > !intel_crtc->config->video_color_range)
> >   coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
> > 
> >   /*
> > @@ -8629,7 +8629,7 @@ static void intel_set_pipe_csc(struct drm_crtc *crtc)
> >   if (INTEL_INFO(dev)->gen > 6) {
> >   uint16_t postoff = 0;
> > 
> > - if (intel_crtc->config->limited_color_range)
> > + if (intel_crtc->config->limited_color_range &&
> > !intel_crtc->config->video_color_range)
> >   postoff = (16 * (1 << 12) / 255) & 0x1fff;
> > 
> >   I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), postoff);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 0598932..6940243 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -372,6 +372,13 @@ struct intel_crtc_state {
> >*/
> >   bool limited_color_range;
> > 
> > + /*
> > +  *
> > +  * Use reduced/limited/broadcast rgb range without compressing.
> > +  *
> > +  */
> > + bool video_color_range;
> 
> I think the names and semantics are confusion, resulting in hard-to-read
> if conditions. What about:
> 
>   bool limit_color_range; /* should we limit from full->16:235 in
>   the encoder/csc? */

We might call this simply as 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Daniel Vetter]

On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> Implement a new i915_audio_component_ops, get_eld().  It's called by
> the audio driver to fetch the current ELD of the given HDMI/DP port.
> It returns the size of ELD bytes if it's valid, or zero if the audio
> is disabled or unplugged, or a negative error code.
> 
> For achieving this, a new field audio_enabled is added to struct
> intel_digital_port.  This is set/reset at each audio enable/disable
> call in intel_audio.c.
> 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 40 
> ++
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  include/drm/i915_component.h   |  3 +++
>  3 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 0c38cc6c82ae..6b318a8d5dc9 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -521,6 +521,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>  
>   connector->eld[6] = drm_av_sync_delay(connector, adjusted_mode) / 2;
>  
> + intel_dig_port->audio_enabled = true;
>   if (dev_priv->display.audio_codec_enable)
>   dev_priv->display.audio_codec_enable(connector, intel_encoder,
>adjusted_mode);
> @@ -545,6 +546,7 @@ void intel_audio_codec_disable(struct intel_encoder 
> *intel_encoder)
>   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_dig_port->port;
>  
> + intel_dig_port->audio_enabled = false;
>   if (dev_priv->display.audio_codec_disable)
>   dev_priv->display.audio_codec_disable(intel_encoder);
>  
> @@ -702,6 +704,43 @@ static int i915_audio_component_sync_audio_rate(struct 
> device *dev,
>   return 0;
>  }
>  
> +static int i915_audio_component_get_eld(struct device *dev, int port,
> + bool *enabled,
> + unsigned char *buf, int max_bytes)
> +{
> + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> + struct drm_device *drm_dev = dev_priv->dev;
> + struct intel_encoder *intel_encoder;
> + struct intel_digital_port *intel_dig_port;
> + struct drm_connector *connector;
> + unsigned char *eld;
> + int ret = -EINVAL;
> +

Locking is a bit in-flux atm with atomic, but needs
dev_priv->dev->mode_config->mutex here to protect against the eld
changing.

> + mutex_lock(_priv->av_mutex);
> + for_each_intel_encoder(drm_dev, intel_encoder) {
> + if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
> + intel_encoder->type != INTEL_OUTPUT_HDMI)

MST? Not that I have a clue how that should work ;-)

> + continue;
> + intel_dig_port = enc_to_dig_port(_encoder->base);
> + if (port == intel_dig_port->port) {
> + ret = 0;
> + *enabled = intel_dig_port->audio_enabled;
> + if (!*enabled)
> + break;
> + connector = drm_select_eld(_encoder->base);
> + if (!connector)
> + break;
> + eld = connector->eld;
> + ret = min(max_bytes, drm_eld_size(eld));

How can the caller figure out what the eld size is if you use min here? At
least in drm we just return the size we want if it's too small.

> + memcpy(buf, eld, ret);
> + break;
> + }
> + }
> +
> + mutex_unlock(_priv->av_mutex);
> + return ret;
> +}
> +
>  static const struct i915_audio_component_ops i915_audio_component_ops = {
>   .owner  = THIS_MODULE,
>   .get_power  = i915_audio_component_get_power,
> @@ -709,6 +748,7 @@ static const struct i915_audio_component_ops 
> i915_audio_component_ops = {
>   .codec_wake_override = i915_audio_component_codec_wake_override,
>   .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
>   .sync_audio_rate = i915_audio_component_sync_audio_rate,
> + .get_eld= i915_audio_component_get_eld,
>  };
>  
>  static int i915_audio_component_bind(struct device *i915_dev,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0598932ce623..4afc7560be04 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -798,6 +798,7 @@ struct intel_digital_port {
>   u32 saved_port_bits;
>   struct intel_dp dp;
>   struct intel_hdmi hdmi;
> + bool audio_enabled;

Needs a comment that this is protected by dev_priv->av_mutex.

>   enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
>   bool release_cl2_override;
>  };
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index 

Re: [Intel-gfx] [PATCH 3/7] drm/i915: refactoring audio component functions

[Daniel Vetter]

On Mon, Nov 30, 2015 at 02:37:47PM +0100, Takashi Iwai wrote:
> We have a common loop of encoder to look for the given audio port in
> two audio component functions.  Split out a local helper function to
> do it for the code simplification.
> 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 61 
> --
>  1 file changed, 32 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 6b318a8d5dc9..024e88ae6305 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -630,17 +630,33 @@ static int i915_audio_component_get_cdclk_freq(struct 
> device *dev)
>   return ret;
>  }
>  
> +static struct intel_encoder *audio_port_to_encoder(struct drm_device 
> *drm_dev,
> +int port)
> +{
> + struct intel_encoder *intel_encoder;
> + struct intel_digital_port *intel_dig_port;
> +
> + for_each_intel_encoder(drm_dev, intel_encoder) {
> + if (intel_encoder->type != INTEL_OUTPUT_HDMI &&
> + intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT)
> + continue;
> + intel_dig_port = enc_to_dig_port(_encoder->base);
> + if (port == intel_dig_port->port)

If this is static, maybe just maintain a snd_pin_to_port mapping in
dev_priv? That's the approach we're usually taking, and it has the benefit
of making it clear(er) that the binding is static ... Or is it not?

Makes sense otherwise.
-Daniel

> + return intel_encoder;
> + }
> + return NULL;
> +}
> +
>  static int i915_audio_component_sync_audio_rate(struct device *dev,
>   int port, int rate)
>  {
>   struct drm_i915_private *dev_priv = dev_to_i915(dev);
>   struct drm_device *drm_dev = dev_priv->dev;
>   struct intel_encoder *intel_encoder;
> - struct intel_digital_port *intel_dig_port;
>   struct intel_crtc *crtc;
>   struct drm_display_mode *mode;
>   struct i915_audio_component *acomp = dev_priv->audio_component;
> - enum pipe pipe = -1;
> + enum pipe pipe;
>   u32 tmp;
>   int n;
>  
> @@ -652,22 +668,14 @@ static int i915_audio_component_sync_audio_rate(struct 
> device *dev,
>  
>   mutex_lock(_priv->av_mutex);
>   /* 1. get the pipe */
> - for_each_intel_encoder(drm_dev, intel_encoder) {
> - if (intel_encoder->type != INTEL_OUTPUT_HDMI)
> - continue;
> - intel_dig_port = enc_to_dig_port(_encoder->base);
> - if (port == intel_dig_port->port) {
> - crtc = to_intel_crtc(intel_encoder->base.crtc);
> - pipe = crtc->pipe;
> - break;
> - }
> - }
> -
> - if (pipe == INVALID_PIPE) {
> + intel_encoder = audio_port_to_encoder(drm_dev, port);
> + if (!intel_encoder || intel_encoder->type != INTEL_OUTPUT_HDMI) {
>   DRM_DEBUG_KMS("no pipe for the port %c\n", port_name(port));
>   mutex_unlock(_priv->av_mutex);
>   return -ENODEV;
>   }
> + crtc = to_intel_crtc(intel_encoder->base.crtc);
> + pipe = crtc->pipe;
>   DRM_DEBUG_KMS("pipe %c connects port %c\n",
> pipe_name(pipe), port_name(port));
>   mode = >config->base.adjusted_mode;
> @@ -717,23 +725,18 @@ static int i915_audio_component_get_eld(struct device 
> *dev, int port,
>   int ret = -EINVAL;
>  
>   mutex_lock(_priv->av_mutex);
> - for_each_intel_encoder(drm_dev, intel_encoder) {
> - if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
> - intel_encoder->type != INTEL_OUTPUT_HDMI)
> - continue;
> + intel_encoder = audio_port_to_encoder(drm_dev, port);
> + if (intel_encoder) {
> + ret = 0;
>   intel_dig_port = enc_to_dig_port(_encoder->base);
> - if (port == intel_dig_port->port) {
> - ret = 0;
> - *enabled = intel_dig_port->audio_enabled;
> - if (!*enabled)
> - break;
> + *enabled = intel_dig_port->audio_enabled;
> + if (*enabled) {
>   connector = drm_select_eld(_encoder->base);
> - if (!connector)
> - break;
> - eld = connector->eld;
> - ret = min(max_bytes, drm_eld_size(eld));
> - memcpy(buf, eld, ret);
> - break;
> + if (connector) {
> + eld = connector->eld;
> + ret = min(max_bytes, drm_eld_size(eld));
> + memcpy(buf, eld, ret);
> + }
>   }
>   }
>  
> 

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

[Tvrtko Ursulin]

Hi,

On 29/11/15 12:43, Vinay Belgaumkar wrote:

These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.

Caveat: These tests were designed to run on 64-bit system. Future work
includes adding logic to ensure these tests can run on 32-bit systems with
PPGTT support. Some tests are currently disabled for 32-bit systems for that
reason.

v2: Added cc and signed-off-by fields

v3: Fixed review comments, added helper functions. Removed userptr error
scenarios covered by existing userptr tests. Modified stress test to have
100K buffers, it now runs for ~30 mins, checks every element has been written
to correctly, and pins buffers at different VMAs.

v4: Changed name to gem_softpin

v5: More fixes. Removed the file based tests, will move them to userptr tests.
Added a function that validates appropriate PPGTT support before running tests.
Optimized stack space and memory footprint in stress test. Removed the eviction
test, will add it back after verifying proper functionality.

v6: Split basic test into userptr and bo
Fixed some coding style issues.

Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Signed-off-by: Vinay Belgaumkar 
---
  tests/.gitignore   |1 +
  tests/Makefile.sources |1 +
  tests/gem_softpin.c| 1003 
  3 files changed, 1005 insertions(+)
  create mode 100644 tests/gem_softpin.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 80af9a7..424870b 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -21,6 +21,7 @@ gem_bad_blit
  gem_bad_length
  gem_bad_reloc
  gem_basic
+gem_softpin
  gem_caching
  gem_close_race
  gem_concurrent_all
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 8fb2de8..2008d4a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -11,6 +11,7 @@ TESTS_progs_M = \
drv_hangman \
gem_bad_reloc \
gem_basic \
+   gem_softpin \
gem_caching \
gem_close_race \
gem_concurrent_blit \
diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
new file mode 100644
index 000..7cec732
--- /dev/null
+++ b/tests/gem_softpin.c
@@ -0,0 +1,1003 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Vinay Belgaumkar 
+ *Thomas Daniel 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "drm.h"
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_chipset.h"
+#include "intel_io.h"
+#include "i915_drm.h"
+#include 
+#include 
+#include 
+#include 
+#include "igt_kms.h"
+#include 
+#include 
+#include 
+
+#define BO_SIZE 4096
+#define MULTIPAGE_BO_SIZE 2 * BO_SIZE
+#define STORE_BATCH_BUFFER_SIZE 4
+#define EXEC_OBJECT_PINNED (1<<4)
+#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
+#define SHARED_BUFFER_SIZE 4096
+
+typedef struct drm_i915_gem_userptr i915_gem_userptr;
+
+static uint32_t init_userptr(int fd, i915_gem_userptr *, void *ptr, uint64_t 
size);
+static void *create_mem_buffer(uint64_t size);
+static int gem_call_userptr_ioctl(int fd, i915_gem_userptr *userptr);
+static void gem_pin_userptr_test(void);
+static void gem_pin_bo_test(void);
+static void gem_pin_invalid_vma_test(void);
+static void gem_pin_overlap_test(void);
+static void gem_pin_high_address_test(void);
+
+#define NO_PPGTT 0
+#define ALIASING_PPGTT 1
+#define FULL_32_BIT_PPGTT 2
+#define FULL_48_BIT_PPGTT 3
+/* uses_full_ppgtt
+ * Finds supported PPGTT details.
+ * @fd 

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling

[Daniel Vetter]

On Mon, Nov 30, 2015 at 04:08:34PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 30, 2015 at 09:25:03AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 26, 2015 at 10:55:53PM +0200, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
> > > for transocoder B/C. And more importnatnly we should not consider
> > > the state of underrun reporting for transcoders B/C when checking
> > > whether we can enable the south error interrupt.
> > > 
> > > The whole thing is a bit of mess since we store the underrun reporting
> > > state for transcoder A under intel_crtc for pipe A, irrespective of
> > > which pipe may actually be driving the transcoder. But I figured trying
> > > to change that would result in more churn.
> > > 
> > > Caveat: Still untested
> > > 
> > > v2: Use HAS_PCH_LPT_H instead of HAS_DDI
> > > Use cpt_check_pch_fifo_underruns() on LPT-H/WPT-H too
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > I've battled hsw lpt fifo underrun issues last week and never seen a fifo
> > underrun on pipe B/C. Have you seen them anywhere really?
> 
> No, I've not seen it. We mark underrun detection as disabled for active
> pipes in intel_sanitize_crtc(), and we never turn it back on except for
> transcoder A, so I'm thinking we'll never actually enable the south
> error interrup on LPT if a non-pch port is enabled on boot.

Hm right this is broken for pch ... I guess we need an IS_HSW(dev) : PCH_A
: pipe in there to get this right.

I do get plenty pch fifo underruns here, but I guess my bios boots with
vga on pipe A and hence I get away with this bug ;-)
 
> Note that so far I didn't check if that's actually the case, but based
> on the code I can't come to any other conclusion.

Yeah seems indeed broken, but I think simpler to fix in the crtc sanitize
code.
-Daniel

> 
> > 
> > If not I think we can skip this patch here, since I think I tracked it all
> > down.
> > -Daniel
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_fifo_underrun.c | 27 
> > > ++-
> > >  1 file changed, 22 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
> > > b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > > index bda526660e20..3d3acc8b8367 100644
> > > --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > > +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> > > @@ -48,6 +48,14 @@
> > >   * The code also supports underrun detection on the PCH transcoder.
> > >   */
> > >  
> > > +static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
> > > +   enum transcoder pch_transcoder)
> > > +{
> > > + /* LPT-H/WPT-H have only transcoder A */
> > > + return HAS_PCH_CPT(dev_priv) ||
> > > + (HAS_PCH_LPT_H(dev_priv) && pch_transcoder == TRANSCODER_A);
> > > +}
> > > +
> > >  static bool ivb_can_enable_err_int(struct drm_device *dev)
> > >  {
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > > @@ -69,13 +77,16 @@ static bool ivb_can_enable_err_int(struct drm_device 
> > > *dev)
> > >  static bool cpt_can_enable_serr_int(struct drm_device *dev)
> > >  {
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > > - enum pipe pipe;
> > > - struct intel_crtc *crtc;
> > > + enum transcoder pch_transcoder;
> > >  
> > >   assert_spin_locked(_priv->irq_lock);
> > >  
> > > - for_each_pipe(dev_priv, pipe) {
> > > - crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> > > + for_each_pipe(dev_priv, pch_transcoder) {
> > > + struct intel_crtc *crtc =
> > > + 
> > > to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
> > > +
> > > + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> > > + continue;
> > >  
> > >   if (crtc->pch_fifo_underrun_disabled)
> > >   return false;
> > > @@ -206,6 +217,9 @@ static void cpt_check_pch_fifo_underruns(struct 
> > > intel_crtc *crtc)
> > >  
> > >   assert_spin_locked(_priv->irq_lock);
> > >  
> > > + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> > > + return;
> > > +
> > >   if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
> > >   return;
> > >  
> > > @@ -222,6 +236,9 @@ static void cpt_set_fifo_underrun_reporting(struct 
> > > drm_device *dev,
> > >  {
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > >  
> > > + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> > > + return;
> > > +
> > >   if (enable) {
> > >   I915_WRITE(SERR_INT,
> > >  SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
> > > @@ -436,7 +453,7 @@ void intel_check_pch_fifo_underruns(struct 
> > > drm_i915_private *dev_priv)
> > >   if (crtc->pch_fifo_underrun_disabled)
> > >   continue;
> > >  
> > > - if 

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

[Daniel Vetter]

On Mon, Nov 30, 2015 at 03:11:16PM +0100, Daniel Vetter wrote:
> On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> > index 30d89e0da2c6..058d39e8d57f 100644
> > --- a/include/drm/i915_component.h
> > +++ b/include/drm/i915_component.h
> > @@ -38,6 +38,7 @@
> >   * @codec_wake_override: Enable/Disable generating the codec wake signal
> >   * @get_cdclk_freq: get the Core Display Clock in KHz
> >   * @sync_audio_rate: set n/cts based on the sample rate
> > + * @get_eld: fill the audio state and ELD bytes for the given port
> 
> In 4.4 kerneldoc supports extended in-line comments for struct members
> like this:
> 
> >   */
> >  struct i915_audio_component_ops {
> > struct module *owner;
> > @@ -46,6 +47,8 @@ struct i915_audio_component_ops {
> > void (*codec_wake_override)(struct device *, bool enable);
> > int (*get_cdclk_freq)(struct device *);
> > int (*sync_audio_rate)(struct device *, int port, int rate);
> 
>   /**
>* @get_eld:
>*
>* lots of blabla, possibly in multiple paragraphs.
>*/
> 
> Please use that layout and put a copy of the more detailed description you
> put into the commit message of how ->get_eld exactly works.
> 
> I did ask for this to get done as part of some of the previous, and it was
> partially done but not exactly how kerneldoc wants it :( But I think we
> need to start somewhere ...

Strike that, I looked at the wrong tree ;-) linux-next should have all the
patches using the new extended style.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Slaughter the thundering i915_wait_request herd

[Chris Wilson]

On Mon, Nov 30, 2015 at 01:32:16PM +, Tvrtko Ursulin wrote:
> 
> On 30/11/15 12:30, Chris Wilson wrote:
> >On Mon, Nov 30, 2015 at 12:05:50PM +, Tvrtko Ursulin wrote:
> >>>+  struct intel_breadcrumbs {
> >>>+  spinlock_t lock; /* protects the per-engine request list */
> >>
> >>s/list/tree/
> >
> >list. We use the tree as a list!
> 
> Maybe but it confuses the reader a bit who goes and looks for some
> list then.
> 
> Related, when I was playing with this I was piggy backing on the
> existing per engine request list.

A separate list with separate locking only used when waiting, that's the
appeal for me.
 
> If they are seqno ordered there, and I think they are, then the
> waker thread just traverses it in order until hitting the not
> completed one, waking up every req->wait_queue as it goes.
>
> In this case it doesn't matter that the waiters come in in
> indeterministic order so we don't need a (new) tree.
> 
> But the downside is the thread needs struct mutex. And that the
> retirement from that list is so lazy..

And we can't even take struct_mutex!

> 
> >>>+  struct task_struct *task; /* bh for all user interrupts */
> >>>+  struct intel_breadcrumbs_engine {
> >>>+  struct rb_root requests; /* sorted by retirement */
> >>>+  struct drm_i915_gem_request *first;
> >>
> >>/* First request in the tree to be completed next by the hw. */
> >>
> >>?
> >
> >/* first */ ?
> 
> Funny? :) First what? Why make the reader reverse engineer it?

struct drm_i915_gem_request *first_waiter; ?

Please don't make me add /* ^^^ */

> >>For a later extension:
> >>
> >>How would you view, some time in the future, adding a bool return to
> >>ring->put_irq() which would say to the thread that it failed to
> >>disable interrupts?
> >>
> >>In this case thread would exit and would need to be restarted when
> >>the next waiter queues up. Possibly extending the
> >>idle->put_irq->exit durations as well then.
> >
> >Honestly, not keen on the idea that the lowlevel put_irq can fail (makes
> >cleanup much more fraught). I don't see what improvement you intend
> >here, maybe clarifying that would help explain what you mean.
> 
> Don't know, maybe reflecting the fact it wasn't the last put_irq
> call so let the caller handle it if they want. We can leave this
> discussion for the future.

Hmm. The only other use is the trace_irq. It would be nice to eliminate
that and the ring->irq_count.
> 
> >>>@@ -2986,16 +2981,16 @@ static void i915_hangcheck_elapsed(struct 
> >>>work_struct *work)
> >>>   if (ring_idle(ring, seqno)) {
> >>>   ring->hangcheck.action = HANGCHECK_IDLE;
> >>>
> >>>-  if (waitqueue_active(>irq_queue)) {
> >>>+  if 
> >>>(READ_ONCE(dev_priv->breadcrumbs.engine[ring->id].first)) {
> >>
> >>READ_ONCE is again strange, but other than that I don't know the
> >>hangcheck code to really evaulate it.
> >>
> >>Perhaps this also means this line needs a comment describing what
> >>condition/state is actually approximating with the check.
> >
> >All we are doing is asking if anyone is waiting on the GPU, because the
> >GPU has finished all of its work. If so, the IRQ handling is suspect
> >(modulo the pre-existing race condition clearly earmarked by READ_ONCE).
> 
> Cool, /* Check if someone is waiting on the GPU */ then would make me happy.

+static bool any_waiters_on_engine(struct intel_engine_cs *engine)
+{
+   return 
READ_ONCE(engine->i915->breadcrumbs.engine[engine->id].first_waiter);
+}
+
 static bool any_waiters(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *ring;
int i;
 
for_each_ring(ring, dev_priv, i)
-   if (ring->irq_refcount)
+   if (any_waiters_on_engine(engine))
return true;
 
return false;

> >>>+  while (!kthread_should_stop()) {
> >>>+  unsigned reset_counter = i915_reset_counter(>gpu_error);
> >>>+  unsigned long timeout_jiffies;
> >>>+  bool idling = false;
> >>>+
> >>>+  /* On every tick, walk the seqno-ordered list of requests
> >>>+   * and for each retired request wakeup its clients. If we
> >>>+   * find an unfinished request, go back to sleep.
> >>>+   */
> >>
> >>s/tick/loop/ ?
> >s/tick/iteration/ I'm sticking with tick
> 
> Tick makes me tick of a scheduler tick so to me it is the worst of
> the three. Iteration sounds really good. Whether that will be a
> tick/jiffie/orsomething is definite a bit lower in the code.

Hmm, that was the connection I liked with tick.
 
> >>And if we don't find and unfinished request still go back to sleep. :)
> >
> >Ok.
> >
> >>>+  set_current_state(TASK_INTERRUPTIBLE);
> >>>+
> >>>+  /* Note carefully that we do not hold a reference for the
> >>>+   * requests on this list. Therefore we only inspect them
> >>>+   * whilst holding 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/dsi: merge pre_pll_enable hook to pre_enable

[Daniel Vetter]

On Fri, Nov 27, 2015 at 01:26:40PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 27, 2015 at 12:21:44PM +0200, Jani Nikula wrote:
> > For DSI, the pre_pll_enable and the pre_enable hooks are called
> > back-to-back on all platforms that support DSI. The distinction is
> > artificial for DSI, for which we enable the DSI PLL in the encoder
> > hooks. Do everything in pre_enable, and remove DSI pre_pll_enable hook.
> > 
> > Signed-off-by: Jani Nikula 
> 
> I was eyeing this same thing at some point.
> 
> For the series:
> Reviewed-by: Ville Syrjälä 

Yeah, all the pretties in here!

Reviewed-by: Daniel Vetter 

Btw about bxt dsi I wonder whether we should partially merge this with the
cpu transcoder (since it's only either that or a dsi encoder aparrently).
At least I remember that we still had some issues with bxt's
dsi_get_hw_state?

Cheers, Daniel

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 16 +---
> >  1 file changed, 5 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index efb5a27dd49c..08c46c49c481 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -462,6 +462,8 @@ static void intel_dsi_enable(struct intel_encoder 
> > *encoder)
> > intel_panel_enable_backlight(intel_dsi->attached_connector);
> >  }
> >  
> > +static void intel_dsi_prepare(struct intel_encoder *intel_encoder);
> > +
> >  static void intel_dsi_pre_enable(struct intel_encoder *encoder)
> >  {
> > struct drm_device *dev = encoder->base.dev;
> > @@ -474,6 +476,9 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> > *encoder)
> >  
> > DRM_DEBUG_KMS("\n");
> >  
> > +   intel_dsi_prepare(encoder);
> > +   intel_enable_dsi_pll(encoder);
> > +
> > /* Panel Enable over CRC PMIC */
> > if (intel_dsi->gpio_panel)
> > gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
> > @@ -1026,15 +1031,6 @@ static void intel_dsi_prepare(struct intel_encoder 
> > *intel_encoder)
> > }
> >  }
> >  
> > -static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder)
> > -{
> > -   DRM_DEBUG_KMS("\n");
> > -
> > -   intel_dsi_prepare(encoder);
> > -   intel_enable_dsi_pll(encoder);
> > -
> > -}
> > -
> >  static enum drm_connector_status
> >  intel_dsi_detect(struct drm_connector *connector, bool force)
> >  {
> > @@ -1154,9 +1150,7 @@ void intel_dsi_init(struct drm_device *dev)
> >  
> > drm_encoder_init(dev, encoder, _dsi_funcs, DRM_MODE_ENCODER_DSI);
> >  
> > -   /* XXX: very likely not all of these are needed */
> > intel_encoder->compute_config = intel_dsi_compute_config;
> > -   intel_encoder->pre_pll_enable = intel_dsi_pre_pll_enable;
> > intel_encoder->pre_enable = intel_dsi_pre_enable;
> > intel_encoder->enable = intel_dsi_enable_nop;
> > intel_encoder->disable = intel_dsi_pre_disable;
> > -- 
> > 2.1.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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