Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Jani Nikula]

On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
>
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  6 ++
>  2 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..cdb04c9 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);

\n missing.

> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);

\n missing.

> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..1269ef8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> +# define DP_REV_10  0x10
> +# define DP_REV_11  0x11
> +# define DP_REV_12  0x12
> +# define DP_REV_13  0x13
> +# define DP_REV_14  0x14

I am not sure what good these buy us, but if people think they're the
way to go, then so be it. Just bear in mind that per spec, "The DPCD
revision number does not necessarily match the DisplayPort version
number." so "DP_REV" doesn't actually mean *DP* revision.


BR,
Jani.

>  
>  #define DP_MAX_LINK_RATE0x001
>  
> @@ -118,6 +123,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Maarten Lankhorst]

Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
>> Similar to enable_fbc, enable_psr was ignored at runtime if it was
>> changed. The easiest fix is to pretend enable_psr is ignored at
>> configure time, and never activate it for !enable_psr, so both cases
>> are handled without modesets.
> What about cases where psr_flush() is not called and consequently the
> module parameter is not checked? With HW tracking, PSR is
> enabled/disabled during modeset and the hardware is expected to exit and
> activate PSR without driver intervention.
It looks like intel_frontbuffer_flush always calls intel_psr_flush,
so we at least get a PSR toggle after every atomic commit?

~Maarten

>> Signed-off-by: Maarten Lankhorst 
>> Tested-by: Benjamin Berg 
>> Cc: Benjamin Berg 
>> ---
>>  drivers/gpu/drm/i915/intel_psr.c | 19 ++-
>>  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
>> b/drivers/gpu/drm/i915/intel_psr.c
>> index 23175c5c4a50..ac3ce7a1c2a7 100644
>> --- a/drivers/gpu/drm/i915/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>> @@ -502,11 +502,6 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>>  if (!CAN_PSR(dev_priv))
>>  return;
>>  
>> -if (!i915_modparams.enable_psr) {
>> -DRM_DEBUG_KMS("PSR disable by flag\n");
>> -return;
>> -}
>> -
>>  /*
>>   * HSW spec explicitly says PSR is tied to port A.
>>   * BDW+ platforms with DDI implementation of PSR have different
>> @@ -559,7 +554,10 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>>  
>>  crtc_state->has_psr = true;
>>  crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
>> -DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
>> +if (i915_modparams.enable_psr)
>> +DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : 
>> "");
>> +else
>> +DRM_DEBUG_KMS("PSR disable by flag\n");
>>  }
>>  
>>  static void intel_psr_activate(struct intel_dp *intel_dp)
>> @@ -652,7 +650,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>>  dev_priv->psr.enable_source(intel_dp, crtc_state);
>>  dev_priv->psr.enabled = intel_dp;
>>  
>> -if (INTEL_GEN(dev_priv) >= 9) {
>> +if (!i915_modparams.enable_psr) {
>> +DRM_DEBUG_KMS("PSR disable by flag\n");
>> +} else if (INTEL_GEN(dev_priv) >= 9) {
>>  intel_psr_activate(intel_dp);
>>  } else {
>>  /*
>> @@ -843,7 +843,7 @@ static void intel_psr_work(struct work_struct *work)
>>   * recheck. Since psr_flush first clears this and then reschedules we
>>   * won't ever miss a flush when bailing out here.
>>   */
>> -if (dev_priv->psr.busy_frontbuffer_bits)
>> +if (dev_priv->psr.busy_frontbuffer_bits || !i915_modparams.enable_psr)
>>  goto unlock;
>>  
>>  intel_psr_activate(intel_dp);
>> @@ -1015,7 +1015,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>>  return;
>>  
>>  mutex_lock(_priv->psr.lock);
>> -if (!dev_priv->psr.enabled) {
>> +if (!dev_priv->psr.enabled || !i915_modparams.enable_psr) {
>> +intel_psr_exit(dev_priv);
>>  mutex_unlock(_priv->psr.lock);
>>  return;
>>  }


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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

[Ramalingam C]

On Tuesday 27 February 2018 04:20 AM, Chris Wilson wrote:

Quoting Ramalingam C (2018-02-26 17:12:39)

DP and HDMI HDCP specifications are varying with respect to
detecting the R0 and ksv_fifo availability.

DP will produce CP_IRQ and set a bit for indicating the R0 and
FIFO_READY status.

Whereas HDMI will set a bit for FIFO_READY but there is no bit
indication for R0 ready. And also polling of READY bit is needed for
HDMI as ther is no CP_IRQ.

So Fielding the CP_IRQ for DP and the polling the READY bit for a
period and blindly waiting for a fixed time for R0 incase of HDMI are
moved into corresponding hdcp_shim.

Signed-off-by: Ramalingam C 
---
+static int intel_dp_hdcp_wait_for_cp_irq(struct completion *cp_irq_recved,
+int timeout)
+{
+   long ret;
+
+   if (completion_done(cp_irq_recved))
+   reinit_completion(cp_irq_recved);
+
+   ret = wait_for_completion_interruptible_timeout(cp_irq_recved,
+   msecs_to_jiffies(
+   timeout));
+   reinit_completion(cp_irq_recved);

This is not thread-safe.

The trick is to use a waitqueue to interrupt the sleeps inside the wait
loops to complete the polling quicker. (As stated, you can't escape the
polling, and you always need to check the IRQ was for the event you
expected anyway.)
-Chris


Chris,

I think I am lost here. Could you please help me understand what are we missing 
here?
Completion also uses the wait_queue and each thread that want to wait for a 
event waits on it.
And on IRQ arrival through complete_all we are marking the completion->done and 
waking up all the thread sleeping at completion wait_queue.

Are you suggesting wait_event_timeout as we have in intel_dp_aux_wait_done?

Thanks,
--Ram


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

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/uc: Start preparing GuC/HuC for reset

[Sagar Arun Kamble]

On 3/5/2018 8:13 PM, Chris Wilson wrote:

Quoting Michal Wajdeczko (2018-03-05 14:29:16)

Right after GPU reset there will be a small window of time during which
some of GuC/HuC fields will still show state before reset. Let's start
to fix that by sanitizing firmware status as we will use it shortly.

v2: s/reset_prepare/prepare_to_reset (Michel)
 don't forget about gem_sanitize path (Daniele)
v3: rebased

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michel Thierry 
Reviewed-by: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/i915_gem.c|  5 -
  drivers/gpu/drm/i915/intel_guc.h   |  5 +
  drivers/gpu/drm/i915/intel_huc.h   |  5 +
  drivers/gpu/drm/i915/intel_uc.c| 14 ++
  drivers/gpu/drm/i915/intel_uc.h|  1 +
  drivers/gpu/drm/i915/intel_uc_fw.h |  6 ++
  6 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a5bd073..aedb17d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2981,6 +2981,7 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
 }
  
 i915_gem_revoke_fences(dev_priv);

+   intel_uc_prepare_to_reset(dev_priv);
  
 return err;

  }
@@ -4882,8 +4883,10 @@ void i915_gem_sanitize(struct drm_i915_private *i915)
  * it may impact the display and we are uncertain about the stability
  * of the reset, so this could be applied to even earlier gen.
  */
-   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915))
+   if (INTEL_GEN(i915) >= 5 && intel_has_gpu_reset(i915)) {
+   intel_uc_prepare_to_reset(i915);
 WARN_ON(intel_gpu_reset(i915, ALL_ENGINES));

This still feels wrong. If we accept that we will have to reload the fw
on resume, why are we not just sanitzing the uc state and forcing the
reload?

Hi Chris,

intel_uc_prepare_to_reset() is sanitizing uc state and reload is 
happening through gem_init_hw in resume path.

what are we missing?

Thanks,
Sagar

-Chris


--
Thanks,
Sagar

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

[Intel-gfx] ✓ Fi.CI.IGT: success for igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Patchwork]

== Series Details ==

Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx
URL   : https://patchwork.freedesktop.org/series/39571/
State : success

== Summary ==

 Known issues:

Test gem_softpin:
Subgroup noreloc-s3:
skip   -> PASS   (shard-snb) fdo#103375
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-right-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-modesetfrombusy:
pass   -> FAIL   (shard-apl) fdo#103167
Subgroup fbc-suspend:
fail   -> PASS   (shard-apl) fdo#101623
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3448 pass:1806 dwarn:1   dfail:0   fail:8   skip:1632 
time:12072s
shard-hswtotal:3484 pass:1772 dwarn:1   dfail:0   fail:2   skip:1708 
time:11921s
shard-snbtotal:3484 pass:1364 dwarn:2   dfail:0   fail:1   skip:2117 
time:7142s
Blacklisted hosts:
shard-kbltotal:3328 pass:1791 dwarn:7   dfail:1   fail:7   skip:1519 
time:8399s

== Logs ==

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

[Intel-gfx] [PULL] gvt-next for 4.17

[Zhenyu Wang]

Hi,

Here's gvt-next update for 4.17. Biggest update is for huge code
refactor of shadow ppgtt from Changbin which is the most obscured
part, and with KBL context save/restore improvement from Weinan,
with other fixes.

Thanks.
--
The following changes since commit 1f267a572b573b0b155022750cba93001f4367a8:

  drm/i915: Update DRIVER_DATE to 20180305 (2018-03-05 11:56:15 +0200)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2018-03-08

for you to fetch changes up to 991ecefbdd4b81719597d6c406df8d26ef5c1546:

  drm/i915/gvt: Return error at the failure of finding page_track (2018-03-06 
14:49:38 +0800)


gvt-next-2018-03-08

- big refactor for shadow ppgtt (Changbin)
- KBL context save/restore via LRI cmd (Weinan)
- misc smatch fixes (Zhenyu)
- Properly unmap dma for guest page (Changbin)
- other misc fixes (Xiong, etc.)


Changbin Du (18):
  drm/i915/gvt: Rework shadow graphic memory management code
  drm/i915/gvt: Refine the intel_vgpu_mm reference management
  drm/i915/gvt: Refine ggtt and ppgtt root entry ops
  drm/i915/gvt: Refine ggtt_set_shadow_entry
  drm/i915/gvt: Add verbose gtt shadow logs
  drm/i915/gvt: Rename ggtt related functions to be more specific
  drm/i915/gvt: Factor out intel_vgpu_{get, put}_ppgtt_mm interface
  drm/i915/gvt: Use standard pte bit definition
  drm/i915/gvt: Refine pte shadowing process
  drm/i915/gvt: Rework shadow page management code
  drm/i915/gvt: Rename shadow_page to short name spt
  drm/i915/gvt: Rename mpt api {set, unset}_wp_page to {enable, 
disable}_page_track
  drm/i915/gvt: Don't extend page_track to mpt layer
  drm/i915/gvt: Provide generic page_track infrastructure for 
write-protected page
  drm/i915/gvt: Manage shadow pages with radix tree
  drm/i915/gvt: Define PTE addr mask with GENMASK_ULL
  drm/i915/gvt: Fix guest vGPU hang caused by very high dma setup overhead
  drm/i915/kvmgt: Add kvmgt debugfs entry nr_cache_entries under vgpu

Weinan Li (3):
  drm/i915/gvt: add define GEN9_MOCS_SIZE
  drm/i915/gvt: add interface to check if context is inhibit
  drm/i915/gvt: init mmio by lri command in vgpu inhibit context

Xiong Zhang (2):
  drm/i915/gvt: Release gvt->lock at the failure of finding page track
  drm/i915/gvt: Return error at the failure of finding page_track

Zhenyu Wang (7):
  drm/i915/gvt: Fix one gvt_vgpu_error() use in dmabuf.c
  drm/i915/gvt: remove gvt max port definition
  drm/i915/gvt: Fix vGPU sched timeslice calculation warning
  drm/i915/gvt: Fix check error of vgpu create failure message
  drm/i915/gvt: Fix check error on fence mmio handler
  drm/i915/gvt: Fix one indent error
  drm/i915/gvt: Fix check error on hws_pga_write() fail message

 drivers/gpu/drm/i915/gvt/Makefile   |2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c   |2 +-
 drivers/gpu/drm/i915/gvt/gtt.c  | 1457 ++-
 drivers/gpu/drm/i915/gvt/gtt.h  |  189 ++--
 drivers/gpu/drm/i915/gvt/gvt.c  |2 +-
 drivers/gpu/drm/i915/gvt/gvt.h  |   21 +-
 drivers/gpu/drm/i915/gvt/handlers.c |   38 +-
 drivers/gpu/drm/i915/gvt/hypercall.h|9 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c|  313 ---
 drivers/gpu/drm/i915/gvt/mmio.c |9 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c |  210 -
 drivers/gpu/drm/i915/gvt/mmio_context.h |5 +
 drivers/gpu/drm/i915/gvt/mpt.h  |   67 +-
 drivers/gpu/drm/i915/gvt/page_track.c   |  184 
 drivers/gpu/drm/i915/gvt/page_track.h   |   56 ++
 drivers/gpu/drm/i915/gvt/sched_policy.c |5 +-
 drivers/gpu/drm/i915/gvt/scheduler.c|   44 +-
 drivers/gpu/drm/i915/gvt/trace.h|   10 +-
 drivers/gpu/drm/i915/gvt/vgpu.c |1 +
 19 files changed, 1468 insertions(+), 1156 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gvt/page_track.c
 create mode 100644 drivers/gpu/drm/i915/gvt/page_track.h


-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Patchwork]

== Series Details ==

Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx
URL   : https://patchwork.freedesktop.org/series/39571/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
b4689dce36d0fbd9aec70d5a4b077c43a6b9c254 igt: Remove gen7_forcewake_mt

with latest DRM-Tip kernel build CI_DRM_3892
fc93d196b8e4 drm-tip: 2018y-03m-07d-23h-55m-21s UTC integration manifest

Testlist changes:
+igt@gem_ctx_freq@blt
+igt@gem_ctx_freq@blt-inflight
+igt@gem_ctx_freq@bsd
+igt@gem_ctx_freq@bsd1
+igt@gem_ctx_freq@bsd1-inflight
+igt@gem_ctx_freq@bsd2
+igt@gem_ctx_freq@bsd2-inflight
+igt@gem_ctx_freq@bsd-inflight
+igt@gem_ctx_freq@idempotent
+igt@gem_ctx_freq@independent
+igt@gem_ctx_freq@invalid
+igt@gem_ctx_freq@render
+igt@gem_ctx_freq@render-inflight
+igt@gem_ctx_freq@sandwich
+igt@gem_ctx_freq@smoketest
+igt@gem_ctx_freq@vebox
+igt@gem_ctx_freq@vebox-inflight

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-byt-j1900) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:504s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:252  dwarn:0   dfail:0   fail:1   skip:35  
time:485s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:509s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:472s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:522s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:538s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:530s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s

== Logs ==

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

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

Signed-off-by: Chris Wilson 
---
A few more test ideas.
---
 tests/Makefile.am  |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 512 +
 tests/meson.build  |   1 +
 4 files changed, 515 insertions(+)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..bd60837d
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,512 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 8
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   return __gem_context_set_param(fd, );
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int delay)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(delay);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 0);
+
+   gem_quiescent_gpu(fd);
+   measured = measure_frequency(pmu, 1);
+   igt_info("Initial (idle) freq: %.1fMHz\n",measured);
+   igt_require(measured >= min - 50 && measured <= min + 50);
+
+   for (uint32_t freq = min + 50; freq <= max; freq += 100) {
+   uint32_t cur, discard;
+
+   

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Quoting Antonio Argenziano (2018-03-08 00:55:47)
> 
> 
> On 07/03/18 14:49, Chris Wilson wrote:
> > +static void single(int fd, const struct intel_execution_engine *e)
> > +{
> > + const unsigned int engine = e->exec_id | e->flags;
> > + uint32_t ctx = gem_context_create(fd);
> > + uint32_t min, max;
> > + double measured;
> > + igt_spin_t *spin;
> > + int pmu;
> > +
> > + get_freq(fd, ctx, , );
> > + igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
> > +
> > + pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
> > + igt_require(pmu >= 0);
> > +
> > + gem_quiescent_gpu(fd);
> > + measured = measure_frequency(pmu, 1);
> > + igt_info("Initial (idle) freq: %.1fMHz\n",measured);
> > + igt_require(measured >= min - 50 && measured <= min + 50);
> > +
> > + for (uint32_t freq = min + 50; freq <= max; freq += 100) {
> > + set_freq(fd, ctx, freq, freq);
> > +
> > + gem_quiescent_gpu(fd);
> > + spin = __igt_spin_batch_new(fd, ctx, engine, 0);
> > + usleep(1);
> > +
> > + measured = measure_frequency(pmu, 5);
> > + igt_debugfs_dump(fd, "i915_rps_boost_info");
> > +
> > + igt_spin_batch_free(fd, spin);
> > + igt_info("%s(single): Measured %.1fMHz, expected %dMhz\n",
> > +  e->name, measured, freq);
> > + igt_assert(measured > freq - 100 && measured < freq + 100);
> > + }
> > + gem_quiescent_gpu(fd);
> 
> Check frequency has gone back to ~min.

It's not that interesting a test (covered already by pmu) as we
essentially lie anyway over idle.

> I would suggest to split here into two sub-tests.
> 
> > + spin = __igt_spin_batch_new(fd, ctx, engine, 0);
> > + for (uint32_t freq = min + 50; freq <= max; freq += 100) {
> > + igt_spin_t *kick;
> > +
> > + set_freq(fd, ctx, freq, freq);
> > +
> > + /*
> > +  * When requesting a new frequency on the currently
> > +  * executing context, it does not take effect until the
> > +  * next context switch. In this case, we trigger a lite
> > +  * restore.
> 
> Is this enforced by the ABI? 

Enforced? No. The comment is precisely because it's not checked on
calling whether the context is currently on the HW and trying hard to be
sure that no one expects us to do that check. i.e. that set_freq()
doesn't change frequency itself, but doesn't rule it out either as it
may appear to have that effect due to many external factors.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Antonio Argenziano]

On 07/03/18 14:49, Chris Wilson wrote:

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

Signed-off-by: Chris Wilson 
---
  tests/Makefile.am  |   2 +-
  tests/Makefile.sources |   1 +
  tests/gem_ctx_freq.c   | 190 +
  tests/meson.build  |   1 +
  4 files changed, 193 insertions(+), 1 deletion(-)
  create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index edd689a4..f42641f6 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
  drm_import_export_LDADD = $(LDADD) -lpthread
  gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
  gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
  gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
  gem_ctx_thrash_LDADD = $(LDADD) -lpthread
  gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
@@ -128,7 +129,6 @@ prime_self_import_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
  prime_self_import_LDADD = $(LDADD) -lpthread
  gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
  gem_userptr_blits_LDADD = $(LDADD) -lpthread
-perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
  
  gem_wait_LDADD = $(LDADD) -lrt

  kms_flip_LDADD = $(LDADD) -lrt -lpthread
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 05cdc1ef..06e729ef 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -59,6 +59,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_shared \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..a01ce01b
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 8
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   gem_context_set_param(fd, );
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int delay)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(delay);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 0);
+
+   gem_quiescent_gpu(fd);
+   measured = 

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Benson Leung]

Hi Matt,

On Wed, Mar 07, 2018 at 04:28:51PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> 
> Signed-off-by: Matt Atwood 

Tested-by: Benson Leung 

V5 passes link training on that same panel from before with 8th bit set in
DPCD 0x000e.
 
Thanks,
Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


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

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/sun4i/sun4i_tcon.c

between commit:

  e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")

from the drm-misc-fixes tree and commit:

  34d698f6e349 ("drm/sun4i: Add has_channel_0 TCON quirk")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2de586b7c98b,0d6c5ed44795..
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@@ -1143,11 -1155,15 +1164,16 @@@ static const struct sun4i_tcon_quirks s
  };
  
  static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
+   .has_channel_0  = true,
 +  .supports_lvds  = true,
  };
  
+ static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
+   .has_channel_1  = true,
+ };
+ 
  static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
-   /* nothing is supported */
+   .has_channel_0  = true,
  };
  
  /* sun4i_drv uses this list to check if a device node is a TCON */


pgpvqbnENgx86.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..cdb04c9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..1269ef8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DP_REV_10  0x10
+# define DP_REV_11  0x11
+# define DP_REV_12  0x12
+# define DP_REV_13  0x13
+# define DP_REV_14  0x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Benson Leung]

Hey Matt,

Your patch doesn't build. Missing semicolon, dude.

On Wed, Mar 07, 2018 at 04:13:58PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  6 ++
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..6985ff3 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);
> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4)

Need a semicolon here.

/mnt/host/source/src/third_party/kernel/v4.14/drivers/gpu/drm/drm_dp_helper.c: 
In function 'drm_dp_link_train_clock_recovery_delay':
/mnt/host/source/src/third_party/kernel/v4.14/drivers/gpu/drm/drm_dp_helper.c:131:1:
 error: expected ';' before '}' token
 }
 ^
make[4]: *** 
[/mnt/host/source/src/third_party/kernel/v4.14/scripts/Makefile.build:320: 
drivers/gpu/drm/drm_dp_helper.o] Error 1


Thanks,
Benson

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Add Wa_2201832410 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add Wa_2201832410 (rev2)
URL   : https://patchwork.freedesktop.org/series/39408/
State : success

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
incomplete -> PASS   (shard-hsw)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-top-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +3

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

shard-apltotal:3381 pass:1778 dwarn:3   dfail:0   fail:7   skip:1591 
time:11871s
shard-hswtotal:3467 pass:1772 dwarn:1   dfail:0   fail:2   skip:1691 
time:11862s
shard-snbtotal:3467 pass:1362 dwarn:2   dfail:0   fail:2   skip:2101 
time:7014s
Blacklisted hosts:
shard-kbltotal:3394 pass:1898 dwarn:11  dfail:0   fail:8   skip:1476 
time:9117s

== Logs ==

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

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..6985ff3 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4)
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..1269ef8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DP_REV_10  0x10
+# define DP_REV_11  0x11
+# define DP_REV_12  0x12
+# define DP_REV_13  0x13
+# define DP_REV_14  0x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-07 at 15:43 -0800, Rodrigo Vivi wrote:
> On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote:
> > On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote:
> > > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > > > plane MMIOs are written to. But this flush should not be necessary for
> > > > > PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> > > > > for FBC, the spec says "Flips or changes to plane size and panning" 
> > > > > cause
> > > > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> > > > > cursor updates in their frontbuffer_flush implementations.
> > > > > 
> > > > >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > > > > "Compressing: yes" when I move the cursor around.
> > > > > 
> > > > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush 
> > > > > frontbuffer.
> > > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > > > 
> > > > > Cc: Paulo Zanoni 
> > > > > Cc: Ville Syrjälä 
> > > > > Cc: Chris Wilson 
> > > > > Cc: Rodrigo Vivi 
> > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 91ce8a0522a3..18b08e263ee1 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane 
> > > > > *plane,
> > > > > if (ret)
> > > > > goto out_unlock;
> > > > >  
> > > > > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > > > > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> > > > 
> > > > What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> > > > aiui.
> > > > -Chris
> > > 
> > > 
> > > That was the idea but there's a problem with not knowing if PSR exit is
> > > fully complete before we begin updating the plane registers in
> > > pipe_update_start().
> > > 
> > > Let's say PSR was active and display is in DC6. A flip comes in, without
> > > _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
> > > enabling that happens in pipe_update_start. We immediately follow that
> > > with programming the plane MMIO's without checking if PSR fully exited.
> > > If PSR and DC6 happen to exit while we were in the middle of programming
> > > plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
> > > partially programmed registers. _flush(DIRTYFB) gives us an opportunity
> > > to exit PSR fully by starting early.
> > > 
> > > As for legacy_cursor_update(), since there is no vblank enabling
> > > involved, we avoid updating the MMIO's in the midst of PSR exit
> > 
> > I don't believe you will be ever in a case that you write to any register
> > and get any flip or anything without exiting DC6 before that happens.
> > 
> > Or the CSR mechanism of DC6 will be simply wrong.
> > 
> > Would this be enough?
> 
> ok... just ignore my previous comment...
> I believe we can move with the safest side and maybe revisit this later.
> 
> From what I remember of the FBC nuke needs as well I believe this is
> the right move.
> 
> Although I'm asking myself now if we are not changing the meaning of the
> ORIGINS here. Shouldn't we add a new origin and update the handling?
> 
> of "flip" is a good description for this call?
> 

The action taken for this frontbuffer_flush() is the same as origin ==
FLIP. I think it is better to add a new one when we want the features
(psr,fbc) to distinguish and react differently. 


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

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Manasi Navare]

On Wed, Mar 07, 2018 at 03:44:09PM -0800, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  4 
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..671b823 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);

I thought there were comments about setting this to a max of 4 if its greater
than 4.

> +
> + if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))
 ^ space needed between if and open bracket

>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4)
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);
> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..5bac397 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,9 @@
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> +# define DP_REV_12  0x012
> +# define DP_REV_13  0x013
> +# define DP_REV_14  0x014
>

IMHO, if we are creating these #defines for revisions then we should
do it for all values so 0x10, 0x11.

Manasi
  
>  #define DP_MAX_LINK_RATE0x001
>  
> @@ -118,6 +121,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

Signed-off-by: Chris Wilson 
---
 tests/Makefile.am  |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 338 +
 tests/meson.build  |   1 +
 4 files changed, 341 insertions(+)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index dbc7be72..389f7fc7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4a81ac4a..3d079c42 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..e68d9dd9
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,338 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 8
+
+static int __set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   return __gem_context_set_param(fd, );
+}
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   igt_assert_eq(__set_freq(fd, ctx, min, max), 0);
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int delay)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(delay);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 0);
+
+   gem_quiescent_gpu(fd);
+   measured = measure_frequency(pmu, 1);
+   igt_info("Initial (idle) freq: %.1fMHz\n",measured);
+   igt_require(measured >= min - 50 && measured <= min + 50);
+
+   for (uint32_t freq = min + 50; freq <= max; freq += 100) {
+   set_freq(fd, ctx, freq, freq);
+
+   

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add Wa_2201832410

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 02:48:05PM -0800, Rafael Antognolli wrote:
> Matches bspec.
> 
> Reviewed-by: Rafael Antognolli 

pushed, thanks

> 
> On Wed, Mar 07, 2018 at 02:09:12PM -0800, Rodrigo Vivi wrote:
> > "Clock gating bug in GWL may not clear barrier state when an EOT
> > is received, causing a hang the next time that barrier is used."
> > 
> > HSDES: 2201832410
> > 
> > Cc: Rafael Antognolli 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 3 +++
> >  drivers/gpu/drm/i915/intel_pm.c | 5 +
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 4787d9bf58b9..e6a8c0ee7df1 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3965,6 +3965,9 @@ enum {
> >  #define  SARBUNIT_CLKGATE_DIS  (1 << 5)
> >  #define  RCCUNIT_CLKGATE_DIS   (1 << 7)
> >  
> > +#define SUBSLICE_UNIT_LEVEL_CLKGATE_MMIO(0x9524)
> > +#define  GWUNIT_CLKGATE_DIS(1 << 16)
> > +
> >  #define UNSLICE_UNIT_LEVEL_CLKGATE _MMIO(0x9434)
> >  #define  VFUNIT_CLKGATE_DIS(1 << 20)
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 6cab20ce167a..b8da4dcdd584 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -8522,6 +8522,11 @@ static void cnl_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> > val |= SARBUNIT_CLKGATE_DIS;
> > I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
> >  
> > +   /* Wa_2201832410:cnl */
> > +   val = I915_READ(SUBSLICE_UNIT_LEVEL_CLKGATE);
> > +   val |= GWUNIT_CLKGATE_DIS;
> > +   I915_WRITE(SUBSLICE_UNIT_LEVEL_CLKGATE, val);
> > +
> > /* WaDisableVFclkgate:cnl */
> > /* WaVFUnitClockGatingDisable:cnl */
> > val = I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE);
> > -- 
> > 2.13.6
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Ilia Mirkin]

On Wed, Mar 7, 2018 at 6:44 PM,   wrote:
> From: Matt Atwood 
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
>
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
>
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
>
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
>
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  4 
>  2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..671b823 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> +   if (rd_interval > 4)
> +   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> rd_interval);
> +
> +   if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))

Was this meant to be dpcd[DP_DPCD_REV] >= DP_REV_14? It doesn't appear
to be a bitmask...

Also I think you're supposed to say "if (" rather than "if(".

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

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  4 
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..671b823 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if(rd_interval == 0 || (dpcd[DP_DPCD_REV] & DP_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4)
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..5bac397 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,9 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DP_REV_12  0x012
+# define DP_REV_13  0x013
+# define DP_REV_14  0x014
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +121,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* 1.3 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote:
> On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > > plane MMIOs are written to. But this flush should not be necessary for
> > > > PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> > > > for FBC, the spec says "Flips or changes to plane size and panning" 
> > > > cause
> > > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> > > > cursor updates in their frontbuffer_flush implementations.
> > > > 
> > > >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > > > "Compressing: yes" when I move the cursor around.
> > > > 
> > > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer.
> > > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > > 
> > > > Cc: Paulo Zanoni 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Chris Wilson 
> > > > Cc: Rodrigo Vivi 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 91ce8a0522a3..18b08e263ee1 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane 
> > > > *plane,
> > > > if (ret)
> > > > goto out_unlock;
> > > >  
> > > > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > > > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> > > 
> > > What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> > > aiui.
> > > -Chris
> > 
> > 
> > That was the idea but there's a problem with not knowing if PSR exit is
> > fully complete before we begin updating the plane registers in
> > pipe_update_start().
> > 
> > Let's say PSR was active and display is in DC6. A flip comes in, without
> > _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
> > enabling that happens in pipe_update_start. We immediately follow that
> > with programming the plane MMIO's without checking if PSR fully exited.
> > If PSR and DC6 happen to exit while we were in the middle of programming
> > plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
> > partially programmed registers. _flush(DIRTYFB) gives us an opportunity
> > to exit PSR fully by starting early.
> > 
> > As for legacy_cursor_update(), since there is no vblank enabling
> > involved, we avoid updating the MMIO's in the midst of PSR exit
> 
> I don't believe you will be ever in a case that you write to any register
> and get any flip or anything without exiting DC6 before that happens.
> 
> Or the CSR mechanism of DC6 will be simply wrong.
> 
> Would this be enough?

ok... just ignore my previous comment...
I believe we can move with the safest side and maybe revisit this later.

From what I remember of the FBC nuke needs as well I believe this is
the right move.

Although I'm asking myself now if we are not changing the meaning of the
ORIGINS here. Shouldn't we add a new origin and update the handling?

of "flip" is a good description for this call?

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Add Wa_2201832410 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add Wa_2201832410 (rev2)
URL   : https://patchwork.freedesktop.org/series/39408/
State : success

== Summary ==

Series 39408v2 drm/i915/cnl: Add Wa_2201832410
https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/2/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:480s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:463s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:509s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:292s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:520s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

0ada78bfa33814b53fc0ce9549a384261bbfffc3 drm-tip: 2018y-03m-07d-22h-14m-49s UTC 
integration manifest
dccad0adc34f drm/i915/cnl: Add Wa_2201832410

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote:
> On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > > plane MMIOs are written to. But this flush should not be necessary for
> > > PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> > > for FBC, the spec says "Flips or changes to plane size and panning" cause
> > > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> > > cursor updates in their frontbuffer_flush implementations.
> > > 
> > >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > > "Compressing: yes" when I move the cursor around.
> > > 
> > > v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer.
> > > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > > 
> > > Cc: Paulo Zanoni 
> > > Cc: Ville Syrjälä 
> > > Cc: Chris Wilson 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 91ce8a0522a3..18b08e263ee1 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane 
> > > *plane,
> > > if (ret)
> > > goto out_unlock;
> > >  
> > > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> > 
> > What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> > aiui.
> > -Chris
> 
> 
> That was the idea but there's a problem with not knowing if PSR exit is
> fully complete before we begin updating the plane registers in
> pipe_update_start().
> 
> Let's say PSR was active and display is in DC6. A flip comes in, without
> _flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
> enabling that happens in pipe_update_start. We immediately follow that
> with programming the plane MMIO's without checking if PSR fully exited.
> If PSR and DC6 happen to exit while we were in the middle of programming
> plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
> partially programmed registers. _flush(DIRTYFB) gives us an opportunity
> to exit PSR fully by starting early.
> 
> As for legacy_cursor_update(), since there is no vblank enabling
> involved, we avoid updating the MMIO's in the midst of PSR exit

I don't believe you will be ever in a case that you write to any register
and get any flip or anything without exiting DC6 before that happens.

Or the CSR mechanism of DC6 will be simply wrong.

Would this be enough?

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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 10:54:28PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Wed, 2018-03-07 at 14:46 -0800, Rodrigo Vivi wrote:
> > On Tue, Mar 06, 2018 at 07:34:18PM -0800, Dhinakaran Pandiyan wrote:
> > > From: "Pandiyan, Dhinakaran" 
> > > 
> > > i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to
> > > DIRTYFB. The callers however are at a vantage point to decide if hardware
> > > frontbuffer tracking can do the flush for us. For example, legacy cursor
> > > updates, like flips, write to MMIO registers, which then triggers PSR 
> > > flush
> > > by the hardware. Moving frontbuffer_flush out will enable us to skip a
> > > software initiated flush by setting origin to FLIP. Thanks to Chris for 
> > > the
> > > idea.
> > > 
> > > v2:
> > > Rebased due to Ville adding intel_plane_pin_fb().
> > > Minor code reordering as fb_obj_flush doesn't need struct_mutex (Chris)
> > > 
> > > Cc: Chris Wilson 
> > > Cc: Ville Syrjälä 
> > > Cc: Paulo Zanoni 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c  | 9 -
> > >  drivers/gpu/drm/i915/intel_display.c | 9 +++--
> > >  drivers/gpu/drm/i915/intel_fbdev.c   | 5 +++--
> > >  drivers/gpu/drm/i915/intel_overlay.c | 1 +
> > >  4 files changed, 15 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index a5bd07338b46..e4c5a1a22d8b 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -4071,9 +4071,10 @@ int i915_gem_set_caching_ioctl(struct drm_device 
> > > *dev, void *data,
> > >  }
> > >  
> > >  /*
> > > - * Prepare buffer for display plane (scanout, cursors, etc).
> > > - * Can be called from an uninterruptible phase (modesetting) and allows
> > > - * any flushes to be pipelined (for pageflips).
> > > + * Prepare buffer for display plane (scanout, cursors, etc). Can be 
> > > called from
> > > + * an uninterruptible phase (modesetting) and allows any flushes to be 
> > > pipelined
> > > + * (for pageflips). We only flush the caches while preparing the buffer 
> > > for
> > > + * display, the callers are responsible for frontbuffer flush.
> > >   */
> > >  struct i915_vma *
> > >  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
> > > @@ -4129,9 +4130,7 @@ i915_gem_object_pin_to_display_plane(struct 
> > > drm_i915_gem_object *obj,
> > >  
> > >   vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
> > >  
> > > - /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
> > 
> > Although flush by some definition here is invalidate + flush
> > I see flush operations as the operation to be performed at the 
> > "end-of-frame".
> > After the operation was done and whatever had to be modified was modified.
> > 
> > I see you patch changing the flush to the creation and begin of the fb 
> > handling
> > like on creating and init fb functions. I believe by that time we are not 
> > ready
> > to exit PSR yet.
> > 
> > What am I missing?
> 
> 
> The functions that you are referring to call
> i915_gem_object_pin_to_display_plane() which in turn calls frontbuffer
> flush. This patch is just a refactor, doesn't change whether flush() is
> called. I am trying to move it up the call stack so that flush() can be
> selectively removed depending on the call site.

Oh! now it made more sense...

probably this phrase is more clear than the current commit message for a
commit message.

But I checked the code and I agree it is right, so:

Reviewed-by: Rodrigo Vivi 



> 
> 
> 
> 
> > 
> > >   __i915_gem_object_flush_for_display(obj);
> > > - intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > >  
> > >   /* It should now be out of any other write domains, and we can update
> > >* the domain values for our changes.
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 331084082545..91ce8a0522a3 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2858,6 +2858,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > > *intel_crtc,
> > >   return;
> > >   }
> > >  
> > > + obj = intel_fb_obj(fb);
> > > + intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > > +
> > >   plane_state->src_x = 0;
> > >   plane_state->src_y = 0;
> > >   plane_state->src_w = fb->width << 16;
> > > @@ -2871,7 +2874,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > > *intel_crtc,
> > >   intel_state->base.src = drm_plane_state_src(plane_state);
> > >   intel_state->base.dst = drm_plane_state_dest(plane_state);
> > >  
> > > - obj = intel_fb_obj(fb);
> > >   if (i915_gem_object_is_tiled(obj))
> > >   dev_priv->preserve_bios_swizzle = true;
> > >  

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Pandiyan, Dhinakaran]

On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> > plane MMIOs are written to. But this flush should not be necessary for
> > PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> > for FBC, the spec says "Flips or changes to plane size and panning" cause
> > FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> > cursor updates in their frontbuffer_flush implementations.
> > 
> >  /sys/kernel/debug/dri/0/i915_fbc_status shows
> > "Compressing: yes" when I move the cursor around.
> > 
> > v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer.
> > v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> > 
> > Cc: Paulo Zanoni 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 91ce8a0522a3..18b08e263ee1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane *plane,
> > if (ret)
> > goto out_unlock;
> >  
> > -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> > +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);
> 
> What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
> aiui.
> -Chris


That was the idea but there's a problem with not knowing if PSR exit is
fully complete before we begin updating the plane registers in
pipe_update_start().

Let's say PSR was active and display is in DC6. A flip comes in, without
_flush(DIRTYFB) in prepare_plane_fb(), PSR exit is delayed until vblank
enabling that happens in pipe_update_start. We immediately follow that
with programming the plane MMIO's without checking if PSR fully exited.
If PSR and DC6 happen to exit while we were in the middle of programming
plane MMIO's, the resulting vblank toggle (from PSR exit) might activate
partially programmed registers. _flush(DIRTYFB) gives us an opportunity
to exit PSR fully by starting early.

As for legacy_cursor_update(), since there is no vblank enabling
involved, we avoid updating the MMIO's in the midst of PSR exit


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Add Wa_2201832410 (rev2)

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 10:59:12PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/cnl: Add Wa_2201832410 (rev2)
> URL   : https://patchwork.freedesktop.org/series/39408/
> State : failure
> 
> == Summary ==
> 
> Series 39408v2 drm/i915/cnl: Add Wa_2201832410
> https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/2/mbox/
> 
>  Possible new issues:
> 
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> INCOMPLETE (fi-glk-1)

yet another false positive... going to the 3rd attempt :/

> 
> fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
> time:424s
> fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
> time:429s
> fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
> time:371s
> fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
> time:496s
> fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
> time:277s
> fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
> time:486s
> fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
> time:492s
> fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
> time:479s
> fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
> time:468s
> fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
> time:404s
> fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
> time:579s
> fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
> time:504s
> fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
> time:414s
> fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
> time:289s
> fi-glk-1 total:109  pass:96   dwarn:0   dfail:0   fail:0   skip:12 
> fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
> time:397s
> fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
> time:408s
> fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
> time:464s
> fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
> time:424s
> fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
> time:469s
> fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:458s
> fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
> time:506s
> fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
> time:583s
> fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:431s
> fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
> time:524s
> fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
> time:532s
> fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
> time:495s
> fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
> time:480s
> fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
> time:422s
> fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
> time:432s
> fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
> time:519s
> fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
> time:396s
> 
> 0ada78bfa33814b53fc0ce9549a384261bbfffc3 drm-tip: 2018y-03m-07d-22h-14m-49s 
> UTC integration manifest
> 571e850d4a9e drm/i915/cnl: Add Wa_2201832410
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8265/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Add Wa_2201832410 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add Wa_2201832410 (rev2)
URL   : https://patchwork.freedesktop.org/series/39408/
State : failure

== Summary ==

Series 39408v2 drm/i915/cnl: Add Wa_2201832410
https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/2/mbox/

 Possible new issues:

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> INCOMPLETE (fi-glk-1)

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:424s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:429s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:468s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:504s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:109  pass:96   dwarn:0   dfail:0   fail:0   skip:12 
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:469s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:524s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:519s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s

0ada78bfa33814b53fc0ce9549a384261bbfffc3 drm-tip: 2018y-03m-07d-22h-14m-49s UTC 
integration manifest
571e850d4a9e drm/i915/cnl: Add Wa_2201832410

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

[Pandiyan, Dhinakaran]

On Wed, 2018-03-07 at 14:46 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 06, 2018 at 07:34:18PM -0800, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran" 
> > 
> > i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to
> > DIRTYFB. The callers however are at a vantage point to decide if hardware
> > frontbuffer tracking can do the flush for us. For example, legacy cursor
> > updates, like flips, write to MMIO registers, which then triggers PSR flush
> > by the hardware. Moving frontbuffer_flush out will enable us to skip a
> > software initiated flush by setting origin to FLIP. Thanks to Chris for the
> > idea.
> > 
> > v2:
> > Rebased due to Ville adding intel_plane_pin_fb().
> > Minor code reordering as fb_obj_flush doesn't need struct_mutex (Chris)
> > 
> > Cc: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Paulo Zanoni 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c  | 9 -
> >  drivers/gpu/drm/i915/intel_display.c | 9 +++--
> >  drivers/gpu/drm/i915/intel_fbdev.c   | 5 +++--
> >  drivers/gpu/drm/i915/intel_overlay.c | 1 +
> >  4 files changed, 15 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index a5bd07338b46..e4c5a1a22d8b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4071,9 +4071,10 @@ int i915_gem_set_caching_ioctl(struct drm_device 
> > *dev, void *data,
> >  }
> >  
> >  /*
> > - * Prepare buffer for display plane (scanout, cursors, etc).
> > - * Can be called from an uninterruptible phase (modesetting) and allows
> > - * any flushes to be pipelined (for pageflips).
> > + * Prepare buffer for display plane (scanout, cursors, etc). Can be called 
> > from
> > + * an uninterruptible phase (modesetting) and allows any flushes to be 
> > pipelined
> > + * (for pageflips). We only flush the caches while preparing the buffer for
> > + * display, the callers are responsible for frontbuffer flush.
> >   */
> >  struct i915_vma *
> >  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
> > @@ -4129,9 +4130,7 @@ i915_gem_object_pin_to_display_plane(struct 
> > drm_i915_gem_object *obj,
> >  
> > vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
> >  
> > -   /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
> 
> Although flush by some definition here is invalidate + flush
> I see flush operations as the operation to be performed at the "end-of-frame".
> After the operation was done and whatever had to be modified was modified.
> 
> I see you patch changing the flush to the creation and begin of the fb 
> handling
> like on creating and init fb functions. I believe by that time we are not 
> ready
> to exit PSR yet.
> 
> What am I missing?


The functions that you are referring to call
i915_gem_object_pin_to_display_plane() which in turn calls frontbuffer
flush. This patch is just a refactor, doesn't change whether flush() is
called. I am trying to move it up the call stack so that flush() can be
selectively removed depending on the call site.




> 
> > __i915_gem_object_flush_for_display(obj);
> > -   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> >  
> > /* It should now be out of any other write domains, and we can update
> >  * the domain values for our changes.
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 331084082545..91ce8a0522a3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2858,6 +2858,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > *intel_crtc,
> > return;
> > }
> >  
> > +   obj = intel_fb_obj(fb);
> > +   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > +
> > plane_state->src_x = 0;
> > plane_state->src_y = 0;
> > plane_state->src_w = fb->width << 16;
> > @@ -2871,7 +2874,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > *intel_crtc,
> > intel_state->base.src = drm_plane_state_src(plane_state);
> > intel_state->base.dst = drm_plane_state_dest(plane_state);
> >  
> > -   obj = intel_fb_obj(fb);
> > if (i915_gem_object_is_tiled(obj))
> > dev_priv->preserve_bios_swizzle = true;
> >  
> > @@ -12785,6 +12787,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> > if (ret)
> > return ret;
> >  
> > +   intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> > +
> > if (!new_state->fence) { /* implicit fencing */
> > struct dma_fence *fence;
> >  
> > @@ -13172,8 +13176,9 @@ intel_legacy_cursor_update(struct drm_plane *plane,
> > if (ret)
> > goto out_unlock;
> >  
> > -   old_fb = old_plane_state->fb;
> > +   intel_fb_obj_flush(intel_fb_obj(fb), 

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

[Chris Wilson]

Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19)
> DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor
> plane MMIOs are written to. But this flush should not be necessary for
> PSR as hardware tracking triggers PSR exit when MMIOs are written. As
> for FBC, the spec says "Flips or changes to plane size and panning" cause
> FBC to be nuked. Use origin == ORIGIN_FLIP so that features can ignore
> cursor updates in their frontbuffer_flush implementations.
> 
>  /sys/kernel/debug/dri/0/i915_fbc_status shows
> "Compressing: yes" when I move the cursor around.
> 
> v3: Use ORIGIN_FLIP now that pin_to_display does not flush frontbuffer.
> v2: Update comment in i915_gem_object_pin_to_display_plane. (Chris)
> 
> Cc: Paulo Zanoni 
> Cc: Ville Syrjälä 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 91ce8a0522a3..18b08e263ee1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13176,7 +13176,7 @@ intel_legacy_cursor_update(struct drm_plane *plane,
> if (ret)
> goto out_unlock;
>  
> -   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
> +   intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_FLIP);

What about prepare_plane? That should reduce to ORIGIN_FLIP as well,
aiui.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

[Chris Wilson]

Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.

Signed-off-by: Chris Wilson 
---
 tests/Makefile.am  |   2 +-
 tests/Makefile.sources |   1 +
 tests/gem_ctx_freq.c   | 190 +
 tests/meson.build  |   1 +
 4 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 tests/gem_ctx_freq.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index edd689a4..f42641f6 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -104,6 +104,7 @@ drm_import_export_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 drm_import_export_LDADD = $(LDADD) -lpthread
 gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
+gem_ctx_freq_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
@@ -128,7 +129,6 @@ prime_self_import_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 prime_self_import_LDADD = $(LDADD) -lpthread
 gem_userptr_blits_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_userptr_blits_LDADD = $(LDADD) -lpthread
-perf_pmu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 
 gem_wait_LDADD = $(LDADD) -lrt
 kms_flip_LDADD = $(LDADD) -lrt -lpthread
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 05cdc1ef..06e729ef 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -59,6 +59,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_freq \
gem_ctx_isolation \
gem_ctx_param \
gem_ctx_shared \
diff --git a/tests/gem_ctx_freq.c b/tests/gem_ctx_freq.c
new file mode 100644
index ..a01ce01b
--- /dev/null
+++ b/tests/gem_ctx_freq.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_perf.h"
+
+#define LOCAL_CONTEXT_PARAM_FREQUENCY 8
+
+static void set_freq(int fd, uint32_t ctx, uint32_t min, uint32_t max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   .value = (uint64_t)max << 32 | min,
+   };
+
+   gem_context_set_param(fd, );
+}
+
+static void get_freq(int fd, uint32_t ctx, uint32_t *min, uint32_t *max)
+{
+   struct drm_i915_gem_context_param param = {
+   .ctx_id = ctx,
+   .param = LOCAL_CONTEXT_PARAM_FREQUENCY,
+   };
+
+   gem_context_get_param(fd, );
+
+   *min = param.value & 0x;
+   *max = param.value >> 32;
+}
+
+static double measure_frequency(int pmu, int delay)
+{
+   uint64_t data[2];
+   uint64_t d_t, d_v;
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v = -data[0];
+   d_t = -data[1];
+
+   usleep(delay);
+
+   igt_assert_eq(read(pmu, data, sizeof(data)), sizeof(data));
+   d_v += data[0];
+   d_t += data[1];
+
+   return d_v * 1e9 / d_t;
+}
+
+static void single(int fd, const struct intel_execution_engine *e)
+{
+   const unsigned int engine = e->exec_id | e->flags;
+   uint32_t ctx = gem_context_create(fd);
+   uint32_t min, max;
+   double measured;
+   igt_spin_t *spin;
+   int pmu;
+
+   get_freq(fd, ctx, , );
+   igt_info("Min freq: %dMHz; Max freq: %dMHz\n", min, max);
+
+   pmu = perf_i915_open(I915_PMU_REQUESTED_FREQUENCY);
+   igt_require(pmu >= 0);
+
+   gem_quiescent_gpu(fd);
+   measured = measure_frequency(pmu, 1);
+   igt_info("Initial (idle) freq: 

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add Wa_2201832410

[Rafael Antognolli]

Matches bspec.

Reviewed-by: Rafael Antognolli 

On Wed, Mar 07, 2018 at 02:09:12PM -0800, Rodrigo Vivi wrote:
> "Clock gating bug in GWL may not clear barrier state when an EOT
> is received, causing a hang the next time that barrier is used."
> 
> HSDES: 2201832410
> 
> Cc: Rafael Antognolli 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 3 +++
>  drivers/gpu/drm/i915/intel_pm.c | 5 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4787d9bf58b9..e6a8c0ee7df1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3965,6 +3965,9 @@ enum {
>  #define  SARBUNIT_CLKGATE_DIS(1 << 5)
>  #define  RCCUNIT_CLKGATE_DIS (1 << 7)
>  
> +#define SUBSLICE_UNIT_LEVEL_CLKGATE  _MMIO(0x9524)
> +#define  GWUNIT_CLKGATE_DIS  (1 << 16)
> +
>  #define UNSLICE_UNIT_LEVEL_CLKGATE   _MMIO(0x9434)
>  #define  VFUNIT_CLKGATE_DIS  (1 << 20)
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 6cab20ce167a..b8da4dcdd584 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8522,6 +8522,11 @@ static void cnl_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>   val |= SARBUNIT_CLKGATE_DIS;
>   I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
>  
> + /* Wa_2201832410:cnl */
> + val = I915_READ(SUBSLICE_UNIT_LEVEL_CLKGATE);
> + val |= GWUNIT_CLKGATE_DIS;
> + I915_WRITE(SUBSLICE_UNIT_LEVEL_CLKGATE, val);
> +
>   /* WaDisableVFclkgate:cnl */
>   /* WaVFUnitClockGatingDisable:cnl */
>   val = I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE);
> -- 
> 2.13.6
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

[Rodrigo Vivi]

On Tue, Mar 06, 2018 at 07:34:18PM -0800, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran" 
> 
> i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to
> DIRTYFB. The callers however are at a vantage point to decide if hardware
> frontbuffer tracking can do the flush for us. For example, legacy cursor
> updates, like flips, write to MMIO registers, which then triggers PSR flush
> by the hardware. Moving frontbuffer_flush out will enable us to skip a
> software initiated flush by setting origin to FLIP. Thanks to Chris for the
> idea.
> 
> v2:
> Rebased due to Ville adding intel_plane_pin_fb().
> Minor code reordering as fb_obj_flush doesn't need struct_mutex (Chris)
> 
> Cc: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Paulo Zanoni 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_gem.c  | 9 -
>  drivers/gpu/drm/i915/intel_display.c | 9 +++--
>  drivers/gpu/drm/i915/intel_fbdev.c   | 5 +++--
>  drivers/gpu/drm/i915/intel_overlay.c | 1 +
>  4 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a5bd07338b46..e4c5a1a22d8b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4071,9 +4071,10 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
> void *data,
>  }
>  
>  /*
> - * Prepare buffer for display plane (scanout, cursors, etc).
> - * Can be called from an uninterruptible phase (modesetting) and allows
> - * any flushes to be pipelined (for pageflips).
> + * Prepare buffer for display plane (scanout, cursors, etc). Can be called 
> from
> + * an uninterruptible phase (modesetting) and allows any flushes to be 
> pipelined
> + * (for pageflips). We only flush the caches while preparing the buffer for
> + * display, the callers are responsible for frontbuffer flush.
>   */
>  struct i915_vma *
>  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
> @@ -4129,9 +4130,7 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>  
>   vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
>  
> - /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */

Although flush by some definition here is invalidate + flush
I see flush operations as the operation to be performed at the "end-of-frame".
After the operation was done and whatever had to be modified was modified.

I see you patch changing the flush to the creation and begin of the fb handling
like on creating and init fb functions. I believe by that time we are not ready
to exit PSR yet.

What am I missing?

>   __i915_gem_object_flush_for_display(obj);
> - intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
>  
>   /* It should now be out of any other write domains, and we can update
>* the domain values for our changes.
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 331084082545..91ce8a0522a3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2858,6 +2858,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>   return;
>   }
>  
> + obj = intel_fb_obj(fb);
> + intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> +
>   plane_state->src_x = 0;
>   plane_state->src_y = 0;
>   plane_state->src_w = fb->width << 16;
> @@ -2871,7 +2874,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>   intel_state->base.src = drm_plane_state_src(plane_state);
>   intel_state->base.dst = drm_plane_state_dest(plane_state);
>  
> - obj = intel_fb_obj(fb);
>   if (i915_gem_object_is_tiled(obj))
>   dev_priv->preserve_bios_swizzle = true;
>  
> @@ -12785,6 +12787,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
>   if (ret)
>   return ret;
>  
> + intel_fb_obj_flush(obj, ORIGIN_DIRTYFB);
> +
>   if (!new_state->fence) { /* implicit fencing */
>   struct dma_fence *fence;
>  
> @@ -13172,8 +13176,9 @@ intel_legacy_cursor_update(struct drm_plane *plane,
>   if (ret)
>   goto out_unlock;
>  
> - old_fb = old_plane_state->fb;
> + intel_fb_obj_flush(intel_fb_obj(fb), ORIGIN_DIRTYFB);
>  
> + old_fb = old_plane_state->fb;
>   i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(fb),
> intel_plane->frontbuffer_bit);
>  
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 6f12adc06365..65a3313723c9 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -221,6 +221,9 @@ static int intelfb_create(struct drm_fb_helper *helper,
>   goto out_unlock;
>   }
>  
> + fb = >fb->base;
> + 

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Pandiyan, Dhinakaran]

On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
> Similar to enable_fbc, enable_psr was ignored at runtime if it was
> changed. The easiest fix is to pretend enable_psr is ignored at
> configure time, and never activate it for !enable_psr, so both cases
> are handled without modesets.

What about cases where psr_flush() is not called and consequently the
module parameter is not checked? With HW tracking, PSR is
enabled/disabled during modeset and the hardware is expected to exit and
activate PSR without driver intervention.


> Signed-off-by: Maarten Lankhorst 
> Tested-by: Benjamin Berg 
> Cc: Benjamin Berg 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 23175c5c4a50..ac3ce7a1c2a7 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -502,11 +502,6 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>   if (!CAN_PSR(dev_priv))
>   return;
>  
> - if (!i915_modparams.enable_psr) {
> - DRM_DEBUG_KMS("PSR disable by flag\n");
> - return;
> - }
> -
>   /*
>* HSW spec explicitly says PSR is tied to port A.
>* BDW+ platforms with DDI implementation of PSR have different
> @@ -559,7 +554,10 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>  
>   crtc_state->has_psr = true;
>   crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
> - DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
> + if (i915_modparams.enable_psr)
> + DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : 
> "");
> + else
> + DRM_DEBUG_KMS("PSR disable by flag\n");
>  }
>  
>  static void intel_psr_activate(struct intel_dp *intel_dp)
> @@ -652,7 +650,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   dev_priv->psr.enable_source(intel_dp, crtc_state);
>   dev_priv->psr.enabled = intel_dp;
>  
> - if (INTEL_GEN(dev_priv) >= 9) {
> + if (!i915_modparams.enable_psr) {
> + DRM_DEBUG_KMS("PSR disable by flag\n");
> + } else if (INTEL_GEN(dev_priv) >= 9) {
>   intel_psr_activate(intel_dp);
>   } else {
>   /*
> @@ -843,7 +843,7 @@ static void intel_psr_work(struct work_struct *work)
>* recheck. Since psr_flush first clears this and then reschedules we
>* won't ever miss a flush when bailing out here.
>*/
> - if (dev_priv->psr.busy_frontbuffer_bits)
> + if (dev_priv->psr.busy_frontbuffer_bits || !i915_modparams.enable_psr)
>   goto unlock;
>  
>   intel_psr_activate(intel_dp);
> @@ -1015,7 +1015,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   return;
>  
>   mutex_lock(_priv->psr.lock);
> - if (!dev_priv->psr.enabled) {
> + if (!dev_priv->psr.enabled || !i915_modparams.enable_psr) {
> + intel_psr_exit(dev_priv);
>   mutex_unlock(_priv->psr.lock);
>   return;
>   }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Manasi Navare]

On Wed, Mar 07, 2018 at 02:06:08PM -0800, Rodrigo Vivi wrote:
> On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> > > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
> > > > 
> > > > 
> > > > 
> > > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com 
> > > > > wrote:
> > > > > > From: Matt Atwood 
> > > > > > 
> > > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme 
> > > > > > from 8
> > > > > > bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, 
> > > > > > for
> > > > > > panels that use this new feature, this would cause a wait interval 
> > > > > > for
> > > > > > clock recovery of at least 512 ms, much higher then spec maximum of 
> > > > > > 16 ms.
> > > > > > This behavior is described in table 2-158 of DP 1.4 spec address 
> > > > > > Eh.
> > > > > > To avoid breaking panels 
> > > > 
> > > > See comment below:
> > > > 
> > > > > that are not spec compliant we now warn on
> > > > > > invalid values.
> > > > > > 
> > > > > > V2: commit title/message, masking all 7 bits, warn on out of spec 
> > > > > > values.
> > > > > 
> > > > > this approach is even better imho.
> > > > > 
> > > > > > 
> > > > > > Signed-off-by: Matt Atwood 
> > > > > 
> > > > > Reviewed-by: Rodrigo Vivi 
> > > > > 
> > > > > > ---
> > > > > >  drivers/gpu/drm/drm_dp_helper.c | 18 ++
> > > > > >  include/drm/drm_dp_helper.h |  1 +
> > > > > >  2 files changed, 15 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > > > index adf79be..a718ccc 100644
> > > > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > > > @@ -119,18 +119,28 @@ u8 
> > > > > > drm_dp_get_adjust_request_pre_emphasis(const u8 
> > > > > > link_status[DP_LINK_STATUS_SI
> > > > > >  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> > > > > >  
> > > > > >  void drm_dp_link_train_clock_recovery_delay(const u8 
> > > > > > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > > > > > -   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > > > > > +   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> > > > > > DP_TRAINING_AUX_RD_MASK;
> > > > > > +
> > > > > > +   if (rd_interval > 4)
> > > > > > +   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> > > > > > rd_interval);
> > > > 
> > > > Some default for panels without a valid value?
> > > > rd_interval = 4;
> > > > "AUX read interval out of range, using max %d ms"
> > > >
> > > 
> > > The problem with setting the upper bound to 4 is that there are panels
> > > that do not follow the spec and expect a longer than 16 ms delay. So
> > > if we set the upper bound to 4 in those cases the panels might not work.
> > > 
> > > So we decided to go with this approach where we tell the users that panel 
> > > is requesting
> > > out of range AUX value but then set it to the value * 4 in the else part.
> > > 
> > 
> > Thanks for the clarification. My concern is if the DPCD is advertizing
> > an out of spec value, it might as well be advertizing a delay that the
> > panel doesn't need. And I thought panel quirks were supposed to be used
> > for working around things like this. To be clear, this is not a big
> > enough concern to block this fix.
> > 
> > Like I said in the other email, this patch refers to DP 1.4, shouldn't
> > the clock recovery delay be updated too (in a separate patch)?
> 
> We clearly need more work here.
> 
> I can see here on DP-v1.2a_d11:
> 
> 00h = 100us for the Main Link Clock Recovery phase 400us for the Main Link 
> Channel
> Equalization phase and for FAUX training.
> 01h = 4ms all.
> 02h = 8ms all.
> 03h = 12ms all.
> 04h = 16ms all.
> 
> So probably the initial mask on this patch should be marked with /* XXX 1.2? 
> */
> because it clearly got introduced in some 1.2 minor release.
> 
> But even for DP 1.2 it doesn't seem we are doing it right on the 0 case.
> It seems that we are using 100us for both channel eq and clock recovery, 
> right?
> or am I missing something?
> 
> Then DP 1.3 keeps same config.
> 
> But DP 1.4 change all values.
> 
> clock recovery is always 100us and channel eq is depending on this bit * 4 
> and 400us when bit is zeroed.
> 
> But limited to 4.
> 
> So we probably need 3 patches here:
> 1. - This one to protect against bad panels masking it and mentioning DP 1.2,
>  nor 1.3 or 1.4. Also limiting rd_interval to 4 as DK suggested. Panels 
> cannot
>  expect all drivers are using this value * 4 blindly since it is not on 
> spec.

So if some panels still expect a greater delay, those will fail link training. 
But
yes if we want them to be 

[Intel-gfx] [PATCH] drm/i915/cnl: Add Wa_2201832410

[Rodrigo Vivi]

"Clock gating bug in GWL may not clear barrier state when an EOT
is received, causing a hang the next time that barrier is used."

HSDES: 2201832410

Cc: Rafael Antognolli 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_pm.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4787d9bf58b9..e6a8c0ee7df1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3965,6 +3965,9 @@ enum {
 #define  SARBUNIT_CLKGATE_DIS  (1 << 5)
 #define  RCCUNIT_CLKGATE_DIS   (1 << 7)
 
+#define SUBSLICE_UNIT_LEVEL_CLKGATE_MMIO(0x9524)
+#define  GWUNIT_CLKGATE_DIS(1 << 16)
+
 #define UNSLICE_UNIT_LEVEL_CLKGATE _MMIO(0x9434)
 #define  VFUNIT_CLKGATE_DIS(1 << 20)
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6cab20ce167a..b8da4dcdd584 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8522,6 +8522,11 @@ static void cnl_init_clock_gating(struct 
drm_i915_private *dev_priv)
val |= SARBUNIT_CLKGATE_DIS;
I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
 
+   /* Wa_2201832410:cnl */
+   val = I915_READ(SUBSLICE_UNIT_LEVEL_CLKGATE);
+   val |= GWUNIT_CLKGATE_DIS;
+   I915_WRITE(SUBSLICE_UNIT_LEVEL_CLKGATE, val);
+
/* WaDisableVFclkgate:cnl */
/* WaVFUnitClockGatingDisable:cnl */
val = I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE);
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Rodrigo Vivi]

On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote:
> > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote:
> > > 
> > > 
> > > 
> > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote:
> > > > On Tue, Mar 06, 2018 at 10:37:48AM -0800, matthew.s.atw...@intel.com 
> > > > wrote:
> > > > > From: Matt Atwood 
> > > > > 
> > > > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheme from 8
> > > > > bits to 7 bits in DPCD 0x000e. The 8th bit describes a new feature, 
> > > > > for
> > > > > panels that use this new feature, this would cause a wait interval for
> > > > > clock recovery of at least 512 ms, much higher then spec maximum of 
> > > > > 16 ms.
> > > > > This behavior is described in table 2-158 of DP 1.4 spec address 
> > > > > Eh.
> > > > > To avoid breaking panels 
> > > 
> > > See comment below:
> > > 
> > > > that are not spec compliant we now warn on
> > > > > invalid values.
> > > > > 
> > > > > V2: commit title/message, masking all 7 bits, warn on out of spec 
> > > > > values.
> > > > 
> > > > this approach is even better imho.
> > > > 
> > > > > 
> > > > > Signed-off-by: Matt Atwood 
> > > > 
> > > > Reviewed-by: Rodrigo Vivi 
> > > > 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_dp_helper.c | 18 ++
> > > > >  include/drm/drm_dp_helper.h |  1 +
> > > > >  2 files changed, 15 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > > index adf79be..a718ccc 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > > @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const 
> > > > > u8 link_status[DP_LINK_STATUS_SI
> > > > >  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
> > > > >  
> > > > >  void drm_dp_link_train_clock_recovery_delay(const u8 
> > > > > dpcd[DP_RECEIVER_CAP_SIZE]) {
> > > > > - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> > > > > + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> > > > > DP_TRAINING_AUX_RD_MASK;
> > > > > +
> > > > > + if (rd_interval > 4)
> > > > > + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)", 
> > > > > rd_interval);
> > > 
> > > Some default for panels without a valid value?
> > >   rd_interval = 4;
> > >   "AUX read interval out of range, using max %d ms"
> > >
> > 
> > The problem with setting the upper bound to 4 is that there are panels
> > that do not follow the spec and expect a longer than 16 ms delay. So
> > if we set the upper bound to 4 in those cases the panels might not work.
> > 
> > So we decided to go with this approach where we tell the users that panel 
> > is requesting
> > out of range AUX value but then set it to the value * 4 in the else part.
> > 
> 
> Thanks for the clarification. My concern is if the DPCD is advertizing
> an out of spec value, it might as well be advertizing a delay that the
> panel doesn't need. And I thought panel quirks were supposed to be used
> for working around things like this. To be clear, this is not a big
> enough concern to block this fix.
> 
> Like I said in the other email, this patch refers to DP 1.4, shouldn't
> the clock recovery delay be updated too (in a separate patch)?

We clearly need more work here.

I can see here on DP-v1.2a_d11:

00h = 100us for the Main Link Clock Recovery phase 400us for the Main Link 
Channel
Equalization phase and for FAUX training.
01h = 4ms all.
02h = 8ms all.
03h = 12ms all.
04h = 16ms all.

So probably the initial mask on this patch should be marked with /* XXX 1.2? */
because it clearly got introduced in some 1.2 minor release.

But even for DP 1.2 it doesn't seem we are doing it right on the 0 case.
It seems that we are using 100us for both channel eq and clock recovery, right?
or am I missing something?

Then DP 1.3 keeps same config.

But DP 1.4 change all values.

clock recovery is always 100us and channel eq is depending on this bit * 4 and 
400us when bit is zeroed.

But limited to 4.

So we probably need 3 patches here:
1. - This one to protect against bad panels masking it and mentioning DP 1.2,
 nor 1.3 or 1.4. Also limiting rd_interval to 4 as DK suggested. Panels 
cannot
 expect all drivers are using this value * 4 blindly since it is not on 
spec.
2. - Fix channel eq for 0 case since 1.2. It should be 400us.
3. - For DP version >= 1.4 always use 100us for clock req or follow this 
register for
 channel eq.

Thoughts?

> 
> 
> > Manasi
> >  
> > > 
> > > > > +
> > > > > + if (rd_interval == 0)
> > > > >   udelay(100);
> > > > >   else
> > > > > - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> > > > > + mdelay(rd_interval * 4);
> > > > >  }
> > > 

Re: [Intel-gfx] [PATCH] drm/i915: Kill the remaining CHV HBR2 leftovers

[Pandiyan, Dhinakaran]

On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> AFAIK CHV was supposed to have HBR2 originally, but in the end the feature
> was dropped. We still have some code leftovers from those early days.
> Eliminate them.
> 

Not much in the spec about HBR2 other than the support for TP3. Since we
don't support HBR2 on CHV, removing the unused TPS3 bits looks correct.



> The extra bit for the training pattern seems to be dead in the hardware.
> I can set it (in fact I can set almost any reserved bit in the
> registers) but it doesn't seem to interfere with the operation of the
> hardware. Either that or I'm very lucky that my displays complete link
> training with the incorrect pattern being sent out.
> 

I don't think I follow this, are you saying there's no need to clear the
TPS3 bit? Isn't it better to have the mask include 1 << 14, so that
_intel_dp_set_link_train() clears the bit?



> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 --
>  drivers/gpu/drm/i915/intel_dp.c | 20 
>  2 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 95a2e51ecbb0..f3efc242df2d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5250,8 +5250,6 @@ enum {
>  #define   DP_LINK_TRAIN_OFF  (3 << 28)
>  #define   DP_LINK_TRAIN_MASK (3 << 28)
>  #define   DP_LINK_TRAIN_SHIFT28
> -#define   DP_LINK_TRAIN_PAT_3_CHV(1 << 14)
> -#define   DP_LINK_TRAIN_MASK_CHV ((3 << 28)|(1<<14))
>  
>  /* CPT Link training mode */
>  #define   DP_LINK_TRAIN_PAT_1_CPT(0 << 8)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index aba2f45819d8..df1772044208 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -92,8 +92,6 @@ static const struct dp_link_dpll chv_dpll[] = {
>   { .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } },
>   { 27,   /* m2_int = 27, m2_fraction = 0 */
>   { .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } },
> - { 54,   /* m2_int = 27, m2_fraction = 0 */
> - { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
>  };
>  
>  /**
> @@ -2908,10 +2906,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
>   }
>  
>   } else {
> - if (IS_CHERRYVIEW(dev_priv))
> - *DP &= ~DP_LINK_TRAIN_MASK_CHV;
> - else
> - *DP &= ~DP_LINK_TRAIN_MASK;
> + *DP &= ~DP_LINK_TRAIN_MASK;
>  
>   switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
>   case DP_TRAINING_PATTERN_DISABLE:
> @@ -2924,12 +2919,8 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
>   *DP |= DP_LINK_TRAIN_PAT_2;
>   break;
>   case DP_TRAINING_PATTERN_3:
> - if (IS_CHERRYVIEW(dev_priv)) {
> - *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> - } else {
> - DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
> instead\n");
> - *DP |= DP_LINK_TRAIN_PAT_2;
> - }
> + DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
> instead\n");
> + *DP |= DP_LINK_TRAIN_PAT_2;
>   break;
>   }
>   }
> @@ -3668,10 +3659,7 @@ intel_dp_link_down(struct intel_encoder *encoder,
>   DP &= ~DP_LINK_TRAIN_MASK_CPT;
>   DP |= DP_LINK_TRAIN_PAT_IDLE_CPT;
>   } else {
> - if (IS_CHERRYVIEW(dev_priv))
> - DP &= ~DP_LINK_TRAIN_MASK_CHV;
> - else
> - DP &= ~DP_LINK_TRAIN_MASK;
> + DP &= ~DP_LINK_TRAIN_MASK;
>   DP |= DP_LINK_TRAIN_PAT_IDLE;
>   }
>   I915_WRITE(intel_dp->output_reg, DP);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Add Wa_2201832410

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add Wa_2201832410
URL   : https://patchwork.freedesktop.org/series/39408/
State : failure

== Summary ==

Applying: drm/i915/cnl: Add Wa_2201832410
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/cnl: Add Wa_2201832410
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: store all mmio bases in intel_engines

[Patchwork]

== Series Details ==

Series: drm/i915: store all mmio bases in intel_engines
URL   : https://patchwork.freedesktop.org/series/39556/
State : success

== Summary ==

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
fail   -> PASS   (shard-apl) fdo#101623
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3381 pass:1780 dwarn:1   dfail:0   fail:7   skip:1591 
time:11800s
shard-hswtotal:3467 pass:1771 dwarn:1   dfail:0   fail:3   skip:1691 
time:11892s
shard-snbtotal:3467 pass:1363 dwarn:2   dfail:0   fail:1   skip:2101 
time:7027s
Blacklisted hosts:
shard-kbltotal:3467 pass:1899 dwarn:26  dfail:1   fail:8   skip:1533 
time:9186s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915: Disable preemption and sleeping 
while using the punit sideband
URL   : https://patchwork.freedesktop.org/series/39555/
State : warning

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
pass   -> SKIP   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341 +1
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-fencing:
pass   -> FAIL   (shard-apl) fdo#103207
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +4
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test kms_vblank:
Subgroup pipe-a-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583

shard-apltotal:3381 pass:1777 dwarn:3   dfail:0   fail:8   skip:1591 
time:11918s
shard-hswtotal:3467 pass:1769 dwarn:1   dfail:0   fail:4   skip:1692 
time:11894s
shard-snbtotal:3467 pass:1361 dwarn:2   dfail:0   fail:3   skip:2101 
time:6970s
Blacklisted hosts:
shard-kbltotal:3316 pass:1821 dwarn:19  dfail:0   fail:8   skip:1466 
time:8725s

== Logs ==

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

Re: [Intel-gfx] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

[Adam Jackson]

On Wed, 2018-03-07 at 07:46 -0800, Rodrigo Vivi wrote:
> Copied from Mesa with no modifications.
> 
> Gives us Geminilake and Kaby Lake platform names updates and
> sync on Coffee Lake PCI IDs.
> 
> Cc: Timo Aaltonen 
> Signed-off-by: Rodrigo Vivi 

Merged, thanks:

remote: I: patch #208689 updated using rev 
90e0cdd42dfda2accfadffa5c550712696902e14.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   43576b901..90e0cdd42  master -> master

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

Re: [Intel-gfx] vlv punit and sideband tidy

[Rogozhkin, Dmitry V]

On Wed, 2018-03-07 at 19:41 +, Chris Wilson wrote:
> Mika
> believes that if we keep the cpu in C0 whilst the gpu is busy, then
> it
> behaves much better -- but that is a very tough sell

Chris, Mika, I wonder does i915 driver tries to keep CPU in C0 at the
moment already or you just consider this? If it is doing anything to
CPU while gpu is busy, could you, please, clarify what exactly and
point me to the code/key patches? Please, answer from BDW/SKL gen
perspective rather than VLV.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: store all mmio bases in intel_engines

[Patchwork]

== Series Details ==

Series: drm/i915: store all mmio bases in intel_engines
URL   : https://patchwork.freedesktop.org/series/39556/
State : success

== Summary ==

Series 39556v1 drm/i915: store all mmio bases in intel_engines
https://patchwork.freedesktop.org/api/1.0/series/39556/revisions/1/mbox/

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#104108

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:428s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:502s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:480s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:507s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:287s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:518s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:532s
fi-skl-6700k2total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:496s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:525s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s

73d5ac42e64ff83e10989dd5fe0cd82070a78d3b drm-tip: 2018y-03m-07d-18h-48m-39s UTC 
integration manifest
631f6d0764f1 drm/i915: store all mmio bases in intel_engines

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915: Disable preemption and sleeping 
while using the punit sideband
URL   : https://patchwork.freedesktop.org/series/39555/
State : success

== Summary ==

Series 39555v1 series starting with [01/10] drm/i915: Disable preemption and 
sleeping while using the punit sideband
https://patchwork.freedesktop.org/api/1.0/series/39555/revisions/1/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:511s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:481s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:509s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:469s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:525s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:423s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:521s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s

73d5ac42e64ff83e10989dd5fe0cd82070a78d3b drm-tip: 2018y-03m-07d-18h-48m-39s UTC 
integration manifest
a7a9e1e325b4 drm/i915: Move sandybride pcode access to intel_sideband.c
d12473821321 drm/i915: Merge sandybridge_pcode_(read|write)
b10cb74b0527 drm/i915: Merge sbi read/write into a single accessor
63631b4f5471 drm/i915: Separate sideband declarations to intel_sideband.h
5d12dc0c771a drm/i915: Replace pcu_lock with sb_lock
1ef581a7e9ce Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail 
v3"
a87d0c97d0bd drm/i915: Reduce RPS update frequency on Valleyview/Cherryview
03181469e7e9 drm/i915: Lift sideband locking for vlv_punit_(read|write)
2eff43aedb58 drm/i915: Lift acquiring the vlv punit magic to a common sb-get
8cbb0d7b87e5 drm/i915: Disable preemption and sleeping while using the punit 
sideband

== Logs ==

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

Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-03-07 19:45:15)
> The mmio bases we're currently storing in the intel_engines array are
> only valid for a subset of gens, so we need to ignore them and use
> different values in some cases. Instead of doing that, we can have a
> table of [starting gen, mmio base] pairs for each engine in
> intel_engines and select the correct one based on the gen we're running
> on in a consistent way.
> 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c  | 77 
> +
>  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
>  2 files changed, 49 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 4ba139c27fba..1dd92cac8d67 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -81,12 +81,16 @@ static const struct engine_class_info 
> intel_engine_classes[] = {
> },
>  };
>  
> +#define MAX_MMIO_BASES 3
>  struct engine_info {
> unsigned int hw_id;
> unsigned int uabi_id;
> u8 class;
> u8 instance;
> -   u32 mmio_base;
> +   struct engine_mmio_base {
> +   u32 gen : 8;
> +   u32 base : 24;
> +   } mmio_bases[MAX_MMIO_BASES];

Needs a note to mention the array must be in reverse gen order.

I would even add a selftest just to verify the arrays.

> unsigned irq_shift;
>  };
>  
> @@ -96,7 +100,9 @@ static const struct engine_info intel_engines[] = {
> .uabi_id = I915_EXEC_RENDER,
> .class = RENDER_CLASS,
> .instance = 0,
> -   .mmio_base = RENDER_RING_BASE,
> +   .mmio_bases = {
> +   { .gen = 1, .base = RENDER_RING_BASE }

Even gen0 (i740) has the render ring :)

> +static u32 __engine_mmio_base(struct drm_i915_private *i915,
> + const struct engine_mmio_base* bases)
> +{
> +   int i;
> +
> +   for (i = 0; i < MAX_MMIO_BASES; i++)
> +   if (INTEL_GEN(i915) >= bases[i].gen)
> +   break;
> +
> +   GEM_BUG_ON(i == MAX_MMIO_BASES);
> +   GEM_BUG_ON(!bases[i].base);
> +
> +   return bases[i].base;
> +}
> +
>  static int
>  intel_engine_setup(struct drm_i915_private *dev_priv,
>enum intel_engine_id id)
> @@ -257,25 +296,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
>  class_info->name, info->instance) >=
> sizeof(engine->name));
> engine->hw_id = engine->guc_id = info->hw_id;
> -   if (INTEL_GEN(dev_priv) >= 11) {
> -   switch (engine->id) {
> -   case VCS:
> -   engine->mmio_base = GEN11_BSD_RING_BASE;
> -   break;
> -   case VCS2:
> -   engine->mmio_base = GEN11_BSD2_RING_BASE;
> -   break;
> -   case VECS:
> -   engine->mmio_base = GEN11_VEBOX_RING_BASE;
> -   break;
> -   default:
> -   /* take the original value for all other engines  */
> -   engine->mmio_base = info->mmio_base;
> -   break;
> -   }
> -   } else {
> -   engine->mmio_base = info->mmio_base;
> -   }
> +   engine->mmio_base = __engine_mmio_base(dev_priv, info->mmio_bases);
> engine->irq_shift = info->irq_shift;
> engine->class = info->class;
> engine->instance = info->instance;

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

[Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

[Daniele Ceraolo Spurio]

The mmio bases we're currently storing in the intel_engines array are
only valid for a subset of gens, so we need to ignore them and use
different values in some cases. Instead of doing that, we can have a
table of [starting gen, mmio base] pairs for each engine in
intel_engines and select the correct one based on the gen we're running
on in a consistent way.

Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 77 +
 drivers/gpu/drm/i915/intel_ringbuffer.c |  1 -
 2 files changed, 49 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..1dd92cac8d67 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -81,12 +81,16 @@ static const struct engine_class_info 
intel_engine_classes[] = {
},
 };
 
+#define MAX_MMIO_BASES 3
 struct engine_info {
unsigned int hw_id;
unsigned int uabi_id;
u8 class;
u8 instance;
-   u32 mmio_base;
+   struct engine_mmio_base {
+   u32 gen : 8;
+   u32 base : 24;
+   } mmio_bases[MAX_MMIO_BASES];
unsigned irq_shift;
 };
 
@@ -96,7 +100,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
.instance = 0,
-   .mmio_base = RENDER_RING_BASE,
+   .mmio_bases = {
+   { .gen = 1, .base = RENDER_RING_BASE }
+   },
.irq_shift = GEN8_RCS_IRQ_SHIFT,
},
[BCS] = {
@@ -104,7 +110,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
.instance = 0,
-   .mmio_base = BLT_RING_BASE,
+   .mmio_bases = {
+   { .gen = 6, .base = BLT_RING_BASE }
+   },
.irq_shift = GEN8_BCS_IRQ_SHIFT,
},
[VCS] = {
@@ -112,7 +120,11 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 0,
-   .mmio_base = GEN6_BSD_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD_RING_BASE },
+   { .gen = 6, .base = GEN6_BSD_RING_BASE },
+   { .gen = 4, .base = BSD_RING_BASE }
+   },
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
},
[VCS2] = {
@@ -120,7 +132,10 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 1,
-   .mmio_base = GEN8_BSD2_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD2_RING_BASE },
+   { .gen = 8, .base = GEN8_BSD2_RING_BASE }
+   },
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
},
[VCS3] = {
@@ -128,7 +143,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 2,
-   .mmio_base = GEN11_BSD3_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD3_RING_BASE }
+   },
.irq_shift = 0, /* not used */
},
[VCS4] = {
@@ -136,7 +153,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 3,
-   .mmio_base = GEN11_BSD4_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_BSD4_RING_BASE }
+   },
.irq_shift = 0, /* not used */
},
[VECS] = {
@@ -144,7 +163,10 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
.instance = 0,
-   .mmio_base = VEBOX_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, .base = GEN11_VEBOX_RING_BASE },
+   { .gen = 7, .base = VEBOX_RING_BASE }
+   },
.irq_shift = GEN8_VECS_IRQ_SHIFT,
},
[VECS2] = {
@@ -152,7 +174,9 @@ static const struct engine_info intel_engines[] = {
.uabi_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
.instance = 1,
-   .mmio_base = GEN11_VEBOX2_RING_BASE,
+   .mmio_bases = {
+   { .gen = 11, 

[Intel-gfx] [PATCH 07/10] drm/i915: Separate sideband declarations to intel_sideband.h

[Chris Wilson]

Split the sideback declarations out of the ginormous i915_drv.h

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +
 drivers/gpu/drm/i915/i915_drv.h | 62 
 drivers/gpu/drm/i915/i915_sysfs.c   |  2 +
 drivers/gpu/drm/i915/intel_cdclk.c  |  1 +
 drivers/gpu/drm/i915/intel_display.c| 19 +
 drivers/gpu/drm/i915/intel_dp.c |  6 ++-
 drivers/gpu/drm/i915/intel_dpio_phy.c   |  1 +
 drivers/gpu/drm/i915/intel_dsi.c|  7 +++-
 drivers/gpu/drm/i915/intel_dsi_pll.c|  4 +-
 drivers/gpu/drm/i915/intel_dsi_vbt.c| 11 +++--
 drivers/gpu/drm/i915/intel_hdmi.c   |  5 ++-
 drivers/gpu/drm/i915/intel_pm.c |  7 +++-
 drivers/gpu/drm/i915/intel_runtime_pm.c |  1 +
 drivers/gpu/drm/i915/intel_sideband.c   |  2 +
 drivers/gpu/drm/i915/intel_sideband.h   | 71 +
 15 files changed, 121 insertions(+), 80 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_sideband.h

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 82b8bfe2940c..9cade1a8baff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -29,8 +29,10 @@
 #include 
 #include 
 #include 
+
 #include "intel_drv.h"
 #include "intel_guc_submission.h"
+#include "intel_sideband.h"
 
 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 61df8c338e20..f421009fe6f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -794,11 +794,6 @@ enum intel_pch {
PCH_NOP,
 };
 
-enum intel_sbi_destination {
-   SBI_ICLK,
-   SBI_MPHY,
-};
-
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
 #define QUIRK_INVERT_BRIGHTNESS (1<<2)
 #define QUIRK_BACKLIGHT_PRESENT (1<<3)
@@ -3766,63 +3761,6 @@ int sandybridge_pcode_write_timeout(struct 
drm_i915_private *dev_priv, u32 mbox,
 int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
  u32 reply_mask, u32 reply, int timeout_base_ms);
 
-/* intel_sideband.c */
-
-enum {
-   VLV_IOSF_SB_BUNIT,
-   VLV_IOSF_SB_CCK,
-   VLV_IOSF_SB_CCU,
-   VLV_IOSF_SB_DPIO,
-   VLV_IOSF_SB_FLISDSI,
-   VLV_IOSF_SB_GPIO,
-   VLV_IOSF_SB_NC,
-   VLV_IOSF_SB_PUNIT,
-};
-
-void vlv_iosf_sb_get(struct drm_i915_private *dev_priv, unsigned long ports);
-u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
-void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
u32 val);
-void vlv_iosf_sb_put(struct drm_i915_private *dev_priv, unsigned long ports);
-
-void vlv_punit_get(struct drm_i915_private *dev_priv);
-u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
-int vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
-void vlv_punit_put(struct drm_i915_private *dev_priv);
-
-void vlv_nc_get(struct drm_i915_private *dev_priv);
-u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
-void vlv_nc_put(struct drm_i915_private *dev_priv);
-
-void vlv_cck_get(struct drm_i915_private *dev_priv);
-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);
-void vlv_cck_put(struct drm_i915_private *dev_priv);
-
-void vlv_ccu_get(struct drm_i915_private *dev_priv);
-u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-void vlv_ccu_put(struct drm_i915_private *dev_priv);
-
-void vlv_bunit_get(struct drm_i915_private *dev_priv);
-u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-void vlv_bunit_put(struct drm_i915_private *dev_priv);
-
-void vlv_dpio_get(struct drm_i915_private *dev_priv);
-u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg);
-void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int 
reg, u32 val);
-void vlv_dpio_put(struct drm_i915_private *dev_priv);
-
-void vlv_flisdsi_get(struct drm_i915_private *dev_priv);
-u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-void vlv_flisdsi_put(struct drm_i915_private *dev_priv);
-
-u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
-  enum intel_sbi_destination destination);
-void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
-enum intel_sbi_destination destination);
-
 /* intel_dpio_phy.c */
 void bxt_port_to_phy_channel(struct drm_i915_private *dev_priv, enum port port,
 enum dpio_phy *phy, enum dpio_channel *ch);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 

[Intel-gfx] [PATCH 09/10] drm/i915: Merge sandybridge_pcode_(read|write)

[Chris Wilson]

These routines are identical except in the nature of the value parameter.
For writes it is a pure in-param, but for a read, we need an out-param.
Since they differ in a single line, merge the two routines into one.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_pm.c | 114 ++--
 1 file changed, 40 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1f1f0eb060c7..cbebf36fdeda 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9155,12 +9155,10 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
}
 }
 
-static inline int gen6_check_mailbox_status(struct drm_i915_private *dev_priv)
+static inline int gen6_check_mailbox_status(struct drm_i915_private *dev_priv,
+   u32 mbox)
 {
-   uint32_t flags =
-   I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_ERROR_MASK;
-
-   switch (flags) {
+   switch (mbox & GEN6_PCODE_ERROR_MASK) {
case GEN6_PCODE_SUCCESS:
return 0;
case GEN6_PCODE_UNIMPLEMENTED_CMD:
@@ -9173,17 +9171,15 @@ static inline int gen6_check_mailbox_status(struct 
drm_i915_private *dev_priv)
case GEN6_PCODE_TIMEOUT:
return -ETIMEDOUT;
default:
-   MISSING_CASE(flags);
+   MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
return 0;
}
 }
 
-static inline int gen7_check_mailbox_status(struct drm_i915_private *dev_priv)
+static inline int gen7_check_mailbox_status(struct drm_i915_private *dev_priv,
+   u32 mbox)
 {
-   uint32_t flags =
-   I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_ERROR_MASK;
-
-   switch (flags) {
+   switch (mbox & GEN6_PCODE_ERROR_MASK) {
case GEN6_PCODE_SUCCESS:
return 0;
case GEN6_PCODE_ILLEGAL_CMD:
@@ -9195,18 +9191,21 @@ static inline int gen7_check_mailbox_status(struct 
drm_i915_private *dev_priv)
case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
return -EOVERFLOW;
default:
-   MISSING_CASE(flags);
+   MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
return 0;
}
 }
 
-static int __sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 
mbox, u32 *val)
+static int __sandybridge_pcode_rw(struct drm_i915_private *dev_priv,
+ u32 mbox, u32 *val,
+ int fast_timeout_us,
+ int slow_timeout_ms,
+ bool is_read)
 {
-   int status;
-
lockdep_assert_held(_priv->sb_lock);
 
-   /* GEN6_PCODE_* are outside of the forcewake domain, we can
+   /*
+* GEN6_PCODE_* are outside of the forcewake domain, we can
 * use te fw I915_READ variants to reduce the amount of work
 * required when reading/writing.
 */
@@ -9220,69 +9219,36 @@ static int __sandybridge_pcode_read(struct 
drm_i915_private *dev_priv, u32 mbox,
 
if (__intel_wait_for_register_fw(dev_priv,
 GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 
0,
-500, 0, NULL))
+fast_timeout_us,
+slow_timeout_ms,
+))
return -ETIMEDOUT;
 
-   *val = I915_READ_FW(GEN6_PCODE_DATA);
-   I915_WRITE_FW(GEN6_PCODE_DATA, 0);
+   if (is_read)
+   *val = I915_READ_FW(GEN6_PCODE_DATA);
 
if (INTEL_GEN(dev_priv) > 6)
-   status = gen7_check_mailbox_status(dev_priv);
+   return gen7_check_mailbox_status(dev_priv, mbox);
else
-   status = gen6_check_mailbox_status(dev_priv);
-
-   return status;
+   return gen6_check_mailbox_status(dev_priv, mbox);
 }
 
 int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 
*val)
 {
-   int status;
+   int err;
 
mutex_lock(_priv->sb_lock);
-   status = __sandybridge_pcode_read(dev_priv, mbox, val);
+   err = __sandybridge_pcode_rw(dev_priv, mbox, val,
+   500, 0,
+   true);
mutex_unlock(_priv->sb_lock);
 
-   if (status) {
+   if (err) {
DRM_DEBUG_DRIVER("warning: pcode (read from mbox %x) mailbox 
access failed for %ps: %d\n",
-mbox, __builtin_return_address(0), status);
+mbox, __builtin_return_address(0), err);
}
 
-   return status;
-}
-
-static int __sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv,
-u32 mbox, u32 val,
-  

[Intel-gfx] [PATCH 10/10] drm/i915: Move sandybride pcode access to intel_sideband.c

[Chris Wilson]

sandybride_pcode is another sideband, so move it to their new home.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   |  10 --
 drivers/gpu/drm/i915/intel_hdcp.c |   3 +-
 drivers/gpu/drm/i915/intel_pm.c   | 194 --
 drivers/gpu/drm/i915/intel_sideband.c | 194 ++
 drivers/gpu/drm/i915/intel_sideband.h |  10 ++
 5 files changed, 206 insertions(+), 205 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f421009fe6f7..9aa22d674eea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3751,16 +3751,6 @@ intel_display_capture_error_state(struct 
drm_i915_private *dev_priv);
 extern void intel_display_print_error_state(struct drm_i915_error_state_buf *e,
struct intel_display_error_state 
*error);
 
-int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 
*val);
-int sandybridge_pcode_write_timeout(struct drm_i915_private *dev_priv, u32 
mbox,
-   u32 val, int fast_timeout_us,
-   int slow_timeout_ms);
-#define sandybridge_pcode_write(dev_priv, mbox, val)   \
-   sandybridge_pcode_write_timeout(dev_priv, mbox, val, 500, 0)
-
-int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
- u32 reply_mask, u32 reply, int timeout_base_ms);
-
 /* intel_dpio_phy.c */
 void bxt_port_to_phy_channel(struct drm_i915_private *dev_priv, enum port port,
 enum dpio_phy *phy, enum dpio_channel *ch);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 81259a4fbdfd..18d06dde3fe5 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -11,8 +11,9 @@
 #include 
 #include 
 
-#include "intel_drv.h"
 #include "i915_reg.h"
+#include "intel_drv.h"
+#include "intel_sideband.h"
 
 #define KEY_LOAD_TRIES 5
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cbebf36fdeda..d04f4559d7da 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9155,200 +9155,6 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
}
 }
 
-static inline int gen6_check_mailbox_status(struct drm_i915_private *dev_priv,
-   u32 mbox)
-{
-   switch (mbox & GEN6_PCODE_ERROR_MASK) {
-   case GEN6_PCODE_SUCCESS:
-   return 0;
-   case GEN6_PCODE_UNIMPLEMENTED_CMD:
-   return -ENODEV;
-   case GEN6_PCODE_ILLEGAL_CMD:
-   return -ENXIO;
-   case GEN6_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
-   case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
-   return -EOVERFLOW;
-   case GEN6_PCODE_TIMEOUT:
-   return -ETIMEDOUT;
-   default:
-   MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
-   return 0;
-   }
-}
-
-static inline int gen7_check_mailbox_status(struct drm_i915_private *dev_priv,
-   u32 mbox)
-{
-   switch (mbox & GEN6_PCODE_ERROR_MASK) {
-   case GEN6_PCODE_SUCCESS:
-   return 0;
-   case GEN6_PCODE_ILLEGAL_CMD:
-   return -ENXIO;
-   case GEN7_PCODE_TIMEOUT:
-   return -ETIMEDOUT;
-   case GEN7_PCODE_ILLEGAL_DATA:
-   return -EINVAL;
-   case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
-   return -EOVERFLOW;
-   default:
-   MISSING_CASE(mbox & GEN6_PCODE_ERROR_MASK);
-   return 0;
-   }
-}
-
-static int __sandybridge_pcode_rw(struct drm_i915_private *dev_priv,
- u32 mbox, u32 *val,
- int fast_timeout_us,
- int slow_timeout_ms,
- bool is_read)
-{
-   lockdep_assert_held(_priv->sb_lock);
-
-   /*
-* GEN6_PCODE_* are outside of the forcewake domain, we can
-* use te fw I915_READ variants to reduce the amount of work
-* required when reading/writing.
-*/
-
-   if (I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_READY)
-   return -EAGAIN;
-
-   I915_WRITE_FW(GEN6_PCODE_DATA, *val);
-   I915_WRITE_FW(GEN6_PCODE_DATA1, 0);
-   I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);
-
-   if (__intel_wait_for_register_fw(dev_priv,
-GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 
0,
-fast_timeout_us,
-slow_timeout_ms,
-))
-   return -ETIMEDOUT;
-
-   if (is_read)
-   *val = I915_READ_FW(GEN6_PCODE_DATA);
-
-   if (INTEL_GEN(dev_priv) > 

[Intel-gfx] [PATCH 06/10] drm/i915: Replace pcu_lock with sb_lock

[Chris Wilson]

We now have two locks for sideband access. The general one covering
sideband access across all generation, sb_lock, and a specific one
covering sideband access via the punit on vlv/chv. After lifting the
sb_lock around the punit into the callers, the pcu_lock is now redudant
and can be separated from its other use to regulate RPS (essentially
giving RPS a lock all of its own).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  55 +-
 drivers/gpu/drm/i915/i915_drv.h |  10 +--
 drivers/gpu/drm/i915/i915_irq.c |   4 +-
 drivers/gpu/drm/i915/i915_sysfs.c   |  40 +-
 drivers/gpu/drm/i915/intel_cdclk.c  |  28 ---
 drivers/gpu/drm/i915/intel_display.c|   6 --
 drivers/gpu/drm/i915/intel_hdcp.c   |   2 -
 drivers/gpu/drm/i915/intel_pm.c | 127 +++-
 drivers/gpu/drm/i915/intel_runtime_pm.c |   8 --
 drivers/gpu/drm/i915/intel_sideband.c   |   4 -
 10 files changed, 104 insertions(+), 180 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 20a6c00a7365..82b8bfe2940c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1074,8 +1074,6 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
u32 rpmodectl, freq_sts;
 
-   mutex_lock(_priv->pcu_lock);
-
rpmodectl = I915_READ(GEN6_RP_CONTROL);
seq_printf(m, "Video Turbo Mode: %s\n",
   yesno(rpmodectl & GEN6_RP_MEDIA_TURBO));
@@ -1110,7 +1108,6 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m,
   "efficient (RPe) frequency: %d MHz\n",
   intel_gpu_freq(dev_priv, rps->efficient_freq));
-   mutex_unlock(_priv->pcu_lock);
} else if (INTEL_GEN(dev_priv) >= 6) {
u32 rp_state_limits;
u32 gt_perf_status;
@@ -1525,12 +1522,9 @@ static int gen6_drpc_info(struct seq_file *m)
gen9_powergate_status = I915_READ(GEN9_PWRGT_DOMAIN_STATUS);
}
 
-   if (INTEL_GEN(dev_priv) <= 7) {
-   mutex_lock(_priv->pcu_lock);
+   if (INTEL_GEN(dev_priv) <= 7)
sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
   );
-   mutex_unlock(_priv->pcu_lock);
-   }
 
seq_printf(m, "RC1e Enabled: %s\n",
   yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
@@ -1799,30 +1793,24 @@ static int i915_ring_freq_table(struct seq_file *m, 
void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_rps *rps = _priv->gt_pm.rps;
-   int ret = 0;
int gpu_freq, ia_freq;
unsigned int max_gpu_freq, min_gpu_freq;
 
if (!HAS_LLC(dev_priv))
return -ENODEV;
 
-   intel_runtime_pm_get(dev_priv);
-
-   ret = mutex_lock_interruptible(_priv->pcu_lock);
-   if (ret)
-   goto out;
+   min_gpu_freq = rps->min_freq;
+   max_gpu_freq = rps->max_freq;
 
if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
/* Convert GT frequency to 50 HZ units */
-   min_gpu_freq = rps->min_freq_softlimit / GEN9_FREQ_SCALER;
-   max_gpu_freq = rps->max_freq_softlimit / GEN9_FREQ_SCALER;
-   } else {
-   min_gpu_freq = rps->min_freq_softlimit;
-   max_gpu_freq = rps->max_freq_softlimit;
+   min_gpu_freq /= GEN9_FREQ_SCALER;
+   max_gpu_freq /= GEN9_FREQ_SCALER;
}
 
seq_puts(m, "GPU freq (MHz)\tEffective CPU freq (MHz)\tEffective Ring 
freq (MHz)\n");
 
+   intel_runtime_pm_get(dev_priv);
for (gpu_freq = min_gpu_freq; gpu_freq <= max_gpu_freq; gpu_freq++) {
ia_freq = gpu_freq;
sandybridge_pcode_read(dev_priv,
@@ -1836,12 +1824,9 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)
   ((ia_freq >> 0) & 0xff) * 100,
   ((ia_freq >> 8) & 0xff) * 100);
}
-
-   mutex_unlock(_priv->pcu_lock);
-
-out:
intel_runtime_pm_put(dev_priv);
-   return ret;
+
+   return 0;
 }
 
 static int i915_opregion(struct seq_file *m, void *unused)
@@ -4169,7 +4154,7 @@ i915_max_freq_set(void *data, u64 val)
 
DRM_DEBUG_DRIVER("Manually setting max freq to %llu\n", val);
 
-   ret = mutex_lock_interruptible(_priv->pcu_lock);
+   ret = mutex_lock_interruptible(>lock);
if (ret)
return ret;
 
@@ -4182,8 +4167,8 @@ i915_max_freq_set(void *data, u64 val)
hw_min = rps->min_freq;
 
if (val < hw_min || val > hw_max || val < rps->min_freq_softlimit) {
-   

[Intel-gfx] [PATCH 04/10] drm/i915: Reduce RPS update frequency on Valleyview/Cherryview

[Chris Wilson]

Valleyview and Cherryview update the GPU frequency via the punit, which
is very expensive as we have to ensure the cores do not sleep during the
comms. If we perform frequent RPS evaluations, the frequent punit
requests cause measurable system overhead for little benefit, so
increase the evaluation intervals to reduce the number of times we try
and change frequency.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2d02ddc895ca..29afaa077d32 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6165,6 +6165,19 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
break;
}
 
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   /*
+* Baytrail and Braswell control the gpu frequency via the
+* punit, which is very slow and expensive to communicate with,
+* as we synchronously force the package to C0. If we try and
+* update the gpufreq too often we cause measurable system
+* load for little benefit (effectively stealing CPU time for
+* the GPU, negatively impacting overall throughput).
+*/
+   ei_up <<= 2;
+   ei_down <<= 2;
+   }
+
/* When byt can survive without system hang with dynamic
 * sw freq adjustments, this restriction can be lifted.
 */
-- 
2.16.2

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

[Intel-gfx] [PATCH 02/10] drm/i915: Lift acquiring the vlv punit magic to a common sb-get

[Chris Wilson]

As we now employ a very heavy pm_qos around the punit access, we want to
minimise the number of synchronous requests by performing one for the
whole punit sequence rather than around individual accesses. The
sideband lock is used for this, so push the pm_qos into the sideband
lock acquisition and release, moving it from the lowlevel punit rw
routine to the callers. In the first step, we move the punit magic into
the common sideband lock so that we can acquire a bunch of ports
simultaneously, and if need be extend the workaround protection later.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  44 ++--
 drivers/gpu/drm/i915/intel_cdclk.c  |   6 +-
 drivers/gpu/drm/i915/intel_display.c|  37 +-
 drivers/gpu/drm/i915/intel_dp.c |   4 +-
 drivers/gpu/drm/i915/intel_dpio_phy.c   |  37 +-
 drivers/gpu/drm/i915/intel_dsi.c|   8 +--
 drivers/gpu/drm/i915/intel_dsi_pll.c|  14 ++--
 drivers/gpu/drm/i915/intel_dsi_vbt.c|   8 +--
 drivers/gpu/drm/i915/intel_hdmi.c   |   4 +-
 drivers/gpu/drm/i915/intel_pm.c |   4 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |   8 +--
 drivers/gpu/drm/i915/intel_sideband.c   | 115 +++-
 12 files changed, 207 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b8da17304ebe..afc89a8f43e8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3773,25 +3773,61 @@ int skl_pcode_request(struct drm_i915_private 
*dev_priv, u32 mbox, u32 request,
  u32 reply_mask, u32 reply, int timeout_base_ms);
 
 /* intel_sideband.c */
+
+enum {
+   VLV_IOSF_SB_BUNIT,
+   VLV_IOSF_SB_CCK,
+   VLV_IOSF_SB_CCU,
+   VLV_IOSF_SB_DPIO,
+   VLV_IOSF_SB_FLISDSI,
+   VLV_IOSF_SB_GPIO,
+   VLV_IOSF_SB_NC,
+   VLV_IOSF_SB_PUNIT,
+};
+
+void vlv_iosf_sb_get(struct drm_i915_private *dev_priv, unsigned long ports);
+u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
+void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
u32 val);
+void vlv_iosf_sb_put(struct drm_i915_private *dev_priv, unsigned long ports);
+
+void vlv_punit_get(struct drm_i915_private *dev_priv);
 u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
 int vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val);
+void vlv_punit_put(struct drm_i915_private *dev_priv);
+
+void vlv_nc_get(struct drm_i915_private *dev_priv);
 u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
-u32 vlv_iosf_sb_read(struct drm_i915_private *dev_priv, u8 port, u32 reg);
-void vlv_iosf_sb_write(struct drm_i915_private *dev_priv, u8 port, u32 reg, 
u32 val);
+void vlv_nc_put(struct drm_i915_private *dev_priv);
+
+void vlv_cck_get(struct drm_i915_private *dev_priv);
 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);
+void vlv_cck_put(struct drm_i915_private *dev_priv);
+
+void vlv_ccu_get(struct drm_i915_private *dev_priv);
 u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+void vlv_ccu_put(struct drm_i915_private *dev_priv);
+
+void vlv_bunit_get(struct drm_i915_private *dev_priv);
 u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+void vlv_bunit_put(struct drm_i915_private *dev_priv);
+
+void vlv_dpio_get(struct drm_i915_private *dev_priv);
 u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg);
 void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int 
reg, u32 val);
+void vlv_dpio_put(struct drm_i915_private *dev_priv);
+
+void vlv_flisdsi_get(struct drm_i915_private *dev_priv);
+u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+void vlv_flisdsi_put(struct drm_i915_private *dev_priv);
+
 u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
   enum intel_sbi_destination destination);
 void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
 enum intel_sbi_destination destination);
-u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 
 /* intel_dpio_phy.c */
 void bxt_port_to_phy_channel(struct drm_i915_private *dev_priv, enum port port,
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index dc7db8a2caf8..411009ff85aa 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -552,7 +552,8 @@ static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
}

[Intel-gfx] [PATCH 01/10] drm/i915: Disable preemption and sleeping while using the punit sideband

[Chris Wilson]

While we talk to the punit over its sideband, we need to prevent the cpu
from sleeping in order to prevent a potential machine hang.

Note that by itself, it appears that pm_qos_update_request (via
intel_idle) doesn't provide a sufficient barrier to ensure that all core
are indeed awake (out of Cstate) and that the package is awake. To do so,
we need to supplement the pm_qos with a manual ping on_each_cpu.

v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there
is insufficient evidence to implicate a wider problem atm. Similarly,
restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre
of users.

The working theory, courtesy of Ville and Hans, is the issue lies within
the power delivery and so is likely to be unit and board specific and
occurs when both the unit/fw require extra power at the same time as the
cpu package is changing its own power state.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Hans de Goede 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c   |  6 +++
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_sideband.c | 89 +++
 3 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d61b51c0bf0b..bfb9d7b6b678 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -913,6 +913,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
spin_lock_init(_priv->uncore.lock);
 
mutex_init(_priv->sb_lock);
+   pm_qos_add_request(_priv->sb_qos,
+  PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
+
mutex_init(_priv->modeset_restore_lock);
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
@@ -964,6 +967,9 @@ static void i915_driver_cleanup_early(struct 
drm_i915_private *dev_priv)
intel_irq_fini(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
+
+   pm_qos_remove_request(_priv->sb_qos);
+   mutex_destroy(_priv->sb_lock);
 }
 
 static int i915_mmio_setup(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 604389d0b6a3..b8da17304ebe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1907,6 +1907,7 @@ struct drm_i915_private {
 
/* Sideband mailbox protection */
struct mutex sb_lock;
+   struct pm_qos_request sb_qos;
 
/** Cached value of IMR to avoid reads in updating the bitfield */
union {
diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 75c872bb8cc9..d56eda33734e 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -22,6 +22,8 @@
  *
  */
 
+#include 
+
 #include "i915_drv.h"
 #include "intel_drv.h"
 
@@ -39,18 +41,48 @@
 /* Private register write, double-word addressing, non-posted */
 #define SB_CRWRDA_NP   0x07
 
-static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
-  u32 port, u32 opcode, u32 addr, u32 *val)
+static void ping(void *info)
 {
-   u32 cmd, be = 0xf, bar = 0;
-   bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
+}
 
-   cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
-   (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
-   (bar << IOSF_BAR_SHIFT);
+static void __vlv_punit_get(struct drm_i915_private *dev_priv)
+{
+   iosf_mbi_punit_acquire();
 
-   WARN_ON(!mutex_is_locked(_priv->sb_lock));
+   /*
+* Prevent the cpu from sleeping while we use this sideband, otherwise
+* the punit may cause a machine hang. The issue appears to be isolated
+* with changing the power state of the CPU package while changing
+* the power state via the punit, and we have only observed it
+* reliably on 4-core Baytail systems suggesting the issue is in the
+* power delivery mechanism and likely to be be board/function
+* specific. Hence we presume the workaround needs only be applied
+* to the Valleyview P-unit and not all sideband communications.
+*/
+   if (IS_VALLEYVIEW(dev_priv)) {
+   pm_qos_update_request(_priv->sb_qos, 0);
+   on_each_cpu(ping, NULL, 1);
+   }
+}
+
+static void __vlv_punit_put(struct drm_i915_private *dev_priv)
+{
+   if (IS_VALLEYVIEW(dev_priv))
+   pm_qos_update_request(_priv->sb_qos, PM_QOS_DEFAULT_VALUE);
 
+   

[Intel-gfx] [PATCH 05/10] Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3"

[Chris Wilson]

With the vlv sideband fixed to avoid sleeping while we talk to the
punit, the system should be much more stable and be able to utilise the
punit without risk.

This reverts commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation
thresholds on Baytrail v3")

References: 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds on 
Baytrail v3")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Len Brown 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: frit...@xbmc.org
---
 drivers/gpu/drm/i915/intel_pm.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 29afaa077d32..1d52bbf1860a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6178,12 +6178,6 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
ei_down <<= 2;
}
 
-   /* When byt can survive without system hang with dynamic
-* sw freq adjustments, this restriction can be lifted.
-*/
-   if (IS_VALLEYVIEW(dev_priv))
-   goto skip_hw_write;
-
I915_WRITE(GEN6_RP_UP_EI,
   GT_INTERVAL_FROM_US(dev_priv, ei_up));
I915_WRITE(GEN6_RP_UP_THRESHOLD,
@@ -6204,7 +6198,6 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
   GEN6_RP_UP_BUSY_AVG |
   GEN6_RP_DOWN_IDLE_AVG);
 
-skip_hw_write:
rps->power = new_power;
rps->up_threshold = threshold_up;
rps->down_threshold = threshold_down;
-- 
2.16.2

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

[Intel-gfx] [PATCH 08/10] drm/i915: Merge sbi read/write into a single accessor

[Chris Wilson]

Since intel_sideband_read and intel_sideband_write differ by only a
couple of lines (depending on whether we feed the value in or out),
merge the two into a single common accessor.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_sideband.c | 93 +--
 1 file changed, 33 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
b/drivers/gpu/drm/i915/intel_sideband.c
index 87e34787939b..e5faebb511ae 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -309,91 +309,64 @@ void vlv_dpio_put(struct drm_i915_private *dev_priv)
 }
 
 /* SBI access */
-u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
-  enum intel_sbi_destination destination)
+static int intel_sbi_rw(struct drm_i915_private *dev_priv, u16 reg,
+   enum intel_sbi_destination destination,
+   u32 *val, bool is_read)
 {
-   u32 value = 0;
+   u32 cmd;
 
lockdep_assert_held(_priv->sb_lock);
 
-   if (intel_wait_for_register(dev_priv,
-   SBI_CTL_STAT, SBI_BUSY, 0,
-   100)) {
+   if (intel_wait_for_register_fw(dev_priv,
+  SBI_CTL_STAT, SBI_BUSY, 0,
+  100)) {
DRM_ERROR("timeout waiting for SBI to become ready\n");
-   return 0;
+   return -EBUSY;
}
 
-   I915_WRITE(SBI_ADDR, (reg << 16));
-   I915_WRITE(SBI_DATA, 0);
+   I915_WRITE_FW(SBI_ADDR, (u32)reg << 16);
+   I915_WRITE_FW(SBI_DATA, is_read ? 0 : *val);
 
if (destination == SBI_ICLK)
-   value = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRRD;
+   cmd = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRRD;
else
-   value = SBI_CTL_DEST_MPHY | SBI_CTL_OP_IORD;
-   I915_WRITE(SBI_CTL_STAT, value | SBI_BUSY);
+   cmd = SBI_CTL_DEST_MPHY | SBI_CTL_OP_IORD;
+   if (!is_read)
+   cmd |= BIT(8);
+   I915_WRITE_FW(SBI_CTL_STAT, cmd | SBI_BUSY);
 
-   if (intel_wait_for_register(dev_priv,
-   SBI_CTL_STAT,
-   SBI_BUSY,
-   0,
-   100)) {
+   if (__intel_wait_for_register_fw(dev_priv,
+SBI_CTL_STAT, SBI_BUSY, 0,
+100, 100, )) {
DRM_ERROR("timeout waiting for SBI to complete read\n");
-   return 0;
+   return -ETIMEDOUT;
}
 
-   if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
+   if (cmd & SBI_RESPONSE_FAIL) {
DRM_ERROR("error during SBI read of reg %x\n", reg);
-   return 0;
+   return -ENXIO;
}
 
-   return I915_READ(SBI_DATA);
+   if (is_read)
+   *val = I915_READ_FW(SBI_DATA);
+
+   return 0;
 }
 
-void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
-enum intel_sbi_destination destination)
+u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
+  enum intel_sbi_destination destination)
 {
-   u32 tmp;
-
-   lockdep_assert_held(_priv->sb_lock);
-
-   if (intel_wait_for_register(dev_priv,
-   SBI_CTL_STAT, SBI_BUSY, 0,
-   100)) {
-   DRM_ERROR("timeout waiting for SBI to become ready\n");
-   return;
-   }
+   u32 result = 0;
 
-   I915_WRITE(SBI_ADDR, (reg << 16));
-   I915_WRITE(SBI_DATA, value);
-
-   if (destination == SBI_ICLK)
-   tmp = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRWR;
-   else
-   tmp = SBI_CTL_DEST_MPHY | SBI_CTL_OP_IOWR;
-   I915_WRITE(SBI_CTL_STAT, SBI_BUSY | tmp);
-
-   if (intel_wait_for_register(dev_priv,
-   SBI_CTL_STAT,
-   SBI_BUSY,
-   0,
-   100)) {
-   DRM_ERROR("timeout waiting for SBI to complete write\n");
-   return;
-   }
+   intel_sbi_rw(dev_priv, reg, destination, , true);
 
-   if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
-   DRM_ERROR("error during SBI write of %x to reg %x\n",
- value, reg);
-   return;
-   }
+   return result;
 }
 
-u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
+void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
+enum intel_sbi_destination destination)
 {
-   u32 val = 0;
-   vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRRDDA_NP,
-   reg, );
-   return val;
+   

[Intel-gfx] [PATCH 03/10] drm/i915: Lift sideband locking for vlv_punit_(read|write)

[Chris Wilson]

Lift the sideband acquisition for vlv_punit_read and vlv_punit_write
into their callers, so that we can lock the sideband once for a sequence
of operations, rather than perform the heavyweight acquisition on each
request.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  3 +++
 drivers/gpu/drm/i915/i915_sysfs.c   | 14 +-
 drivers/gpu/drm/i915/intel_cdclk.c  | 24 +
 drivers/gpu/drm/i915/intel_display.c| 16 +++-
 drivers/gpu/drm/i915/intel_pm.c | 46 +++--
 drivers/gpu/drm/i915/intel_runtime_pm.c |  8 ++
 drivers/gpu/drm/i915/intel_sideband.c   | 18 ++---
 7 files changed, 86 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e838c765b251..20a6c00a7365 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1085,7 +1085,10 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
   yesno((rpmodectl & GEN6_RP_MEDIA_MODE_MASK) ==
  GEN6_RP_MEDIA_SW_MODE));
 
+   vlv_punit_get(dev_priv);
freq_sts = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
+   vlv_punit_put(dev_priv);
+
seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts);
seq_printf(m, "DDR freq: %d MHz\n", dev_priv->mem_freq);
 
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index b33d2158c234..17b20a34e99f 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -258,25 +258,25 @@ static ssize_t gt_act_freq_mhz_show(struct device *kdev,
struct device_attribute *attr, char *buf)
 {
struct drm_i915_private *dev_priv = kdev_minor_to_i915(kdev);
-   int ret;
+   u32 freq;
 
intel_runtime_pm_get(dev_priv);
 
mutex_lock(_priv->pcu_lock);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
-   u32 freq;
+   vlv_punit_get(dev_priv);
freq = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
-   ret = intel_gpu_freq(dev_priv, (freq >> 8) & 0xff);
+   vlv_punit_put(dev_priv);
+
+   freq = (freq >> 8) & 0xff;
} else {
-   ret = intel_gpu_freq(dev_priv,
-intel_get_cagf(dev_priv,
-   I915_READ(GEN6_RPSTAT1)));
+   freq = intel_get_cagf(dev_priv, I915_READ(GEN6_RPSTAT1));
}
mutex_unlock(_priv->pcu_lock);
 
intel_runtime_pm_put(dev_priv);
 
-   return snprintf(buf, PAGE_SIZE, "%d\n", ret);
+   return snprintf(buf, PAGE_SIZE, "%d\n", intel_gpu_freq(dev_priv, freq));
 }
 
 static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 411009ff85aa..e53e8c36a591 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -461,13 +461,19 @@ static void vlv_get_cdclk(struct drm_i915_private 
*dev_priv,
 {
u32 val;
 
+   mutex_lock(_priv->pcu_lock);
+   vlv_iosf_sb_get(dev_priv,
+   BIT(VLV_IOSF_SB_CCK) | BIT(VLV_IOSF_SB_PUNIT));
+
cdclk_state->vco = vlv_get_hpll_vco(dev_priv);
cdclk_state->cdclk = vlv_get_cck_clock(dev_priv, "cdclk",
   CCK_DISPLAY_CLOCK_CONTROL,
   cdclk_state->vco);
 
-   mutex_lock(_priv->pcu_lock);
val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
+
+   vlv_iosf_sb_put(dev_priv,
+   BIT(VLV_IOSF_SB_CCK) | BIT(VLV_IOSF_SB_PUNIT));
mutex_unlock(_priv->pcu_lock);
 
if (IS_VALLEYVIEW(dev_priv))
@@ -540,6 +546,11 @@ static void vlv_set_cdclk(struct drm_i915_private 
*dev_priv,
 */
intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
 
+   vlv_iosf_sb_get(dev_priv,
+   BIT(VLV_IOSF_SB_CCK) |
+   BIT(VLV_IOSF_SB_BUNIT) |
+   BIT(VLV_IOSF_SB_PUNIT));
+
mutex_lock(_priv->pcu_lock);
val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
val &= ~DSPFREQGUAR_MASK;
@@ -552,9 +563,6 @@ static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
}
mutex_unlock(_priv->pcu_lock);
 
-   vlv_iosf_sb_get(dev_priv,
-   BIT(VLV_IOSF_SB_CCK) | BIT(VLV_IOSF_SB_BUNIT));
-
if (cdclk == 40) {
u32 divider;
 
@@ -588,7 +596,9 @@ static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
vlv_bunit_write(dev_priv, BUNIT_REG_BISOC, val);
 
vlv_iosf_sb_put(dev_priv,
-   BIT(VLV_IOSF_SB_CCK) | 

[Intel-gfx] vlv punit and sideband tidy

[Chris Wilson]

While we continue to observe hangs even with this w/a in place, I do
believe we are in a better position (although that may just be my
confirmation bias). I certainly don't think it's all happy yet. Mika
believes that if we keep the cpu in C0 whilst the gpu is busy, then it
behaves much better -- but that is a very tough sell; virtually disabling
cpu powersaving entirely, for the gpu rarely sleeps under the target
workloads.

Still I think this series moves us forwards and would appreciation acks
or an outright nak to drop it. :)
-Chris

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only prune fences after wait-for-all (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Only prune fences after wait-for-all (rev2)
URL   : https://patchwork.freedesktop.org/series/39547/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
dmesg-warn -> INCOMPLETE (shard-snb) fdo#105185 +3
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
fail   -> PASS   (shard-apl) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-mmap-wc:
pass   -> FAIL   (shard-apl) fdo#101623 +1
Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3467 pass:1823 dwarn:1   dfail:0   fail:10  skip:1632 
time:12136s
shard-hswtotal:3467 pass:1773 dwarn:1   dfail:0   fail:1   skip:1691 
time:11607s
shard-snbtotal:3432 pass:1350 dwarn:1   dfail:0   fail:2   skip:2078 
time:6772s
Blacklisted hosts:
shard-kbltotal:3308 pass:1859 dwarn:2   dfail:0   fail:7   skip:1438 
time:8602s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle changing enable_psr parameter at runtime better

[Patchwork]

== Series Details ==

Series: drm/i915: Handle changing enable_psr parameter at runtime better
URL   : https://patchwork.freedesktop.org/series/39545/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS   (shard-apl) fdo#105341
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +7
Test kms_flip:
Subgroup flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-c-planes:
pass   -> INCOMPLETE (shard-hsw) fdo#103375 +1
Test kms_rotation_crc:
Subgroup primary-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3467 pass:1824 dwarn:2   dfail:0   fail:8   skip:1632 
time:12308s
shard-hswtotal:3455 pass:1763 dwarn:2   dfail:0   fail:3   skip:1685 
time:11400s
shard-snbtotal:3467 pass:1360 dwarn:4   dfail:0   fail:2   skip:2101 
time:7032s
Blacklisted hosts:
shard-kbltotal:3467 pass:1951 dwarn:2   dfail:0   fail:7   skip:1507 
time:9549s

== Logs ==

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

Re: [Intel-gfx] [PATCH 6/6] drm: Reject bad property flag combinations

[Ville Syrjälä]

On Tue, Mar 06, 2018 at 07:22:51PM +0100, Daniel Vetter wrote:
> On Tue, Mar 06, 2018 at 06:48:49PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Pimp drm_property_type_valid() to check for more fails with the
> > property flags. Also make the check before adding the property,
> > and bail out if things look bad.
> > 
> > Since we're now chekcing for more than the type let's also
> > change the function name to drm_property_flags_valid().
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_property.c | 29 +++--
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> > index 027a50e55e96..6ac6ee41a6a3 100644
> > --- a/drivers/gpu/drm/drm_property.c
> > +++ b/drivers/gpu/drm/drm_property.c
> > @@ -50,11 +50,27 @@
> >   * IOCTL and in the get/set property IOCTL.
> >   */
> >  
> > -static bool drm_property_type_valid(struct drm_property *property)
> > +static bool drm_property_flags_valid(u32 flags)
> >  {
> > -   if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
> > -   return !(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
> > -   return !!(property->flags & DRM_MODE_PROP_LEGACY_TYPE);
> > +   u32 legacy_type = flags & DRM_MODE_PROP_LEGACY_TYPE;
> > +   u32 ext_type = flags & DRM_MODE_PROP_EXTENDED_TYPE;
> > +
> > +   /* Reject undefined/deprecated flags */
> > +   if (flags & ~(DRM_MODE_PROP_LEGACY_TYPE |
> > + DRM_MODE_PROP_EXTENDED_TYPE |
> > + DRM_MODE_PROP_IMMUTABLE |
> > + DRM_MODE_PROP_ATOMIC))
> > +   return false;
> > +
> > +   /* We want either a legacy type or an extended type, but not both */
> > +   if (!legacy_type == !ext_type)
> > +   return false;
> > +
> > +   /* Only one legacy type at a time please */
> > +   if (legacy_type && !is_power_of_2(legacy_type))
> > +   return false;
> > +
> > +   return true;
> >  }
> 
> I think this catches everything. Well except not-yet-assigned
> EXTENDED_TYPE defines, but really we can overdo this :-)

Hmm. Yeah, I guess that kind of a fail is fairly unlikely because the
defines won't be there. Would require the driver to basically pass in
utter garbage instead of just a bad combination of existing flags.

> 
> Reviewed-by: Daniel Vetter 

Thanks. Series pushed to drm-misc-next.

> >  
> >  /**
> > @@ -79,6 +95,9 @@ struct drm_property *drm_property_create(struct 
> > drm_device *dev,
> > struct drm_property *property = NULL;
> > int ret;
> >  
> > +   if (WARN_ON(!drm_property_flags_valid(flags)))
> > +   return NULL;
> > +
> > if (WARN_ON(strlen(name) >= DRM_PROP_NAME_LEN))
> > return NULL;
> >  
> > @@ -108,8 +127,6 @@ struct drm_property *drm_property_create(struct 
> > drm_device *dev,
> >  
> > list_add_tail(>head, >mode_config.property_list);
> >  
> > -   WARN_ON(!drm_property_type_valid(property));
> > -
> > return property;
> >  fail:
> > kfree(property->values);
> > -- 
> > 2.16.1
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

[Chris Wilson]

Quoting Michal Wajdeczko (2018-03-07 12:47:01)
> Header intel_ringbuffer.h is using definitions from i915_reg.h
> but forget to include it. Remove this hidden dependency by
> explicitly include missing header.
> 
> v2: add reminder (Chris)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Reviewed-by: Tvrtko Ursulin  #1

Patchwork decided not to pick up this series. Could you collate the r-b
and resend?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only prune fences after wait-for-all (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Only prune fences after wait-for-all (rev2)
URL   : https://patchwork.freedesktop.org/series/39547/
State : success

== Summary ==

Series 39547v2 drm/i915: Only prune fences after wait-for-all
https://patchwork.freedesktop.org/api/1.0/series/39547/revisions/2/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:503s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:579s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:504s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:287s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:467s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:498s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

c362488c07f3f59581a479b2f3b82219fb5bfee3 drm-tip: 2018y-03m-07d-15h-23m-59s UTC 
integration manifest
3f4f3a155ac2 drm/i915: Only prune fences after wait-for-all

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all

[Chris Wilson]

Quoting Chris Wilson (2018-03-07 17:13:03)
> Currently, we only allow ourselves to prune the fences so long as
> all the waits completed (i.e. all the fences we checked were signaled),
> and that the reservation snapshot did not change across the wait.
> However, if we only waited for a subset of the reservation object, i.e.
> just waiting for the last writer to complete as opposed to all readers
> as well, then we would erroneously conclude we could prune the fences as
> indeed although all of our waits were successful, they did not represent
> the totality of the reservation object.
> 
> v2: We only need to check the shared fences due to construction (i.e.
> all of the shared fences will be later than the exclusive fence, if
> any).
> 

Testcase: igt/drv_hangman

As it turns out, that is pretty much the only way we can observe this
bug. (At least not without drinking more than one cup of tea.)

You could construct something to try and overwrite the reader on another
engine, tricky to observe though. However, it is the goal of
selftests/live_coherency and gem_exec_flush to try and catch this type
of error, so should try harder.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3)
URL   : https://patchwork.freedesktop.org/series/39508/
State : success

== Summary ==

 Possible new issues:

Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-a:
skip   -> PASS   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursorb-vs-flipa-varying-size:
dmesg-warn -> PASS   (shard-hsw)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
skip   -> PASS   (shard-snb)
Subgroup pipe-a-wait-busy-hang:
skip   -> PASS   (shard-snb)
Subgroup pipe-b-wait-idle:
dmesg-warn -> PASS   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#105341 +1
Test gem_softpin:
Subgroup noreloc-s3:
skip   -> PASS   (shard-snb) fdo#103375
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-right-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060 +1
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
fail   -> PASS   (shard-apl) fdo#101623
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3381 pass:1780 dwarn:1   dfail:0   fail:7   skip:1591 
time:11799s
shard-hswtotal:3467 pass:1771 dwarn:1   dfail:0   fail:3   skip:1691 
time:11917s
shard-snbtotal:3467 pass:1363 dwarn:2   dfail:0   fail:2   skip:2100 
time:7055s
Blacklisted hosts:
shard-kbltotal:3308 pass:1857 dwarn:1   dfail:0   fail:8   skip:1440 
time:8612s

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all

[Chris Wilson]

Currently, we only allow ourselves to prune the fences so long as
all the waits completed (i.e. all the fences we checked were signaled),
and that the reservation snapshot did not change across the wait.
However, if we only waited for a subset of the reservation object, i.e.
just waiting for the last writer to complete as opposed to all readers
as well, then we would erroneously conclude we could prune the fences as
indeed although all of our waits were successful, they did not represent
the totality of the reservation object.

v2: We only need to check the shared fences due to construction (i.e.
all of the shared fences will be later than the exclusive fence, if
any).

Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a5bd07338b46..9b48b5101357 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -433,20 +433,28 @@ i915_gem_object_wait_reservation(struct 
reservation_object *resv,
dma_fence_put(shared[i]);
kfree(shared);
 
+   /*
+* If both shared fences and an exclusive fence exist,
+* then by construction the shared fences must be later
+* than the exclusive fence. If we successfully wait for
+* all the shared fences, we know that the exclusive fence
+* must all be signaled. If all the shared fences are
+* signaled, we can prune the array and recover the
+* floating references on the fences/requests.
+*/
prune_fences = count && timeout >= 0;
} else {
excl = reservation_object_get_excl_rcu(resv);
}
 
-   if (excl && timeout >= 0) {
+   if (excl && timeout >= 0)
timeout = i915_gem_object_wait_fence(excl, flags, timeout,
 rps_client);
-   prune_fences = timeout >= 0;
-   }
 
dma_fence_put(excl);
 
-   /* Oportunistically prune the fences iff we know they have *all* been
+   /*
+* Oportunistically prune the fences iff we know they have *all* been
 * signaled and that the reservation object has not been changed (i.e.
 * no new fences have been added).
 */
-- 
2.16.2

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

[Intel-gfx] [PATCH] drm/i915: Only prune fences after wait-for-all

[Chris Wilson]

Currently, we only allow ourselves to prune the fences so long as
all the waits completed (i.e. all the fences we checked were signaled),
and that the reservation snapshot did not change across the wait.
However, if we only waited for a subset of the reservation object, i.e.
just waiting for the last writer to complete as opposed to all readers
as well, then we would erroneously conclude we could prune the fences as
indeed although all of our waits were successful, they did not represent
the totality of the reservation object.

Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a5bd07338b46..e3e52b9a74e9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -407,7 +407,7 @@ i915_gem_object_wait_reservation(struct reservation_object 
*resv,
 {
unsigned int seq = __read_seqcount_begin(>seq);
struct dma_fence *excl;
-   bool prune_fences = false;
+   bool prune_fences;
 
if (flags & I915_WAIT_ALL) {
struct dma_fence **shared;
@@ -432,17 +432,13 @@ i915_gem_object_wait_reservation(struct 
reservation_object *resv,
for (; i < count; i++)
dma_fence_put(shared[i]);
kfree(shared);
-
-   prune_fences = count && timeout >= 0;
} else {
excl = reservation_object_get_excl_rcu(resv);
}
 
-   if (excl && timeout >= 0) {
+   if (excl && timeout >= 0)
timeout = i915_gem_object_wait_fence(excl, flags, timeout,
 rps_client);
-   prune_fences = timeout >= 0;
-   }
 
dma_fence_put(excl);
 
@@ -450,6 +446,7 @@ i915_gem_object_wait_reservation(struct reservation_object 
*resv,
 * signaled and that the reservation object has not been changed (i.e.
 * no new fences have been added).
 */
+   prune_fences = flags & I915_WAIT_ALL && timeout >= 0;
if (prune_fences && !__read_seqcount_retry(>seq, seq)) {
if (reservation_object_trylock(resv)) {
if (!__read_seqcount_retry(>seq, seq))
-- 
2.16.2

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle changing enable_psr parameter at runtime better

[Patchwork]

== Series Details ==

Series: drm/i915: Handle changing enable_psr parameter at runtime better
URL   : https://patchwork.freedesktop.org/series/39545/
State : success

== Summary ==

Series 39545v1 drm/i915: Handle changing enable_psr parameter at runtime better
https://patchwork.freedesktop.org/api/1.0/series/39545/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:425s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:495s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:504s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:418s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:292s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:521s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:465s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:517s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:424s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s

c362488c07f3f59581a479b2f3b82219fb5bfee3 drm-tip: 2018y-03m-07d-15h-23m-59s UTC 
integration manifest
7b2597370ab9 drm/i915: Handle changing enable_psr parameter at runtime better

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Move i915_gpu_error into its own header

[Chris Wilson]

Quoting Michal Wajdeczko (2018-03-07 12:47:04)
> Error state management code was moved into separate .c unit
> but we didn't move related definitions into own header.
> 
> v2: move also intel_display_error_state forward decl
> fix ("Prefer 'unsigned int' to bare use of 'unsigned'")
> warnings detected by checkpatch in moved code (Michal)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915: Finish the wait-for-wedge by 
retiring all the inflight requests
URL   : https://patchwork.freedesktop.org/series/39532/
State : success

== Summary ==

 Possible new issues:

Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-a:
skip   -> PASS   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursorb-vs-flipa-varying-size:
dmesg-warn -> PASS   (shard-hsw)
Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
skip   -> PASS   (shard-snb)
Subgroup pipe-a-wait-busy-hang:
skip   -> PASS   (shard-snb)
Subgroup pipe-b-wait-idle:
dmesg-warn -> PASS   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#105341 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-right-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368 +2

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-apltotal:3394 pass:1786 dwarn:1   dfail:0   fail:8   skip:1597 
time:11868s
shard-hswtotal:3429 pass:1751 dwarn:1   dfail:0   fail:5   skip:1670 
time:11284s
shard-snbtotal:3467 pass:1362 dwarn:2   dfail:0   fail:2   skip:2101 
time:6988s
Blacklisted hosts:
shard-kbltotal:3381 pass:1900 dwarn:3   dfail:0   fail:7   skip:1470 
time:9183s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Change parameters order in i915_gem_batch_pool_init

[Chris Wilson]

Quoting Michal Wajdeczko (2018-03-07 12:47:02)
> Function i915_gem_batch_pool_init() failed to follow obj-verb
> naming schema. Fix that by swapping function parameters.
> While here, change license text to SPDX format.
> 
> v2: use intel_engine_init_batch_pool (Chris) as proxy (Michal)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 

Fair compromise.
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Maarten Lankhorst]

Op 07-03-18 om 16:21 schreef Ville Syrjälä:
> On Wed, Mar 07, 2018 at 04:04:32PM +0100, Maarten Lankhorst wrote:
>> This will get rid of the following error:
>> [   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
>> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
>> [   74.730311] Modules linked in: vgem snd_hda_codec_hdmi 
>> snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal 
>> intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec 
>> crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib 
>> snd_pcm tg3 lpc_ich mei_me mei prime_numbers
>> [   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
>> 4.16.0-rc2-CI-CI_DRM_3822+ #1
>> [   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
>> 10/17/2011
>> [   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
>> [   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
>> [   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 
>> 0001
>> [   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 
>> 82068cea
>> [   74.730369] RBP: 88022fb03d70 R08:  R09: 
>> 815d26d0
>> [   74.730371] R10:  R11: a0161ca0 R12: 
>> 0001
>> [   74.730373] R13: 880212448008 R14: 880212448330 R15: 
>> 
>> [   74.730376] FS:  () GS:88022fb0() 
>> knlGS:
>> [   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
>> [   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 
>> 000606e0
>> [   74.730382] Call Trace:
>> [   74.730385]  
>> [   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
>> [   74.730401]  drm_update_vblank_count+0x64/0x240
>> [   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
>> [   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
>> [   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
>> [   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
>> [   74.730548]  __handle_irq_event_percpu+0x3c/0x340
>> [   74.730556]  handle_irq_event_percpu+0x1b/0x50
>> [   74.730561]  handle_irq_event+0x2f/0x50
>> [   74.730566]  handle_edge_irq+0xe4/0x1b0
>> [   74.730572]  handle_irq+0x11/0x20
>> [   74.730576]  do_IRQ+0x5e/0x120
>> [   74.730584]  common_interrupt+0x84/0x84
>> [   74.730586]  
>> [   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
>> [   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
>> ffde
>> [   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 
>> 0001
>> [   74.730599] RDX:  RSI: 8210fb59 RDI: 
>> 820c02e7
>> [   74.730601] RBP: 0004 R08: 40af R09: 
>> 0018
>> [   74.730603] R10:  R11:  R12: 
>> 0004
>> [   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 
>> 82294460
>> [   74.730621]  ? cpuidle_enter_state+0xa6/0x350
>> [   74.730629]  do_idle+0x188/0x1d0
>> [   74.730636]  cpu_startup_entry+0x14/0x20
>> [   74.730641]  start_secondary+0x129/0x160
>> [   74.730646]  secondary_startup_64+0xa5/0xb0
>> [   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 
>> 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff 
>> <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
>> [   74.730754] ---[ end trace 14b1345705b68565 ]---
>>
>> Changes since v1:
>> - Don't try to apply CRC workaround when enabling pipe, it should already be 
>> enabled.
>> Changes since v2:
>> - Make crc functions for !DEBUGFS case inline.
>> - Pass intel_crtc to crc functions.
>> - Add comments to callsites.
>>
>> Cc: Marta Löfstedt 
>> Reported-by: Marta Löfstedt 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c  | 10 
>>  drivers/gpu/drm/i915/intel_drv.h  |  9 +++
>>  drivers/gpu/drm/i915/intel_pipe_crc.c | 46 
>> +--
>>  3 files changed, 58 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 331084082545..2933ad38094f 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12147,6 +12147,9 @@ static void intel_update_crtc(struct drm_crtc *crtc,
>>  if (modeset) {
>>  update_scanline_offset(intel_crtc);
>>  dev_priv->display.crtc_enable(pipe_config, state);
>> +
>> +/* vblanks work again, re-enable pipe CRC. */
>> +intel_crtc_enable_pipe_crc(intel_crtc);
>>  } else {
>>  intel_pre_plane_update(to_intel_crtc_state(old_crtc_state),
>> 

[Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Maarten Lankhorst]

Similar to enable_fbc, enable_psr was ignored at runtime if it was
changed. The easiest fix is to pretend enable_psr is ignored at
configure time, and never activate it for !enable_psr, so both cases
are handled without modesets.

Signed-off-by: Maarten Lankhorst 
Tested-by: Benjamin Berg 
Cc: Benjamin Berg 
---
 drivers/gpu/drm/i915/intel_psr.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 23175c5c4a50..ac3ce7a1c2a7 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -502,11 +502,6 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
if (!CAN_PSR(dev_priv))
return;
 
-   if (!i915_modparams.enable_psr) {
-   DRM_DEBUG_KMS("PSR disable by flag\n");
-   return;
-   }
-
/*
 * HSW spec explicitly says PSR is tied to port A.
 * BDW+ platforms with DDI implementation of PSR have different
@@ -559,7 +554,10 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
 
crtc_state->has_psr = true;
crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
-   DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
+   if (i915_modparams.enable_psr)
+   DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : 
"");
+   else
+   DRM_DEBUG_KMS("PSR disable by flag\n");
 }
 
 static void intel_psr_activate(struct intel_dp *intel_dp)
@@ -652,7 +650,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
dev_priv->psr.enable_source(intel_dp, crtc_state);
dev_priv->psr.enabled = intel_dp;
 
-   if (INTEL_GEN(dev_priv) >= 9) {
+   if (!i915_modparams.enable_psr) {
+   DRM_DEBUG_KMS("PSR disable by flag\n");
+   } else if (INTEL_GEN(dev_priv) >= 9) {
intel_psr_activate(intel_dp);
} else {
/*
@@ -843,7 +843,7 @@ static void intel_psr_work(struct work_struct *work)
 * recheck. Since psr_flush first clears this and then reschedules we
 * won't ever miss a flush when bailing out here.
 */
-   if (dev_priv->psr.busy_frontbuffer_bits)
+   if (dev_priv->psr.busy_frontbuffer_bits || !i915_modparams.enable_psr)
goto unlock;
 
intel_psr_activate(intel_dp);
@@ -1015,7 +1015,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
return;
 
mutex_lock(_priv->psr.lock);
-   if (!dev_priv->psr.enabled) {
+   if (!dev_priv->psr.enabled || !i915_modparams.enable_psr) {
+   intel_psr_exit(dev_priv);
mutex_unlock(_priv->psr.lock);
return;
}
-- 
2.16.2

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

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

[Daniel Vetter]

On Tue, Mar 06, 2018 at 01:32:21PM -0500, Harry Wentland wrote:
> 
> 
> On 2018-03-06 12:13 PM, Daniel Vetter wrote:
> > On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote:
> >> On 2018-03-06 07:18 AM, Ville Syrj??l?? wrote:
> >>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote:
>  On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote:
> > From: Ville Syrj??l?? 
> >
> > edid and display_info are protected by mode_config.mutex. Add lockdep
> > asserts to make sure we're not accessing things w/o the lock.
> >
> > FIXME: pretty sure this will blow up with amdgpu as they seem
> > to be doing edid updates even from the modeset path. Need to figure
> > out what to do about that. Maybe protect the edid/display info with
> > with connection_mutex instead of mode_config.mutex?
> 
>  Imo not doing EDID udpates from the modeset path is the right fix. I 
>  can't
>  think of any reasonable reason to do that at least. Can you point me at
>  the relevant amdgpu code pls (I'm lazy, sry)?
> >>>
> >>> It was some MST thing I believe... (should have written it down)
> >>>
> >>> amdgpu_dm_atomic_check() -> dm_update_crtcs_state() ->
> >>> create_stream_for_sink() -> dm_dp_mst_dc_sink_create() ->
> >>> get_edid/update_edid_property
> >>>
> >>
> >> Yeah, it's because the dc_sink carries the EDID and is only created at
> >> this point for us. It's bugged me ever since we did this. Might be time
> >> to think of a solution to it now.
> > 
> > But how does this work? Userspace won't do a modeset without the EDID
> > present and the modes listed, which means you'll never ever end up in
> > atomic check. This really sounds rather wrong.
> > 
> 
> Not sure if this works correctly with atomic userspace.
> 
> I think with legacy userspace we might rely on the get_connector call
> doing .fill_modes > drm_helper_probe_single_connector_modes > .get_modes
> > dm_dp_mst_get_modes > drm_dp_mst_get_edid

Atomic userspace users the exact same ioctls for connector probing, no
change there.

That leaves me wondering why exactly you're doing this in atomic_check.
Just nuke it?
-Daniel

> 
> Harry
> 
> 
> > Only idea I can come up with is that you're abusing the regular pageflip
> > request as a worker thread, but that's some seriously backwards design.
> > -Daniel
> > 
> >>
> >> Harry
> >>
> 
>  Otherwise I think this is a real good patch.
> 
>  Thanks, Daniel
> 
> >
> > Cc: Keith Packard 
> > Cc: Daniel Vetter 
> > Cc: Harry Wentland 
> > Signed-off-by: Ville Syrj??l?? 
> > ---
> >  drivers/gpu/drm/drm_connector.c| 4 
> >  drivers/gpu/drm/drm_edid.c | 2 ++
> >  drivers/gpu/drm/drm_probe_helper.c | 2 +-
> >  3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 122060792b6f..a9f3536f4e94 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1374,6 +1374,8 @@ int 
> > drm_mode_connector_update_edid_property(struct drm_connector *connector,
> > size_t size = 0;
> > int ret;
> >  
> > +   lockdep_assert_held(>mode_config.mutex);
> > +
> > /* ignore requests to set edid when overridden */
> > if (connector->override_edid)
> > return 0;
> > @@ -1770,6 +1772,8 @@ void drm_connector_reset_display_info(struct 
> > drm_connector *connector)
> >  {
> > struct drm_display_info *info = >display_info;
> >  
> > +   lockdep_assert_held(>dev->mode_config.mutex);
> > +
> > memset(info, 0, sizeof(*info));
> >  }
> >  EXPORT_SYMBOL_GPL(drm_connector_reset_display_info);
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 618093c4a039..7f9e9236114b 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4440,6 +4440,8 @@ u32 drm_add_display_info(struct drm_connector 
> > *connector, const struct edid *edi
> > struct drm_display_info *info = >display_info;
> > u32 quirks = edid_get_quirks(edid);
> >  
> > +   lockdep_assert_held(>dev->mode_config.mutex);
> > +
> > info->width_mm = edid->width_cm * 10;
> > info->height_mm = edid->height_cm * 10;
> >  
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 7dc7e635d7e4..2a2afcf72788 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -400,7 +400,7 @@ int drm_helper_probe_single_connector_modes(struct 
> > drm_connector *connector,
> 

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/6] drm: Reject replacing property enum values

[Ville Syrjälä]

On Tue, Mar 06, 2018 at 09:49:29PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/6] drm: Reject replacing property enum values
> URL   : https://patchwork.freedesktop.org/series/39465/
> State : warning
> 
> == Summary ==
> 
>  Possible new issues:
> 
> Test kms_chv_cursor_fail:
> Subgroup pipe-a-64x64-top-edge:
> dmesg-warn -> PASS   (shard-hsw)
> Subgroup pipe-c-64x64-right-edge:
> pass   -> DMESG-WARN (shard-apl)

Unrelated pipe crc vs. vblank warn:

[   39.323847] WARNING: CPU: 1 PID: 0 at drivers/gpu/drm/drm_vblank.c:620 
drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0

> 
>  Known issues:
> 
> Test gem_eio:
> Subgroup in-flight-contexts:
> pass   -> INCOMPLETE (shard-apl) fdo#105341
> Test kms_atomic_transition:
> Subgroup 1x-modeset-transitions:
> pass   -> FAIL   (shard-apl) fdo#103207
> Test kms_chv_cursor_fail:
> Subgroup pipe-b-256x256-right-edge:
> dmesg-warn -> PASS   (shard-snb) fdo#105185
> Test kms_cursor_legacy:
> Subgroup 2x-long-flip-vs-cursor-atomic:
> fail   -> PASS   (shard-hsw) fdo#104873
> Subgroup flip-vs-cursor-toggle:
> fail   -> PASS   (shard-hsw) fdo#102670
> Test kms_flip:
> Subgroup plain-flip-ts-check:
> fail   -> PASS   (shard-hsw) fdo#100368 +2
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-primscrn-spr-indfb-fullscreen:
> fail   -> PASS   (shard-apl) fdo#101623 +1
> Test pm_lpsp:
> Subgroup screens-disabled:
> pass   -> FAIL   (shard-hsw) fdo#104941
> 
> fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
> fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
> fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
> fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
> fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941
> 
> shard-apltotal:3381 pass:1779 dwarn:2   dfail:0   fail:7   skip:1591 
> time:11922s
> shard-hswtotal:3467 pass:1771 dwarn:1   dfail:0   fail:3   skip:1691 
> time:11848s
> shard-snbtotal:3467 pass:1363 dwarn:1   dfail:0   fail:2   skip:2101 
> time:6972s
> Blacklisted hosts:
> shard-kbltotal:3394 pass:1908 dwarn:3   dfail:0   fail:8   skip:1474 
> time:9081s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8247/shards.html

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

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

[Rodrigo Vivi]

Hi Dave,

Fixes for 2 regressions that got captured by CI.

Here goes drm-intel-fixes-2018-03-07:

- 2 fixes: 1 for perf and 1 execlist submission race.

Thanks,
Rodrigo.

The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1:

  Linux 4.16-rc4 (2018-03-04 14:54:11 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-03-07

for you to fetch changes up to 88d3dfb6a69042381161290c7ce19e1f53fc2a66:

  drm/i915: Suspend submission tasklets around wedging (2018-03-05 16:08:31 
-0800)


- 2 fixes: 1 for perf and 1 execlist submission race.


Chris Wilson (1):
  drm/i915: Suspend submission tasklets around wedging

Lionel Landwerlin (1):
  drm/i915/perf: fix perf stream opening lock

 drivers/gpu/drm/i915/i915_gem.c  |  6 +-
 drivers/gpu/drm/i915/i915_perf.c | 40 +---
 drivers/gpu/drm/i915/intel_lrc.c |  5 +
 3 files changed, 23 insertions(+), 28 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

[Rodrigo Vivi]

Copied from Mesa with no modifications.

Gives us Geminilake and Kaby Lake platform names updates and
sync on Coffee Lake PCI IDs.

Cc: Timo Aaltonen 
Signed-off-by: Rodrigo Vivi 
---
 hw/xfree86/dri2/pci_ids/i965_pci_ids.h | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h 
b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
index 57e70b7ae..feb9c582b 100644
--- a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
+++ b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h
@@ -151,7 +151,7 @@ CHIPSET(0x590B, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x590E, kbl_gt1, "Intel(R) Kabylake GT1")
 CHIPSET(0x5913, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
 CHIPSET(0x5915, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
-CHIPSET(0x5917, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
+CHIPSET(0x5917, kbl_gt2, "Intel(R) UHD Graphics 620 (Kabylake GT2)")
 CHIPSET(0x5912, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby Lake GT2)")
 CHIPSET(0x5916, kbl_gt2, "Intel(R) HD Graphics 620 (Kaby Lake GT2)")
 CHIPSET(0x591A, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
@@ -160,22 +160,30 @@ CHIPSET(0x591D, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby 
Lake GT2)")
 CHIPSET(0x591E, kbl_gt2, "Intel(R) HD Graphics 615 (Kaby Lake GT2)")
 CHIPSET(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
 CHIPSET(0x5923, kbl_gt3, "Intel(R) Kabylake GT3")
-CHIPSET(0x5926, kbl_gt3, "Intel(R) Iris Plus Graphics 640 (Kaby Lake GT3)")
-CHIPSET(0x5927, kbl_gt3, "Intel(R) Iris Plus Graphics 650 (Kaby Lake GT3)")
+CHIPSET(0x5926, kbl_gt3, "Intel(R) Iris Plus Graphics 640 (Kaby Lake GT3e)")
+CHIPSET(0x5927, kbl_gt3, "Intel(R) Iris Plus Graphics 650 (Kaby Lake GT3e)")
 CHIPSET(0x593B, kbl_gt4, "Intel(R) Kabylake GT4")
-CHIPSET(0x3184, glk, "Intel(R) HD Graphics (Geminilake)")
-CHIPSET(0x3185, glk_2x6, "Intel(R) HD Graphics (Geminilake 2x6)")
+CHIPSET(0x3184, glk, "Intel(R) UHD Graphics 605 (Geminilake)")
+CHIPSET(0x3185, glk_2x6, "Intel(R) UHD Graphics 600 (Geminilake 2x6)")
 CHIPSET(0x3E90, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
 CHIPSET(0x3E93, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
-CHIPSET(0x3E91, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
-CHIPSET(0x3E92, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
+CHIPSET(0x3E99, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
+CHIPSET(0x3EA1, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
+CHIPSET(0x3EA4, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)")
+CHIPSET(0x3E91, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
+CHIPSET(0x3E92, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
 CHIPSET(0x3E96, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
-CHIPSET(0x3E9B, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
+CHIPSET(0x3E9A, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
+CHIPSET(0x3E9B, cfl_gt2, "Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)")
 CHIPSET(0x3E94, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
+CHIPSET(0x3EA0, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
+CHIPSET(0x3EA3, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
+CHIPSET(0x3EA9, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)")
+CHIPSET(0x3EA2, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
+CHIPSET(0x3EA5, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
 CHIPSET(0x3EA6, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
 CHIPSET(0x3EA7, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
 CHIPSET(0x3EA8, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
-CHIPSET(0x3EA5, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)")
 CHIPSET(0x5A49, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
 CHIPSET(0x5A4A, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)")
 CHIPSET(0x5A41, cnl_3x8, "Intel(R) HD Graphics (Cannonlake 3x8 GT1)")
-- 
2.13.6

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3)
URL   : https://patchwork.freedesktop.org/series/39508/
State : success

== Summary ==

Series 39508v3 drm/i915: Handle pipe CRC around enabling/disabling pipe.
https://patchwork.freedesktop.org/api/1.0/series/39508/revisions/3/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:369s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:498s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:467s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:582s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:505s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:397s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:418s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:535s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:430s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:389s

36e67bf18117a31df69df314e9e7f3709c37c9c8 drm-tip: 2018y-03m-07d-13h-36m-57s UTC 
integration manifest
6bf990dda548 drm/i915: Handle pipe CRC around enabling/disabling pipe.

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Ville Syrjälä]

On Wed, Mar 07, 2018 at 04:04:32PM +0100, Maarten Lankhorst wrote:
> This will get rid of the following error:
> [   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> [   74.730311] Modules linked in: vgem snd_hda_codec_hdmi 
> snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal 
> intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec 
> crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib 
> snd_pcm tg3 lpc_ich mei_me mei prime_numbers
> [   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
> 4.16.0-rc2-CI-CI_DRM_3822+ #1
> [   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
> [   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> [   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
> [   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 
> 0001
> [   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 
> 82068cea
> [   74.730369] RBP: 88022fb03d70 R08:  R09: 
> 815d26d0
> [   74.730371] R10:  R11: a0161ca0 R12: 
> 0001
> [   74.730373] R13: 880212448008 R14: 880212448330 R15: 
> 
> [   74.730376] FS:  () GS:88022fb0() 
> knlGS:
> [   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
> [   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 
> 000606e0
> [   74.730382] Call Trace:
> [   74.730385]  
> [   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
> [   74.730401]  drm_update_vblank_count+0x64/0x240
> [   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
> [   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
> [   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
> [   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
> [   74.730548]  __handle_irq_event_percpu+0x3c/0x340
> [   74.730556]  handle_irq_event_percpu+0x1b/0x50
> [   74.730561]  handle_irq_event+0x2f/0x50
> [   74.730566]  handle_edge_irq+0xe4/0x1b0
> [   74.730572]  handle_irq+0x11/0x20
> [   74.730576]  do_IRQ+0x5e/0x120
> [   74.730584]  common_interrupt+0x84/0x84
> [   74.730586]  
> [   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
> [   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
> ffde
> [   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 
> 0001
> [   74.730599] RDX:  RSI: 8210fb59 RDI: 
> 820c02e7
> [   74.730601] RBP: 0004 R08: 40af R09: 
> 0018
> [   74.730603] R10:  R11:  R12: 
> 0004
> [   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 
> 82294460
> [   74.730621]  ? cpuidle_enter_state+0xa6/0x350
> [   74.730629]  do_idle+0x188/0x1d0
> [   74.730636]  cpu_startup_entry+0x14/0x20
> [   74.730641]  start_secondary+0x129/0x160
> [   74.730646]  secondary_startup_64+0xa5/0xb0
> [   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 06 
> 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff <0f> 
> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
> [   74.730754] ---[ end trace 14b1345705b68565 ]---
> 
> Changes since v1:
> - Don't try to apply CRC workaround when enabling pipe, it should already be 
> enabled.
> Changes since v2:
> - Make crc functions for !DEBUGFS case inline.
> - Pass intel_crtc to crc functions.
> - Add comments to callsites.
> 
> Cc: Marta Löfstedt 
> Reported-by: Marta Löfstedt 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 10 
>  drivers/gpu/drm/i915/intel_drv.h  |  9 +++
>  drivers/gpu/drm/i915/intel_pipe_crc.c | 46 
> +--
>  3 files changed, 58 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 331084082545..2933ad38094f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12147,6 +12147,9 @@ static void intel_update_crtc(struct drm_crtc *crtc,
>   if (modeset) {
>   update_scanline_offset(intel_crtc);
>   dev_priv->display.crtc_enable(pipe_config, state);
> +
> + /* vblanks work again, re-enable pipe CRC. */
> + intel_crtc_enable_pipe_crc(intel_crtc);
>   } else {
>   intel_pre_plane_update(to_intel_crtc_state(old_crtc_state),
>  pipe_config);
> @@ -12327,6 +12330,13 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   if 

[Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Maarten Lankhorst]

This will get rid of the following error:
[   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
[   74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp 
snd_hda_intel crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep broadcom 
ghash_clmulni_intel snd_hda_core bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei 
prime_numbers
[   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
4.16.0-rc2-CI-CI_DRM_3822+ #1
[   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
[   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
[   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
[   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 0001
[   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 82068cea
[   74.730369] RBP: 88022fb03d70 R08:  R09: 815d26d0
[   74.730371] R10:  R11: a0161ca0 R12: 0001
[   74.730373] R13: 880212448008 R14: 880212448330 R15: 
[   74.730376] FS:  () GS:88022fb0() 
knlGS:
[   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
[   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 000606e0
[   74.730382] Call Trace:
[   74.730385]  
[   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
[   74.730401]  drm_update_vblank_count+0x64/0x240
[   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
[   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
[   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
[   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
[   74.730548]  __handle_irq_event_percpu+0x3c/0x340
[   74.730556]  handle_irq_event_percpu+0x1b/0x50
[   74.730561]  handle_irq_event+0x2f/0x50
[   74.730566]  handle_edge_irq+0xe4/0x1b0
[   74.730572]  handle_irq+0x11/0x20
[   74.730576]  do_IRQ+0x5e/0x120
[   74.730584]  common_interrupt+0x84/0x84
[   74.730586]  
[   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
[   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
ffde
[   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 0001
[   74.730599] RDX:  RSI: 8210fb59 RDI: 820c02e7
[   74.730601] RBP: 0004 R08: 40af R09: 0018
[   74.730603] R10:  R11:  R12: 0004
[   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 82294460
[   74.730621]  ? cpuidle_enter_state+0xa6/0x350
[   74.730629]  do_idle+0x188/0x1d0
[   74.730636]  cpu_startup_entry+0x14/0x20
[   74.730641]  start_secondary+0x129/0x160
[   74.730646]  secondary_startup_64+0xa5/0xb0
[   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 06 
82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff <0f> 0b 
45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
[   74.730754] ---[ end trace 14b1345705b68565 ]---

Changes since v1:
- Don't try to apply CRC workaround when enabling pipe, it should already be 
enabled.
Changes since v2:
- Make crc functions for !DEBUGFS case inline.
- Pass intel_crtc to crc functions.
- Add comments to callsites.

Cc: Marta Löfstedt 
Reported-by: Marta Löfstedt 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c  | 10 
 drivers/gpu/drm/i915/intel_drv.h  |  9 +++
 drivers/gpu/drm/i915/intel_pipe_crc.c | 46 +--
 3 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 331084082545..2933ad38094f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12147,6 +12147,9 @@ static void intel_update_crtc(struct drm_crtc *crtc,
if (modeset) {
update_scanline_offset(intel_crtc);
dev_priv->display.crtc_enable(pipe_config, state);
+
+   /* vblanks work again, re-enable pipe CRC. */
+   intel_crtc_enable_pipe_crc(intel_crtc);
} else {
intel_pre_plane_update(to_intel_crtc_state(old_crtc_state),
   pipe_config);
@@ -12327,6 +12330,13 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
 
if (old_crtc_state->active) {
intel_crtc_disable_planes(crtc, 
old_crtc_state->plane_mask);
+
+   /*
+* We need to disable pipe CRC before disabling the 
pipe,
+* or we race against vblank 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915: Finish the wait-for-wedge by 
retiring all the inflight requests
URL   : https://patchwork.freedesktop.org/series/39532/
State : success

== Summary ==

Series 39532v1 series starting with [1/6] drm/i915: Finish the wait-for-wedge 
by retiring all the inflight requests
https://patchwork.freedesktop.org/api/1.0/series/39532/revisions/1/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:497s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:504s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:501s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:420s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:401s

36e67bf18117a31df69df314e9e7f3709c37c9c8 drm-tip: 2018y-03m-07d-13h-36m-57s UTC 
integration manifest
7dc0b21fe5c5 drm/i915: Only call tasklet_kill() on the first prepare_reset
b6b27d833c1e drm/i915: Wrap engine->schedule in RCU locks for set-wedge 
protection
922b2f72ecc7 drm/i915: Include ring->emit in debugging
bdd4d1164ec2 drm/i915: Update ring position from request on retiring
50b3612924f1 drm/i915: Reset ring space estimate after unwinding the request
95cc7a5b45e6 drm/i915: Finish the wait-for-wedge by retiring all the inflight 
requests

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Ville Syrjälä]

On Wed, Mar 07, 2018 at 03:23:12PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 07, 2018 at 01:10:26PM +0100, Maarten Lankhorst wrote:
> > This will get rid of the following error:
> > [   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
> > drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> > [   74.730311] Modules linked in: vgem snd_hda_codec_hdmi 
> > snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal 
> > intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec 
> > crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core 
> > bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei prime_numbers
> > [   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
> > 4.16.0-rc2-CI-CI_DRM_3822+ #1
> > [   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 
> > 10/17/2011
> > [   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> > [   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
> > [   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 
> > 0001
> > [   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 
> > 82068cea
> > [   74.730369] RBP: 88022fb03d70 R08:  R09: 
> > 815d26d0
> > [   74.730371] R10:  R11: a0161ca0 R12: 
> > 0001
> > [   74.730373] R13: 880212448008 R14: 880212448330 R15: 
> > 
> > [   74.730376] FS:  () GS:88022fb0() 
> > knlGS:
> > [   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
> > [   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 
> > 000606e0
> > [   74.730382] Call Trace:
> > [   74.730385]  
> > [   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
> > [   74.730401]  drm_update_vblank_count+0x64/0x240
> > [   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
> > [   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
> > [   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
> > [   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
> > [   74.730548]  __handle_irq_event_percpu+0x3c/0x340
> > [   74.730556]  handle_irq_event_percpu+0x1b/0x50
> > [   74.730561]  handle_irq_event+0x2f/0x50
> > [   74.730566]  handle_edge_irq+0xe4/0x1b0
> > [   74.730572]  handle_irq+0x11/0x20
> > [   74.730576]  do_IRQ+0x5e/0x120
> > [   74.730584]  common_interrupt+0x84/0x84
> > [   74.730586]  
> > [   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
> > [   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
> > ffde
> > [   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 
> > 0001
> > [   74.730599] RDX:  RSI: 8210fb59 RDI: 
> > 820c02e7
> > [   74.730601] RBP: 0004 R08: 40af R09: 
> > 0018
> > [   74.730603] R10:  R11:  R12: 
> > 0004
> > [   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 
> > 82294460
> > [   74.730621]  ? cpuidle_enter_state+0xa6/0x350
> > [   74.730629]  do_idle+0x188/0x1d0
> > [   74.730636]  cpu_startup_entry+0x14/0x20
> > [   74.730641]  start_secondary+0x129/0x160
> > [   74.730646]  secondary_startup_64+0xa5/0xb0
> > [   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 
> > 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff 
> > <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
> > [   74.730754] ---[ end trace 14b1345705b68565 ]---
> > 
> > Changes since v1:
> > - Don't try to apply CRC workaround when enabling pipe, it should already 
> > be enabled.
> > 
> > Cc: Marta Löfstedt 
> > Reported-by: Marta Löfstedt 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c  |  2 ++
> >  drivers/gpu/drm/i915/intel_drv.h  |  3 +++
> >  drivers/gpu/drm/i915/intel_pipe_crc.c | 44 
> > +--
> >  3 files changed, 42 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 331084082545..67d13fe4c24f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -12147,6 +12147,7 @@ static void intel_update_crtc(struct drm_crtc *crtc,
> > if (modeset) {
> > update_scanline_offset(intel_crtc);
> > dev_priv->display.crtc_enable(pipe_config, state);
> > +   intel_crtc_enable_pipe_crc(crtc);
> 
> I think I'd prefer this to live next to the vblank on/off, with a
> comment. Putting it here gives absolutely no clue why we have to
> do it.

...or at least we need a comment here. 

> 
> > } else {
> > 

[Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

[Chris Wilson]

With a series of unusual events (a sequence of interrupted request
allocations), we could gradually leak the ring->space estimate by
unwinding the ring back to the start of the request, but not return the
used space back to the ring. Eventually and with great misfortune, it
would be possible to trigger ring->space exhaustion with no requests on
the ring.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_request.c | 1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index d437beac3969..efa9ee557f31 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -798,6 +798,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
 
 err_unwind:
rq->ring->emit = rq->head;
+   intel_ring_update_space(rq->ring);
 
/* Make sure we didn't add ourselves to external state before freeing */
GEM_BUG_ON(!list_empty(>active_list));
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1d599524a759..88eeb64041ae 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1593,6 +1593,7 @@ static noinline int wait_for_space(struct intel_ring 
*ring, unsigned int bytes)
if (intel_ring_update_space(ring) >= bytes)
return 0;
 
+   GEM_BUG_ON(list_empty(>request_list));
list_for_each_entry(target, >request_list, ring_link) {
/* Would completion of this request free enough space? */
if (bytes <= __intel_ring_space(target->postfix,
-- 
2.16.2

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

[Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring

[Chris Wilson]

When wedged, we do not update the ring->tail as we submit the requests
causing us to leak the ring->space upon cleaning up the wedged driver.
We can just use the value stored in rq->tail, and keep the submission
backend details away from set-wedge.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_request.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index efa9ee557f31..69b378a323fc 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -358,7 +358,7 @@ static void advance_ring(struct i915_request *request)
 * is just about to be. Either works, if we miss the last two
 * noops - they are safe to be replayed on a reset.
 */
-   tail = READ_ONCE(request->ring->tail);
+   tail = READ_ONCE(request->tail);
} else {
tail = request->postfix;
}
-- 
2.16.2

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

[Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

[Chris Wilson]

tasklet_kill() will spin waiting for the current tasklet to be executed.
However, if tasklet_disable() has been called, then the tasklet is never
executed but permanently put back onto the runlist until
tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
disable/enable pair. This is the case when we call set-wedge from inside
i915_reset(), and another request was submitted to us concurrent to the
reset.

Fixes: 963ddd63c314 ("drm/i915: Suspend submission tasklets around wedging")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3b44952e089f..e75af06904b7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2941,7 +2941,8 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs 
*engine)
 * Turning off the execlists->tasklet until the reset is over
 * prevents the race.
 */
-   tasklet_kill(>execlists.tasklet);
+   if (!atomic_read(>execlists.tasklet.count))
+   tasklet_kill(>execlists.tasklet);
tasklet_disable(>execlists.tasklet);
 
/*
-- 
2.16.2

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

[Intel-gfx] [PATCH 5/6] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

[Chris Wilson]

Similar to the staging around handling of engine->submit_request, we
need to stop adding to the execlists->queue prior to calling
engine->cancel_requests. cancel_requests will move requests from the
queue onto the timeline, so if we add a request onto the queue after that
point, it will be lost.

Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 13 +++--
 drivers/gpu/drm/i915/i915_request.c |  2 ++
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 30cd07ebcb8e..3b44952e089f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -471,10 +471,11 @@ static void __fence_set_priority(struct dma_fence *fence, 
int prio)
 
rq = to_request(fence);
engine = rq->engine;
-   if (!engine->schedule)
-   return;
 
-   engine->schedule(rq, prio);
+   rcu_read_lock();
+   if (engine->schedule)
+   engine->schedule(rq, prio);
+   rcu_read_unlock();
 }
 
 static void fence_set_priority(struct dma_fence *fence, int prio)
@@ -3214,8 +3215,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 */
for_each_engine(engine, i915, id) {
i915_gem_reset_prepare_engine(engine);
+
engine->submit_request = nop_submit_request;
+   engine->schedule = NULL;
}
+   i915->caps.scheduler = 0;
 
/*
 * Make sure no one is running the old callback before we proceed with
@@ -3233,11 +3237,8 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 * start to complete all requests.
 */
engine->submit_request = nop_complete_submit_request;
-   engine->schedule = NULL;
}
 
-   i915->caps.scheduler = 0;
-
/*
 * Make sure no request can slip through without getting completed by
 * either this call here to intel_engine_init_global_seqno, or the one
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 69b378a323fc..0258449579f8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1082,8 +1082,10 @@ void __i915_request_add(struct i915_request *request, 
bool flush_caches)
 * decide whether to preempt the entire chain so that it is ready to
 * run at the earliest possible convenience.
 */
+   rcu_read_lock();
if (engine->schedule)
engine->schedule(request, request->ctx->priority);
+   rcu_read_unlock();
 
local_bh_disable();
i915_sw_fence_commit(>submit);
-- 
2.16.2

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

[Intel-gfx] [PATCH 1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

[Chris Wilson]

Before we reset the GPU after marking the device as wedged, we wait for
all the remaining requests to be completed (and marked as EIO).
Afterwards, we should flush the request lists so the next batch start
with the driver in an idle start.

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

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a5bd07338b46..30cd07ebcb8e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3273,7 +3273,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
if (!test_bit(I915_WEDGED, >gpu_error.flags))
return true;
 
-   /* Before unwedging, make sure that all pending operations
+   /*
+* Before unwedging, make sure that all pending operations
 * are flushed and errored out - we may have requests waiting upon
 * third party fences. We marked all inflight requests as EIO, and
 * every execbuf since returned EIO, for consistency we want all
@@ -3291,7 +3292,8 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
if (!rq)
continue;
 
-   /* We can't use our normal waiter as we want to
+   /*
+* We can't use our normal waiter as we want to
 * avoid recursively trying to handle the current
 * reset. The basic dma_fence_default_wait() installs
 * a callback for dma_fence_signal(), which is
@@ -3306,8 +3308,11 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
return false;
}
}
+   i915_retire_requests(i915);
+   GEM_BUG_ON(i915->gt.active_requests);
 
-   /* Undo nop_submit_request. We prevent all new i915 requests from
+   /*
+* Undo nop_submit_request. We prevent all new i915 requests from
 * being queued (by disallowing execbuf whilst wedged) so having
 * waited for all active requests above, we know the system is idle
 * and do not have to worry about a thread being inside
-- 
2.16.2

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

[Intel-gfx] [PATCH 4/6] drm/i915: Include ring->emit in debugging

[Chris Wilson]

Include ring->emit and ring->space alongside ring->(head,tail) when
printing debug information.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  4 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++---
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e838c765b251..4de0a52f14a9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1923,8 +1923,8 @@ static int i915_gem_framebuffer_info(struct seq_file *m, 
void *data)
 
 static void describe_ctx_ring(struct seq_file *m, struct intel_ring *ring)
 {
-   seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u)",
-  ring->space, ring->head, ring->tail);
+   seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u, emit: %u)",
+  ring->space, ring->head, ring->tail, ring->emit);
 }
 
 static int i915_context_status(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 4ba139c27fba..e71bd6951d9b 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1929,12 +1929,16 @@ void intel_engine_dump(struct intel_engine_cs *engine,
   rq->head, rq->postfix, rq->tail,
   rq->batch ? upper_32_bits(rq->batch->node.start) : 
~0u,
   rq->batch ? lower_32_bits(rq->batch->node.start) : 
~0u);
-   drm_printf(m, "\t\tring->start: 0x%08x\n",
+   drm_printf(m, "\t\tring->start : 0x%08x\n",
   i915_ggtt_offset(rq->ring->vma));
-   drm_printf(m, "\t\tring->head:  0x%08x\n",
+   drm_printf(m, "\t\tring->head:   0x%08x\n",
   rq->ring->head);
-   drm_printf(m, "\t\tring->tail:  0x%08x\n",
+   drm_printf(m, "\t\tring->tail:   0x%08x\n",
   rq->ring->tail);
+   drm_printf(m, "\t\tring->emit:   0x%08x\n",
+  rq->ring->emit);
+   drm_printf(m, "\t\tring->space:  0x%08x\n",
+  rq->ring->space);
}
 
rcu_read_unlock();
-- 
2.16.2

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

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

[Ville Syrjälä]

On Wed, Mar 07, 2018 at 01:10:26PM +0100, Maarten Lankhorst wrote:
> This will get rid of the following error:
> [   74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 
> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> [   74.730311] Modules linked in: vgem snd_hda_codec_hdmi 
> snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal 
> intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec 
> crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib 
> snd_pcm tg3 lpc_ich mei_me mei prime_numbers
> [   74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U   
> 4.16.0-rc2-CI-CI_DRM_3822+ #1
> [   74.730355] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
> [   74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0
> [   74.730361] RSP: 0018:88022fb03d10 EFLAGS: 00010086
> [   74.730365] RAX: a0291d20 RBX: 88021a18 RCX: 
> 0001
> [   74.730367] RDX: 820e7db8 RSI: 0001 RDI: 
> 82068cea
> [   74.730369] RBP: 88022fb03d70 R08:  R09: 
> 815d26d0
> [   74.730371] R10:  R11: a0161ca0 R12: 
> 0001
> [   74.730373] R13: 880212448008 R14: 880212448330 R15: 
> 
> [   74.730376] FS:  () GS:88022fb0() 
> knlGS:
> [   74.730378] CS:  0010 DS:  ES:  CR0: 80050033
> [   74.730380] CR2: 55edcbec9000 CR3: 02210001 CR4: 
> 000606e0
> [   74.730382] Call Trace:
> [   74.730385]  
> [   74.730397]  drm_get_last_vbltimestamp+0x36/0x50
> [   74.730401]  drm_update_vblank_count+0x64/0x240
> [   74.730409]  drm_crtc_accurate_vblank_count+0x41/0x90
> [   74.730453]  display_pipe_crc_irq_handler+0x176/0x220 [i915]
> [   74.730497]  i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915]
> [   74.730537]  ironlake_irq_handler+0x618/0xa30 [i915]
> [   74.730548]  __handle_irq_event_percpu+0x3c/0x340
> [   74.730556]  handle_irq_event_percpu+0x1b/0x50
> [   74.730561]  handle_irq_event+0x2f/0x50
> [   74.730566]  handle_edge_irq+0xe4/0x1b0
> [   74.730572]  handle_irq+0x11/0x20
> [   74.730576]  do_IRQ+0x5e/0x120
> [   74.730584]  common_interrupt+0x84/0x84
> [   74.730586]  
> [   74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350
> [   74.730593] RSP: 0018:c908beb8 EFLAGS: 0212 ORIG_RAX: 
> ffde
> [   74.730597] RAX: 880226b80040 RBX: 0031fc3e RCX: 
> 0001
> [   74.730599] RDX:  RSI: 8210fb59 RDI: 
> 820c02e7
> [   74.730601] RBP: 0004 R08: 40af R09: 
> 0018
> [   74.730603] R10:  R11:  R12: 
> 0004
> [   74.730606] R13: e8d00430 R14: 001166120bf4 R15: 
> 82294460
> [   74.730621]  ? cpuidle_enter_state+0xa6/0x350
> [   74.730629]  do_idle+0x188/0x1d0
> [   74.730636]  cpu_startup_entry+0x14/0x20
> [   74.730641]  start_secondary+0x129/0x160
> [   74.730646]  secondary_startup_64+0xa5/0xb0
> [   74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 06 
> 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff <0f> 
> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41
> [   74.730754] ---[ end trace 14b1345705b68565 ]---
> 
> Changes since v1:
> - Don't try to apply CRC workaround when enabling pipe, it should already be 
> enabled.
> 
> Cc: Marta Löfstedt 
> Reported-by: Marta Löfstedt 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c  |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h  |  3 +++
>  drivers/gpu/drm/i915/intel_pipe_crc.c | 44 
> +--
>  3 files changed, 42 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 331084082545..67d13fe4c24f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12147,6 +12147,7 @@ static void intel_update_crtc(struct drm_crtc *crtc,
>   if (modeset) {
>   update_scanline_offset(intel_crtc);
>   dev_priv->display.crtc_enable(pipe_config, state);
> + intel_crtc_enable_pipe_crc(crtc);

I think I'd prefer this to live next to the vblank on/off, with a
comment. Putting it here gives absolutely no clue why we have to
do it.

>   } else {
>   intel_pre_plane_update(to_intel_crtc_state(old_crtc_state),
>  pipe_config);
> @@ -12327,6 +12328,7 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
>  
>   if (old_crtc_state->active) {
>   intel_crtc_disable_planes(crtc, 
> 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2)
URL   : https://patchwork.freedesktop.org/series/39508/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#105341 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-top-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +1
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368 +2
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
pass   -> FAIL   (shard-apl) fdo#101623
Test kms_rotation_crc:
Subgroup primary-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#99912
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252 +1

fdo#105341 https://bugs.freedesktop.org/show_bug.cgi?id=105341
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3295 pass:1735 dwarn:1   dfail:0   fail:6   skip:1550 
time:11368s
shard-hswtotal:3394 pass:1736 dwarn:1   dfail:0   fail:3   skip:1652 
time:11380s
shard-snbtotal:3467 pass:1363 dwarn:2   dfail:0   fail:1   skip:2101 
time:7046s
Blacklisted hosts:
shard-kbltotal:3381 pass:1883 dwarn:14  dfail:1   fail:9   skip:1473 
time:8857s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Assert that the request is indeed complete when signaled from irq

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-05 12:25:21)
> 
> On 05/03/2018 11:21, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-03-05 11:12:45)
> >>
> >> On 05/03/2018 10:41, Chris Wilson wrote:
> >>> After we call dma_fence_signal(), confirm that the request was indeed
> >>> complete.
> >>>
> >>> Signed-off-by: Chris Wilson 
> >>> Cc: Tvrtko Ursulin 
> >>> ---
> >>>drivers/gpu/drm/i915/i915_irq.c | 1 +
> >>>1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >>> b/drivers/gpu/drm/i915/i915_irq.c
> >>> index ce16003ef048..633c18785c1e 100644
> >>> --- a/drivers/gpu/drm/i915/i915_irq.c
> >>> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >>> @@ -1123,6 +1123,7 @@ static void notify_ring(struct intel_engine_cs 
> >>> *engine)
> >>>
> >>>if (rq) {
> >>>dma_fence_signal(>fence);
> >>> + GEM_BUG_ON(!i915_request_completed(rq));
> >>>i915_request_put(rq);
> >>>}
> >>>
> >>>
> >>
> >> What's the motivation? There is a i915_seqno_passed check a few lines
> > 
> > The seqno check is on wait.seqno, this is to confirm it all ties
> > together with the request and our preemption avoidance is solid. The
> > motivation was the bug in the signaler along the same lines.
> > 
> >> above. So there would have to be a confusion in internal breadcrumbs
> >> state for this to be possible. In which case I'd rather put the assert
> >> in breadcrumbs code. For instance in intel_wait_check_request, asserting
> >> that the seqno in wait matches the seqno in wait->request.
> > 
> > The entire point of that check is to say when they don't match so that
> > we know when the request was unsubmitted during the wait.
> 
> Ok my suggesting wasn't really appropriate. I just disliked a bit open 
> coding the assert. No smart and worthwhile suggestions to improve it. 
> i915_request_signal came to mind to wrap the assert and dma_fence_signal 
> but I dont see sufficient call sites.

i915_request_signal() isn't a bad suggestion. We don't want many
dma_fence_signal() callsites but on all occasions the assertion should
hold true.

I'll try to remember for next time I'm passing.

> Reviewed-by: Tvrtko Ursulin 

Thanks and pushed,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Make header i915_pmu.h more robust

[Tvrtko Ursulin]

On 07/03/2018 12:47, Michal Wajdeczko wrote:

Definitions in i915_pmu.h header depend on other types and
declarations that were not explicitly included. Fix that by
adding related headers and forward declarations.
While here, change license text to SPDX format.

v2: don't drop "intel_ringbuffer.h" (Tvrtko)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


---
  drivers/gpu/drm/i915/i915_pmu.c | 27 +++
  drivers/gpu/drm/i915/i915_pmu.h | 30 ++
  2 files changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 964467b..4bc7aef 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -1,33 +1,12 @@
  /*
- * Copyright © 2017 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.
+ * SPDX-License-Identifier: MIT
   *
+ * Copyright © 2017-2018 Intel Corporation
   */
  
-#include 

-#include 
-
-#include "i915_drv.h"
  #include "i915_pmu.h"
  #include "intel_ringbuffer.h"
+#include "i915_drv.h"
  
  /* Frequency for the sampling timer for events which need it. */

  #define FREQUENCY 200
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index aa1b1a9..2ba7352 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -1,29 +1,19 @@
  /*
- * Copyright © 2017 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.
+ * SPDX-License-Identifier: MIT
   *
+ * Copyright © 2017-2018 Intel Corporation
   */
+
  #ifndef __I915_PMU_H__
  #define __I915_PMU_H__
  
+#include 

+#include 
+#include 
+#include 
+
+struct drm_i915_private;
+
  enum {
__I915_SAMPLE_FREQ_ACT = 0,
__I915_SAMPLE_FREQ_REQ,


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

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

[Tvrtko Ursulin]

On 07/03/2018 12:47, Michal Wajdeczko wrote:

Header intel_ringbuffer.h is using definitions from i915_reg.h
but forget to include it. Remove this hidden dependency by
explicitly include missing header.

v2: add reminder (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin  #1


Reviewed-by: Tvrtko Ursulin 


---
  drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 26605f3..e4933dd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -7,6 +7,7 @@
  #include "i915_gem_batch_pool.h"
  #include "i915_gem_timeline.h"
  
+#include "i915_reg.h" /* FIXME split out i915_gpu_commands.h */

  #include "i915_pmu.h"
  #include "i915_request.h"
  #include "i915_selftest.h"


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

[Intel-gfx] [PATCH v2 1/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

[Michal Wajdeczko]

Header intel_ringbuffer.h is using definitions from i915_reg.h
but forget to include it. Remove this hidden dependency by
explicitly include missing header.

v2: add reminder (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin  #1
---
 drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 26605f3..e4933dd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -7,6 +7,7 @@
 #include "i915_gem_batch_pool.h"
 #include "i915_gem_timeline.h"
 
+#include "i915_reg.h" /* FIXME split out i915_gpu_commands.h */
 #include "i915_pmu.h"
 #include "i915_request.h"
 #include "i915_selftest.h"
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 2/4] drm/i915: Change parameters order in i915_gem_batch_pool_init

[Michal Wajdeczko]

Function i915_gem_batch_pool_init() failed to follow obj-verb
naming schema. Fix that by swapping function parameters.
While here, change license text to SPDX format.

v2: use intel_engine_init_batch_pool (Chris) as proxy (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 30 ++
 drivers/gpu/drm/i915/i915_gem_batch_pool.h | 29 +
 drivers/gpu/drm/i915/intel_engine_cs.c |  9 ++---
 3 files changed, 17 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index d3cbe84..f3890b6 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -1,29 +1,11 @@
 /*
- * Copyright © 2014 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.
+ * SPDX-License-Identifier: MIT
  *
+ * Copyright © 2014-2018 Intel Corporation
  */
 
-#include "i915_drv.h"
 #include "i915_gem_batch_pool.h"
+#include "i915_drv.h"
 
 /**
  * DOC: batch pool
@@ -41,11 +23,11 @@
 
 /**
  * i915_gem_batch_pool_init() - initialize a batch buffer pool
- * @engine: the associated request submission engine
  * @pool: the batch buffer pool
+ * @engine: the associated request submission engine
  */
-void i915_gem_batch_pool_init(struct intel_engine_cs *engine,
- struct i915_gem_batch_pool *pool)
+void i915_gem_batch_pool_init(struct i915_gem_batch_pool *pool,
+ struct intel_engine_cs *engine)
 {
int n;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.h 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
index 10d5ac4..56947da 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.h
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
@@ -1,31 +1,13 @@
 /*
- * Copyright © 2014 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.
+ * SPDX-License-Identifier: MIT
  *
+ * Copyright © 2014-2018 Intel Corporation
  */
 
 #ifndef I915_GEM_BATCH_POOL_H
 #define I915_GEM_BATCH_POOL_H
 
-#include "i915_drv.h"
+#include 
 
 struct intel_engine_cs;
 
@@ -34,9 +16,8 @@ struct i915_gem_batch_pool {
struct list_head cache_list[4];
 };
 
-/* i915_gem_batch_pool.c */
-void i915_gem_batch_pool_init(struct intel_engine_cs *engine,
- struct i915_gem_batch_pool *pool);
+void i915_gem_batch_pool_init(struct i915_gem_batch_pool *pool,
+ struct intel_engine_cs *engine);
 void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
 struct drm_i915_gem_object*
 i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool, size_t size);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 

[Intel-gfx] [PATCH v2 4/4] drm/i915: Move i915_gpu_error into its own header

[Michal Wajdeczko]

Error state management code was moved into separate .c unit
but we didn't move related definitions into own header.

v2: move also intel_display_error_state forward decl
fix ("Prefer 'unsigned int' to bare use of 'unsigned'")
warnings detected by checkpatch in moved code (Michal)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h   | 332 +--
 drivers/gpu/drm/i915/i915_gpu_error.c |   1 +
 drivers/gpu/drm/i915/i915_gpu_error.h | 355 ++
 3 files changed, 357 insertions(+), 331 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gpu_error.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7eec99d7..6728f9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -72,7 +72,7 @@
 #include "i915_gem_object.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_timeline.h"
-
+#include "i915_gpu_error.h"
 #include "i915_request.h"
 #include "i915_vma.h"
 
@@ -453,172 +453,6 @@ struct intel_csr {
uint32_t allowed_dc_mask;
 };
 
-struct intel_display_error_state;
-
-struct i915_gpu_state {
-   struct kref ref;
-   ktime_t time;
-   ktime_t boottime;
-   ktime_t uptime;
-
-   struct drm_i915_private *i915;
-
-   char error_msg[128];
-   bool simulated;
-   bool awake;
-   bool wakelock;
-   bool suspended;
-   int iommu;
-   u32 reset_count;
-   u32 suspend_count;
-   struct intel_device_info device_info;
-   struct intel_driver_caps driver_caps;
-   struct i915_params params;
-
-   struct i915_error_uc {
-   struct intel_uc_fw guc_fw;
-   struct intel_uc_fw huc_fw;
-   struct drm_i915_error_object *guc_log;
-   } uc;
-
-   /* Generic register state */
-   u32 eir;
-   u32 pgtbl_er;
-   u32 ier;
-   u32 gtier[4], ngtier;
-   u32 ccid;
-   u32 derrmr;
-   u32 forcewake;
-   u32 error; /* gen6+ */
-   u32 err_int; /* gen7 */
-   u32 fault_data0; /* gen8, gen9 */
-   u32 fault_data1; /* gen8, gen9 */
-   u32 done_reg;
-   u32 gac_eco;
-   u32 gam_ecochk;
-   u32 gab_ctl;
-   u32 gfx_mode;
-
-   u32 nfence;
-   u64 fence[I915_MAX_NUM_FENCES];
-   struct intel_overlay_error_state *overlay;
-   struct intel_display_error_state *display;
-
-   struct drm_i915_error_engine {
-   int engine_id;
-   /* Software tracked state */
-   bool idle;
-   bool waiting;
-   int num_waiters;
-   unsigned long hangcheck_timestamp;
-   bool hangcheck_stalled;
-   enum intel_engine_hangcheck_action hangcheck_action;
-   struct i915_address_space *vm;
-   int num_requests;
-   u32 reset_count;
-
-   /* position of active request inside the ring */
-   u32 rq_head, rq_post, rq_tail;
-
-   /* our own tracking of ring head and tail */
-   u32 cpu_ring_head;
-   u32 cpu_ring_tail;
-
-   u32 last_seqno;
-
-   /* Register state */
-   u32 start;
-   u32 tail;
-   u32 head;
-   u32 ctl;
-   u32 mode;
-   u32 hws;
-   u32 ipeir;
-   u32 ipehr;
-   u32 bbstate;
-   u32 instpm;
-   u32 instps;
-   u32 seqno;
-   u64 bbaddr;
-   u64 acthd;
-   u32 fault_reg;
-   u64 faddr;
-   u32 rc_psmi; /* sleep state */
-   u32 semaphore_mboxes[I915_NUM_ENGINES - 1];
-   struct intel_instdone instdone;
-
-   struct drm_i915_error_context {
-   char comm[TASK_COMM_LEN];
-   pid_t pid;
-   u32 handle;
-   u32 hw_id;
-   int priority;
-   int ban_score;
-   int active;
-   int guilty;
-   bool bannable;
-   } context;
-
-   struct drm_i915_error_object {
-   u64 gtt_offset;
-   u64 gtt_size;
-   int page_count;
-   int unused;
-   u32 *pages[0];
-   } *ringbuffer, *batchbuffer, *wa_batchbuffer, *ctx, *hws_page;
-
-   struct drm_i915_error_object **user_bo;
-   long user_bo_count;
-
-   struct drm_i915_error_object *wa_ctx;
-   struct drm_i915_error_object *default_state;
-
-   struct drm_i915_error_request {
-   long jiffies;
-   pid_t pid;
-   u32 context;
-   

[Intel-gfx] [PATCH v2 3/4] drm/i915: Make header i915_pmu.h more robust

[Michal Wajdeczko]

Definitions in i915_pmu.h header depend on other types and
declarations that were not explicitly included. Fix that by
adding related headers and forward declarations.
While here, change license text to SPDX format.

v2: don't drop "intel_ringbuffer.h" (Tvrtko)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 27 +++
 drivers/gpu/drm/i915/i915_pmu.h | 30 ++
 2 files changed, 13 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 964467b..4bc7aef 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -1,33 +1,12 @@
 /*
- * Copyright © 2017 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.
+ * SPDX-License-Identifier: MIT
  *
+ * Copyright © 2017-2018 Intel Corporation
  */
 
-#include 
-#include 
-
-#include "i915_drv.h"
 #include "i915_pmu.h"
 #include "intel_ringbuffer.h"
+#include "i915_drv.h"
 
 /* Frequency for the sampling timer for events which need it. */
 #define FREQUENCY 200
diff --git a/drivers/gpu/drm/i915/i915_pmu.h b/drivers/gpu/drm/i915/i915_pmu.h
index aa1b1a9..2ba7352 100644
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@ -1,29 +1,19 @@
 /*
- * Copyright © 2017 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.
+ * SPDX-License-Identifier: MIT
  *
+ * Copyright © 2017-2018 Intel Corporation
  */
+
 #ifndef __I915_PMU_H__
 #define __I915_PMU_H__
 
+#include 
+#include 
+#include 
+#include 
+
+struct drm_i915_private;
+
 enum {
__I915_SAMPLE_FREQ_ACT = 0,
__I915_SAMPLE_FREQ_REQ,
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 4/6] drm/i915/icl: Enhanced execution list support

[Chris Wilson]

Quoting Mika Kuoppala (2018-03-02 16:14:59)
> From: Thomas Daniel 
> 
> Enhanced Execlists is an upgraded version of execlists which supports
> up to 8 ports. The lrcs to be submitted are written to a submit queue
> (the ExecLists Submission Queue - ELSQ), which is then loaded on the
> HW. When writing to the ELSP register, the lrcs are written cyclically
> in the queue from position 0 to position 7. Alternatively, it is
> possible to write directly in the individual positions of the queue
> using the ELSQC registers. To be able to re-use all the existing code
> we're using the latter method and we're currently limiting ourself to
> only using 2 elements.
> 
> v2: Rebase.
> v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
> v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
> v5: Reword commit, rename regs to be closer to specs, turn off
> preemption (Daniele), reuse engine->execlists.elsp (Chris)
> v6: use has_logical_ring_elsq to differentiate the new paths
> v7: add preemption support, rename els to submit_reg (Chris)
> v8: save the ctrl register inside the execlists struct, drop CSB
> handling updates (superseded by preempt_complete_status) (Chris)
> v9: s/drm_i915_gem_request/i915_request (Mika)
> v10: resolved conflict in inject_preempt_context (Mika)
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Thomas Daniel 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Daniele Ceraolo Spurio 
> Reviewed-by: Chris Wilson  (v8)
Reviewed-by: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2)
URL   : https://patchwork.freedesktop.org/series/39508/
State : success

== Summary ==

Series 39508v2 drm/i915: Handle pipe CRC around enabling/disabling pipe.
https://patchwork.freedesktop.org/api/1.0/series/39508/revisions/2/mbox/

 Known issues:

Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:423s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:504s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:466s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:502s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:425s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:466s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:434s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:521s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:533s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:507s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s

8a4eb4556f66d7ab7ad512d5c3d239da8de6b750 drm-tip: 2018y-03m-06d-22h-59m-29s UTC 
integration manifest
f64f76ced1a4 drm/i915: Handle pipe CRC around enabling/disabling pipe.

== Logs ==

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