Re: [Intel-gfx] [PATCH] drm/i915: Check ppgtt validity for GVT GEM context

2018-10-10 Thread Zhenyu Wang
On 2018.10.09 14:08:20 +0800, Xiong Zhang wrote:
> The guest couldn't boot up under GVT-g environment as the following call
> trace exists:
> [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 
> 0100
> [  272.504834] Call Trace:
> [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
> [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
> [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
> [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
> [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
> 
> GVT GEM context is created by i915_gem_context_create_gvt() which doesn't
> allocate ppgtt. So GVT GEM context structure doesn't have a valid
> i915_hw_ppgtt.
> 
> GVT maintain a shadow ppgtt for each guest ppgtt, and attach this shadow
> ppgtt to gpu when the corresponding guest ppgtt will be scheduled onto gpu.
> The structure of shadow ppgtt is different from i915_hw_ppgtt, a lot of gvt
> refactor work should be done in order to use i915_hw_ppgtt structure.
> So let's fix the regression first.
> 
> Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for 
> execlists")
> 
> Signed-off-by: Xiong Zhang 
> ---

Chris, any comment? Without this, current gvt breaks on drm tip with kernel 
oops.
Could we fix the regression first then check gvt ctx stub ppgtt handling later?
Which would require more change on gvt side, not sure if need any more helper 
from
i915 ppgtt code with a clean fix..

Thanks

>  drivers/gpu/drm/i915/intel_lrc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ff0e2b3..d604d8a 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -385,7 +385,7 @@ static u64 execlists_update_context(struct i915_request 
> *rq)
>* PML4 is allocated during ppgtt init, so this is not needed
>* in 48-bit mode.
>*/
> - if (!i915_vm_is_48bit(>vm))
> + if (ppgtt && !i915_vm_is_48bit(>vm))
>   execlists_update_context_pdps(ppgtt, reg_state);
>  
>   return ce->lrc_desc;
> @@ -1210,7 +1210,6 @@ execlists_context_pin(struct intel_engine_cs *engine,
>   struct intel_context *ce = to_intel_context(ctx, engine);
>  
>   lockdep_assert_held(>i915->drm.struct_mutex);
> - GEM_BUG_ON(!ctx->ppgtt);
>  
>   if (likely(ce->pin_count++))
>   return ce;
> @@ -2538,7 +2537,7 @@ static void execlists_init_reg_state(u32 *regs,
>   CTX_REG(regs, CTX_PDP0_UDW, GEN8_RING_PDP_UDW(engine, 0), 0);
>   CTX_REG(regs, CTX_PDP0_LDW, GEN8_RING_PDP_LDW(engine, 0), 0);
>  
> - if (i915_vm_is_48bit(>ppgtt->vm)) {
> + if (ctx->ppgtt && i915_vm_is_48bit(>ppgtt->vm)) {
>   /* 64b PPGTT (48bit canonical)
>* PDP0_DESCRIPTOR contains the base address to PML4 and
>* other PDP Descriptors are ignored.
> -- 
> 2.7.4
> 

-- 
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.IGT: success for drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK
URL   : https://patchwork.freedesktop.org/series/50815/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4964_full -> Patchwork_10416_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_ctx_isolation@vcs0-s3:
  shard-skl:  PASS -> INCOMPLETE (fdo#104108, fdo#107773)

igt@gem_mmap@bad-object:
  shard-apl:  PASS -> DMESG-WARN (fdo#103558, fdo#105602)

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-skl:  NOTRUN -> TIMEOUT (fdo#108039)

igt@gem_pwrite@huge-gtt-fbr:
  shard-snb:  NOTRUN -> INCOMPLETE (fdo#105411)

igt@kms_addfb_basic@bo-too-small-due-to-tiling:
  shard-snb:  NOTRUN -> DMESG-WARN (fdo#107469) +5

igt@kms_available_modes_crc@available_mode_test_crc:
  shard-apl:  PASS -> FAIL (fdo#106641)

igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
  shard-skl:  NOTRUN -> DMESG-WARN (fdo#107956)

igt@kms_cursor_crc@cursor-128x128-random:
  shard-apl:  PASS -> FAIL (fdo#103232) +1

igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
  shard-glk:  PASS -> DMESG-WARN (fdo#106538, fdo#105763) +1

igt@kms_cursor_legacy@pipe-a-single-move:
  shard-glk:  PASS -> INCOMPLETE (fdo#103359, k.org#198133)

igt@kms_fbcon_fbt@psr:
  shard-skl:  NOTRUN -> FAIL (fdo#107882)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
  shard-apl:  PASS -> FAIL (fdo#103167) +1

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
  shard-skl:  NOTRUN -> FAIL (fdo#103167)

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
  shard-glk:  PASS -> FAIL (fdo#103167) +2

igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-cpu:
  shard-glk:  PASS -> DMESG-FAIL (fdo#106538)

igt@kms_frontbuffer_tracking@fbc-stridechange:
  shard-skl:  NOTRUN -> FAIL (fdo#105683)

igt@kms_plane@pixel-format-pipe-b-planes:
  shard-skl:  NOTRUN -> DMESG-FAIL (fdo#103166, fdo#106885)

{igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb}:
  shard-skl:  NOTRUN -> FAIL (fdo#108145)

igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
  shard-apl:  PASS -> FAIL (fdo#103166) +1

igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
  shard-skl:  NOTRUN -> FAIL (fdo#103166)

igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
  shard-glk:  PASS -> FAIL (fdo#103166)

igt@kms_setmode@basic:
  shard-apl:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@debugfs_test@read_all_entries_display_off:
  shard-skl:  INCOMPLETE (fdo#104108) -> PASS

igt@drv_hangman@error-state-capture-render:
  shard-glk:  INCOMPLETE (fdo#103359, k.org#198133) -> PASS

igt@drv_suspend@shrink:
  shard-glk:  INCOMPLETE (fdo#106886, fdo#103359, k.org#198133) -> 
PASS

igt@gem_mmap_gtt@medium-copy-xy:
  shard-apl:  INCOMPLETE (fdo#103927) -> PASS

igt@gem_workarounds@suspend-resume-fd:
  shard-skl:  INCOMPLETE (fdo#104108, fdo#107773) -> PASS +1

igt@kms_cursor_crc@cursor-256x256-onscreen:
  shard-apl:  FAIL (fdo#103232) -> PASS

igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transitions-varying-size:
  shard-kbl:  DMESG-WARN (fdo#105604) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
  shard-apl:  FAIL (fdo#103167) -> PASS +1

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
  shard-glk:  FAIL (fdo#103167) -> PASS +1

igt@kms_plane@plane-position-covered-pipe-c-planes:
  shard-glk:  FAIL (fdo#103166) -> PASS

igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
  shard-apl:  FAIL (fdo#103166) -> PASS +2

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS

igt@perf_pmu@other-init-0:
  shard-snb:  INCOMPLETE (fdo#105411) -> PASS

igt@perf_pmu@rc6-runtime-pm:
  shard-glk:  FAIL (fdo#105010) -> PASS

igt@pm_rpm@gem-execbuf-stress-extra-wait:
  shard-skl:  INCOMPLETE (fdo#107807, fdo#107803) -> PASS


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

  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103558 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/6] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/6] drm/i915/psr: Use intel_psr_exit() in 
intel_psr_disable_source()
URL   : https://patchwork.freedesktop.org/series/50843/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4967 -> Patchwork_10420 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50843/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-cfl-8109u:   PASS -> DMESG-WARN (fdo#107345)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS


 Warnings 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-cfl-8109u:   DMESG-WARN (fdo#107345) -> INCOMPLETE (fdo#108126, 
fdo#106070)


  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070
  fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126


== Participating hosts (45 -> 41) ==

  Additional (1): fi-pnv-d510 
  Missing(5): fi-ctg-p8600 fi-bsw-cyan fi-ilk-m540 fi-byt-squawks fi-icl-u2 


== Build changes ==

* Linux: CI_DRM_4967 -> Patchwork_10420

  CI_DRM_4967: 684ab6b2f3f8406c38726f4bca2749cf71b83292 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10420: f6d1a298698cb989b2815418cf3a93ce0f0ecada @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f6d1a298698c drm/i915: Check PSR errors instead of retrain while PSR is enabled
05c85ce0b5be drm/i915: Avoid a full port detection in the first eDP short pulse
360c870bdbd8 drm/i915: Disable PSR when a PSR aux error happen
41d5f03eb1ca drm/i915/psr: Move intel_psr_disable_source() code to 
intel_psr_disable_locked()
fe951f1f71bb drm/i915/psr: Always wait for idle state when disabling PSR
c0b0cfb53d72 drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/6] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/6] drm/i915/psr: Use intel_psr_exit() in 
intel_psr_disable_source()
URL   : https://patchwork.freedesktop.org/series/50843/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()
Okay!

Commit: drm/i915/psr: Always wait for idle state when disabling PSR
Okay!

Commit: drm/i915/psr: Move intel_psr_disable_source() code to 
intel_psr_disable_locked()
Okay!

Commit: drm/i915: Disable PSR when a PSR aux error happen
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3725:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3726:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Avoid a full port detection in the first eDP short pulse
Okay!

Commit: drm/i915: Check PSR errors instead of retrain while PSR is enabled
Okay!

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


[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_crtc_background_color: overhaul for latest ABI proposal

2018-10-10 Thread Patchwork
== Series Details ==

Series: tests/kms_crtc_background_color: overhaul for latest ABI proposal
URL   : https://patchwork.freedesktop.org/series/50835/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4958 -> IGTPW_1935 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50835/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
  fi-kbl-8809g:   PASS -> DMESG-WARN (fdo#107762)

igt@kms_flip@basic-flip-vs-dpms:
  fi-hsw-4770r:   PASS -> DMESG-WARN (fdo#105602)


 Possible fixes 

igt@pm_rpm@basic-pci-d3-state:
  fi-skl-6600u:   FAIL (fdo#107707) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


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


== Participating hosts (48 -> 41) ==

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bwr-2160 
fi-bsw-cyan fi-ctg-p8600 


== Build changes ==

* IGT: IGT_4672 -> IGTPW_1935

  CI_DRM_4958: 9990e1665029dc2ef4a9c0632b8a2f516263e595 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1935: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1935/
  IGT_4672: 4497591d2572831a9f07fd9e48a2571bfcffe354 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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


[Intel-gfx] [PATCH v2 5/6] drm/i915: Avoid a full port detection in the first eDP short pulse

2018-10-10 Thread José Roberto de Souza
Some eDP panels do not set a valid sink count value and even for the
ones that sets is should always be one for eDP, that is why it is not
cached in intel_edp_init_dpcd().

But intel_dp_short_pulse() compares the old count with the read one
if there is a mistmatch a full port detection will be executed, what
was happening in the first short pulse interruption of eDP panels
that sets sink count.

Instead of just skip the compasison for eDP panels, lets not read
the sink count at all for eDP.

v2: the previous version of this patch was caching the sink count
in intel_edp_init_dpcd() but I was pointed out by Ville a patch that
handled a case of a eDP panel that do not set sink count

Cc: Ville Syrjälä 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_dp.c | 44 +++--
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 13ff89be6ad6..1826d491efd7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4034,8 +4034,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
 static bool
 intel_dp_get_dpcd(struct intel_dp *intel_dp)
 {
-   u8 sink_count;
-
if (!intel_dp_read_dpcd(intel_dp))
return false;
 
@@ -4045,25 +4043,35 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
intel_dp_set_common_rates(intel_dp);
}
 
-   if (drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, _count) <= 0)
-   return false;
-
/*
-* Sink count can change between short pulse hpd hence
-* a member variable in intel_dp will track any changes
-* between short pulse interrupts.
+* Some eDP panels do not set a valid value for sink count, that is why
+* it don't care about read it here and in intel_edp_init_dpcd().
 */
-   intel_dp->sink_count = DP_GET_SINK_COUNT(sink_count);
+   if (!intel_dp_is_edp(intel_dp)) {
+   u8 count;
+   ssize_t r;
 
-   /*
-* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
-* a dongle is present but no display. Unless we require to know
-* if a dongle is present or not, we don't need to update
-* downstream port information. So, an early return here saves
-* time from performing other operations which are not required.
-*/
-   if (!intel_dp_is_edp(intel_dp) && !intel_dp->sink_count)
-   return false;
+   r = drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, );
+   if (r < 1)
+   return false;
+
+   /*
+* Sink count can change between short pulse hpd hence
+* a member variable in intel_dp will track any changes
+* between short pulse interrupts.
+*/
+   intel_dp->sink_count = DP_GET_SINK_COUNT(count);
+
+   /*
+* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
+* a dongle is present but no display. Unless we require to know
+* if a dongle is present or not, we don't need to update
+* downstream port information. So, an early return here saves
+* time from performing other operations which are not required.
+*/
+   if (!intel_dp->sink_count)
+   return false;
+   }
 
if (!drm_dp_is_branch(intel_dp->dpcd))
return true; /* native DP sink */
-- 
2.19.1

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


[Intel-gfx] [PATCH v2 2/6] drm/i915/psr: Always wait for idle state when disabling PSR

2018-10-10 Thread José Roberto de Souza
It should always wait for idle state when disabling PSR because PSR
could be inactive due a call to intel_psr_exit() and while PSR is
still being disabled asynchronously userspace could change the
modeset causing a call to psr_disable() that will not wait for PSR
idle and then PSR will be enabled again while PSR is still not idle.

v2: rebased on top of the patch reusing psr_exit()

Cc: Rodrigo Vivi 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 41 ++--
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index f698b3f45c6d..16d0e3df7de0 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -661,8 +661,12 @@ static void intel_psr_exit(struct drm_i915_private 
*dev_priv)
 {
u32 val;
 
-   if (!dev_priv->psr.active)
+   if (!dev_priv->psr.active) {
+   if (INTEL_GEN(dev_priv) >= 9)
+   WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
+   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
return;
+   }
 
if (dev_priv->psr.psr2_enabled) {
val = I915_READ(EDP_PSR2_CTL);
@@ -680,32 +684,23 @@ static void
 intel_psr_disable_source(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   i915_reg_t psr_status;
+   u32 psr_status_mask;
 
-   if (dev_priv->psr.active) {
-   i915_reg_t psr_status;
-   u32 psr_status_mask;
-
-   intel_psr_exit(dev_priv);
+   intel_psr_exit(dev_priv);
 
-   if (dev_priv->psr.psr2_enabled) {
-   psr_status = EDP_PSR2_STATUS;
-   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
-   } else {
-   psr_status = EDP_PSR_STATUS;
-   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
-   }
-
-   /* Wait till PSR is idle */
-   if (intel_wait_for_register(dev_priv,
-   psr_status, psr_status_mask, 0,
-   2000))
-   DRM_ERROR("Timed out waiting for PSR Idle State\n");
+   if (dev_priv->psr.psr2_enabled) {
+   psr_status = EDP_PSR2_STATUS;
+   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
} else {
-   if (dev_priv->psr.psr2_enabled)
-   WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
-   else
-   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
+   psr_status = EDP_PSR_STATUS;
+   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
}
+
+   /* Wait till PSR is idle */
+   if (intel_wait_for_register(dev_priv, psr_status, psr_status_mask, 0,
+   2000))
+   DRM_ERROR("Timed out waiting for PSR Idle State\n");
 }
 
 static void intel_psr_disable_locked(struct intel_dp *intel_dp)
-- 
2.19.1

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


[Intel-gfx] [PATCH v2 3/6] drm/i915/psr: Move intel_psr_disable_source() code to intel_psr_disable_locked()

2018-10-10 Thread José Roberto de Souza
In the past we had hooks to configure HW for VLV/CHV too, in the drop
of VLV/CHV support the intel_psr_disable_source() code was not moved
to the caller, so doing it here.

Suggested-by: Dhinakaran Pandiyan 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 16d0e3df7de0..70d4e26e17b5 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -680,13 +680,20 @@ static void intel_psr_exit(struct drm_i915_private 
*dev_priv)
dev_priv->psr.active = false;
 }
 
-static void
-intel_psr_disable_source(struct intel_dp *intel_dp)
+static void intel_psr_disable_locked(struct intel_dp *intel_dp)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
i915_reg_t psr_status;
u32 psr_status_mask;
 
+   lockdep_assert_held(_priv->psr.lock);
+
+   if (!dev_priv->psr.enabled)
+   return;
+
+   DRM_DEBUG_KMS("Disabling PSR%s\n",
+ dev_priv->psr.psr2_enabled ? "2" : "1");
+
intel_psr_exit(dev_priv);
 
if (dev_priv->psr.psr2_enabled) {
@@ -701,20 +708,6 @@ intel_psr_disable_source(struct intel_dp *intel_dp)
if (intel_wait_for_register(dev_priv, psr_status, psr_status_mask, 0,
2000))
DRM_ERROR("Timed out waiting for PSR Idle State\n");
-}
-
-static void intel_psr_disable_locked(struct intel_dp *intel_dp)
-{
-   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-
-   lockdep_assert_held(_priv->psr.lock);
-
-   if (!dev_priv->psr.enabled)
-   return;
-
-   DRM_DEBUG_KMS("Disabling PSR%s\n",
- dev_priv->psr.psr2_enabled ? "2" : "1");
-   intel_psr_disable_source(intel_dp);
 
/* Disable PSR on Sink */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
-- 
2.19.1

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


[Intel-gfx] [PATCH v2 6/6] drm/i915: Check PSR errors instead of retrain while PSR is enabled

2018-10-10 Thread José Roberto de Souza
When a PSR error happens sink also update the link status values
while source do not retrain link as required in the PSR exit
sequence.
So in the short pulse handling it was returning earlier and doing a
full detection and attempting to retrain but it fails because for
most sinks the main link is disabled while PSR is active, before even
check PSR errors.

Just call intel_psr_short_pulse() before
intel_dp_needs_link_retrain() is also not the right fix as
intel_dp_needs_link_retrain() would return true and trigger a full
detection and trying to retrain link while PSR HW is also doing that.

Check for PSR active is also not safe as it could be inactive due a
frontbuffer invalidate and still doing the PSR exit sequence.

Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_dp.c  |  7 +++
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_psr.c | 15 +++
 3 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1826d491efd7..2a21a9e29eb2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4396,6 +4396,13 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
if (!intel_dp->link_trained)
return false;
 
+   /*
+* While PSR is enabled, HW will control main-link and retrain when
+* exiting PSR
+*/
+   if (intel_psr_enabled(intel_dp))
+   return false;
+
if (!intel_dp_get_link_status(intel_dp, link_status))
return false;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3dea7a1bda7f..147a116cfc71 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1958,6 +1958,7 @@ void intel_psr_irq_handler(struct drm_i915_private 
*dev_priv, u32 psr_iir);
 void intel_psr_short_pulse(struct intel_dp *intel_dp);
 int intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state,
u32 *out_value);
+bool intel_psr_enabled(struct intel_dp *intel_dp);
 
 /* intel_runtime_pm.c */
 int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index ad09130cb4ad..e4429f2f3034 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1138,3 +1138,18 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
 exit:
mutex_unlock(>lock);
 }
+
+bool intel_psr_enabled(struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   bool ret;
+
+   if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp))
+   return false;
+
+   mutex_lock(_priv->psr.lock);
+   ret = (dev_priv->psr.dp == intel_dp && dev_priv->psr.enabled);
+   mutex_unlock(_priv->psr.lock);
+
+   return ret;
+}
-- 
2.19.1

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


[Intel-gfx] [PATCH v2 1/6] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()

2018-10-10 Thread José Roberto de Souza
Both functions have the same code to disable PSR, so let's reuse that
code instead of duplicate.

Suggested-by: Dhinakaran Pandiyan 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_psr.c | 50 ++--
 1 file changed, 21 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 423cdf84059c..f698b3f45c6d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -657,6 +657,25 @@ void intel_psr_enable(struct intel_dp *intel_dp,
mutex_unlock(_priv->psr.lock);
 }
 
+static void intel_psr_exit(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   if (!dev_priv->psr.active)
+   return;
+
+   if (dev_priv->psr.psr2_enabled) {
+   val = I915_READ(EDP_PSR2_CTL);
+   WARN_ON(!(val & EDP_PSR2_ENABLE));
+   I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
+   } else {
+   val = I915_READ(EDP_PSR_CTL);
+   WARN_ON(!(val & EDP_PSR_ENABLE));
+   I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
+   }
+   dev_priv->psr.active = false;
+}
+
 static void
 intel_psr_disable_source(struct intel_dp *intel_dp)
 {
@@ -666,20 +685,14 @@ intel_psr_disable_source(struct intel_dp *intel_dp)
i915_reg_t psr_status;
u32 psr_status_mask;
 
+   intel_psr_exit(dev_priv);
+
if (dev_priv->psr.psr2_enabled) {
psr_status = EDP_PSR2_STATUS;
psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
-
-   I915_WRITE(EDP_PSR2_CTL,
-  I915_READ(EDP_PSR2_CTL) &
-  ~(EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE));
-
} else {
psr_status = EDP_PSR_STATUS;
psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
-
-   I915_WRITE(EDP_PSR_CTL,
-  I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
}
 
/* Wait till PSR is idle */
@@ -687,8 +700,6 @@ intel_psr_disable_source(struct intel_dp *intel_dp)
psr_status, psr_status_mask, 0,
2000))
DRM_ERROR("Timed out waiting for PSR Idle State\n");
-
-   dev_priv->psr.active = false;
} else {
if (dev_priv->psr.psr2_enabled)
WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
@@ -926,25 +937,6 @@ static void intel_psr_work(struct work_struct *work)
mutex_unlock(_priv->psr.lock);
 }
 
-static void intel_psr_exit(struct drm_i915_private *dev_priv)
-{
-   u32 val;
-
-   if (!dev_priv->psr.active)
-   return;
-
-   if (dev_priv->psr.psr2_enabled) {
-   val = I915_READ(EDP_PSR2_CTL);
-   WARN_ON(!(val & EDP_PSR2_ENABLE));
-   I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE);
-   } else {
-   val = I915_READ(EDP_PSR_CTL);
-   WARN_ON(!(val & EDP_PSR_ENABLE));
-   I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE);
-   }
-   dev_priv->psr.active = false;
-}
-
 /**
  * intel_psr_invalidate - Invalidade PSR
  * @dev_priv: i915 device
-- 
2.19.1

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


[Intel-gfx] [PATCH v2 4/6] drm/i915: Disable PSR when a PSR aux error happen

2018-10-10 Thread José Roberto de Souza
While PSR is active hardware will do aux transactions by it self to
wakeup sink to receive a new frame when necessary. If that
transaction is not acked by sink, hardware will trigger this
interruption.

So let's disable PSR as it is a hint that there is problem with this
sink.

The removed FIXME was asking to manually train the link but we don't
need to do that as by spec sink should do a short pulse when it is
out of sync with source, we just need to make sure it is awaken and
the SDP header with PSR disable will trigger this condition.

Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_psr.c | 39 
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef037fed..e8ba00dd2c51 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -638,6 +638,7 @@ struct i915_psr {
u8 sink_sync_latency;
ktime_t last_entry_attempt;
ktime_t last_exit;
+   u32 irq_aux_error;
 };
 
 enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 70d4e26e17b5..ad09130cb4ad 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -159,10 +159,16 @@ void intel_psr_irq_handler(struct drm_i915_private 
*dev_priv, u32 psr_iir)
   BIT(TRANSCODER_C);
 
for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
-   /* FIXME: Exit PSR and link train manually when this happens. */
-   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
-   DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
- transcoder_name(cpu_transcoder));
+   if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
+   DRM_WARN("[transcoder %s] PSR aux error\n",
+transcoder_name(cpu_transcoder));
+
+   spin_lock(_priv->irq_lock);
+   dev_priv->psr.irq_aux_error |= BIT(cpu_transcoder);
+   spin_unlock(_priv->irq_lock);
+
+   schedule_work(_priv->psr.work);
+   }
 
if (psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
dev_priv->psr.last_entry_attempt = time_ns;
@@ -893,11 +899,36 @@ int intel_psr_set_debugfs_mode(struct drm_i915_private 
*dev_priv,
return ret;
 }
 
+static void intel_psr_handle_irq(struct drm_i915_private *dev_priv)
+{
+   struct i915_psr *psr = _priv->psr;
+   u32 irq_aux_error;
+
+   spin_lock_irq(_priv->irq_lock);
+   irq_aux_error = psr->irq_aux_error;
+   psr->irq_aux_error = 0;
+   spin_unlock_irq(_priv->irq_lock);
+
+   /* right now PSR is only enabled in eDP */
+   WARN_ON(irq_aux_error & ~BIT(TRANSCODER_EDP));
+
+   mutex_lock(>lock);
+
+   intel_psr_disable_locked(psr->dp);
+   /* let's make sure that sink is awaken */
+   drm_dp_dpcd_writeb(>dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
+
+   mutex_unlock(_priv->psr.lock);
+}
+
 static void intel_psr_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), psr.work);
 
+   if (READ_ONCE(dev_priv->psr.irq_aux_error))
+   intel_psr_handle_irq(dev_priv);
+
mutex_lock(_priv->psr.lock);
 
if (!dev_priv->psr.enabled)
-- 
2.19.1

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v12,1/2] drm: Add connector property to limit max bpc

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [v12,1/2] drm: Add connector property to limit max 
bpc
URL   : https://patchwork.freedesktop.org/series/50837/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4966 -> Patchwork_10419 =

== Summary - FAILURE ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50837/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@kms_chamelium@dp-edid-read:
  fi-kbl-7500u:   PASS -> WARN


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-blb-e6850:   PASS -> INCOMPLETE (fdo#107718)

igt@kms_flip@basic-plain-flip:
  fi-ilk-650: PASS -> DMESG-WARN (fdo#106387)

igt@kms_pipe_crc_basic@read-crc-pipe-a:
  fi-byt-clapper: PASS -> FAIL (fdo#107362)


 Possible fixes 

igt@gem_exec_suspend@basic-s3:
  fi-cfl-8109u:   INCOMPLETE (fdo#107187, fdo#108126) -> PASS

igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
  fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS +1

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
  fi-byt-clapper: FAIL (fdo#107362) -> PASS


  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#106387 https://bugs.freedesktop.org/show_bug.cgi?id=106387
  fdo#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
  fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126


== Participating hosts (46 -> 41) ==

  Missing(5): fi-ctg-p8600 fi-bsw-cyan fi-ilk-m540 fi-byt-squawks fi-icl-u2 


== Build changes ==

* Linux: CI_DRM_4966 -> Patchwork_10419

  CI_DRM_4966: 0ac03a984dd32a77b02eabb6f0ef110ec5b5bdf2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10419: 9edc443b3a834eced3cc490a3a8b2bb03443c671 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9edc443b3a83 drm/i915: Allow "max bpc" property to limit pipe_bpp
6a34b028e864 drm: Add connector property to limit max bpc

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10419/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 CRTC background color

2018-10-10 Thread Patchwork
== Series Details ==

Series: CRTC background color
URL   : https://patchwork.freedesktop.org/series/50834/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4966 -> Patchwork_10418 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50834/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#105128, fdo#107139)


 Possible fixes 

igt@gem_exec_suspend@basic-s3:
  fi-cfl-8109u:   INCOMPLETE (fdo#107187, fdo#108126) -> PASS

igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
  fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS +1

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
  fi-byt-clapper: FAIL (fdo#107362) -> PASS


  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126


== Participating hosts (46 -> 41) ==

  Missing(5): fi-ctg-p8600 fi-bsw-cyan fi-ilk-m540 fi-byt-squawks fi-icl-u2 


== Build changes ==

* Linux: CI_DRM_4966 -> Patchwork_10418

  CI_DRM_4966: 0ac03a984dd32a77b02eabb6f0ef110ec5b5bdf2 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10418: a0be1f8ad993cd192497be261ebfcc25525018b9 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a0be1f8ad993 drm/i915/gen9+: Add support for pipe background color
472f325f4ac4 drm: Add CRTC background color property

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v12,1/2] drm: Add connector property to limit max bpc

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [v12,1/2] drm: Add connector property to limit max 
bpc
URL   : https://patchwork.freedesktop.org/series/50837/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm: Add connector property to limit max bpc
+drivers/gpu/drm/drm_atomic.c:397:34: warning: expression using sizeof(void)
+drivers/gpu/drm/drm_atomic.c:397:34: warning: expression using sizeof(void)

Commit: drm/i915: Allow "max bpc" property to limit pipe_bpp
+drivers/gpu/drm/i915/intel_display.c:10801:15: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_display.c:10801:15: warning: expression using 
sizeof(void)

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


[Intel-gfx] [PATCH i-g-t 3/6] lib/igt_fb: Check for cairo surface success

2018-10-10 Thread Deepak Rawat
For vmwgfx cairo surface creation fails due to stride mismatch, add a
igt_require_f() for surface.

v2: Check for surface creation failure.

Signed-off-by: Deepak Rawat 
---
 lib/igt_fb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 335ece69..1bb6d324 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -1433,6 +1433,10 @@ static void create_cairo_surface__gtt(int fd, struct 
igt_fb *fb)
cairo_image_surface_create_for_data(ptr,

drm_format_to_cairo(fb->drm_format),
fb->width, fb->height, 
fb->strides[0]);
+   igt_require_f(cairo_surface_status(fb->cairo_surface) == 
CAIRO_STATUS_SUCCESS,
+ "Unable to create a cairo surface: %s\n",
+ 
cairo_status_to_string(cairo_surface_status(fb->cairo_surface)));
+
fb->domain = I915_GEM_DOMAIN_GTT;
 
cairo_surface_set_user_data(fb->cairo_surface,
-- 
2.17.1

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


[Intel-gfx] [PATCH i-g-t 2/6] lib/igt_fb: Call dumb_destroy ioctl in case of dumb buffers

2018-10-10 Thread Deepak Rawat
vmwgfx does not support GEM interface so calling gem_close on vmwgfx
results in error.

v2: Use drmIoctl with error when ioctl() failed.

v3: Seperate ioctl wrapper.

Signed-off-by: Deepak Rawat 
---
 lib/igt_fb.c  |  5 -
 lib/igt_kms.c | 22 ++
 lib/igt_kms.h |  1 +
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 35be2e88..335ece69 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -2121,7 +2121,10 @@ void igt_remove_fb(int fd, struct igt_fb *fb)
 
cairo_surface_destroy(fb->cairo_surface);
do_or_die(drmModeRmFB(fd, fb->fb_id));
-   gem_close(fd, fb->gem_handle);
+   if (fb->is_dumb)
+   kmstest_dumb_destroy(fd, fb->gem_handle);
+   else
+   gem_close(fd, fb->gem_handle);
fb->fb_id = 0;
 }
 
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index b2cbaa11..6e499f48 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -641,6 +641,28 @@ void *kmstest_dumb_map_buffer(int fd, uint32_t handle, 
uint64_t size,
return ptr;
 }
 
+static int __kmstest_dumb_destroy(int fd, uint32_t handle)
+{
+   struct drm_mode_destroy_dumb arg = { handle };
+   int err = 0;
+
+   if (drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, ))
+   err = -errno;
+
+   errno = 0;
+   return err;
+}
+
+/**
+ * kmstest_dumb_destroy:
+ * @fd: Opened drm file descriptor
+ * @handle: Offset in the file referred to by fd
+ */
+void kmstest_dumb_destroy(int fd, uint32_t handle)
+{
+   igt_assert_eq(__kmstest_dumb_destroy(fd, handle), 0);
+}
+
 /*
  * Returns: the previous mode, or KD_GRAPHICS if no /dev/tty0 was
  * found and nothing was done.
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 38fa944e..cbfcced9 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -222,6 +222,7 @@ uint32_t kmstest_dumb_create(int fd, int width, int height, 
int bpp,
 
 void *kmstest_dumb_map_buffer(int fd, uint32_t handle, uint64_t size,
  unsigned prot);
+void kmstest_dumb_destroy(int fd, uint32_t handle);
 void kmstest_wait_for_pageflip(int fd);
 unsigned int kmstest_get_vblank(int fd, int pipe, unsigned int flags);
 void igt_assert_plane_visible(int fd, enum pipe pipe, bool visibility);
-- 
2.17.1

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


[Intel-gfx] [PATCH i-g-t 5/6] tests/kms_atomic: Add a new test case for FB_DAMAGE_CLIPS plane property

2018-10-10 Thread Deepak Rawat
Some simple test cases to use FB_DAMAGE_CLIPS plane property.

Cc: ville.syrj...@linux.intel.com
Cc: Daniel Vetter 
Cc: Pekka Paalanen 
Cc: Daniel Stone 
Signed-off-by: Deepak Rawat 
---
 lib/igt_kms.c  |   1 +
 lib/igt_kms.h  |   1 +
 tests/kms_atomic.c | 260 +
 3 files changed, 262 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 6e499f48..7a3ce2f6 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -177,6 +177,7 @@ const char * const 
igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
[IGT_PLANE_COLOR_RANGE] = "COLOR_RANGE",
[IGT_PLANE_PIXEL_BLEND_MODE] = "pixel blend mode",
[IGT_PLANE_ALPHA] = "alpha",
+   [IGT_PLANE_FB_DAMAGE_CLIPS] = "FB_DAMAGE_CLIPS",
 };
 
 const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index cbfcced9..e1c9a6a5 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -269,6 +269,7 @@ enum igt_atomic_plane_properties {
IGT_PLANE_COLOR_RANGE,
IGT_PLANE_PIXEL_BLEND_MODE,
IGT_PLANE_ALPHA,
+   IGT_PLANE_FB_DAMAGE_CLIPS,
IGT_NUM_PLANE_PROPS
 };
 
diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 3aad2d9a..20dfc978 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -56,6 +56,24 @@
 
 IGT_TEST_DESCRIPTION("Test atomic modesetting API");
 
+/* signed32 drm_mode_rect declared here for use with drm damage for page-flip 
*/
+struct damage_rect {
+   int x1;
+   int y1;
+   int x2;
+   int y2;
+};
+
+static inline int damage_rect_width(struct damage_rect *r)
+{
+   return r->x2 - r->x1;
+}
+
+static inline int damage_rect_height(struct damage_rect *r)
+{
+   return r->y2 - r->y1;
+}
+
 enum kms_atomic_check_relax {
ATOMIC_RELAX_NONE = 0,
CRTC_RELAX_MODE = (1 << 0),
@@ -835,6 +853,240 @@ static void atomic_invalid_params(igt_pipe_t *pipe,
do_ioctl_err(display->drm_fd, DRM_IOCTL_MODE_ATOMIC, , EFAULT);
 }
 
+static void atomic_plane_damage(igt_pipe_t *pipe, igt_plane_t *plane, struct 
igt_fb *fb)
+{
+   struct damage_rect *damage;
+   struct igt_fb fb_1;
+   struct igt_fb fb_2;
+   cairo_t *cr_1;
+   cairo_t *cr_2;
+
+   damage = malloc(sizeof(*damage) * 2);
+   igt_assert(damage);
+
+   /* Color fb with white rect at center */
+   igt_create_color_fb(pipe->display->drm_fd, fb->width, fb->height,
+   fb->drm_format, I915_TILING_NONE, 0.2, 0.2, 0.2,
+   _1);
+   cr_1 = igt_get_cairo_ctx(pipe->display->drm_fd, _1);
+   igt_paint_color(cr_1, fb->width/4, fb->height/4, fb->width/2,
+   fb->height/2, 1.0, 1.0, 1.0);
+   igt_put_cairo_ctx(pipe->display->drm_fd, _1, cr_1);
+
+   /*
+* Flip the primary plane to new color fb using atomic API and check the
+* state.
+*/
+   igt_plane_set_fb(plane, _1);
+   crtc_commit(pipe, plane, COMMIT_ATOMIC, ATOMIC_RELAX_NONE);
+
+   /*
+* Change the color of top left clip from center and issue plane update
+* with damage and verify the state.
+*/
+   damage[0].x1 = 0;
+   damage[0].y1 = 0;
+   damage[0].x2 = fb->width/2;
+   damage[0].y2 = fb->height/2;
+
+   cr_1 = igt_get_cairo_ctx(pipe->display->drm_fd, _1);
+   igt_paint_color(cr_1, damage[0].x1, damage[0].y1,
+   damage_rect_width([0]),
+   damage_rect_height([0]), 1.0, 0, 0);
+   igt_put_cairo_ctx(pipe->display->drm_fd, _1, cr_1);
+
+   igt_plane_set_fb(plane, _1);
+   igt_plane_replace_prop_blob(plane, IGT_PLANE_FB_DAMAGE_CLIPS, damage,
+   sizeof(*damage));
+   crtc_commit(pipe, plane, COMMIT_ATOMIC, ATOMIC_RELAX_NONE);
+
+   /*
+* Change the color of top left and bottom right clip from center and
+* issue plane update with damage and verify the state.
+*/
+   damage[0].x1 = 0;
+   damage[0].y1 = 0;
+   damage[0].x2 = fb->width/2;
+   damage[0].y2 = fb->height/2;
+
+   damage[1].x1 = fb->width/2;
+   damage[1].y1 = fb->height/2;
+   damage[1].x2 = fb->width;
+   damage[1].y2 = fb->height;
+
+   cr_1 = igt_get_cairo_ctx(pipe->display->drm_fd, _1);
+   igt_paint_color(cr_1, damage[0].x1, damage[0].y1,
+   damage_rect_width([0]),
+   damage_rect_height([0]), 1.0, 0, 1.0);
+   igt_paint_color(cr_1, damage[1].x1, damage[1].y1,
+   damage_rect_width([1]),
+   damage_rect_height([1]), 0, 0, 1.0);
+   igt_put_cairo_ctx(pipe->display->drm_fd, _1, cr_1);
+
+   igt_plane_set_fb(plane, _1);
+   igt_plane_replace_prop_blob(plane, IGT_PLANE_FB_DAMAGE_CLIPS, damage,
+   sizeof(*damage) * 2);
+   crtc_commit(pipe, plane, COMMIT_ATOMIC, ATOMIC_RELAX_NONE);
+
+   /*
+* Issue a plane update with 

[Intel-gfx] [PATCH i-g-t 4/6] lib: Don't call igt_require_fb_modifiers() when no modifier

2018-10-10 Thread Deepak Rawat
vmwgfx doesn't support fb modifier so skip igt_require_fb_modifiers()
when modifier are not passed.

Signed-off-by: Deepak Rawat 
---
 lib/ioctl_wrappers.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 0929c43f..3a11cb6e 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1678,7 +1678,10 @@ int __kms_addfb(int fd, uint32_t handle,
struct drm_mode_fb_cmd2 f;
int ret, i;
 
-   igt_require_fb_modifiers(fd);
+   if (modifier)
+   igt_require_fb_modifiers(fd);
+   else
+   flags &= ~DRM_MODE_FB_MODIFIERS;
 
memset(, 0, sizeof(f));
 
-- 
2.17.1

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


[Intel-gfx] [PATCH i-g-t 6/6] tests/plane_damage: Integrate kernel selftest test-drm_damage_helper

2018-10-10 Thread Deepak Rawat
Call kernel selftest module test-drm_damage_helper from igt.

v2:
- Add test alphabetically.
- Add test to meson build.

Cc: ville.syrj...@linux.intel.com
Cc: Daniel Vetter 
Cc: Pekka Paalanen 
Cc: Daniel Stone 
Signed-off-by: Deepak Rawat 
---
 tests/Makefile.sources|  1 +
 tests/drm_plane_damage.c  | 10 ++
 tests/igt_command_line.sh |  2 +-
 tests/meson.build |  1 +
 4 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 tests/drm_plane_damage.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 001f1a2b..eae5f39e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -32,6 +32,7 @@ TESTS_progs = \
debugfs_test \
drm_import_export \
drm_mm \
+   drm_plane_damage \
drm_read \
drv_getparams_basic \
drv_hangman \
diff --git a/tests/drm_plane_damage.c b/tests/drm_plane_damage.c
new file mode 100644
index ..c2b793cc
--- /dev/null
+++ b/tests/drm_plane_damage.c
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include "igt.h"
+#include "igt_kmod.h"
+
+IGT_TEST_DESCRIPTION("Basic sanity check of DRM's plane damage helper 
iterator.");
+
+igt_main
+{
+   igt_kselftests("test-drm_damage_helper", NULL, NULL, NULL);
+}
diff --git a/tests/igt_command_line.sh b/tests/igt_command_line.sh
index 8285ba62..621b2cbd 100755
--- a/tests/igt_command_line.sh
+++ b/tests/igt_command_line.sh
@@ -90,7 +90,7 @@ check_test ()
# Subtest enumeration of kernel selftest launchers depends
# on the running kernel. If selftests are not enabled,
# they will output nothing and exit with 0.
-   if [ "$testname" != "drv_selftest" -a "$testname" != "drm_mm" 
]; then
+   if [ "$testname" != "drv_selftest" -a "$testname" != "drm_mm" 
-a "$testname" != "drm_plane_damage" ]; then
fail $test
fi
fi
diff --git a/tests/meson.build b/tests/meson.build
index 697ff515..5acd7aa2 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -9,6 +9,7 @@ test_progs = [
'debugfs_test',
'drm_import_export',
'drm_mm',
+   'drm_plane_damage',
'drm_read',
'drv_getparams_basic',
'drv_hangman',
-- 
2.17.1

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


[Intel-gfx] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device

2018-10-10 Thread Deepak Rawat
Add DRIVER_VMWGFX to represent vmwgfx device for running igt tests.

v2: Don't remove second virtio_gpu

Signed-off-by: Deepak Rawat 
---
 lib/drmtest.c | 8 
 lib/drmtest.h | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index fee9d33a..9d013a00 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -105,6 +105,11 @@ bool is_i915_device(int fd)
return __is_device(fd, "i915");
 }
 
+bool is_vmwgfx_device(int fd)
+{
+   return __is_device(fd, "vmwg");
+}
+
 static bool has_known_intel_chipset(int fd)
 {
struct drm_i915_getparam gp;
@@ -206,6 +211,7 @@ static const struct module {
{ DRIVER_VGEM, "vgem" },
{ DRIVER_VIRTIO, "virtio-gpu" },
{ DRIVER_VIRTIO, "virtio_gpu" },
+   { DRIVER_VMWGFX, "vmwgfx" },
{}
 };
 
@@ -348,6 +354,8 @@ static const char *chipset_to_str(int chipset)
return "virtio";
case DRIVER_AMDGPU:
return "amdgpu";
+   case DRIVER_VMWGFX:
+   return "vmwgfx";
case DRIVER_ANY:
return "any";
default:
diff --git a/lib/drmtest.h b/lib/drmtest.h
index 949865ee..0213fb51 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -43,6 +43,7 @@
 #define DRIVER_VGEM(1 << 2)
 #define DRIVER_VIRTIO  (1 << 3)
 #define DRIVER_AMDGPU  (1 << 4)
+#define DRIVER_VMWGFX  (1 << 5)
 /*
  * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
  * with vgem as well as a supported driver, you can end up with a
@@ -80,6 +81,8 @@ void igt_require_intel(int fd);
 
 bool is_i915_device(int fd);
 
+bool is_vmwgfx_device(int fd);
+
 /**
  * do_or_die:
  * @x: command
-- 
2.17.1

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


[Intel-gfx] [PATCH v3 04/18] drm/selftest: Add drm damage helper selftest

2018-10-10 Thread Deepak Rawat
Selftest for drm damage helper iterator functions.

Cc: ville.syrj...@linux.intel.com
Cc: Daniel Vetter 
Cc: Pekka Paalanen 
Cc: Daniel Stone 
Cc: intel-gfx@lists.freedesktop.org
Cc: igt-...@lists.freedesktop.org
Cc: petri.latv...@intel.com
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Deepak Rawat 
---
 drivers/gpu/drm/selftests/Makefile|   3 +-
 .../selftests/drm_damage_helper_selftests.h   |  22 +
 .../drm/selftests/test-drm_damage_helper.c| 844 ++
 3 files changed, 868 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
 create mode 100644 drivers/gpu/drm/selftests/test-drm_damage_helper.c

diff --git a/drivers/gpu/drm/selftests/Makefile 
b/drivers/gpu/drm/selftests/Makefile
index 9fc349fa18e9..88ac216f5962 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm-helper.o
+obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm-helper.o \
+   test-drm_damage_helper.o
diff --git a/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h 
b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
new file mode 100644
index ..3a1cbe05bef0
--- /dev/null
+++ b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+selftest(damage_iter_no_damage, igt_damage_iter_no_damage)
+selftest(damage_iter_no_damage_fractional_src, 
igt_damage_iter_no_damage_fractional_src)
+selftest(damage_iter_no_damage_src_moved, igt_damage_iter_no_damage_src_moved)
+selftest(damage_iter_no_damage_fractional_src_moved, 
igt_damage_iter_no_damage_fractional_src_moved)
+selftest(damage_iter_no_damage_not_visible, 
igt_damage_iter_no_damage_not_visible)
+selftest(damage_iter_no_damage_no_crtc, igt_damage_iter_no_damage_no_crtc)
+selftest(damage_iter_no_damage_no_fb, igt_damage_iter_no_damage_no_fb)
+selftest(damage_iter_simple_damage, igt_damage_iter_simple_damage)
+selftest(damage_iter_single_damage, igt_damage_iter_single_damage)
+selftest(damage_iter_single_damage_intersect_src, 
igt_damage_iter_single_damage_intersect_src)
+selftest(damage_iter_single_damage_outside_src, 
igt_damage_iter_single_damage_outside_src)
+selftest(damage_iter_single_damage_fractional_src, 
igt_damage_iter_single_damage_fractional_src)
+selftest(damage_iter_single_damage_intersect_fractional_src, 
igt_damage_iter_single_damage_intersect_fractional_src)
+selftest(damage_iter_single_damage_outside_fractional_src, 
igt_damage_iter_single_damage_outside_fractional_src)
+selftest(damage_iter_single_damage_src_moved, 
igt_damage_iter_single_damage_src_moved)
+selftest(damage_iter_single_damage_fractional_src_moved, 
igt_damage_iter_single_damage_fractional_src_moved)
+selftest(damage_iter_damage, igt_damage_iter_damage)
+selftest(damage_iter_damage_one_intersect, 
igt_damage_iter_damage_one_intersect)
+selftest(damage_iter_damage_one_outside, igt_damage_iter_damage_one_outside)
+selftest(damage_iter_damage_src_moved, igt_damage_iter_damage_src_moved)
+selftest(damage_iter_damage_not_visible, igt_damage_iter_damage_not_visible)
diff --git a/drivers/gpu/drm/selftests/test-drm_damage_helper.c 
b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
new file mode 100644
index ..17754734c47a
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
@@ -0,0 +1,844 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Test case for drm_damage_helper functions
+ */
+
+#define pr_fmt(fmt) "drm_damage_helper: " fmt
+
+#include 
+#include 
+
+#define TESTS "drm_damage_helper_selftests.h"
+#include "drm_selftest.h"
+
+#define FAIL(test, msg, ...) \
+   do { \
+   if (test) { \
+   pr_err("%s/%u: " msg, __FUNCTION__, __LINE__, 
##__VA_ARGS__); \
+   return -EINVAL; \
+   } \
+   } while (0)
+
+#define FAIL_ON(x) FAIL((x), "%s", "FAIL_ON(" __stringify(x) ")\n")
+
+static void set_plane_src(struct drm_plane_state *state, int x1, int y1, int 
x2,
+ int y2)
+{
+   state->src.x1 = x1;
+   state->src.y1 = y1;
+   state->src.x2 = x2;
+   state->src.y2 = y2;
+}
+
+static void set_damage_clip(struct drm_mode_rect *r, int x1, int y1, int x2,
+   int y2)
+{
+   r->x1 = x1;
+   r->y1 = y1;
+   r->x2 = x2;
+   r->y2 = y2;
+}
+
+static void set_damage_blob(struct drm_property_blob *damage_blob,
+   struct drm_mode_rect *r, uint32_t size)
+{
+   damage_blob->length = size;
+   damage_blob->data = r;
+}
+
+static void set_plane_damage(struct drm_plane_state *state,
+struct drm_property_blob *damage_blob)
+{
+   state->fb_damage_clips = damage_blob;
+}
+
+static bool check_damage_clip(struct drm_plane_state *state, struct drm_rect 
*r,
+ int x1, 

[Intel-gfx] [PATCH v12 1/2] drm: Add connector property to limit max bpc

2018-10-10 Thread Radhakrishna Sripada
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.

Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.

V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
V9: Const display_info(Ville)
V10,V11: Fix CI issues.
V12: Add the Kernel documentation(Daniel)

Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Kishore Kadiyala 
Cc: Rodrigo Vivi 
Cc: Manasi Navare 
Cc: Stanislav Lisovskiy 
Cc: Sunpeng Li 
Acked-by: Daniel Vetter 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/drm_atomic.c|  5 +
 drivers/gpu/drm/drm_atomic_helper.c |  4 
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 
 drivers/gpu/drm/drm_connector.c | 39 +
 include/drm/drm_connector.h | 20 +++
 5 files changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2870ae205237..cd8362dc4f74 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,11 @@ static int drm_atomic_connector_check(struct drm_connector 
*connector,
 {
struct drm_crtc_state *crtc_state;
struct drm_writeback_job *writeback_job = state->writeback_job;
+   const struct drm_display_info *info = >display_info;
+
+   state->max_bpc = info->bpc ? info->bpc : 8;
+   if (connector->max_bpc_property)
+   state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
 
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) || 
!writeback_job)
return 0;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index e6a2cf72de5e..8bc919e3b271 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -669,6 +669,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->max_requested_bpc !=
+   new_connector_state->max_requested_bpc)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..86ac33922b09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 
return set_out_fence_for_connector(state->state, connector,
   fence_ptr);
+   } else if (property == connector->max_bpc_property) {
+   state->max_requested_bpc = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = 0;
} else if (property == config->writeback_out_fence_ptr_property) {
*val = 0;
+   } else if (property == connector->max_bpc_property) {
+   *val = state->max_requested_bpc;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5d01414ec9f7..a346004a1c4f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -932,6 +932,11 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, 
drm_cp_enum_list)
  *   is no longer protected and userspace should take appropriate action
  *   (whatever that might be).
  *
+ * max bpc:
+ * This range property is used by userspace to limit the bit depth. When
+ * used the driver would limit the bpc in accordance with the valid range
+ * supported by the hardware and sink.
+ *
  * Connectors also have one standardized atomic property:
  *
  * CRTC_ID:
@@ 

[Intel-gfx] [PATCH v12 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp

2018-10-10 Thread Radhakrishna Sripada
Use the newly added "max bpc" connector property to limit pipe bpp.

V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
V12: Fix debug message(Ville)

Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Kishore Kadiyala 
Cc: Manasi Navare 
Cc: Stanislav Lisovskiy 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_display.c | 48 +---
 drivers/gpu/drm/i915/intel_dp.c  |  4 +++
 drivers/gpu/drm/i915/intel_hdmi.c|  5 
 3 files changed, 37 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a145efba9157..a597c4410f5d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10869,30 +10869,38 @@ static void 
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
drm_connector_list_iter_end(_iter);
 }
 
-static void
-connected_sink_compute_bpp(struct intel_connector *connector,
-  struct intel_crtc_state *pipe_config)
+static int
+connected_sink_max_bpp(const struct drm_connector_state *conn_state,
+  struct intel_crtc_state *pipe_config)
 {
-   const struct drm_display_info *info = >base.display_info;
-   int bpp = pipe_config->pipe_bpp;
+   int bpp;
+   struct drm_display_info *info = _state->connector->display_info;
 
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
+   bpp = min(pipe_config->pipe_bpp, conn_state->max_bpc * 3);
 
-   /* Don't use an invalid EDID bpc value */
-   if (info->bpc != 0 && info->bpc * 3 < bpp) {
-   DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported 
max of %d\n",
- bpp, info->bpc * 3);
-   pipe_config->pipe_bpp = info->bpc * 3;
+   switch (conn_state->max_bpc) {
+   case 6 ... 7:
+   pipe_config->pipe_bpp = 6 * 3;
+   case 8 ... 9:
+   pipe_config->pipe_bpp = 8 * 3;
+   break;
+   case 10 ... 11:
+   pipe_config->pipe_bpp = 10 * 3;
+   break;
+   case 12:
+   pipe_config->pipe_bpp = 12 * 3;
+   break;
+   default:
+   return -EINVAL;
}
 
-   /* Clamp bpp to 8 on screens without EDID 1.4 */
-   if (info->bpc == 0 && bpp > 24) {
-   DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit 
of 24\n",
- bpp);
-   pipe_config->pipe_bpp = 24;
+   if (bpp != pipe_config->pipe_bpp) {
+   DRM_DEBUG_KMS("Limiting display bpp to %d instead of Edid bpp "
+ "%d, requested bpp %d\n", bpp, 3 * info->bpc,
+ 3 * conn_state->max_requested_bpc);
+   pipe_config->pipe_bpp = bpp;
}
+   return 0;
 }
 
 static int
@@ -10923,8 +10931,8 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != >base)
continue;
 
-   connected_sink_compute_bpp(to_intel_connector(connector),
-  pipe_config);
+   if (connected_sink_max_bpp(connector_state, pipe_config) < 0)
+   return -EINVAL;
}
 
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0855b9785f7b..863c8832fe8b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5705,6 +5705,10 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
+   if (HAS_GMCH_DISPLAY(dev_priv))
+   drm_connector_attach_max_bpc_property(connector, 6, 10);
+   else if (INTEL_GEN(dev_priv) >= 5)
+   drm_connector_attach_max_bpc_property(connector, 6, 12);
 
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2c53efc463e6..3158ab085a30 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2103,11 +2103,16 @@ static const struct drm_encoder_funcs 
intel_hdmi_enc_funcs = {
 static void
 intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector 
*connector)
 {
+   struct drm_i915_private *dev_priv = 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for CRTC background color

2018-10-10 Thread Patchwork
== Series Details ==

Series: CRTC background color
URL   : https://patchwork.freedesktop.org/series/50834/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
472f325f4ac4 drm: Add CRTC background color property
-:87: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield.  Prefer bool 
bitfields as unsigned int or u<8|16|32>
#87: FILE: include/drm/drm_crtc.h:175:
+   bool bgcolor_changed : 1;

-:155: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#155: FILE: include/uapi/drm/drm_mode.h:912:
+#define DRM_RGBA_RED(c, numbits)   (__u16)((c & 0xull) >> (16-numbits))
  ^

-:155: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to 
avoid precedence issues
#155: FILE: include/uapi/drm/drm_mode.h:912:
+#define DRM_RGBA_RED(c, numbits)   (__u16)((c & 0xull) >> (16-numbits))

-:155: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as 
'(numbits)' to avoid precedence issues
#155: FILE: include/uapi/drm/drm_mode.h:912:
+#define DRM_RGBA_RED(c, numbits)   (__u16)((c & 0xull) >> (16-numbits))

-:156: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#156: FILE: include/uapi/drm/drm_mode.h:913:
+#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits))
  ^

-:156: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#156: FILE: include/uapi/drm/drm_mode.h:913:
+#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits))
  ^

-:156: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to 
avoid precedence issues
#156: FILE: include/uapi/drm/drm_mode.h:913:
+#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits))

-:156: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as 
'(numbits)' to avoid precedence issues
#156: FILE: include/uapi/drm/drm_mode.h:913:
+#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits))

-:157: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#157: FILE: include/uapi/drm/drm_mode.h:914:
+#define DRM_RGBA_BLUE(c, numbits)  (__u16)((c & 0xull<<32) >> (48-numbits))
  ^

-:157: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#157: FILE: include/uapi/drm/drm_mode.h:914:
+#define DRM_RGBA_BLUE(c, numbits)  (__u16)((c & 0xull<<32) >> (48-numbits))
  ^

-:157: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to 
avoid precedence issues
#157: FILE: include/uapi/drm/drm_mode.h:914:
+#define DRM_RGBA_BLUE(c, numbits)  (__u16)((c & 0xull<<32) >> (48-numbits))

-:157: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as 
'(numbits)' to avoid precedence issues
#157: FILE: include/uapi/drm/drm_mode.h:914:
+#define DRM_RGBA_BLUE(c, numbits)  (__u16)((c & 0xull<<32) >> (48-numbits))

-:158: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#158: FILE: include/uapi/drm/drm_mode.h:915:
+#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits))
  ^

-:158: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#158: FILE: include/uapi/drm/drm_mode.h:915:
+#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits))
  ^

-:158: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to 
avoid precedence issues
#158: FILE: include/uapi/drm/drm_mode.h:915:
+#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits))

-:158: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as 
'(numbits)' to avoid precedence issues
#158: FILE: include/uapi/drm/drm_mode.h:915:
+#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits))

total: 0 errors, 1 warnings, 15 checks, 108 lines checked
a0be1f8ad993 drm/i915/gen9+: Add support for pipe background color

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


[Intel-gfx] [PATCH i-g-t] tests/kms_crtc_background_color: overhaul for latest ABI proposal

2018-10-10 Thread Matt Roper
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them.  However the
corresponding IGT test did get merged and has basically been dead code
ever since.

A couple years later we may finally be getting closer to landing the
kernel patches (there's some interest in this functionality now from
both the ChromeOS and Weston camps), so lets update the IGT test to
match the latest proposed ABI, and to remove some of the cruft from the
original test that wouldn't actually work.

It's worth noting that we don't seem to be able to test this feature
with CRC's.  Originally we wanted to draw a color into a plane's FB
(with Cairo) and then compare the CRC to turning off all planes and just
setting the CRTC background to the same color.  However the precision
and rounding of the color components causes the CRC's to come out
differently, even though the end result is visually identical.  So at
the moment this test is mainly useful for visual inspection in
interactive mode.

Signed-off-by: Matt Roper 
---
 lib/igt_kms.c |   2 +-
 tests/kms_crtc_background_color.c | 221 --
 2 files changed, 120 insertions(+), 103 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index b2cbaa11..f34817b5 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -180,7 +180,7 @@ const char * const 
igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
 };
 
 const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
-   [IGT_CRTC_BACKGROUND] = "background_color",
+   [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
[IGT_CRTC_CTM] = "CTM",
[IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
[IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
diff --git a/tests/kms_crtc_background_color.c 
b/tests/kms_crtc_background_color.c
index 3df3401f..9c5a7523 100644
--- a/tests/kms_crtc_background_color.c
+++ b/tests/kms_crtc_background_color.c
@@ -25,164 +25,181 @@
 #include "igt.h"
 #include 
 
-
 IGT_TEST_DESCRIPTION("Test crtc background color feature");
 
+/*
+ * The original idea was to paint a desired color into a full-screen primary
+ * plane and then compare that CRC with turning off all planes and setting the
+ * CRTC background to the same color.  Unforunately, the rounding and precision
+ * of color values as rendered by cairo vs created by the display controller
+ * are slightly different and give different CRC's, even though they're
+ * visually identical.
+ *
+ * Since we can't really use CRC's for testing, this test is mainly useful for
+ * visual inspection in interactive mode at the moment.
+ */
+
 typedef struct {
int gfx_fd;
-   igt_display_t display;
-   struct igt_fb fb;
-   igt_crc_t ref_crc;
-   igt_pipe_crc_t *pipe_crc;
+   igt_output_t *output;
+   drmModeModeInfo *mode;
 } data_t;
 
-#define BLACK  0x00   /* BGR 8bpc */
-#define CYAN   0x00   /* BGR 8bpc */
-#define PURPLE 0xFF00FF   /* BGR 8bpc */
-#define WHITE  0xFF   /* BGR 8bpc */
-
-#define BLACK640x /* BGR 16bpc */
-#define CYAN64 0x /* BGR 16bpc */
-#define PURPLE64   0x /* BGR 16bpc */
-#define YELLOW64   0x /* BGR 16bpc */
-#define WHITE640x /* BGR 16bpc */
-#define RED64  0x /* BGR 16bpc */
-#define GREEN640x /* BGR 16bpc */
-#define BLUE64 0x /* BGR 16bpc */
+/*
+ * Local copy of proposed kernel uapi
+ */
+static inline __u64
+local_rgba(__u8 bpc, __u16 red, __u16 green, __u16 blue, __u16 alpha)
+{
+   int msb_shift = 16 - bpc;
 
+   return (__u64)alpha << msb_shift << 48 |
+  (__u64)blue  << msb_shift << 32 |
+  (__u64)green << msb_shift << 16 |
+  (__u64)red   << msb_shift;
+}
+#define LOCAL_RGBA_RED(c, numbits)   (__u16)((c & 0xull) >> 
(16-numbits))
+#define LOCAL_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> 
(32-numbits))
+#define LOCAL_RGBA_BLUE(c, numbits)  (__u16)((c & 0xull<<32) >> 
(48-numbits))
+#define LOCAL_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> 
(64-numbits))
+
+
+/* 8bpc values */
+#define BLACK  local_rgba(8, 0,   0,0, 0xff)
+#define REDlocal_rgba(8, 0xff,0,0, 0xff)
+#define GREEN  local_rgba(8,0, 0xff,0, 0xff)
+#define BLUE   local_rgba(8,0,0, 0xff, 0xff)
+#define YELLOW local_rgba(8, 0xff, 0xff,0, 0xff)
+#define WHITE  local_rgba(8, 0xff, 0xff, 0xff, 0xff)
+
+/* 16bpc values */
+#define BLACK64local_rgba(16,  0,  0,  0, 0x)
+#define RED64  local_rgba(16, 0x,  0,  0, 0x)
+#define GREEN64local_rgba(16,  0, 0x,  0, 0x)
+#define BLUE64 local_rgba(16,  0,  0, 0x, 0x)
+#define YELLOW64   local_rgba(16, 

[Intel-gfx] [PATCH 1/2] drm: Add CRTC background color property

2018-10-10 Thread Matt Roper
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes).  Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.

To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value.  Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.

Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c |  5 +
 drivers/gpu/drm/drm_mode_config.c |  6 ++
 include/drm/drm_crtc.h| 17 +
 include/drm/drm_mode_config.h |  5 +
 include/uapi/drm/drm_mode.h   | 26 ++
 6 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 3ba996069d69..2f8c55668089 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -101,6 +101,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,
state->planes_changed = false;
state->connectors_changed = false;
state->color_mgmt_changed = false;
+   state->bgcolor_changed = false;
state->zpos_changed = false;
state->commit = NULL;
state->event = NULL;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..399f0ead5370 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -467,6 +467,9 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
return -EFAULT;
 
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+   } else if (property == config->bgcolor_property) {
+   state->background_color = val;
+   state->bgcolor_changed = true;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
} else {
@@ -499,6 +502,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+   else if (property == config->bgcolor_property)
+   *val = state->background_color;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..75e376755176 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -352,6 +352,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
 
+   prop = drm_property_create_range(dev, 0, "BACKGROUND_COLOR",
+0, GENMASK_ULL(63, 0));
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.bgcolor_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b21437bc95bf..ddfdad9ccecb 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -168,6 +168,11 @@ struct drm_crtc_state {
 * drivers to steer the atomic commit control flow.
 */
bool color_mgmt_changed : 1;
+   /**
+* @bgcolor_changed: Background color value has changed.  Used by
+* drivers to steer the atomic commit control flow.
+*/
+   bool bgcolor_changed : 1;
 
/**
 * @no_vblank:
@@ -274,6 +279,18 @@ struct drm_crtc_state {
 */
struct drm_property_blob *gamma_lut;
 
+   /**
+* @background_color:
+*
+* RGB value representing the pipe's background color.  The background
+* color (aka "canvas color") of a pipe is the color that will be used
+* for pixels not covered by a plane, or covered by transparent pixels
+* of a plane.  The value here should be built via drm_rgba();
+* individual color components can be extracted with desired precision
+* via the DRM_RGBA_*() macros.
+*/
+   u64 background_color;
+
/**
 * @target_vblank:
 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 928e4172a0bb..c3f57a9e5b31 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h

[Intel-gfx] [PATCH 0/2] CRTC background color

2018-10-10 Thread Matt Roper
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes).  Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.

Earlier versions of these patches were floated on dri-devel about 2.5
years ago, but at that time the only userspace software that made use of
this was closed-source (product-specific Wayland compositors), so we
never landed the patches upstream.  I'm told that there's now some
renewed interest in this functionality from both the ChromeOS camp and
the Weston camp, so I'm re-posting updated kernel patches here to get
the ball rolling again.  As always, we'll still need the patches for at
least one of those projects to get posted (and reviewed) somewhere
public before we actually merge these kernel patches.

Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com

Matt Roper (2):
  drm: Add CRTC background color property
  drm/i915/gen9+: Add support for pipe background color

 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c |  5 +
 drivers/gpu/drm/drm_mode_config.c |  6 ++
 drivers/gpu/drm/i915/i915_debugfs.c   |  9 
 drivers/gpu/drm/i915/i915_reg.h   |  6 ++
 drivers/gpu/drm/i915/intel_display.c  | 34 +++
 include/drm/drm_crtc.h| 17 
 include/drm/drm_mode_config.h |  5 +
 include/uapi/drm/drm_mode.h   | 26 +++
 9 files changed, 109 insertions(+)

-- 
2.14.4

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


[Intel-gfx] [PATCH 2/2] drm/i915/gen9+: Add support for pipe background color

2018-10-10 Thread Matt Roper
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes.  Let's expose this for use by
compositors.

Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  9 +
 drivers/gpu/drm/i915/i915_reg.h  |  6 ++
 drivers/gpu/drm/i915/intel_display.c | 34 ++
 3 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4565eda29c87..cc423f7f3e62 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3254,6 +3254,15 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
intel_plane_info(m, crtc);
}
 
+   if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+   uint64_t background = 
pipe_config->base.background_color;
+
+   seq_printf(m, "\tbackground color (10bpc): r=%x g=%x 
b=%x\n",
+  DRM_RGBA_RED(background, 10),
+  DRM_RGBA_GREEN(background, 10),
+  DRM_RGBA_BLUE(background, 10));
+   }
+
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 20785417953d..988183870f6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5661,6 +5661,12 @@ enum {
 #define   PIPEMISC_DITHER_TYPE_SP  (0 << 2)
 #define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
 
+/* Skylake+ pipe bottom (background) color */
+#define _PIPE_BOTTOM_COLOR_A   0x70034
+#define PIPE_BOTTOM_GAMMA_ENABLE   (1 << 31)
+#define PIPE_BOTTOM_CSC_ENABLE (1 << 30)
+#define PIPE_BOTTOM_COLOR(pipe)_MMIO_PIPE2(pipe, 
_PIPE_BOTTOM_COLOR_A)
+
 #define VLV_DPFLIPSTAT _MMIO(VLV_DISPLAY_BASE + 
0x70028)
 #define   PIPEB_LINE_COMPARE_INT_EN(1 << 29)
 #define   PIPEB_HLINE_INT_EN   (1 << 28)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a145efba9157..2ee402a98e70 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3853,6 +3853,28 @@ void intel_finish_reset(struct drm_i915_private 
*dev_priv)
clear_bit(I915_RESET_MODESET, _priv->gpu_error.flags);
 }
 
+static void skl_update_background_color(const struct intel_crtc_state *cstate)
+{
+   struct intel_crtc *crtc = to_intel_crtc(cstate->base.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   uint64_t propval = cstate->base.background_color;
+   uint32_t hwval;
+
+   /* Hardware is programmed with 10 bits of precision */
+   hwval = DRM_RGBA_RED(propval, 10) << 20
+ | DRM_RGBA_GREEN(propval, 10) << 10
+ | DRM_RGBA_BLUE(propval, 10);
+
+   /*
+* Set CSC and gamma for bottom color to ensure background pixels
+* receive the same color transformations as plane content.
+*/
+   hwval |= PIPE_BOTTOM_CSC_ENABLE;
+   hwval |= PIPE_BOTTOM_GAMMA_ENABLE;
+
+   I915_WRITE_FW(PIPE_BOTTOM_COLOR(crtc->pipe), hwval);
+}
+
 static void intel_update_pipe_config(const struct intel_crtc_state 
*old_crtc_state,
 const struct intel_crtc_state 
*new_crtc_state)
 {
@@ -3887,6 +3909,9 @@ static void intel_update_pipe_config(const struct 
intel_crtc_state *old_crtc_sta
else if (old_crtc_state->pch_pfit.enabled)
ironlake_pfit_disable(old_crtc_state);
}
+
+   if (new_crtc_state->base.bgcolor_changed)
+   skl_update_background_color(new_crtc_state);
 }
 
 static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -10791,6 +10816,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
crtc_state->planes_changed = true;
}
 
+   if (crtc_state->bgcolor_changed)
+   pipe_config->update_pipe = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(pipe_config);
@@ -13831,6 +13859,7 @@ static void intel_crtc_init_scalers(struct intel_crtc 
*crtc,
 
 static int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe)
 {
+   struct drm_mode_config *mode_config = _priv->drm.mode_config;
struct intel_crtc *intel_crtc;
struct intel_crtc_state *crtc_state = NULL;
struct intel_plane *primary = NULL;
@@ -13905,6 +13934,11 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: Add OA buffer size uAPI parameter

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: Add OA buffer size uAPI parameter
URL   : https://patchwork.freedesktop.org/series/50810/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4964_full -> Patchwork_10415_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_busy@busy-render:
  shard-apl:  PASS -> INCOMPLETE (fdo#103927)

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-skl:  NOTRUN -> TIMEOUT (fdo#108039)

igt@kms_addfb_basic@bo-too-small-due-to-tiling:
  shard-snb:  NOTRUN -> DMESG-WARN (fdo#107469) +1

igt@kms_available_modes_crc@available_mode_test_crc:
  shard-apl:  PASS -> FAIL (fdo#106641)

igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
  shard-skl:  NOTRUN -> DMESG-WARN (fdo#107956)

igt@kms_cursor_crc@cursor-64x64-dpms:
  shard-apl:  PASS -> FAIL (fdo#103232)

igt@kms_cursor_legacy@cursora-vs-flipa-toggle:
  shard-glk:  PASS -> DMESG-WARN (fdo#105763, fdo#106538)

igt@kms_fbcon_fbt@psr:
  shard-skl:  NOTRUN -> FAIL (fdo#107882)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105363)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
  shard-skl:  NOTRUN -> FAIL (fdo#103167)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
  shard-apl:  PASS -> FAIL (fdo#103167) +3

igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
  shard-glk:  PASS -> FAIL (fdo#103167) +1

igt@kms_frontbuffer_tracking@fbc-stridechange:
  shard-skl:  NOTRUN -> FAIL (fdo#105683)

igt@kms_plane@pixel-format-pipe-b-planes:
  shard-skl:  NOTRUN -> DMESG-FAIL (fdo#106885, fdo#103166)

{igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb}:
  shard-skl:  NOTRUN -> FAIL (fdo#108145)

{igt@kms_plane_alpha_blend@pipe-c-alpha-7efc}:
  shard-kbl:  NOTRUN -> FAIL (fdo#108146)

igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
  shard-apl:  PASS -> FAIL (fdo#103166) +1

igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
  shard-skl:  NOTRUN -> FAIL (fdo#103166)

igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
  shard-skl:  PASS -> INCOMPLETE (fdo#104108, fdo#107773)

igt@kms_vblank@pipe-b-wait-forked:
  shard-snb:  NOTRUN -> INCOMPLETE (fdo#105411)

igt@pm_rpm@debugfs-read:
  shard-skl:  PASS -> INCOMPLETE (fdo#107807) +2

igt@pm_rpm@modeset-lpsp-stress-no-wait:
  shard-skl:  NOTRUN -> INCOMPLETE (fdo#107807)

igt@prime_vgem@basic-fence-flip:
  shard-kbl:  PASS -> FAIL (fdo#104008)


 Possible fixes 

igt@debugfs_test@read_all_entries_display_off:
  shard-skl:  INCOMPLETE (fdo#104108) -> PASS

igt@drv_hangman@error-state-capture-render:
  shard-glk:  INCOMPLETE (fdo#103359, k.org#198133) -> PASS

igt@drv_suspend@shrink:
  shard-glk:  INCOMPLETE (k.org#198133, fdo#103359, fdo#106886) -> 
PASS

igt@gem_mmap_gtt@medium-copy-xy:
  shard-apl:  INCOMPLETE (fdo#103927) -> PASS

igt@gem_workarounds@suspend-resume-fd:
  shard-skl:  INCOMPLETE (fdo#104108, fdo#107773) -> PASS +1

igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
  shard-snb:  DMESG-WARN (fdo#107956) -> PASS

igt@kms_cursor_crc@cursor-128x128-suspend:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transitions-varying-size:
  shard-kbl:  DMESG-WARN (fdo#105604) -> PASS

igt@kms_flip@flip-vs-expired-vblank:
  shard-skl:  FAIL (fdo#105363) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
  shard-apl:  FAIL (fdo#103167) -> PASS +2

igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
  shard-apl:  FAIL (fdo#103166) -> PASS +1

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS

igt@perf_pmu@other-init-0:
  shard-snb:  INCOMPLETE (fdo#105411) -> PASS

igt@perf_pmu@rc6-runtime-pm:
  shard-glk:  FAIL (fdo#105010) -> PASS

igt@perf_pmu@rc6-runtime-pm-long:
  shard-kbl:  FAIL (fdo#105010) -> PASS

igt@pm_rpm@gem-execbuf-stress-extra-wait:
  shard-skl:  INCOMPLETE (fdo#107803, fdo#107807) -> PASS

igt@pm_rpm@pc8-residency:
  shard-skl:  INCOMPLETE (fdo#107807) -> SKIP


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

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

Re: [Intel-gfx] drm-intel-fixes CI issues

2018-10-10 Thread Lyude Paul
speaking for my own patches here I'm fine with that!

On Thu, 2018-10-11 at 09:17 +1000, David Airlie wrote:
> On Thu, Oct 11, 2018 at 8:53 AM Rodrigo Vivi  wrote:
> > 
> > Hi all,
> > 
> > I need your help to decide what to do with this round of fixes.
> > 
> > I have collected these patches this week:
> > 
> > commit b43e8916172a ("drm/i915/dp: Link train Fallback on eDP only if
> > fallback link BW can fit panel's native mode")
> > commit 5abb01e541ed ("drm/i915: Fix intel_dp_mst_best_encoder()")
> > commit 02713246296d ("drm/i915: Skip vcpi allocation for MSTB ports that
> > are gone")
> > commit cc6e027f5f50 ("drm/i915: Don't unset intel_connector->mst_port")
> > commit f5aec50ba21e ("drm/i915: Use the correct crtc when sanitizing plane
> > mapping")
> > commit 6547684bf50a ("drm/i915: Restore vblank interrupts earlier")
> > 
> > CI_DIF_309 represents Greg's v4.19-rc7 and it is clean.
> > 
> > However 2 following CI runs are kind of strange.
> > 
> > There's few underruns here and there, but those looks flip-flops.
> > 
> > My biggest concern is specially around:
> > 
> > igt@kms_plane@pixel-format-pipe-a-planes:
> > https://intel-gfx-ci.01.org/tree/drm-intel-fixes/shards.html
> > 
> > 
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/CI_DIF_311/shard-glk8/igt@kms_pl...@pixel-format-pipe-c-planes.html
> > 
> > Thoughts?
> > 
> > I'm holding the pull request for now and will try to do some local tests
> > here
> > to see if I can identify a culprit.
> 
> At this late in the game for rc8, unless these fix a major regression
> in the current tree, I'd say drop them until -next.
> 
> Dave.
-- 
Cheers,
Lyude Paul

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


Re: [Intel-gfx] drm-intel-fixes CI issues

2018-10-10 Thread David Airlie
On Thu, Oct 11, 2018 at 8:53 AM Rodrigo Vivi  wrote:
>
> Hi all,
>
> I need your help to decide what to do with this round of fixes.
>
> I have collected these patches this week:
>
> commit b43e8916172a ("drm/i915/dp: Link train Fallback on eDP only if 
> fallback link BW can fit panel's native mode")
> commit 5abb01e541ed ("drm/i915: Fix intel_dp_mst_best_encoder()")
> commit 02713246296d ("drm/i915: Skip vcpi allocation for MSTB ports that are 
> gone")
> commit cc6e027f5f50 ("drm/i915: Don't unset intel_connector->mst_port")
> commit f5aec50ba21e ("drm/i915: Use the correct crtc when sanitizing plane 
> mapping")
> commit 6547684bf50a ("drm/i915: Restore vblank interrupts earlier")
>
> CI_DIF_309 represents Greg's v4.19-rc7 and it is clean.
>
> However 2 following CI runs are kind of strange.
>
> There's few underruns here and there, but those looks flip-flops.
>
> My biggest concern is specially around:
>
> igt@kms_plane@pixel-format-pipe-a-planes:
> https://intel-gfx-ci.01.org/tree/drm-intel-fixes/shards.html
>
> https://intel-gfx-ci.01.org/tree/drm-intel-fixes/CI_DIF_311/shard-glk8/igt@kms_pl...@pixel-format-pipe-c-planes.html
>
> Thoughts?
>
> I'm holding the pull request for now and will try to do some local tests here
> to see if I can identify a culprit.

At this late in the game for rc8, unless these fix a major regression
in the current tree, I'd say drop them until -next.

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


[Intel-gfx] drm-intel-fixes CI issues

2018-10-10 Thread Rodrigo Vivi
Hi all,

I need your help to decide what to do with this round of fixes.

I have collected these patches this week:

commit b43e8916172a ("drm/i915/dp: Link train Fallback on eDP only if fallback 
link BW can fit panel's native mode")
commit 5abb01e541ed ("drm/i915: Fix intel_dp_mst_best_encoder()")
commit 02713246296d ("drm/i915: Skip vcpi allocation for MSTB ports that are 
gone")
commit cc6e027f5f50 ("drm/i915: Don't unset intel_connector->mst_port")
commit f5aec50ba21e ("drm/i915: Use the correct crtc when sanitizing plane 
mapping")
commit 6547684bf50a ("drm/i915: Restore vblank interrupts earlier")

CI_DIF_309 represents Greg's v4.19-rc7 and it is clean.

However 2 following CI runs are kind of strange.

There's few underruns here and there, but those looks flip-flops.

My biggest concern is specially around:

igt@kms_plane@pixel-format-pipe-a-planes:
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/shards.html

https://intel-gfx-ci.01.org/tree/drm-intel-fixes/CI_DIF_311/shard-glk8/igt@kms_pl...@pixel-format-pipe-c-planes.html

Thoughts?

I'm holding the pull request for now and will try to do some local tests here
to see if I can identify a culprit.

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/debugfs: Do not print cached information of a disconnected sink

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915/debugfs: Do not print cached 
information of a disconnected sink
URL   : https://patchwork.freedesktop.org/series/50827/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4965 -> Patchwork_10417 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50827/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-blb-e6850:   PASS -> INCOMPLETE (fdo#107718)

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-byt-clapper: PASS -> FAIL (fdo#107362)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362)


 Possible fixes 

igt@kms_frontbuffer_tracking@basic:
  fi-byt-clapper: FAIL (fdo#103167) -> PASS


  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718


== Participating hosts (47 -> 40) ==

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan 
fi-ctg-p8600 fi-pnv-d510 


== Build changes ==

* Linux: CI_DRM_4965 -> Patchwork_10417

  CI_DRM_4965: f71ab7ae77be14182f92d78b5a6a790fce761fc9 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10417: 89bbe839d82fe3df2f08ea022c3ca729e7fb451a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

89bbe839d82f drm/i915/icl: Fix crash when getting DPLL of a MST encoder in TC 
ports
6839410e443f drm/i915/icl: Delay hotplug processing for tc ports
ec1e029c48bf drm/i915: Initialize panel_vdd_work only for eDP ports
fb0e11b9660a drm/i915/icl: Set TC type to unknown when a sudden disconnection 
happen
39ba94708d75 drm/i915/icl: Set TC type to unknown in the disconnection flow
c1271e6d3ea6 drm/i915/debugfs: Do not print cached information of a 
disconnected sink

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915/debugfs: Do not print cached information of a disconnected sink

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915/debugfs: Do not print cached 
information of a disconnected sink
URL   : https://patchwork.freedesktop.org/series/50827/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/debugfs: Do not print cached information of a disconnected sink
Okay!

Commit: drm/i915/icl: Set TC type to unknown in the disconnection flow
Okay!

Commit: drm/i915/icl: Set TC type to unknown when a sudden disconnection happen
Okay!

Commit: drm/i915: Initialize panel_vdd_work only for eDP ports
Okay!

Commit: drm/i915/icl: Delay hotplug processing for tc ports
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3725:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3726:16: warning: expression 
using sizeof(void)

Commit: drm/i915/icl: Fix crash when getting DPLL of a MST encoder in TC ports
Okay!

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


[Intel-gfx] [PATCH 5/6] drm/i915/icl: Delay hotplug processing for tc ports

2018-10-10 Thread José Roberto de Souza
Some USB type-C dongles requires some time to power on before being
able to process aux channel transactions.
It was not a problem for older gens because there was a bridge
between DP port and USB-C controller adding some delay but ICL
handles type-C native.

So here trying to do a aux channel transaction at each 150ms for up 5
times, before giving up.

Cc: Paulo Zanoni 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_dp.c  |  7 
 drivers/gpu/drm/i915/intel_drv.h |  6 ++-
 drivers/gpu/drm/i915/intel_hotplug.c | 58 
 4 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef037fed..b3f1fc865366 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2810,6 +2810,7 @@ enum hpd_pin intel_hpd_pin_default(struct 
drm_i915_private *dev_priv,
   enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
 void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
+void intel_hotplug_tc_wa_work(struct work_struct *__work);
 
 /* i915_irq.c */
 static inline void i915_queue_hangcheck(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 60e62a3c1e22..b945385cd5bc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5289,6 +5289,7 @@ void intel_dp_encoder_destroy(struct drm_encoder *encoder)
 {
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
struct intel_dp *intel_dp = _dig_port->dp;
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
intel_dp_mst_encoder_cleanup(intel_dig_port);
if (intel_dp_is_edp(intel_dp)) {
@@ -5305,6 +5306,8 @@ void intel_dp_encoder_destroy(struct drm_encoder *encoder)
unregister_reboot_notifier(_dp->edp_notifier);
intel_dp->edp_notifier.notifier_call = NULL;
}
+   } else if (IS_ICELAKE(dev_priv)) {
+   cancel_delayed_work_sync(_dp->tc_wa_work);
}
 
intel_dp_aux_fini(intel_dp);
@@ -6663,6 +,10 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
 
+   if (IS_ICELAKE(dev_priv) && !intel_dp_is_edp(intel_dp))
+   INIT_DELAYED_WORK(_dp->tc_wa_work,
+ intel_hotplug_tc_wa_work);
+
return true;
 
 fail:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3dea7a1bda7f..174a54aa966a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1100,7 +1100,11 @@ struct intel_dp {
int panel_power_cycle_delay;
int backlight_on_delay;
int backlight_off_delay;
-   struct delayed_work panel_vdd_work;
+   union {
+   struct delayed_work panel_vdd_work;
+   struct delayed_work tc_wa_work;
+   };
+   u8 tc_wa_count;
bool want_panel_vdd;
unsigned long last_power_on;
unsigned long last_backlight_off;
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..96546067f832 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -323,6 +323,45 @@ static void i915_digport_work_func(struct work_struct 
*work)
}
 }
 
+#define TC_WA_DELAY_MSEC 150
+#define TC_WA_TRIES 5
+
+void intel_hotplug_tc_wa_work(struct work_struct *__work)
+{
+   struct intel_dp *intel_dp = container_of(to_delayed_work(__work),
+struct intel_dp, tc_wa_work);
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct intel_encoder *intel_encoder = _dig_port->base;
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+   struct drm_device *dev = _priv->drm;
+   u8 val;
+
+   if (!intel_port_is_tc(dev_priv, intel_encoder->port) ||
+   !intel_digital_port_connected(intel_encoder))
+   return;
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_DPCD_REV, , 1) < 1) {
+   intel_dp->tc_wa_count++;
+
+   if (intel_dp->tc_wa_count < TC_WA_TRIES) {
+   unsigned long delay;
+
+   delay = msecs_to_jiffies(TC_WA_DELAY_MSEC);
+   schedule_delayed_work(_dp->tc_wa_work, delay);
+   } else {
+   DRM_DEBUG_KMS("TC not responsive, giving up\n");
+   }
+   } else {
+   mutex_lock(>mode_config.mutex);
+   val = intel_encoder->hotplug(intel_encoder, 

[Intel-gfx] [PATCH 2/6] drm/i915/icl: Set TC type to unknown in the disconnection flow

2018-10-10 Thread José Roberto de Souza
Otherwise it would be in a inconsistent state as port is disconnected
but with a valid tc type.

Also setting it to unknown will earlier return
icl_tc_phy_disconnect() for any future calls to
intel_digital_port_connected(), this way we don't need to check if
port is marked as safe everytime.

Cc: Paulo Zanoni 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_dp.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 13ff89be6ad6..d3f31103b8ec 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4934,21 +4934,24 @@ static void icl_tc_phy_disconnect(struct 
drm_i915_private *dev_priv,
  struct intel_digital_port *dig_port)
 {
enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
-   u32 val;
 
-   if (dig_port->tc_type != TC_PORT_LEGACY &&
-   dig_port->tc_type != TC_PORT_TYPEC)
+   if (dig_port->tc_type == TC_PORT_UNKNOWN)
return;
 
/*
-* This function may be called many times in a row without an HPD event
-* in between, so try to avoid the write when we can.
+* TBT disconnection flow is read the live status, what was done in
+* caller.
 */
-   val = I915_READ(PORT_TX_DFLEXDPCSSS);
-   if (val & DP_PHY_MODE_STATUS_NOT_SAFE(tc_port)) {
+   if (dig_port->tc_type == TC_PORT_TYPEC ||
+   dig_port->tc_type == TC_PORT_LEGACY) {
+   u32 val;
+
+   val = I915_READ(PORT_TX_DFLEXDPCSSS);
val &= ~DP_PHY_MODE_STATUS_NOT_SAFE(tc_port);
I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
}
+
+   dig_port->tc_type = TC_PORT_UNKNOWN;
 }
 
 /*
-- 
2.19.1

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


[Intel-gfx] [PATCH 3/6] drm/i915/icl: Set TC type to unknown when a sudden disconnection happen

2018-10-10 Thread José Roberto de Souza
Otherwise it would be in a inconsistent state as port is disconnected
but with a valid tc type.

Cc: Paulo Zanoni 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d3f31103b8ec..d3af6aa1959a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4863,6 +4863,9 @@ static void icl_update_tc_port_type(struct 
drm_i915_private *dev_priv,
  type_str);
 }
 
+static void icl_tc_phy_disconnect(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *dig_port);
+
 /*
  * This function implements the first part of the Connect Flow described by our
  * specification, Gen11 TypeC Programming chapter. The rest of the flow 
(reading
@@ -4917,9 +4920,7 @@ static bool icl_tc_phy_connect(struct drm_i915_private 
*dev_priv,
if (dig_port->tc_type == TC_PORT_TYPEC &&
!(I915_READ(PORT_TX_DFLEXDPSP) & TC_LIVE_STATE_TC(tc_port))) {
DRM_DEBUG_KMS("TC PHY %d sudden disconnect.\n", tc_port);
-   val = I915_READ(PORT_TX_DFLEXDPCSSS);
-   val &= ~DP_PHY_MODE_STATUS_NOT_SAFE(tc_port);
-   I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
+   icl_tc_phy_disconnect(dev_priv, dig_port);
return false;
}
 
-- 
2.19.1

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


[Intel-gfx] [PATCH 4/6] drm/i915: Initialize panel_vdd_work only for eDP ports

2018-10-10 Thread José Roberto de Souza
It is only used by eDP ports so no need to initialize it for each DP
port.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_dp.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d3af6aa1959a..60e62a3c1e22 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6418,6 +6418,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
if (!intel_dp_is_edp(intel_dp))
return true;
 
+   INIT_DELAYED_WORK(_dp->panel_vdd_work, edp_panel_vdd_work);
+
/*
 * On IBX/CPT we may get here with LVDS already registered. Since the
 * driver uses the only internal power sequencer available for both
@@ -6624,9 +6626,6 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 
intel_dp_aux_init(intel_dp);
 
-   INIT_DELAYED_WORK(_dp->panel_vdd_work,
- edp_panel_vdd_work);
-
intel_connector_attach_encoder(intel_connector, intel_encoder);
 
if (HAS_DDI(dev_priv))
-- 
2.19.1

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


[Intel-gfx] [PATCH 6/6] drm/i915/icl: Fix crash when getting DPLL of a MST encoder in TC ports

2018-10-10 Thread José Roberto de Souza
enc_to_dig_port() returns NULL for encoders of type
INTEL_OUTPUT_DP_MST causing the crash bellow:

[ 2832.836101] BUG: unable to handle kernel paging request at 12b8
[ 2832.843062] PGD 0 P4D 0
[ 2832.845610] Oops:  [#1] SMP
[ 2832.848764] CPU: 2 PID: 3577 Comm: kworker/2:0 Tainted: GW 
4.19.0-rc7+ #491
[ 2832.857106] Hardware name: Intel Corporation Ice Lake Client 
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS 
ICLSFWR1.R00.2352.A01.1808281852 08/28/2018
[ 2832.870734] Workqueue: events output_poll_execute
[ 2832.875480] RIP: 0010:icl_get_dpll+0xa4/0x5d0 [i915]
[ 2832.880449] Code: e9 03 f3 48 ab 8b 6e 74 41 8b 8c 24 5c 03 00 00 85 ed 0f 
88 3f 02 00 00 83 fd 01 0f 8e ad 01 00 00 83 fd 05 0f 8f 2d 02 00 00 <83> ba b8 
12 00 00 02 48 8b 36 0f 84 39 02 00 00 44 8b be ec 89 00
[ 2832.899176] RSP: 0018:c90001b57a78 EFLAGS: 00010293
[ 2832.904404] RAX:  RBX: c90001b57a94 RCX: 00083d60
[ 2832.911536] RDX:  RSI: 8804a8c0dc00 RDI: c90001b57b18
[ 2832.918668] RBP: 0003 R08: 8804a8c1f990 R09: 8804a8c1f990
[ 2832.925797] R10:  R11: 8804a8e99600 R12: 8804a776
[ 2832.932930] R13: 88049e94d000 R14: 88049e94d000 R15: 000e
[ 2832.940063] FS:  () GS:8804b030() 
knlGS:
[ 2832.948147] CS:  0010 DS:  ES:  CR0: 80050033
[ 2832.953893] CR2: 12b8 CR3: 04a1d004 CR4: 00760ee0
[ 2832.961027] DR0:  DR1:  DR2: 
[ 2832.968155] DR3:  DR6: fffe0ff0 DR7: 0400
[ 2832.975286] PKRU: 5554
[ 2832.978003] Call Trace:
[ 2832.980496]  haswell_crtc_compute_clock+0x3d/0x68 [i915]
[ 2832.985841]  intel_crtc_atomic_check+0x61/0x340 [i915]
[ 2832.990987]  drm_atomic_helper_check_planes+0x130/0x1c0
[ 2832.996245]  intel_atomic_check+0x4d5/0x10f0 [i915]
[ 2833.001147]  drm_atomic_check_only+0x484/0x690
[ 2833.005629]  drm_atomic_commit+0x13/0x50
[ 2833.009564]  restore_fbdev_mode_atomic+0x1c9/0x1e0
[ 2833.014363]  drm_fb_helper_restore_fbdev_mode_unlocked+0x47/0x90
[ 2833.020368]  drm_fb_helper_set_par+0x29/0x50
[ 2833.024641]  drm_fb_helper_hotplug_event.part.33+0x92/0xb0
[ 2833.030130]  drm_kms_helper_hotplug_event+0x26/0x30
[ 2833.035013]  output_poll_execute+0x192/0x1b0
[ 2833.039293]  process_one_work+0x2a5/0x5f0
[ 2833.043315]  worker_thread+0x2d/0x3d0
[ 2833.046988]  ? rescuer_thread+0x340/0x340
[ 2833.051009]  kthread+0x112/0x130
[ 2833.054247]  ? kthread_create_worker_on_cpu+0x70/0x70
[ 2833.059307]  ret_from_fork+0x3a/0x50
[ 2833.062893] Modules linked in: i915 prime_numbers snd_hda_codec_realtek 
snd_hda_codec_generic asix snd_usb_audio snd_usbmidi_lib snd_seq_midi 
snd_seq_midi_event snd_rawmidi cdc_ether usbnet x86_pkg_temp_thermal xhci_pci 
xhci_hcd ucsi_acpi typec_ucsi typec efivarfs [last unloaded: prime_numbers]
[ 2833.088917] CR2: 12b8
[ 2833.092241] ---[ end trace 25f9fe3d47af2e75 ]---
[ 2833.096895] RIP: 0010:icl_get_dpll+0xa4/0x5d0 [i915]
[ 2833.101866] Code: e9 03 f3 48 ab 8b 6e 74 41 8b 8c 24 5c 03 00 00 85 ed 0f 
88 3f 02 00 00 83 fd 01 0f 8e ad 01 00 00 83 fd 05 0f 8f 2d 02 00 00 <83> ba b8 
12 00 00 02 48 8b 36 0f 84 39 02 00 00 44 8b be ec 89 00
[ 2833.120589] RSP: 0018:c90001b57a78 EFLAGS: 00010293
[ 2833.125815] RAX:  RBX: c90001b57a94 RCX: 00083d60
[ 2833.132946] RDX:  RSI: 8804a8c0dc00 RDI: c90001b57b18
[ 2833.140080] RBP: 0003 R08: 8804a8c1f990 R09: 8804a8c1f990
[ 2833.147213] R10:  R11: 8804a8e99600 R12: 8804a776
[ 2833.154350] R13: 88049e94d000 R14: 88049e94d000 R15: 000e
[ 2833.161483] FS:  () GS:8804b030() 
knlGS:
[ 2833.169565] CS:  0010 DS:  ES:  CR0: 80050033
[ 2833.175313] CR2: 12b8 CR3: 04a1d004 CR4: 00760ee0
[ 2833.182449] DR0:  DR1:  DR2: 
[ 2833.189578] DR3:  DR6: fffe0ff0 DR7: 0400
[ 2833.196712] PKRU: 5554

MST ports are allocated from struct intel_dp_mst_encoder not from
struct intel_digital_port as regular ports, so to get the TC type it
is necessary check the primary digital port of the mst encoder.

Cc: Paulo Zanoni 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 874646357ad1..23a1bc17a3f9 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2867,8 +2867,7 @@ static struct intel_shared_dpll *
 icl_get_dpll(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
 struct intel_encoder *encoder)
 {
-

[Intel-gfx] [PATCH 1/6] drm/i915/debugfs: Do not print cached information of a disconnected sink

2018-10-10 Thread José Roberto de Souza
Besides of give the expected output of i915_display_info it will also
avoid some aux ch transactions that would timeout by obvious reasons.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 00c551d3e409..89dd60dc7b00 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3065,16 +3065,17 @@ static void intel_connector_info(struct seq_file *m,
seq_printf(m, "connector %d: type %s, status: %s\n",
   connector->base.id, connector->name,
   drm_get_connector_status_name(connector->status));
-   if (connector->status == connector_status_connected) {
-   seq_printf(m, "\tname: %s\n", connector->display_info.name);
-   seq_printf(m, "\tphysical dimensions: %dx%dmm\n",
-  connector->display_info.width_mm,
-  connector->display_info.height_mm);
-   seq_printf(m, "\tsubpixel order: %s\n",
-  
drm_get_subpixel_order_name(connector->display_info.subpixel_order));
-   seq_printf(m, "\tCEA rev: %d\n",
-  connector->display_info.cea_rev);
-   }
+
+   if (connector->status == connector_status_disconnected)
+   return;
+
+   seq_printf(m, "\tname: %s\n", connector->display_info.name);
+   seq_printf(m, "\tphysical dimensions: %dx%dmm\n",
+  connector->display_info.width_mm,
+  connector->display_info.height_mm);
+   seq_printf(m, "\tsubpixel order: %s\n",
+  
drm_get_subpixel_order_name(connector->display_info.subpixel_order));
+   seq_printf(m, "\tCEA rev: %d\n", connector->display_info.cea_rev);
 
if (!intel_encoder)
return;
-- 
2.19.1

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


Re: [Intel-gfx] [PATCH] drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK

2018-10-10 Thread Mahesh Kumar
On Thu, Oct 11, 2018 at 2:19 AM Mahesh Kumar  wrote:
>
> Hi,
>
> On Wed, Oct 10, 2018 at 11:25 PM Ville Syrjala
>  wrote:
> >
> > From: Ville Syrjälä 
> >
> > The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to
> > the appropriate platforms.
> >
> > This was especially harsh on GLK since we don't even try to read
> > the DIMM information on that platforms, hence valid_dimm was
> > always false and thus we always tried to apply the w/a.
> > Furthermore the w/a pushed the level 0 latency above the
> > level 1 latency, which doesn't really make sense.
> >
> > Cc: Mahesh Kumar 
> > Cc: Maarten Lankhorst 
> > Fixes: 86b592876cb6 ("drm/i915: Implement 16GB dimm wa for latency level-0")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 1392aa56a55a..a51cd09bbf75 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2881,8 +2881,9 @@ static void intel_read_wm_latency(struct 
> > drm_i915_private *dev_priv,
> >  * any underrun. If not able to get Dimm info assume 16GB 
> > dimm
> >  * to avoid any underrun.
> >  */
> > -   if (!dev_priv->dram_info.valid_dimm ||
> > -   dev_priv->dram_info.is_16gb_dimm)
> > +   if (!IS_GEN9_LP(dev_priv) &&
> > +   (!dev_priv->dram_info.valid_dimm ||
> > +dev_priv->dram_info.is_16gb_dimm))
> > wm[0] += 1;
>
> I would rather prefer to update "intel_get_dram_info"  to fill
> valid_dimm and is_16gb_dimm info properly
>
> -   if (INTEL_GEN(dev_priv) < 9 || IS_GEMINILAKE(dev_priv))
> +   if (INTEL_GEN(dev_priv) < 9 )
> return;
>
> +   if (IS_GEN9_LP(dev_priv)) {
> +   dram_info->valid_dimm = true;
> +   dram_info->is_16gb_dimm = false;
> +   }
> +
> +
We don't want to proceed for GLK. So, something like:

+   if (IS_GEN9_LP(dev_priv)) {
+   dram_info->valid_dimm = true;
+   dram_info->is_16gb_dimm = false;
+   }
+
if (INTEL_GEN(dev_priv) < 9 || IS_GEMINILAKE(dev_priv))
return;

-Mahesh
>
> -Mahesh
>
> >
> > } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> > --
> > 2.18.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK

2018-10-10 Thread Mahesh Kumar
Hi,

On Wed, Oct 10, 2018 at 11:25 PM Ville Syrjala
 wrote:
>
> From: Ville Syrjälä 
>
> The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to
> the appropriate platforms.
>
> This was especially harsh on GLK since we don't even try to read
> the DIMM information on that platforms, hence valid_dimm was
> always false and thus we always tried to apply the w/a.
> Furthermore the w/a pushed the level 0 latency above the
> level 1 latency, which doesn't really make sense.
>
> Cc: Mahesh Kumar 
> Cc: Maarten Lankhorst 
> Fixes: 86b592876cb6 ("drm/i915: Implement 16GB dimm wa for latency level-0")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1392aa56a55a..a51cd09bbf75 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2881,8 +2881,9 @@ static void intel_read_wm_latency(struct 
> drm_i915_private *dev_priv,
>  * any underrun. If not able to get Dimm info assume 16GB dimm
>  * to avoid any underrun.
>  */
> -   if (!dev_priv->dram_info.valid_dimm ||
> -   dev_priv->dram_info.is_16gb_dimm)
> +   if (!IS_GEN9_LP(dev_priv) &&
> +   (!dev_priv->dram_info.valid_dimm ||
> +dev_priv->dram_info.is_16gb_dimm))
> wm[0] += 1;

I would rather prefer to update "intel_get_dram_info"  to fill
valid_dimm and is_16gb_dimm info properly

-   if (INTEL_GEN(dev_priv) < 9 || IS_GEMINILAKE(dev_priv))
+   if (INTEL_GEN(dev_priv) < 9 )
return;

+   if (IS_GEN9_LP(dev_priv)) {
+   dram_info->valid_dimm = true;
+   dram_info->is_16gb_dimm = false;
+   }
+
+

-Mahesh

>
> } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> --
> 2.18.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Convert _print_param to a macro

2018-10-10 Thread Nick Desaulniers
On Wed, Oct 10, 2018 at 1:30 PM Michal Wajdeczko
 wrote:
>
> On Wed, 10 Oct 2018 14:01:40 +0200, Jani Nikula
>  wrote:
>
> > On Tue, 09 Oct 2018, Nick Desaulniers  wrote:
> >> On Tue, Oct 9, 2018 at 10:14 AM Nathan Chancellor
> >>  wrote:
> >>>
> >>> When building the kernel with Clang with defconfig and CONFIG_64BIT
> >>> disabled, vmlinux fails to link because of the BUILD_BUG in
> >>> _print_param.
> >>>
> >>> ld: drivers/gpu/drm/i915/i915_params.o: in function `i915_params_dump':
> >>> i915_params.c:(.text+0x56): undefined reference to
> >>> `__compiletime_assert_191'
> >>>
> >>> This function is semantically invalid unless the code is first inlined
> >>> then constant folded, which doesn't work for Clang because semantic
> >>> analysis happens before optimization/inlining. Converting this function
> >>> to a macro avoids this problem and allows Clang to properly remove the
> >>> BUILD_BUG during optimization.
> >>
> >> Thanks Nathan for the patch.  To provide more context, Clang does
> >> semantic analysis before optimization, where as GCC does these
> >> together (IIUC).  So the above link error is from the naked
> >> BUILD_BUG().  Clang can't evaluate the __builtin_strcmp's statically
> >> until inlining has occurred, but that optimization happens after
> >> semantic analysis.  To do the inlining before semantic analysis, we
> >> MUST leverage the preprocessor, which runs before the compiler starts
> >> doing semantic analysis.  I suspect this code is not valid for GCC
> >> unless optimizations are enabled (the kernel only does compile with
> >> optimizations turned on).  This change allows us to build this
> >> translation unit with Clang.
> >>
> >> Acked-by: Nick Desaulniers 
> >> (Note: this is the change I suggested, so not sure whether Acked-by or
> >> Reviewed-by is more appropriate).
> >
> > *Sad trombone*
> >
> > I'd rather see us converting more macros to static inlines than the
> > other way round.
> >
> > I'll let others chime in if they have any better ideas, otherwise I'll
> > apply this one.
>
> Option 1: Just drop BUILD_BUG() from _print_param() function.

I was also thinking of this.

>
> Option 2: Use aliases instead of real types in param() macros.

Will that affect other users of I915_PARAMS_FOR_EACH than _print_param?

Either way, thanks for the help towards resolving this! We appreciate it!

>
> Aliases can be same as in linux/moduleparam.h (charp|int|uint|bool)
> We can convert aliases back to real types but it will also allow
> to construct proper names for dedicated functions - see [1]
>
> Michal
>
> [1] https://patchwork.freedesktop.org/patch/255928/
>
>
> >
> > BR,
> > Jani.
> >
> >>
> >>>
> >>> The output of 'objdump -D' is identically before and after this change
> >>> for GCC regardless of if CONFIG_64BIT is set and allows Clang to link
> >>> the kernel successfully with or without CONFIG_64BIT set.
> >>>
> >>> Link: https://github.com/ClangBuiltLinux/linux/issues/191
> >>> Suggested-by: Nick Desaulniers 
> >>> Signed-off-by: Nathan Chancellor 
> >>> ---
> >>>  drivers/gpu/drm/i915/i915_params.c | 29 +
> >>>  1 file changed, 13 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_params.c
> >>> b/drivers/gpu/drm/i915/i915_params.c
> >>> index 295e981e4a39..a0f20b9b6f2d 100644
> >>> --- a/drivers/gpu/drm/i915/i915_params.c
> >>> +++ b/drivers/gpu/drm/i915/i915_params.c
> >>> @@ -174,22 +174,19 @@ i915_param_named(enable_dpcd_backlight, bool,
> >>> 0600,
> >>>  i915_param_named(enable_gvt, bool, 0400,
> >>> "Enable support for Intel GVT-g graphics virtualization host
> >>> support(default:false)");
> >>>
> >>> -static __always_inline void _print_param(struct drm_printer *p,
> >>> -const char *name,
> >>> -const char *type,
> >>> -const void *x)
> >>> -{
> >>> -   if (!__builtin_strcmp(type, "bool"))
> >>> -   drm_printf(p, "i915.%s=%s\n", name, yesno(*(const bool
> >>> *)x));
> >>> -   else if (!__builtin_strcmp(type, "int"))
> >>> -   drm_printf(p, "i915.%s=%d\n", name, *(const int *)x);
> >>> -   else if (!__builtin_strcmp(type, "unsigned int"))
> >>> -   drm_printf(p, "i915.%s=%u\n", name, *(const unsigned
> >>> int *)x);
> >>> -   else if (!__builtin_strcmp(type, "char *"))
> >>> -   drm_printf(p, "i915.%s=%s\n", name, *(const char **)x);
> >>> -   else
> >>> -   BUILD_BUG();
> >>> -}
> >>> +#define _print_param(p, name, type,
> >>> x)\
> >>> +do
> >>> {
> >>> \
> >>> +   if (!__builtin_strcmp(type,
> >>> "bool"))   \
> >>> +   drm_printf(p, "i915.%s=%s\n", name, yesno(*(const bool
> >>> *)x));  \
> >>> +   else if (!__builtin_strcmp(type,
> >>> "int"))   \
> >>> +   

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

2018-10-10 Thread Sean Paul

Hi Dave,
Another next-fixes pull, pretty light this week.


drm-misc-next-fixes-2018-10-10:
- Fix build failure without CONFIG_DRM_FBDEV_EMULATION (Arnd)
- Add Maxime to drm-misc maintainer group (Sean)

Cc: Arnd Bergmann 
Cc: Sean Paul 

Cheers, Sean


The following changes since commit 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a:

  drm/fb_helper: Allow leaking fbdev smem_start (2018-10-03 21:08:21 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-10-10

for you to fetch changes up to 7372fd049aa8836310f84da5f82dc9eb146915c8:

  MAINTAINERS: Add Maxime Ripard as drm-misc maintainer (2018-10-09 16:16:54 
-0400)


- Fix build failure without CONFIG_DRM_FBDEV_EMULATION (Arnd)
- Add Maxime to drm-misc maintainer group (Sean)

Cc: Arnd Bergmann 
Cc: Sean Paul 


Arnd Bergmann (1):
  drm/imx: fix build failure without CONFIG_DRM_FBDEV_EMULATION

Sean Paul (1):
  MAINTAINERS: Add Maxime Ripard as drm-misc maintainer

 MAINTAINERS| 2 +-
 drivers/gpu/drm/imx/imx-drm-core.c | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Convert _print_param to a macro

2018-10-10 Thread Michal Wajdeczko
On Wed, 10 Oct 2018 14:01:40 +0200, Jani Nikula  
 wrote:



On Tue, 09 Oct 2018, Nick Desaulniers  wrote:

On Tue, Oct 9, 2018 at 10:14 AM Nathan Chancellor
 wrote:


When building the kernel with Clang with defconfig and CONFIG_64BIT
disabled, vmlinux fails to link because of the BUILD_BUG in
_print_param.

ld: drivers/gpu/drm/i915/i915_params.o: in function `i915_params_dump':
i915_params.c:(.text+0x56): undefined reference to
`__compiletime_assert_191'

This function is semantically invalid unless the code is first inlined
then constant folded, which doesn't work for Clang because semantic
analysis happens before optimization/inlining. Converting this function
to a macro avoids this problem and allows Clang to properly remove the
BUILD_BUG during optimization.


Thanks Nathan for the patch.  To provide more context, Clang does
semantic analysis before optimization, where as GCC does these
together (IIUC).  So the above link error is from the naked
BUILD_BUG().  Clang can't evaluate the __builtin_strcmp's statically
until inlining has occurred, but that optimization happens after
semantic analysis.  To do the inlining before semantic analysis, we
MUST leverage the preprocessor, which runs before the compiler starts
doing semantic analysis.  I suspect this code is not valid for GCC
unless optimizations are enabled (the kernel only does compile with
optimizations turned on).  This change allows us to build this
translation unit with Clang.

Acked-by: Nick Desaulniers 
(Note: this is the change I suggested, so not sure whether Acked-by or
Reviewed-by is more appropriate).


*Sad trombone*

I'd rather see us converting more macros to static inlines than the
other way round.

I'll let others chime in if they have any better ideas, otherwise I'll
apply this one.


Option 1: Just drop BUILD_BUG() from _print_param() function.

Option 2: Use aliases instead of real types in param() macros.

Aliases can be same as in linux/moduleparam.h (charp|int|uint|bool)
We can convert aliases back to real types but it will also allow
to construct proper names for dedicated functions - see [1]

Michal

[1] https://patchwork.freedesktop.org/patch/255928/




BR,
Jani.





The output of 'objdump -D' is identically before and after this change
for GCC regardless of if CONFIG_64BIT is set and allows Clang to link
the kernel successfully with or without CONFIG_64BIT set.

Link: https://github.com/ClangBuiltLinux/linux/issues/191
Suggested-by: Nick Desaulniers 
Signed-off-by: Nathan Chancellor 
---
 drivers/gpu/drm/i915/i915_params.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

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

index 295e981e4a39..a0f20b9b6f2d 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -174,22 +174,19 @@ i915_param_named(enable_dpcd_backlight, bool,  
0600,

 i915_param_named(enable_gvt, bool, 0400,
"Enable support for Intel GVT-g graphics virtualization host  
support(default:false)");


-static __always_inline void _print_param(struct drm_printer *p,
-const char *name,
-const char *type,
-const void *x)
-{
-   if (!__builtin_strcmp(type, "bool"))
-   drm_printf(p, "i915.%s=%s\n", name, yesno(*(const bool  
*)x));

-   else if (!__builtin_strcmp(type, "int"))
-   drm_printf(p, "i915.%s=%d\n", name, *(const int *)x);
-   else if (!__builtin_strcmp(type, "unsigned int"))
-   drm_printf(p, "i915.%s=%u\n", name, *(const unsigned  
int *)x);

-   else if (!__builtin_strcmp(type, "char *"))
-   drm_printf(p, "i915.%s=%s\n", name, *(const char **)x);
-   else
-   BUILD_BUG();
-}
+#define _print_param(p, name, type,  
x)\
+do  
{   
\
+   if (!__builtin_strcmp(type,  
"bool"))   \
+   drm_printf(p, "i915.%s=%s\n", name, yesno(*(const bool  
*)x));  \
+   else if (!__builtin_strcmp(type,  
"int"))   \
+   drm_printf(p, "i915.%s=%d\n", name, *(const int  
*)x);  \
+   else if (!__builtin_strcmp(type, "unsigned  
int"))  \
+   drm_printf(p, "i915.%s=%u\n", name, *(const unsigned  
int *)x); \
+   else if (!__builtin_strcmp(type, "char  
*"))\
+   drm_printf(p, "i915.%s=%s\n", name, *(const char  
**)x);\
+
else
\
+
BUILD_BUG();   \

+} while (0)

 /**
  * i915_params_dump - dump i915 modparams
--
2.19.0


___

Re: [Intel-gfx] [PATCH 2/4] drm/i915/perf: pass stream to vfuncs when possible

2018-10-10 Thread Matthew Auld
On Wed, 10 Oct 2018 at 19:55, Lionel Landwerlin
 wrote:
>
> We want to use some of the properties of the perf stream to program
> the hardware in a later commit.
>
> v2: Pass only perf stream as argument (Matthew)
>
> Signed-off-by: Lionel Landwerlin 
> Reviewed-by: Matthew Auld  (v1)
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v11 2/2] drm/i915: Adding YUV444 packed format support for skl+

2018-10-10 Thread Ville Syrjälä
On Thu, Oct 04, 2018 at 03:43:49PM +0300, Stanislav Lisovskiy wrote:
> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
> specification.
> 
> v2: Edited commit message, removed redundant whitespaces.
> 
> v3: Fixed fallthrough logic for the format switch cases.
> 
> v4: Yet again fixed fallthrough logic, to reuse code from other case
> labels.
> 
> v5: Started to use XYUV instead of AYUV, as we don't use alpha.
> 
> v6: Removed unneeded initializer for new XYUV format.
> 
> v7: Added scaling support for DRM_FORMAT_XYUV
> 
> v8: Edited commit message to be more clear about skl+, renamed
> PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
> doesn't support per-pixel alpha. Fixed minor code issues.
> 
> v9: Moved DRM format check to proper place in intel_framebuffer_init.
> 
> v10: Added missing XYUV format to sprite planes for skl+.
> 
> v11: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV.
> 
> Signed-off-by: Stanislav Lisovskiy 

Looks good to me.
Reviewed-by: Ville Syrjälä 

Though one thing we probably want to do still is adjust
intel_plane_check_src_coordinates() to allow odd coordinates for
this format. I think we should be able to just replace those
hardcoded numbers in there with fb->format->[hv]sub and it should
just work (tm).

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  2 +-
>  drivers/gpu/drm/i915/intel_display.c | 15 +++
>  drivers/gpu/drm/i915/intel_sprite.c  |  3 +++
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 09bc8e730ee1..ac24ac4b1d51 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6501,7 +6501,7 @@ enum {
>  #define   PLANE_CTL_FORMAT_XRGB_2101010  (2 << 24)
>  #define   PLANE_CTL_FORMAT_XRGB_ (4 << 24)
>  #define   PLANE_CTL_FORMAT_XRGB_16161616F(6 << 24)
> -#define   PLANE_CTL_FORMAT_AYUV  (8 << 24)
> +#define   PLANE_CTL_FORMAT_XYUV  (8 << 24)
>  #define   PLANE_CTL_FORMAT_INDEXED   (12 << 24)
>  #define   PLANE_CTL_FORMAT_RGB_565   (14 << 24)
>  #define   ICL_PLANE_CTL_FORMAT_MASK  (0x1f << 23)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b2bab57cd113..9e65c47f3f4c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -87,6 +87,7 @@ static const uint32_t skl_primary_formats[] = {
>   DRM_FORMAT_YVYU,
>   DRM_FORMAT_UYVY,
>   DRM_FORMAT_VYUY,
> + DRM_FORMAT_XYUV,
>  };
>  
>  static const uint32_t skl_pri_planar_formats[] = {
> @@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = {
>   DRM_FORMAT_YVYU,
>   DRM_FORMAT_UYVY,
>   DRM_FORMAT_VYUY,
> + DRM_FORMAT_XYUV,
>   DRM_FORMAT_NV12,
>  };
>  
> @@ -2673,6 +2675,8 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
> bool alpha)
>   return DRM_FORMAT_RGB565;
>   case PLANE_CTL_FORMAT_NV12:
>   return DRM_FORMAT_NV12;
> + case PLANE_CTL_FORMAT_XYUV:
> + return DRM_FORMAT_XYUV;
>   default:
>   case PLANE_CTL_FORMAT_XRGB_:
>   if (rgb_order) {
> @@ -3502,6 +3506,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
>   return PLANE_CTL_FORMAT_XRGB_2101010;
>   case DRM_FORMAT_XBGR2101010:
>   return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010;
> + case DRM_FORMAT_XYUV:
> + return PLANE_CTL_FORMAT_XYUV;
>   case DRM_FORMAT_YUYV:
>   return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
>   case DRM_FORMAT_YVYU:
> @@ -4960,6 +4966,7 @@ static int skl_update_scaler_plane(struct 
> intel_crtc_state *crtc_state,
>   case DRM_FORMAT_UYVY:
>   case DRM_FORMAT_VYUY:
>   case DRM_FORMAT_NV12:
> + case DRM_FORMAT_XYUV:
>   break;
>   default:
>   DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
> 0x%x\n",
> @@ -13421,6 +13428,7 @@ static bool skl_plane_format_mod_supported(struct 
> drm_plane *_plane,
>   case DRM_FORMAT_UYVY:
>   case DRM_FORMAT_VYUY:
>   case DRM_FORMAT_NV12:
> + case DRM_FORMAT_XYUV:
>   if (modifier == I915_FORMAT_MOD_Yf_TILED)
>   return true;
>   /* fall through */
> @@ -14545,6 +14553,13 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   goto err;
>   }
>   break;
> + case DRM_FORMAT_XYUV:
> + if (INTEL_GEN(dev_priv) < 9) {
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +   
> drm_get_format_name(mode_cmd->pixel_format, _name));
> + goto err;
> + }
> + break;
>   case DRM_FORMAT_YUYV:
>   

Re: [Intel-gfx] [PATCH xf86-video-intel v3 2/2] sna: Added AYUV format support for textured and sprite video adapters.

2018-10-10 Thread Ville Syrjälä
On Tue, Oct 09, 2018 at 04:30:17PM +0300, Stanislav Lisovskiy wrote:
> v2: Renamed DRM_FORMAT_XYUV to DRM_FORMAT_XYUV.
> Added comment about AYUV byte ordering in Gstreamer.
> 
> v3: Removed sna_composite_op flags related change to the separate patch.
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  src/render_program/Makefile.am|   2 +
>  .../exa_wm_src_sample_argb_ayuv.g8a   |  60 +++
>  .../exa_wm_src_sample_argb_ayuv.g8b   |   6 +
>  src/sna/gen9_render.c |  27 
>  src/sna/sna_render.h  |   4 +
>  src/sna/sna_video.c   | 147 ++
>  src/sna/sna_video.h   |  20 +++
>  src/sna/sna_video_sprite.c|  19 ++-
>  src/sna/sna_video_textured.c  |   8 +
>  9 files changed, 288 insertions(+), 5 deletions(-)
>  create mode 100644 src/render_program/exa_wm_src_sample_argb_ayuv.g8a
>  create mode 100644 src/render_program/exa_wm_src_sample_argb_ayuv.g8b
> 
> diff --git a/src/render_program/Makefile.am b/src/render_program/Makefile.am
> index dc58138f..e35ffa52 100644
> --- a/src/render_program/Makefile.am
> +++ b/src/render_program/Makefile.am
> @@ -196,6 +196,7 @@ INTEL_G7B =   \
>  INTEL_G8A =  \
>   exa_wm_src_affine.g8a   \
>   exa_wm_src_sample_argb.g8a  \
> + exa_wm_src_sample_argb_ayuv.g8a \
>   exa_wm_src_sample_nv12.g8a  \
>   exa_wm_src_sample_planar.g8a\
>   exa_wm_write.g8a\
> @@ -205,6 +206,7 @@ INTEL_G8A =   \
>  
>  INTEL_G8B =  \
>   exa_wm_src_affine.g8b   \
> + exa_wm_src_sample_argb_ayuv.g8b \
>   exa_wm_src_sample_argb.g8b  \
>   exa_wm_src_sample_nv12.g8b  \
>   exa_wm_src_sample_planar.g8b\
> diff --git a/src/render_program/exa_wm_src_sample_argb_ayuv.g8a 
> b/src/render_program/exa_wm_src_sample_argb_ayuv.g8a
> new file mode 100644
> index ..d79840ac
> --- /dev/null
> +++ b/src/render_program/exa_wm_src_sample_argb_ayuv.g8a
> @@ -0,0 +1,60 @@
> +/*
> + * Copyright © 2006 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Wang Zhenyu 
> + *Keith Packard 
> + */
> +
> +/* Sample the src surface */
> +
> +include(`exa_wm.g4i')
> +
> +undefine(`src_msg')
> +undefine(`src_msg_ind')
> +
> +define(`src_msg',   `g65')
> +define(`src_msg_ind',   `65')
> +
> +/* prepare sampler read back gX register, which would be written back to 
> output */
> +
> +/* use simd16 sampler, param 0 is u, param 1 is v. */
> +/* 'payload' loading, assuming tex coord start from g4 */
> +
> +/* load argb */
> +mov (1) g0.8<1>UD0xUD { align1 mask_disable };
> +mov (8) src_msg<1>UD g0<8,8,1>UD { align1 }; /* copy to msg start reg*/
> +
> +/* src_msg will be copied with g0, as it contains send desc */
> +/* emit sampler 'send' cmd */
> +send (16) src_msg_ind/* msg reg index */
> + src_sample_base<1>UW /* readback */
> + null
> + sampler (1,0,F) /* sampler message description, 
> (binding_table,sampler_index,datatype)
> + /* here(src->dst) we should use src_sampler and 
> src_surface */
> + mlen 5 rlen 8 { align1 };   /* required message len 5, readback len 8 */
> +
> +/* Put CbCr into right places */

I guess this could use a comment that we follow the nonsense gstreamer
byte order here rather than the proper AYUV byte order. Or maybe it
would make more sense to just byte swap during the copy anyway.

> +mov (16) src_sample_b<1>UD src_sample_r<1>UD  { align1 };
> +mov (16) src_sample_r<1>UD src_sample_a<1>UD  { align1 };
> +mov (16) src_sample_a<1>F 1.0F;
> +
> diff --git 

Re: [Intel-gfx] [PATCH 3/4] drm/i915/perf: do not warn when OA buffer is already allocated

2018-10-10 Thread Matthew Auld
On Wed, 10 Oct 2018 at 19:55, Lionel Landwerlin
 wrote:
>
> If 2 processes race to open the perf stream, it's possible that one of them
> will see that OA buffer has already been allocated, while a previous process
> is still finishing to reprogram the hardware (on gen8+).
>
> The opening sequence has been reworked a few times and we probably lost
> track of the order in which things are supposed to happen.
>
> Signed-off-by: Lionel Landwerlin 

Accidental resend, or did the locking actually change recently?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 06/10] drm/i915/icl: Mark TC port as safe when interruptions are disabled

2018-10-10 Thread Ville Syrjälä
On Wed, Oct 10, 2018 at 06:27:07PM +, Souza, Jose wrote:
> On Wed, 2018-10-10 at 20:52 +0300, Ville Syrjälä wrote:
> > On Wed, Oct 10, 2018 at 05:23:30PM +, Souza, Jose wrote:
> > > On Wed, 2018-10-10 at 20:15 +0300, Ville Syrjälä wrote:
> > > > On Wed, Oct 10, 2018 at 12:55:07AM +, Souza, Jose wrote:
> > > > > On Tue, 2018-10-02 at 23:35 +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Oct 02, 2018 at 10:50:50AM -0700, José Roberto de
> > > > > > Souza
> > > > > > wrote:
> > > > > > > Before enter in power saving states or before unload the
> > > > > > > driver
> > > > > > > spec states that display driver is required to to mark TC
> > > > > > > ports
> > > > > > > as
> > > > > > > safe so hardware can do the disconnection flow without wait
> > > > > > > for
> > > > > > > display driver handshake.
> > > > > > > When driver is resumed or loaded again, if the TC live
> > > > > > > state is
> > > > > > > still set as connected driver will mark again TC port as
> > > > > > > not
> > > > > > > safe
> > > > > > > as
> > > > > > > required by spec.
> > > > > > > 
> > > > > > > BSpec: 2175
> > > > > > > 
> > > > > > > Cc: Paulo Zanoni 
> > > > > > > Signed-off-by: José Roberto de Souza 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/i915_irq.c | 10 ++
> > > > > > >  1 file changed, 10 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > > index 2e242270e270..58616690f45f 100644
> > > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > > @@ -3640,6 +3640,7 @@ static void gen11_irq_reset(struct
> > > > > > > drm_device
> > > > > > > *dev)
> > > > > > >  {
> > > > > > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > > > > > >   int pipe;
> > > > > > > + u32 val;
> > > > > > >  
> > > > > > >   I915_WRITE(GEN11_GFX_MSTR_IRQ, 0);
> > > > > > >   POSTING_READ(GEN11_GFX_MSTR_IRQ);
> > > > > > > @@ -3661,6 +3662,15 @@ static void gen11_irq_reset(struct
> > > > > > > drm_device *dev)
> > > > > > >  
> > > > > > >   if (HAS_PCH_ICP(dev_priv))
> > > > > > >   GEN3_IRQ_RESET(SDE);
> > > > > > > +
> > > > > > > + /*
> > > > > > > +  * Mark TC ports as safe so hardware can do the
> > > > > > > disconnect flow
> > > > > > > without
> > > > > > > +  * wait for driver to do the handshake
> > > > > > > +  */
> > > > > > > + val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > > > > > + for (pipe = 0; pipe < 4; pipe++)
> > > > > > > + val &= ~(DP_PHY_MODE_STATUS_NOT_SAFE(pipe));
> > > > > > > + I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > > > > > 
> > > > > > Why would we have to do this here? The driver should
> > > > > > relinquish
> > > > > > control
> > > > > > if and when it has shut down the pipes etc. Sounds like a bug
> > > > > > if
> > > > > > we're
> > > > > > hanging on when we have no need for the port.
> > > > > 
> > > > > Right now we take control and only release it when port is
> > > > > disconnected.
> > > > 
> > > > Disconnection is totally asynchronous. Someone could be using the
> > > > port/aux for anything when the disconnect irq happens. Presumably
> > > > bad things will happen if we just go and yank the control away
> > > > when someone is doing stuff. I believe even the spec tells us
> > > > to properly shut things down during the disconnect flow and make
> > > > sure eg. the aux power wells have been fully shut down before
> > > > relinquishing control.
> > > 
> > > In my understanding at the point of the gen11_irq_reset() call all
> > > DDI
> > > DDI ports and aux channels are already off.
> > 
> > I'm not talking about gen11_irq_reset(). But if we are then that gets
> > called during driver load too and everything could be up and running.
> > Though I'm not sure what the BIOS/GOP will do w.r.t. the safe mode
> > knob.
> 
> BIOS should do the same connection flow to use sinks in tc ports.
> 
> > 
> > Anyways, I don't think poking at some display stuff from irq_reset()
> > is a particularly clean apporoach. The irq code should only concern
> 
> Move it to a function? Or move everything reseting display irq to a
> function like is done for gen11_gt_irq_reset().
> 
> > itself with irqs. If we properly track which mode the port is in then
> > I presume we'd just put it back into the tbt mode when the last
> > typec mode user goes away. Or if we try to keep it in typec mode even
> > when there are no users (as some kind of optimimization perhaps?)
> > then
> > we should probably switch it back to tbt mode during some display
> > suspend/shutdown sequence.
> 
> We don't control what mode the connector is in, HW is the one that tell
> us if it is in: type-c, TBT, legacy or disconnected state our only job
> is grab and release this knob.

So s/tbt mode/safe mode/ or whatever. Semantics.

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Check for hangs mid context execution tests

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Check for hangs mid context execution tests
URL   : https://patchwork.freedesktop.org/series/50801/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4961_full -> Patchwork_10413_full =

== Summary - WARNING ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render:
  shard-snb:  SKIP -> PASS

igt@perf_pmu@rc6:
  shard-kbl:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_schedule@pi-ringfull-vebox:
  shard-skl:  NOTRUN -> FAIL (fdo#103158)

igt@gem_ppgtt@blt-vs-render-ctxn:
  shard-skl:  NOTRUN -> TIMEOUT (fdo#108039)

igt@kms_busy@extended-modeset-hang-newfb-render-a:
  shard-skl:  NOTRUN -> DMESG-WARN (fdo#107956)

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render:
  shard-glk:  PASS -> FAIL (fdo#103167)

igt@kms_panel_fitting@legacy:
  shard-skl:  NOTRUN -> FAIL (fdo#105456)

{igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb}:
  shard-skl:  NOTRUN -> FAIL (fdo#108145) +1

{igt@kms_plane_alpha_blend@pipe-b-coverage-7efc}:
  shard-skl:  NOTRUN -> FAIL (fdo#108146)

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)

igt@pm_rpm@debugfs-forcewake-user:
  shard-skl:  PASS -> INCOMPLETE (fdo#107807)

igt@pm_rpm@gem-idle:
  shard-skl:  NOTRUN -> INCOMPLETE (fdo#107807)


 Possible fixes 

igt@drv_suspend@debugfs-reader:
  shard-skl:  INCOMPLETE (fdo#104108, fdo#107773) -> PASS

igt@kms_busy@extended-modeset-hang-newfb-render-a:
  shard-snb:  DMESG-WARN (fdo#107956) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
  shard-apl:  FAIL (fdo#103167) -> PASS

igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
  shard-glk:  FAIL (fdo#103166) -> PASS

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS

igt@pm_rpm@gem-mmap-cpu:
  shard-skl:  INCOMPLETE (fdo#107807) -> PASS


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

  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
  fdo#105456 https://bugs.freedesktop.org/show_bug.cgi?id=105456
  fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773
  fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#108039 https://bugs.freedesktop.org/show_bug.cgi?id=108039
  fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145
  fdo#108146 https://bugs.freedesktop.org/show_bug.cgi?id=108146
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4961 -> Patchwork_10413

  CI_DRM_4961: 1b9d983587107509e70d14509fcd304b19ae0ce0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10413: 2f79f218c3ba344e17eb939a94f45b144070967d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10413/shards.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 drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK
URL   : https://patchwork.freedesktop.org/series/50815/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4964 -> Patchwork_10416 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50815/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#107139, fdo#105128) -> PASS


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


== Participating hosts (46 -> 40) ==

  Additional (1): fi-skl-guc 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan 
fi-snb-2520m fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4964 -> Patchwork_10416

  CI_DRM_4964: 0254d94ff70753445677077960e800e0c4838c7a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10416: abbef66371ccac83818900f0565607c01ad0d1af @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

abbef66371cc drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors

2018-10-10 Thread Ville Syrjälä
On Tue, Oct 09, 2018 at 04:44:24PM -0400, Lyude Paul wrote:
> It appears when testing my previous fix for some of the legacy
> modesetting issues with MST, I misattributed some kernel splats that
> started appearing on my machine after a rebase as being from upstream.
> But it appears they actually came from my patch series:
> 
> [2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] 
> Updating routing for [CONNECTOR:65:eDP-1]
> [2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] 
> [CONNECTOR:65:eDP-1] is not registered
> [2.980516] [ cut here ]
> [2.980519] Could not determine valid watermarks for inherited state
> [2.980553] WARNING: CPU: 3 PID: 551 at 
> drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 
> [i915]
> [2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) 
> syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl 
> x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 
> mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm 
> thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd 
> xhci_pci xhci_hcd
> [2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G   O 
>  4.19.0-rc7Lyude-Test+ #1
> [2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW 
> (1.27 ) 11/10/2016
> [2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915]
> [2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 
> df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b 
> e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00
> [2.980611] RSP: 0018:c9287988 EFLAGS: 00010282
> [2.980614] RAX:  RBX: 88031b488000 RCX: 
> 0006
> [2.980617] RDX: 0007 RSI: 0086 RDI: 
> 880321ad54d0
> [2.980620] RBP: c9287a10 R08: 040a R09: 
> 0065
> [2.980623] R10: 88030ebb8f00 R11: 81416590 R12: 
> 88031b488000
> [2.980626] R13: 88031b4883a0 R14: c92879a8 R15: 
> 880319099800
> [2.980630] FS:  7f475620d180() GS:880321ac() 
> knlGS:
> [2.980633] CS:  0010 DS:  ES:  CR0: 80050033
> [2.980636] CR2: 7f9ef28018a0 CR3: 00031b72c001 CR4: 
> 003606e0
> [2.980639] DR0:  DR1:  DR2: 
> 
> [2.980642] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [2.980645] Call Trace:
> [2.980675]  i915_driver_load+0xb0e/0xdc0 [i915]
> [2.980681]  ? kernfs_add_one+0xe7/0x130
> [2.980709]  i915_pci_probe+0x46/0x60 [i915]
> [2.980715]  pci_device_probe+0xd4/0x150
> [2.980719]  really_probe+0x243/0x3b0
> [2.980722]  driver_probe_device+0xba/0x100
> [2.980726]  __driver_attach+0xe4/0x110
> [2.980729]  ? driver_probe_device+0x100/0x100
> [2.980733]  bus_for_each_dev+0x74/0xb0
> [2.980736]  driver_attach+0x1e/0x20
> [2.980739]  bus_add_driver+0x159/0x230
> [2.980743]  ? 0xa0393000
> [2.980746]  driver_register+0x70/0xc0
> [2.980749]  ? 0xa0393000
> [2.980753]  __pci_register_driver+0x57/0x60
> [2.980780]  i915_init+0x55/0x58 [i915]
> [2.980785]  do_one_initcall+0x4a/0x1c4
> [2.980789]  ? do_init_module+0x27/0x210
> [2.980793]  ? kmem_cache_alloc_trace+0x131/0x190
> [2.980797]  do_init_module+0x60/0x210
> [2.980800]  load_module+0x2063/0x22e0
> [2.980804]  ? vfs_read+0x116/0x140
> [2.980807]  ? vfs_read+0x116/0x140
> [2.980811]  __do_sys_finit_module+0xbd/0x120
> [2.980814]  ? __do_sys_finit_module+0xbd/0x120
> [2.980818]  __x64_sys_finit_module+0x1a/0x20
> [2.980821]  do_syscall_64+0x5a/0x110
> [2.980824]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [2.980826] RIP: 0033:0x7f4754e32879
> [2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 
> f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 
> 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48
> [2.980831] RSP: 002b:7fff43fd97d8 EFLAGS: 0246 ORIG_RAX: 
> 0139
> [2.980834] RAX: ffda RBX: 559a44ca64f0 RCX: 
> 7f4754e32879
> [2.980836] RDX:  RSI: 7f475599f4cd RDI: 
> 0018
> [2.980838] RBP: 7f475599f4cd R08:  R09: 
> 
> [2.980839] R10: 0018 R11: 0246 R12: 
> 
> [2.980841] R13: 559a44c92fd0 R14: 0002 R15: 
> 
> [2.980881] WARNING: CPU: 3 PID: 551 at 
> drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 
> [i915]
> [2.980884] ---[ end trace 5eb47a76277d4731 ]---
> 
> The cause of this appears to be due to the fact that if 

Re: [Intel-gfx] [PATCH 06/10] drm/i915/icl: Mark TC port as safe when interruptions are disabled

2018-10-10 Thread Souza, Jose
On Wed, 2018-10-10 at 20:52 +0300, Ville Syrjälä wrote:
> On Wed, Oct 10, 2018 at 05:23:30PM +, Souza, Jose wrote:
> > On Wed, 2018-10-10 at 20:15 +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 10, 2018 at 12:55:07AM +, Souza, Jose wrote:
> > > > On Tue, 2018-10-02 at 23:35 +0300, Ville Syrjälä wrote:
> > > > > On Tue, Oct 02, 2018 at 10:50:50AM -0700, José Roberto de
> > > > > Souza
> > > > > wrote:
> > > > > > Before enter in power saving states or before unload the
> > > > > > driver
> > > > > > spec states that display driver is required to to mark TC
> > > > > > ports
> > > > > > as
> > > > > > safe so hardware can do the disconnection flow without wait
> > > > > > for
> > > > > > display driver handshake.
> > > > > > When driver is resumed or loaded again, if the TC live
> > > > > > state is
> > > > > > still set as connected driver will mark again TC port as
> > > > > > not
> > > > > > safe
> > > > > > as
> > > > > > required by spec.
> > > > > > 
> > > > > > BSpec: 2175
> > > > > > 
> > > > > > Cc: Paulo Zanoni 
> > > > > > Signed-off-by: José Roberto de Souza 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/i915_irq.c | 10 ++
> > > > > >  1 file changed, 10 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > index 2e242270e270..58616690f45f 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > @@ -3640,6 +3640,7 @@ static void gen11_irq_reset(struct
> > > > > > drm_device
> > > > > > *dev)
> > > > > >  {
> > > > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > > > int pipe;
> > > > > > +   u32 val;
> > > > > >  
> > > > > > I915_WRITE(GEN11_GFX_MSTR_IRQ, 0);
> > > > > > POSTING_READ(GEN11_GFX_MSTR_IRQ);
> > > > > > @@ -3661,6 +3662,15 @@ static void gen11_irq_reset(struct
> > > > > > drm_device *dev)
> > > > > >  
> > > > > > if (HAS_PCH_ICP(dev_priv))
> > > > > > GEN3_IRQ_RESET(SDE);
> > > > > > +
> > > > > > +   /*
> > > > > > +* Mark TC ports as safe so hardware can do the
> > > > > > disconnect flow
> > > > > > without
> > > > > > +* wait for driver to do the handshake
> > > > > > +*/
> > > > > > +   val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > > > > +   for (pipe = 0; pipe < 4; pipe++)
> > > > > > +   val &= ~(DP_PHY_MODE_STATUS_NOT_SAFE(pipe));
> > > > > > +   I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > > > > 
> > > > > Why would we have to do this here? The driver should
> > > > > relinquish
> > > > > control
> > > > > if and when it has shut down the pipes etc. Sounds like a bug
> > > > > if
> > > > > we're
> > > > > hanging on when we have no need for the port.
> > > > 
> > > > Right now we take control and only release it when port is
> > > > disconnected.
> > > 
> > > Disconnection is totally asynchronous. Someone could be using the
> > > port/aux for anything when the disconnect irq happens. Presumably
> > > bad things will happen if we just go and yank the control away
> > > when someone is doing stuff. I believe even the spec tells us
> > > to properly shut things down during the disconnect flow and make
> > > sure eg. the aux power wells have been fully shut down before
> > > relinquishing control.
> > 
> > In my understanding at the point of the gen11_irq_reset() call all
> > DDI
> > DDI ports and aux channels are already off.
> 
> I'm not talking about gen11_irq_reset(). But if we are then that gets
> called during driver load too and everything could be up and running.
> Though I'm not sure what the BIOS/GOP will do w.r.t. the safe mode
> knob.

BIOS should do the same connection flow to use sinks in tc ports.

> 
> Anyways, I don't think poking at some display stuff from irq_reset()
> is a particularly clean apporoach. The irq code should only concern

Move it to a function? Or move everything reseting display irq to a
function like is done for gen11_gt_irq_reset().

> itself with irqs. If we properly track which mode the port is in then
> I presume we'd just put it back into the tbt mode when the last
> typec mode user goes away. Or if we try to keep it in typec mode even
> when there are no users (as some kind of optimimization perhaps?)
> then
> we should probably switch it back to tbt mode during some display
> suspend/shutdown sequence.

We don't control what mode the connector is in, HW is the one that tell
us if it is in: type-c, TBT, legacy or disconnected state our only job
is grab and release this knob.

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


Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v2)

2018-10-10 Thread Guang Bai
On Mon, 8 Oct 2018 08:56:20 -0700
Guang Bai  wrote:

> On Mon, 8 Oct 2018 22:35:34 +0800
> Chris Chiu  wrote:
> 
> > Thanks! I have no problem with this patch.  
> 
> There are Fi.CI.BAT failures with the v2 (only with formatting fix
> added) while the previous patch had passing results.
> Now trying to identify why the failures happened with trybot
> Thanks,
> Guang
The tribot run my patch twice and passes the tests without any error
however I'm recommended to chase down root causes of Patchwork Fi.CI.BAT
test errors still - WIP on that.
Thanks,
Guang
> 
> > 
> > On Thu, Oct 4, 2018 at 2:08 AM Guang Bai 
> > wrote: 
> > > On some platforms, slowly unplugging (wiggling) the HDMI cable
> > > makes the kernel to believe the HDMI display still connected.
> > > This is because the HDMI DDC lines are disconnected sometimes
> > > later after the hot-plug interrupt triggered. Use the hot plug
> > > live states to honor HDMI hot plug status in addtion to access
> > > the DDC channels.
> > >
> > > v2: Fix the formatting issue
> > >
> > > Cc: Jani Nikula 
> > > Cc: Chris Chiu 
> > > Signed-off-by: Guang Bai 
> > > ---
> > >  drivers/gpu/drm/i915/intel_hotplug.c | 32
> > > +--- 1 file changed, 29 insertions(+),
> > > 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > > b/drivers/gpu/drm/i915/intel_hotplug.c
> > > index 648a13c..98ab1ab 100644
> > > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > > @@ -246,17 +246,43 @@ static void
> > > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > > intel_runtime_pm_put(dev_priv);
> > >  }
> > >
> > > +#define MAX_SHORT_PULSE_MS 100
> > > +#define PORT_CHECK_LOOP_COUNT  3
> > > +
> > >  bool intel_encoder_hotplug(struct intel_encoder *encoder,
> > >struct intel_connector *connector)
> > >  {
> > > struct drm_device *dev = connector->base.dev;
> > > -   enum drm_connector_status old_status;
> > > +   enum drm_connector_status old_status, new_status;
> > > +   enum hpd_pin pin = encoder->hpd_pin;
> > > +   struct drm_i915_private *dev_priv =
> > > to_i915(encoder->base.dev);
> > > +   u32 count = 0;
> > >
> > > WARN_ON(!mutex_is_locked(>mode_config.mutex));
> > > old_status = connector->base.status;
> > >
> > > -   connector->base.status =
> > > -   drm_helper_probe_detect(>base, NULL,
> > > false);
> > > +   /*
> > > +* Set HDMI connection status based on hot-plug live
> > > states and
> > > +* display probe results.
> > > +*/
> > > +   if ((encoder->type == INTEL_OUTPUT_HDMI ||
> > > +encoder->type == INTEL_OUTPUT_DDI) &&
> > > +   dev_priv->hotplug.stats[pin].state == HPD_ENABLED) {
> > > +   do {
> > > +   new_status =
> > > connector_status_disconnected;
> > > +   msleep(MAX_SHORT_PULSE_MS);
> > > +
> > > +   if (intel_digital_port_connected(encoder))
> > > +   new_status =
> > > drm_helper_probe_detect(>base,
> > > +
> > > NULL, false);
> > > +   if (new_status ==
> > > connector_status_connected)
> > > +   break;
> > > +   } while (++count <= PORT_CHECK_LOOP_COUNT);
> > > +   connector->base.status = new_status;
> > > +   } else {
> > > +   connector->base.status =
> > > +   drm_helper_probe_detect(>base,
> > > NULL, false);
> > > +   }
> > >
> > > if (old_status == connector->base.status)
> > > return false;
> > > --
> > > 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


Re: [Intel-gfx] [PATCH 06/10] drm/i915/icl: Mark TC port as safe when interruptions are disabled

2018-10-10 Thread Ville Syrjälä
On Wed, Oct 10, 2018 at 05:23:30PM +, Souza, Jose wrote:
> On Wed, 2018-10-10 at 20:15 +0300, Ville Syrjälä wrote:
> > On Wed, Oct 10, 2018 at 12:55:07AM +, Souza, Jose wrote:
> > > On Tue, 2018-10-02 at 23:35 +0300, Ville Syrjälä wrote:
> > > > On Tue, Oct 02, 2018 at 10:50:50AM -0700, José Roberto de Souza
> > > > wrote:
> > > > > Before enter in power saving states or before unload the driver
> > > > > spec states that display driver is required to to mark TC ports
> > > > > as
> > > > > safe so hardware can do the disconnection flow without wait for
> > > > > display driver handshake.
> > > > > When driver is resumed or loaded again, if the TC live state is
> > > > > still set as connected driver will mark again TC port as not
> > > > > safe
> > > > > as
> > > > > required by spec.
> > > > > 
> > > > > BSpec: 2175
> > > > > 
> > > > > Cc: Paulo Zanoni 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_irq.c | 10 ++
> > > > >  1 file changed, 10 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > index 2e242270e270..58616690f45f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > @@ -3640,6 +3640,7 @@ static void gen11_irq_reset(struct
> > > > > drm_device
> > > > > *dev)
> > > > >  {
> > > > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > > > >   int pipe;
> > > > > + u32 val;
> > > > >  
> > > > >   I915_WRITE(GEN11_GFX_MSTR_IRQ, 0);
> > > > >   POSTING_READ(GEN11_GFX_MSTR_IRQ);
> > > > > @@ -3661,6 +3662,15 @@ static void gen11_irq_reset(struct
> > > > > drm_device *dev)
> > > > >  
> > > > >   if (HAS_PCH_ICP(dev_priv))
> > > > >   GEN3_IRQ_RESET(SDE);
> > > > > +
> > > > > + /*
> > > > > +  * Mark TC ports as safe so hardware can do the
> > > > > disconnect flow
> > > > > without
> > > > > +  * wait for driver to do the handshake
> > > > > +  */
> > > > > + val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > > > + for (pipe = 0; pipe < 4; pipe++)
> > > > > + val &= ~(DP_PHY_MODE_STATUS_NOT_SAFE(pipe));
> > > > > + I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > > > 
> > > > Why would we have to do this here? The driver should relinquish
> > > > control
> > > > if and when it has shut down the pipes etc. Sounds like a bug if
> > > > we're
> > > > hanging on when we have no need for the port.
> > > 
> > > Right now we take control and only release it when port is
> > > disconnected.
> > 
> > Disconnection is totally asynchronous. Someone could be using the
> > port/aux for anything when the disconnect irq happens. Presumably
> > bad things will happen if we just go and yank the control away
> > when someone is doing stuff. I believe even the spec tells us
> > to properly shut things down during the disconnect flow and make
> > sure eg. the aux power wells have been fully shut down before
> > relinquishing control.
> 
> In my understanding at the point of the gen11_irq_reset() call all DDI
> DDI ports and aux channels are already off.

I'm not talking about gen11_irq_reset(). But if we are then that gets
called during driver load too and everything could be up and running.
Though I'm not sure what the BIOS/GOP will do w.r.t. the safe mode
knob.

Anyways, I don't think poking at some display stuff from irq_reset()
is a particularly clean apporoach. The irq code should only concern
itself with irqs. If we properly track which mode the port is in then
I presume we'd just put it back into the tbt mode when the last
typec mode user goes away. Or if we try to keep it in typec mode even
when there are no users (as some kind of optimimization perhaps?) then
we should probably switch it back to tbt mode during some display
suspend/shutdown sequence.

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Inject a failure point when registering a connector (rev2)

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Inject a failure point when registering a connector (rev2)
URL   : https://patchwork.freedesktop.org/series/50797/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4961_full -> Patchwork_10412_full =

== Summary - WARNING ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render:
  shard-snb:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_available_modes_crc@available_mode_test_crc:
  shard-apl:  PASS -> FAIL (fdo#106641)

igt@kms_busy@extended-modeset-hang-newfb-render-a:
  shard-skl:  NOTRUN -> DMESG-WARN (fdo#107956) +1

igt@kms_cursor_crc@cursor-64x64-suspend:
  shard-skl:  PASS -> INCOMPLETE (fdo#104108)

igt@kms_fbcon_fbt@psr:
  shard-skl:  NOTRUN -> FAIL (fdo#107882)

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#105363)

igt@kms_flip@plain-flip-fb-recreate:
  shard-skl:  NOTRUN -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
  shard-skl:  NOTRUN -> FAIL (fdo#103167) +1

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
  shard-apl:  PASS -> FAIL (fdo#103167) +1

igt@kms_frontbuffer_tracking@fbc-1p-rte:
  shard-apl:  PASS -> FAIL (fdo#105682, fdo#103167)

igt@kms_frontbuffer_tracking@fbc-stridechange:
  shard-skl:  NOTRUN -> FAIL (fdo#105683)

igt@kms_frontbuffer_tracking@fbc-suspend:
  shard-skl:  PASS -> INCOMPLETE (fdo#105959, fdo#107773, 
fdo#104108)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  shard-skl:  PASS -> INCOMPLETE (fdo#107773, fdo#104108)

{igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb}:
  shard-skl:  NOTRUN -> FAIL (fdo#108145) +2

igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
  shard-apl:  PASS -> FAIL (fdo#103166) +1

igt@kms_setmode@basic:
  shard-hsw:  PASS -> FAIL (fdo#99912)

igt@pm_rpm@dpms-mode-unset-non-lpsp:
  shard-skl:  SKIP -> INCOMPLETE (fdo#107807)


 Possible fixes 

igt@drv_hangman@error-state-capture-render:
  shard-glk:  INCOMPLETE (fdo#103359, k.org#198133) -> PASS

igt@drv_suspend@debugfs-reader:
  shard-skl:  INCOMPLETE (fdo#107773, fdo#104108) -> PASS

igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
  shard-apl:  DMESG-WARN (fdo#107956) -> PASS +1

igt@kms_cursor_crc@cursor-128x128-random:
  shard-apl:  FAIL (fdo#103232) -> PASS

igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
  shard-apl:  FAIL (fdo#103166) -> PASS

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS

igt@perf_pmu@rc6-runtime-pm:
  shard-apl:  FAIL (fdo#105010) -> PASS

igt@pm_rpm@gem-mmap-cpu:
  shard-skl:  INCOMPLETE (fdo#107807) -> PASS


 Warnings 

igt@kms_addfb_basic@bo-too-small-due-to-tiling:
  shard-snb:  DMESG-WARN (fdo#107469) -> INCOMPLETE (fdo#105411)


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

  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
  fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105682 https://bugs.freedesktop.org/show_bug.cgi?id=105682
  fdo#105683 https://bugs.freedesktop.org/show_bug.cgi?id=105683
  fdo#105959 https://bugs.freedesktop.org/show_bug.cgi?id=105959
  fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641
  fdo#107469 https://bugs.freedesktop.org/show_bug.cgi?id=107469
  fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773
  fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807
  

[Intel-gfx] [PATCH] drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to
the appropriate platforms.

This was especially harsh on GLK since we don't even try to read
the DIMM information on that platforms, hence valid_dimm was
always false and thus we always tried to apply the w/a.
Furthermore the w/a pushed the level 0 latency above the
level 1 latency, which doesn't really make sense.

Cc: Mahesh Kumar 
Cc: Maarten Lankhorst 
Fixes: 86b592876cb6 ("drm/i915: Implement 16GB dimm wa for latency level-0")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1392aa56a55a..a51cd09bbf75 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2881,8 +2881,9 @@ static void intel_read_wm_latency(struct drm_i915_private 
*dev_priv,
 * any underrun. If not able to get Dimm info assume 16GB dimm
 * to avoid any underrun.
 */
-   if (!dev_priv->dram_info.valid_dimm ||
-   dev_priv->dram_info.is_16gb_dimm)
+   if (!IS_GEN9_LP(dev_priv) &&
+   (!dev_priv->dram_info.valid_dimm ||
+dev_priv->dram_info.is_16gb_dimm))
wm[0] += 1;
 
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
-- 
2.18.1

___
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/perf: Add OA buffer size uAPI parameter

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: Add OA buffer size uAPI parameter
URL   : https://patchwork.freedesktop.org/series/50810/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4964 -> Patchwork_10415 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50810/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@amdgpu/amd_cs_nop@sync-fork-compute0:
  fi-kbl-8809g:   PASS -> DMESG-WARN (fdo#107762)

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-peppy:   PASS -> DMESG-WARN (fdo#102614)


 Possible fixes 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128, fdo#107139) -> PASS

igt@kms_frontbuffer_tracking@basic:
  fi-byt-clapper: FAIL (fdo#103167) -> PASS


  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107762 https://bugs.freedesktop.org/show_bug.cgi?id=107762


== Participating hosts (46 -> 40) ==

  Additional (1): fi-skl-guc 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan 
fi-snb-2520m fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4964 -> Patchwork_10415

  CI_DRM_4964: 0254d94ff70753445677077960e800e0c4838c7a @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10415: 1744e940bee4f956796650c739532c78c816a70d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1744e940bee4 drm/i915/perf: add a parameter to control the size of OA buffer
b8b8e91b7a92 drm/i915/perf: do not warn when OA buffer is already allocated
08fd704be37c drm/i915/perf: pass stream to vfuncs when possible
a82d071538ce drm/i915/perf: remove redundant oa buffer initialization

== Logs ==

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


Re: [Intel-gfx] [PATCH 06/10] drm/i915/icl: Mark TC port as safe when interruptions are disabled

2018-10-10 Thread Souza, Jose
On Wed, 2018-10-10 at 20:15 +0300, Ville Syrjälä wrote:
> On Wed, Oct 10, 2018 at 12:55:07AM +, Souza, Jose wrote:
> > On Tue, 2018-10-02 at 23:35 +0300, Ville Syrjälä wrote:
> > > On Tue, Oct 02, 2018 at 10:50:50AM -0700, José Roberto de Souza
> > > wrote:
> > > > Before enter in power saving states or before unload the driver
> > > > spec states that display driver is required to to mark TC ports
> > > > as
> > > > safe so hardware can do the disconnection flow without wait for
> > > > display driver handshake.
> > > > When driver is resumed or loaded again, if the TC live state is
> > > > still set as connected driver will mark again TC port as not
> > > > safe
> > > > as
> > > > required by spec.
> > > > 
> > > > BSpec: 2175
> > > > 
> > > > Cc: Paulo Zanoni 
> > > > Signed-off-by: José Roberto de Souza 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_irq.c | 10 ++
> > > >  1 file changed, 10 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index 2e242270e270..58616690f45f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -3640,6 +3640,7 @@ static void gen11_irq_reset(struct
> > > > drm_device
> > > > *dev)
> > > >  {
> > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > int pipe;
> > > > +   u32 val;
> > > >  
> > > > I915_WRITE(GEN11_GFX_MSTR_IRQ, 0);
> > > > POSTING_READ(GEN11_GFX_MSTR_IRQ);
> > > > @@ -3661,6 +3662,15 @@ static void gen11_irq_reset(struct
> > > > drm_device *dev)
> > > >  
> > > > if (HAS_PCH_ICP(dev_priv))
> > > > GEN3_IRQ_RESET(SDE);
> > > > +
> > > > +   /*
> > > > +* Mark TC ports as safe so hardware can do the
> > > > disconnect flow
> > > > without
> > > > +* wait for driver to do the handshake
> > > > +*/
> > > > +   val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > > +   for (pipe = 0; pipe < 4; pipe++)
> > > > +   val &= ~(DP_PHY_MODE_STATUS_NOT_SAFE(pipe));
> > > > +   I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > > 
> > > Why would we have to do this here? The driver should relinquish
> > > control
> > > if and when it has shut down the pipes etc. Sounds like a bug if
> > > we're
> > > hanging on when we have no need for the port.
> > 
> > Right now we take control and only release it when port is
> > disconnected.
> 
> Disconnection is totally asynchronous. Someone could be using the
> port/aux for anything when the disconnect irq happens. Presumably
> bad things will happen if we just go and yank the control away
> when someone is doing stuff. I believe even the spec tells us
> to properly shut things down during the disconnect flow and make
> sure eg. the aux power wells have been fully shut down before
> relinquishing control.

In my understanding at the point of the gen11_irq_reset() call all DDI
DDI ports and aux channels are already off.

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


Re: [Intel-gfx] [PATCH 06/10] drm/i915/icl: Mark TC port as safe when interruptions are disabled

2018-10-10 Thread Ville Syrjälä
On Wed, Oct 10, 2018 at 12:55:07AM +, Souza, Jose wrote:
> On Tue, 2018-10-02 at 23:35 +0300, Ville Syrjälä wrote:
> > On Tue, Oct 02, 2018 at 10:50:50AM -0700, José Roberto de Souza
> > wrote:
> > > Before enter in power saving states or before unload the driver
> > > spec states that display driver is required to to mark TC ports as
> > > safe so hardware can do the disconnection flow without wait for
> > > display driver handshake.
> > > When driver is resumed or loaded again, if the TC live state is
> > > still set as connected driver will mark again TC port as not safe
> > > as
> > > required by spec.
> > > 
> > > BSpec: 2175
> > > 
> > > Cc: Paulo Zanoni 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/i915_irq.c | 10 ++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index 2e242270e270..58616690f45f 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -3640,6 +3640,7 @@ static void gen11_irq_reset(struct drm_device
> > > *dev)
> > >  {
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > >   int pipe;
> > > + u32 val;
> > >  
> > >   I915_WRITE(GEN11_GFX_MSTR_IRQ, 0);
> > >   POSTING_READ(GEN11_GFX_MSTR_IRQ);
> > > @@ -3661,6 +3662,15 @@ static void gen11_irq_reset(struct
> > > drm_device *dev)
> > >  
> > >   if (HAS_PCH_ICP(dev_priv))
> > >   GEN3_IRQ_RESET(SDE);
> > > +
> > > + /*
> > > +  * Mark TC ports as safe so hardware can do the disconnect flow
> > > without
> > > +  * wait for driver to do the handshake
> > > +  */
> > > + val = I915_READ(PORT_TX_DFLEXDPCSSS);
> > > + for (pipe = 0; pipe < 4; pipe++)
> > > + val &= ~(DP_PHY_MODE_STATUS_NOT_SAFE(pipe));
> > > + I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> > 
> > Why would we have to do this here? The driver should relinquish
> > control
> > if and when it has shut down the pipes etc. Sounds like a bug if
> > we're
> > hanging on when we have no need for the port.
> 
> Right now we take control and only release it when port is
> disconnected.

Disconnection is totally asynchronous. Someone could be using the
port/aux for anything when the disconnect irq happens. Presumably
bad things will happen if we just go and yank the control away
when someone is doing stuff. I believe even the spec tells us
to properly shut things down during the disconnect flow and make
sure eg. the aux power wells have been fully shut down before
relinquishing control.

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


Re: [Intel-gfx] [PATCH 4/4] drm/i915/perf: add a parameter to control the size of OA buffer

2018-10-10 Thread Chris Wilson
Quoting Lionel Landwerlin (2018-10-10 17:55:33)
> +static int
> +select_oa_buffer_size(struct drm_i915_private *i915,
> + u64 requested_size,
> + u32 *selected_size,
> + int *selected_exponent)
> +{
> +   const u32 max_size = SZ_16M;
> +
> +   /*
> +* When no size is specified, use the largest size supported
> +* by all generations.
> +*/
> +   if (!requested_size) {
> +   *selected_size = SZ_16M;
> +   *selected_exponent = 7;
> +   return 0;
> +   }
> +
> +   /* Start with the smallest OA buffer size. */
> +   *selected_size = 128 * 1024;
> +   *selected_exponent = 0;
> +   while (requested_size > *selected_size &&
> +  *selected_size < max_size) {
> +   *selected_size *= 2;
> +   *selected_exponent += 1;
> +   }
> +
> +   if (requested_size > *selected_size)
> +   return -EINVAL; /* TODO: ENOMEM? ENODEV? */

order = order_base_2(requested_size);
if (order > 24)
return -EINVAL;
order = max(order, 17);
*selected_size = 1 << order;
*selected_exponent = order - 17;

Returning both is a little redudnant?

return order; (< 0 -> error) ?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/4] drm/i915/perf: add a parameter to control the size of OA buffer

2018-10-10 Thread Lionel Landwerlin

On 10/10/2018 18:01, Chris Wilson wrote:

Quoting Lionel Landwerlin (2018-10-10 17:55:33)

@@ -1518,12 +1520,14 @@ static int alloc_oa_buffer(struct drm_i915_private 
*dev_priv)
 goto err_unref;
  
 /* PreHSW required 512K alignment, HSW requires 16M */

-   vma = i915_gem_object_ggtt_pin(bo, NULL, 0, SZ_16M, 0);
+   vma = i915_gem_object_ggtt_pin(bo, NULL, 0, size, 0);
That's not size, that's align. Presumably this doesn't change as HSW 
is still going to require 16MiB? -Chris

Duh! Thanks a lot!

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: Add OA buffer size uAPI parameter

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: Add OA buffer size uAPI parameter
URL   : https://patchwork.freedesktop.org/series/50810/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: remove redundant oa buffer initialization
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3725:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3708:16: warning: expression 
using sizeof(void)

Commit: drm/i915/perf: pass stream to vfuncs when possible
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3708:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3707:16: warning: expression 
using sizeof(void)

Commit: drm/i915/perf: do not warn when OA buffer is already allocated
Okay!

Commit: drm/i915/perf: add a parameter to control the size of OA buffer
-O:drivers/gpu/drm/i915/i915_perf.c:1422:15: warning: memset with byte count of 
16777216
-O:drivers/gpu/drm/i915/i915_perf.c:1480:15: warning: memset with byte count of 
16777216
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3707:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3709:16: warning: expression 
using sizeof(void)

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: Add OA buffer size uAPI parameter

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915/perf: Add OA buffer size uAPI parameter
URL   : https://patchwork.freedesktop.org/series/50810/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a82d071538ce drm/i915/perf: remove redundant oa buffer initialization
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
gen[78]_oa_enable), so we don't need to initialize when preparing the metric

total: 0 errors, 1 warnings, 0 checks, 53 lines checked
08fd704be37c drm/i915/perf: pass stream to vfuncs when possible
b8b8e91b7a92 drm/i915/perf: do not warn when OA buffer is already allocated
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#8: 
will see that OA buffer has already been allocated, while a previous process

total: 0 errors, 1 warnings, 0 checks, 18 lines checked
1744e940bee4 drm/i915/perf: add a parameter to control the size of OA buffer
-:44: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'tail' may be better as 
'(tail)' to avoid precedence issues
#44: FILE: drivers/gpu/drm/i915/i915_perf.c:215:
+#define OA_TAKEN(tail, head)   ((tail - head) & 
(dev_priv->perf.oa.oa_buffer.size - 1))

-:44: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'head' may be better as 
'(head)' to avoid precedence issues
#44: FILE: drivers/gpu/drm/i915/i915_perf.c:215:
+#define OA_TAKEN(tail, head)   ((tail - head) & 
(dev_priv->perf.oa.oa_buffer.size - 1))

-:182: ERROR:CODE_INDENT: code indent should use tabs where possible
#182: FILE: drivers/gpu/drm/i915/i915_perf.c:1507:
+BUG_ON(size < SZ_128K || size > SZ_16M);$

-:182: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#182: FILE: drivers/gpu/drm/i915/i915_perf.c:1507:
+BUG_ON(size < SZ_128K || size > SZ_16M);$

-:182: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & 
recovery code rather than BUG() or BUG_ON()
#182: FILE: drivers/gpu/drm/i915/i915_perf.c:1507:
+BUG_ON(size < SZ_128K || size > SZ_16M);

-:325: ERROR:CODE_INDENT: code indent should use tabs where possible
#325: FILE: include/uapi/drm/i915_drm.h:1543:
+/**$

-:326: ERROR:CODE_INDENT: code indent should use tabs where possible
#326: FILE: include/uapi/drm/i915_drm.h:1544:
+ * Specify a global OA buffer size to be allocated in bytes.$

-:327: ERROR:CODE_INDENT: code indent should use tabs where possible
#327: FILE: include/uapi/drm/i915_drm.h:1545:
+ * The driver will allocate a HW supported size that is at$

-:328: ERROR:CODE_INDENT: code indent should use tabs where possible
#328: FILE: include/uapi/drm/i915_drm.h:1546:
+ * least as large as specified by this property. Larger sizes$

-:329: ERROR:CODE_INDENT: code indent should use tabs where possible
#329: FILE: include/uapi/drm/i915_drm.h:1547:
+ * than what the HW supports will fail.$

-:330: ERROR:CODE_INDENT: code indent should use tabs where possible
#330: FILE: include/uapi/drm/i915_drm.h:1548:
+ */$

-:331: ERROR:CODE_INDENT: code indent should use tabs where possible
#331: FILE: include/uapi/drm/i915_drm.h:1549:
+DRM_I915_PERF_PROP_OA_BUFFER_SIZE,$

-:331: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#331: FILE: include/uapi/drm/i915_drm.h:1549:
+DRM_I915_PERF_PROP_OA_BUFFER_SIZE,$

total: 8 errors, 3 warnings, 2 checks, 280 lines checked

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


Re: [Intel-gfx] [PATCH 4/4] drm/i915/perf: add a parameter to control the size of OA buffer

2018-10-10 Thread Chris Wilson
Quoting Lionel Landwerlin (2018-10-10 17:55:33)
> @@ -1518,12 +1520,14 @@ static int alloc_oa_buffer(struct drm_i915_private 
> *dev_priv)
> goto err_unref;
>  
> /* PreHSW required 512K alignment, HSW requires 16M */
> -   vma = i915_gem_object_ggtt_pin(bo, NULL, 0, SZ_16M, 0);
> +   vma = i915_gem_object_ggtt_pin(bo, NULL, 0, size, 0);

That's not size, that's align. Presumably this doesn't change as HSW is
still going to require 16MiB?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/4] drm/i915/perf: remove redundant oa buffer initialization

2018-10-10 Thread Lionel Landwerlin
We initialize the OA buffer everytime we enable the OA unit (first call in
gen[78]_oa_enable), so we don't need to initialize when preparing the metric
set.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63ce0da4e723..eef7c811bd8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1529,23 +1529,6 @@ struct i915_oa_ops {
 */
bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
 
-   /**
-* @init_oa_buffer: Resets the head and tail pointers of the
-* circular buffer for periodic OA reports.
-*
-* Called when first opening a stream for OA metrics, but also may be
-* called in response to an OA buffer overflow or other error
-* condition.
-*
-* Note it may be necessary to clear the full OA buffer here as part of
-* maintaining the invariable that new reports must be written to
-* zeroed memory for us to be able to reliable detect if an expected
-* report has not yet landed in memory.  (At least on Haswell the OA
-* buffer tail pointer is not synchronized with reports being visible
-* to the CPU)
-*/
-   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
-
/**
 * @enable_metric_set: Selects and applies any MUX configuration to set
 * up the Boolean and Custom (B/C) counters that are part of the
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 30911efd2cf7..14f7d03aabcf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1530,8 +1530,6 @@ static int alloc_oa_buffer(struct drm_i915_private 
*dev_priv)
goto err_unpin;
}
 
-   dev_priv->perf.oa.ops.init_oa_buffer(dev_priv);
-
DRM_DEBUG_DRIVER("OA Buffer initialized, gtt offset = 0x%x, vaddr = 
%p\n",
 i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma),
 dev_priv->perf.oa.oa_buffer.vaddr);
@@ -2000,7 +1998,7 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
return -EINVAL;
}
 
-   if (!dev_priv->perf.oa.ops.init_oa_buffer) {
+   if (!dev_priv->perf.oa.ops.enable_metric_set) {
DRM_DEBUG("OA unit not supported\n");
return -ENODEV;
}
@@ -3389,7 +3387,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.is_valid_mux_reg =
hsw_is_valid_mux_addr;
dev_priv->perf.oa.ops.is_valid_flex_reg = NULL;
-   dev_priv->perf.oa.ops.init_oa_buffer = gen7_init_oa_buffer;
dev_priv->perf.oa.ops.enable_metric_set = hsw_enable_metric_set;
dev_priv->perf.oa.ops.disable_metric_set = 
hsw_disable_metric_set;
dev_priv->perf.oa.ops.oa_enable = gen7_oa_enable;
@@ -3408,7 +3405,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 */
dev_priv->perf.oa.oa_formats = gen8_plus_oa_formats;
 
-   dev_priv->perf.oa.ops.init_oa_buffer = gen8_init_oa_buffer;
dev_priv->perf.oa.ops.oa_enable = gen8_oa_enable;
dev_priv->perf.oa.ops.oa_disable = gen8_oa_disable;
dev_priv->perf.oa.ops.read = gen8_oa_read;
-- 
2.19.1

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


[Intel-gfx] [PATCH 3/4] drm/i915/perf: do not warn when OA buffer is already allocated

2018-10-10 Thread Lionel Landwerlin
If 2 processes race to open the perf stream, it's possible that one of them
will see that OA buffer has already been allocated, while a previous process
is still finishing to reprogram the hardware (on gen8+).

The opening sequence has been reworked a few times and we probably lost
track of the order in which things are supposed to happen.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_perf.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 88f3f9b6a353..a648ded97969 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1494,13 +1494,15 @@ static int alloc_oa_buffer(struct drm_i915_private 
*dev_priv)
struct i915_vma *vma;
int ret;
 
-   if (WARN_ON(dev_priv->perf.oa.oa_buffer.vma))
-   return -ENODEV;
-
ret = i915_mutex_lock_interruptible(_priv->drm);
if (ret)
return ret;
 
+   if (dev_priv->perf.oa.oa_buffer.vma) {
+   ret = -EBUSY;
+   goto unlock;
+   }
+
BUILD_BUG_ON_NOT_POWER_OF_2(OA_BUFFER_SIZE);
BUILD_BUG_ON(OA_BUFFER_SIZE < SZ_128K || OA_BUFFER_SIZE > SZ_16M);
 
-- 
2.19.1

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


[Intel-gfx] [PATCH 4/4] drm/i915/perf: add a parameter to control the size of OA buffer

2018-10-10 Thread Lionel Landwerlin
The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.

In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buffer to the minimum
size to avoid consuming memory which won't be used by the driver.

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_perf.c | 111 +++
 drivers/gpu/drm/i915/i915_reg.h  |   2 +
 include/uapi/drm/i915_drm.h  |   8 +++
 4 files changed, 95 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65eaac2d7e3c..a0069add9d39 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2053,6 +2053,8 @@ struct drm_i915_private {
u32 last_ctx_id;
int format;
int format_size;
+   u32 size;
+   int size_exponent;
 
/**
 * Locks reads and writes to all head/tail state
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a648ded97969..1eaef711160a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -212,13 +212,7 @@
 #include "i915_oa_icl.h"
 #include "intel_lrc_reg.h"
 
-/* HW requires this to be a power of two, between 128k and 16M, though driver
- * is currently generally designed assuming the largest 16M size is used such
- * that the overflow cases are unlikely in normal operation.
- */
-#define OA_BUFFER_SIZE SZ_16M
-
-#define OA_TAKEN(tail, head)   ((tail - head) & (OA_BUFFER_SIZE - 1))
+#define OA_TAKEN(tail, head)   ((tail - head) & 
(dev_priv->perf.oa.oa_buffer.size - 1))
 
 /**
  * DOC: OA Tail Pointer Race
@@ -361,6 +355,8 @@ struct perf_open_properties {
int oa_format;
bool oa_periodic;
int oa_period_exponent;
+   u32 oa_buffer_size;
+   u32 oa_buffer_size_exponent;
 };
 
 static void free_oa_config(struct drm_i915_private *dev_priv,
@@ -523,7 +519,7 @@ static bool oa_buffer_check_unlocked(struct 
drm_i915_private *dev_priv)
 * could put the tail out of bounds...
 */
if (hw_tail >= gtt_offset &&
-   hw_tail < (gtt_offset + OA_BUFFER_SIZE)) {
+   hw_tail < (gtt_offset + dev_priv->perf.oa.oa_buffer.size)) {
dev_priv->perf.oa.oa_buffer.tails[!aged_idx].offset =
aging_tail = hw_tail;
dev_priv->perf.oa.oa_buffer.aging_timestamp = now;
@@ -652,7 +648,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
u8 *oa_buf_base = dev_priv->perf.oa.oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma);
-   u32 mask = (OA_BUFFER_SIZE - 1);
+   u32 mask = (dev_priv->perf.oa.oa_buffer.size - 1);
size_t start_offset = *offset;
unsigned long flags;
unsigned int aged_tail_idx;
@@ -692,8 +688,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
 * only be incremented by multiples of the report size (notably also
 * all a power of two).
 */
-   if (WARN_ONCE(head > OA_BUFFER_SIZE || head % report_size ||
- tail > OA_BUFFER_SIZE || tail % report_size,
+   if (WARN_ONCE(head > dev_priv->perf.oa.oa_buffer.size || head % 
report_size ||
+ tail > dev_priv->perf.oa.oa_buffer.size || tail % 
report_size,
  "Inconsistent OA buffer pointers: head = %u, tail = %u\n",
  head, tail))
return -EIO;
@@ -716,7 +712,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream 
*stream,
 * here would imply a driver bug that would result
 * in an overrun.
 */
-   if (WARN_ON((OA_BUFFER_SIZE - head) < report_size)) {
+   if (WARN_ON((dev_priv->perf.oa.oa_buffer.size - head) < 
report_size)) {
DRM_ERROR("Spurious OA head ptr: non-integral report 
offset\n");
break;
}
@@ -941,7 +937,7 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
u8 *oa_buf_base = dev_priv->perf.oa.oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma);
-   u32 mask = (OA_BUFFER_SIZE - 1);
+   u32 mask = (dev_priv->perf.oa.oa_buffer.size - 1);
size_t start_offset = *offset;
unsigned long flags;
unsigned int aged_tail_idx;
@@ -978,8 +974,8 @@ static int 

[Intel-gfx] [PATCH 2/4] drm/i915/perf: pass stream to vfuncs when possible

2018-10-10 Thread Lionel Landwerlin
We want to use some of the properties of the perf stream to program
the hardware in a later commit.

v2: Pass only perf stream as argument (Matthew)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld  (v1)
---
 drivers/gpu/drm/i915/i915_drv.h  |  7 +++---
 drivers/gpu/drm/i915/i915_perf.c | 43 +++-
 2 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eef7c811bd8f..65eaac2d7e3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1535,8 +1535,7 @@ struct i915_oa_ops {
 * counter reports being sampled. May apply system constraints such as
 * disabling EU clock gating as required.
 */
-   int (*enable_metric_set)(struct drm_i915_private *dev_priv,
-const struct i915_oa_config *oa_config);
+   int (*enable_metric_set)(struct i915_perf_stream *stream);
 
/**
 * @disable_metric_set: Remove system constraints associated with using
@@ -1547,12 +1546,12 @@ struct i915_oa_ops {
/**
 * @oa_enable: Enable periodic sampling
 */
-   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct i915_perf_stream *stream);
 
/**
 * @oa_disable: Disable periodic sampling
 */
-   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct i915_perf_stream *stream);
 
/**
 * @read: Copy data from the circular OA buffer into a given userspace
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 14f7d03aabcf..88f3f9b6a353 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -890,8 +890,8 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",
  dev_priv->perf.oa.period_exponent);
 
-   dev_priv->perf.oa.ops.oa_disable(dev_priv);
-   dev_priv->perf.oa.ops.oa_enable(dev_priv);
+   dev_priv->perf.oa.ops.oa_disable(stream);
+   dev_priv->perf.oa.ops.oa_enable(stream);
 
/*
 * Note: .oa_enable() is expected to re-init the oabuffer and
@@ -1114,8 +1114,8 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",
  dev_priv->perf.oa.period_exponent);
 
-   dev_priv->perf.oa.ops.oa_disable(dev_priv);
-   dev_priv->perf.oa.ops.oa_enable(dev_priv);
+   dev_priv->perf.oa.ops.oa_disable(stream);
+   dev_priv->perf.oa.ops.oa_enable(stream);
 
oastatus1 = I915_READ(GEN7_OASTATUS1);
}
@@ -1563,9 +1563,11 @@ static void config_oa_regs(struct drm_i915_private 
*dev_priv,
}
 }
 
-static int hsw_enable_metric_set(struct drm_i915_private *dev_priv,
-const struct i915_oa_config *oa_config)
+static int hsw_enable_metric_set(struct i915_perf_stream *stream)
 {
+   struct drm_i915_private *dev_priv = stream->dev_priv;
+   const struct i915_oa_config *oa_config = stream->oa_config;
+
/* PRM:
 *
 * OA unit is using “crclk” for its functionality. When trunk
@@ -1767,9 +1769,10 @@ static int gen8_configure_all_contexts(struct 
drm_i915_private *dev_priv,
return 0;
 }
 
-static int gen8_enable_metric_set(struct drm_i915_private *dev_priv,
- const struct i915_oa_config *oa_config)
+static int gen8_enable_metric_set(struct i915_perf_stream *stream)
 {
+   struct drm_i915_private *dev_priv = stream->dev_priv;
+   const struct i915_oa_config *oa_config = stream->oa_config;
int ret;
 
/*
@@ -1837,10 +1840,10 @@ static void gen10_disable_metric_set(struct 
drm_i915_private *dev_priv)
   I915_READ(RPM_CONFIG1) & ~GEN10_GT_NOA_ENABLE);
 }
 
-static void gen7_oa_enable(struct drm_i915_private *dev_priv)
+static void gen7_oa_enable(struct i915_perf_stream *stream)
 {
-   struct i915_gem_context *ctx =
-   dev_priv->perf.oa.exclusive_stream->ctx;
+   struct drm_i915_private *dev_priv = stream->dev_priv;
+   struct i915_gem_context *ctx = stream->ctx;
u32 ctx_id = dev_priv->perf.oa.specific_ctx_id;
bool periodic = dev_priv->perf.oa.periodic;
u32 period_exponent = dev_priv->perf.oa.period_exponent;
@@ -1867,8 +1870,9 @@ static void gen7_oa_enable(struct drm_i915_private 
*dev_priv)
   GEN7_OACONTROL_ENABLE);
 }
 
-static void gen8_oa_enable(struct drm_i915_private *dev_priv)
+static void gen8_oa_enable(struct i915_perf_stream *stream)
 {
+   struct drm_i915_private *dev_priv = stream->dev_priv;
u32 report_format = dev_priv->perf.oa.oa_buffer.format;
 
  

[Intel-gfx] [PATCH 0/4] drm/i915/perf: Add OA buffer size uAPI parameter

2018-10-10 Thread Lionel Landwerlin
Hi all,

This series cleans up a couple of things (Matthew actually reviewed a
couple patches internally) and adds support for a new opening
parameter for the i915 perf stream, allowing the user to specify the
size of the global OA buffer it wants to use.

Initially I wrote a first series that was trying to guess what the
user wanted and selected the smallest buffer size, but in the end an
actual size parameter is better, giving userspace more flexibility and
removing guesses from i915.

Cheers,

Lionel Landwerlin (4):
  drm/i915/perf: remove redundant oa buffer initialization
  drm/i915/perf: pass stream to vfuncs when possible
  drm/i915/perf: do not warn when OA buffer is already allocated
  drm/i915/perf: add a parameter to control the size of OA buffer

 drivers/gpu/drm/i915/i915_drv.h  |  26 +
 drivers/gpu/drm/i915/i915_perf.c | 168 +--
 drivers/gpu/drm/i915/i915_reg.h  |   2 +
 include/uapi/drm/i915_drm.h  |   8 ++
 4 files changed, 129 insertions(+), 75 deletions(-)

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


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: rename intel_modes.c to intel_connector.c

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: rename intel_modes.c to 
intel_connector.c
URL   : https://patchwork.freedesktop.org/series/50786/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4960_full -> Patchwork_10411_full =

== Summary - WARNING ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@perf_pmu@rc6:
  shard-kbl:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_addfb_basic@bo-too-small-due-to-tiling:
  shard-snb:  NOTRUN -> DMESG-WARN (fdo#107469) +2

igt@kms_busy@extended-pageflip-hang-newfb-render-b:
  shard-glk:  NOTRUN -> DMESG-WARN (fdo#107956) +1

igt@kms_cursor_crc@cursor-64x64-dpms:
  shard-glk:  PASS -> FAIL (fdo#103232)

igt@kms_cursor_legacy@short-flip-before-cursor-toggle:
  shard-snb:  NOTRUN -> INCOMPLETE (fdo#105411)

igt@kms_fbcon_fbt@fbc-suspend:
  shard-skl:  PASS -> INCOMPLETE (fdo#104108, fdo#107773)

igt@kms_flip@plain-flip-fb-recreate:
  shard-skl:  PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
  shard-glk:  PASS -> FAIL (fdo#103167) +3

igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite:
  shard-glk:  NOTRUN -> FAIL (fdo#103167)

igt@kms_plane@plane-position-covered-pipe-c-planes:
  shard-glk:  PASS -> FAIL (fdo#103166)

igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
  shard-skl:  NOTRUN -> FAIL (fdo#103166)

igt@pm_rpm@system-suspend-devices:
  shard-skl:  PASS -> INCOMPLETE (fdo#107807) +1


 Possible fixes 

igt@kms_cursor_crc@cursor-256x256-random:
  shard-apl:  FAIL (fdo#103232) -> PASS +2

igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
  shard-glk:  DMESG-WARN (fdo#106538, fdo#105763) -> PASS +1

igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled:
  shard-skl:  FAIL (fdo#103184) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
  shard-apl:  FAIL (fdo#103167) -> PASS +1

igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-cpu:
  shard-glk:  DMESG-FAIL (fdo#106538) -> PASS

{igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max}:
  shard-glk:  FAIL (fdo#108145) -> PASS

igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
  shard-apl:  FAIL (fdo#103166) -> PASS +3
  shard-glk:  FAIL (fdo#103166) -> PASS

igt@kms_setmode@basic:
  shard-hsw:  FAIL (fdo#99912) -> PASS

igt@perf_pmu@other-init-0:
  shard-snb:  INCOMPLETE (fdo#105411) -> PASS

igt@pm_rpm@gem-execbuf-stress-extra-wait:
  shard-skl:  INCOMPLETE (fdo#107807, fdo#107803) -> PASS


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

  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184
  fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
  fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
  fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
  fdo#107469 https://bugs.freedesktop.org/show_bug.cgi?id=107469
  fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773
  fdo#107803 https://bugs.freedesktop.org/show_bug.cgi?id=107803
  fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (6 -> 6) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4960 -> Patchwork_10411

  CI_DRM_4960: 7ae91656412c0a8f7987eb6478dc03cc0486bc59 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10411: 

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Store all wm memory latency values in .1 usec units

2018-10-10 Thread Ville Syrjälä
On Wed, Oct 10, 2018 at 02:12:30PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-10-10 14:04:43)
> > From: Ville Syrjälä 
> > 
> > In order to simplify the code let's store all memory latency values in
> > 0.1 usec units. This limits the platform specific units to the initial
> > setup code for the most part.
> 
> Asking for a friend: is it 0.1us or 128ns?

100ns

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up the wm mem latency stuff

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Clean up the wm mem latency stuff
URL   : https://patchwork.freedesktop.org/series/50802/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4963 -> Patchwork_10414 =

== Summary - FAILURE ==

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

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50802/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@drv_selftest@live_hugepages:
  fi-glk-dsi: PASS -> DMESG-WARN +18

igt@drv_selftest@live_sanitycheck:
  fi-glk-j4005:   PASS -> DMESG-WARN +18


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
  fi-kbl-8809g:   PASS -> DMESG-WARN (fdo#107762)


 Possible fixes 

igt@amdgpu/amd_cs_nop@fork-gfx0:
  fi-kbl-8809g:   DMESG-WARN (fdo#107762) -> PASS

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   DMESG-WARN (fdo#105128, fdo#107139) -> PASS


  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107762 https://bugs.freedesktop.org/show_bug.cgi?id=107762


== Participating hosts (47 -> 42) ==

  Additional (1): fi-gdg-551 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u2 
fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4963 -> Patchwork_10414

  CI_DRM_4963: bc57a8e99f2f81581a9657a02682902f80488bb3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10414: 9ca6798844ad2db6a72afaf6ac3f6d4c9f36357b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9ca6798844ad drm/i915: Remove the remnants of the ilk+ LP0 wm hack
cc9ff8c60c9f drm/i915: Allow LP3 watermarks on ILK
4d7823f8cfea drm/i915: Drop the funky ilk wm setup
2e6e43af1f55 drm/i915: Sanitize wm latency values for ilk+
aaa6aab9e9f2 drm/i915: Split skl+ and ilk+ read_wm_latency()
3e81eb4b15b0 drm/i915: Eliminate redundant ilk sprite/cursor wm fixup code
f3ddc18d8e10 drm/i915: Make the WM memory latency print more compact
56e36d0fdf5f drm/i915: Add DEFINE_SNPRINTF_ARRAY()
835ecb45c0fd drm/i915: Add dev_priv->wm.num_levels and use it everywhere
720e1b59c0b9 drm/i915: Eliminate skl_latency[]
77e42913e7cf drm/i915: Use the spr/cur latencies on vlv/chv/g4x
3acd8b6f70a5 drm/i915: Store all wm memory latency values in .1 usec units

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up the wm mem latency stuff

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Clean up the wm mem latency stuff
URL   : https://patchwork.freedesktop.org/series/50802/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Store all wm memory latency values in .1 usec units
-O:drivers/gpu/drm/i915/intel_pm.c:1636:16: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:1656:16: warning: expression using sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2511:16: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2511:16: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2535:16: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2535:16: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2528:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2528:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2550:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2550:16: warning: expression using sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2984:17: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2984:17: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2986:29: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2986:29: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2986:17: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2986:17: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2992:29: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2992:29: warning: expression using sizeof(void)
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3725:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3713:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Use the spr/cur latencies on vlv/chv/g4x
Okay!

Commit: drm/i915: Eliminate skl_latency[]
Okay!

Commit: drm/i915: Add dev_priv->wm.num_levels and use it everywhere
-O:drivers/gpu/drm/i915/intel_pm.c:1224:17: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:1219:17: warning: expression using sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:3004:29: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:3004:29: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2988:29: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2988:29: warning: expression using sizeof(void)

Commit: drm/i915: Add DEFINE_SNPRINTF_ARRAY()
Okay!

Commit: drm/i915: Make the WM memory latency print more compact
Okay!

Commit: drm/i915: Eliminate redundant ilk sprite/cursor wm fixup code
Okay!

Commit: drm/i915: Split skl+ and ilk+ read_wm_latency()
Okay!

Commit: drm/i915: Sanitize wm latency values for ilk+
-O:drivers/gpu/drm/i915/intel_pm.c:2892:29: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2892:29: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2925:29: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:2925:29: warning: expression using sizeof(void)

Commit: drm/i915: Drop the funky ilk wm setup
Okay!

Commit: drm/i915: Allow LP3 watermarks on ILK
Okay!

Commit: drm/i915: Remove the remnants of the ilk+ LP0 wm hack
-O:drivers/gpu/drm/i915/intel_pm.c:2777:35: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2777:35: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2778:35: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2778:35: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2779:35: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_pm.c:2779:35: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:6616:35: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:6616:35: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:6616:35: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:6616:35: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:6616:35: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_pm.c:6616:35: warning: expression using sizeof(void)

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Clean up the wm mem latency stuff

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Clean up the wm mem latency stuff
URL   : https://patchwork.freedesktop.org/series/50802/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3acd8b6f70a5 drm/i915: Store all wm memory latency values in .1 usec units
77e42913e7cf drm/i915: Use the spr/cur latencies on vlv/chv/g4x
720e1b59c0b9 drm/i915: Eliminate skl_latency[]
835ecb45c0fd drm/i915: Add dev_priv->wm.num_levels and use it everywhere
56e36d0fdf5f drm/i915: Add DEFINE_SNPRINTF_ARRAY()
-:23: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'values' may be better as 
'(values)' to avoid precedence issues
#23: FILE: drivers/gpu/drm/i915/i915_utils.h:164:
+#define DEFINE_SNPRINTF_ARRAY(name, type, values, index, fmt, ...) \
+void name(char *_str, size_t _len, const type *values, int _nelems) \
+{ \
+   int index; \
+   if (_len) \
+   _str[0] = '\0'; \
+   for (index = 0; index < _nelems; index++) { \
+   int _r = snprintf(_str, _len, "%s" fmt, \
+ index ? ", " : "", __VA_ARGS__); \
+   if (_r >= _len) \
+   return; \
+   _str += _r; \
+   _len -= _r; \
+   } \
+}

-:23: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'index' - possible 
side-effects?
#23: FILE: drivers/gpu/drm/i915/i915_utils.h:164:
+#define DEFINE_SNPRINTF_ARRAY(name, type, values, index, fmt, ...) \
+void name(char *_str, size_t _len, const type *values, int _nelems) \
+{ \
+   int index; \
+   if (_len) \
+   _str[0] = '\0'; \
+   for (index = 0; index < _nelems; index++) { \
+   int _r = snprintf(_str, _len, "%s" fmt, \
+ index ? ", " : "", __VA_ARGS__); \
+   if (_r >= _len) \
+   return; \
+   _str += _r; \
+   _len -= _r; \
+   } \
+}

-:23: WARNING:MACRO_WITH_FLOW_CONTROL: Macros with flow control statements 
should be avoided
#23: FILE: drivers/gpu/drm/i915/i915_utils.h:164:
+#define DEFINE_SNPRINTF_ARRAY(name, type, values, index, fmt, ...) \
+void name(char *_str, size_t _len, const type *values, int _nelems) \
+{ \
+   int index; \
+   if (_len) \
+   _str[0] = '\0'; \
+   for (index = 0; index < _nelems; index++) { \
+   int _r = snprintf(_str, _len, "%s" fmt, \
+ index ? ", " : "", __VA_ARGS__); \
+   if (_r >= _len) \
+   return; \
+   _str += _r; \
+   _len -= _r; \
+   } \
+}

-:24: CHECK:SPACING: spaces preferred around that '*' (ctx:WxV)
#24: FILE: drivers/gpu/drm/i915/i915_utils.h:165:
+void name(char *_str, size_t _len, const type *values, int _nelems) \
   ^

total: 0 errors, 1 warnings, 3 checks, 43 lines checked
f3ddc18d8e10 drm/i915: Make the WM memory latency print more compact
3e81eb4b15b0 drm/i915: Eliminate redundant ilk sprite/cursor wm fixup code
aaa6aab9e9f2 drm/i915: Split skl+ and ilk+ read_wm_latency()
2e6e43af1f55 drm/i915: Sanitize wm latency values for ilk+
4d7823f8cfea drm/i915: Drop the funky ilk wm setup
cc9ff8c60c9f drm/i915: Allow LP3 watermarks on ILK
9ca6798844ad drm/i915: Remove the remnants of the ilk+ LP0 wm hack

___
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/selftests: Check for hangs mid context execution tests

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Check for hangs mid context execution tests
URL   : https://patchwork.freedesktop.org/series/50801/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4961 -> Patchwork_10413 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50801/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
  fi-ilk-650: PASS -> DMESG-WARN (fdo#106387) +1


 Possible fixes 

igt@gem_exec_suspend@basic-s3:
  fi-cfl-8109u:   DMESG-WARN (fdo#107345) -> PASS +1

igt@kms_chamelium@dp-crc-fast:
  fi-kbl-7500u:   FAIL (fdo#103841) -> PASS +2

igt@kms_chamelium@dp-hpd-fast:
  fi-skl-6700k2:  FAIL (fdo#103841) -> SKIP +4

igt@kms_chamelium@hdmi-crc-fast:
  fi-skl-6700k2:  FAIL (fdo#103841) -> PASS +3

igt@kms_chamelium@vga-hpd-fast:
  fi-kbl-7500u:   FAIL (fdo#103841) -> SKIP +4

igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
  fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS


 Warnings 

igt@kms_chamelium@common-hpd-after-suspend:
  fi-kbl-7500u:   FAIL (fdo#103841) -> DMESG-WARN (fdo#102505, 
fdo#105079, fdo#105602)


  fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#105079 https://bugs.freedesktop.org/show_bug.cgi?id=105079
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#106387 https://bugs.freedesktop.org/show_bug.cgi?id=106387
  fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362


== Participating hosts (48 -> 41) ==

  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan 
fi-ctg-p8600 fi-pnv-d510 


== Build changes ==

* Linux: CI_DRM_4961 -> Patchwork_10413

  CI_DRM_4961: 1b9d983587107509e70d14509fcd304b19ae0ce0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10413: 2f79f218c3ba344e17eb939a94f45b144070967d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2f79f218c3ba drm/i915/selftests: Check for hangs mid context execution tests

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10413/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 drm/i915: Inject a failure point when registering a connector (rev2)

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Inject a failure point when registering a connector (rev2)
URL   : https://patchwork.freedesktop.org/series/50797/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4961 -> Patchwork_10412 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50797/revisions/2/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-skl-6700k2:  PASS -> FAIL (fdo#107362, fdo#103191)
  fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191)


 Possible fixes 

igt@gem_exec_suspend@basic-s3:
  fi-cfl-8109u:   DMESG-WARN (fdo#107345) -> PASS +1

igt@kms_chamelium@dp-crc-fast:
  fi-kbl-7500u:   FAIL (fdo#103841) -> PASS +2

igt@kms_chamelium@dp-hpd-fast:
  fi-skl-6700k2:  FAIL (fdo#103841) -> SKIP +4

igt@kms_chamelium@hdmi-crc-fast:
  fi-skl-6700k2:  FAIL (fdo#103841) -> PASS +3

igt@kms_chamelium@vga-hpd-fast:
  fi-kbl-7500u:   FAIL (fdo#103841) -> SKIP +4

igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
  fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS


 Warnings 

igt@kms_chamelium@common-hpd-after-suspend:
  fi-kbl-7500u:   FAIL (fdo#103841) -> DMESG-WARN (fdo#105602, 
fdo#102505, fdo#105079)


  fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#105079 https://bugs.freedesktop.org/show_bug.cgi?id=105079
  fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
  fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362


== Participating hosts (48 -> 42) ==

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u2 
fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4961 -> Patchwork_10412

  CI_DRM_4961: 1b9d983587107509e70d14509fcd304b19ae0ce0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10412: 6e0622acd13f120be3364bbdefbf85934672b40f @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6e0622acd13f drm/i915: Inject a failure point when registering a connector

== Logs ==

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


Re: [Intel-gfx] [PATCH 01/12] drm/i915: Store all wm memory latency values in .1 usec units

2018-10-10 Thread Chris Wilson
Quoting Ville Syrjala (2018-10-10 14:04:43)
> From: Ville Syrjälä 
> 
> In order to simplify the code let's store all memory latency values in
> 0.1 usec units. This limits the platform specific units to the initial
> setup code for the most part.

Asking for a friend: is it 0.1us or 128ns?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 07/12] drm/i915: Eliminate redundant ilk sprite/cursor wm fixup code

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

The functions to fix up the sprite and cursor watermarks on ilk are
identical. Unify them to one, and give it an ilk_ prefix to make it
clear where it should be used.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9fe5a390caa9..067dc1ac4521 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2942,18 +2942,10 @@ static void intel_read_wm_latency(struct 
drm_i915_private *dev_priv,
}
 }
 
-static void intel_fixup_spr_wm_latency(struct drm_i915_private *dev_priv,
-  uint16_t wm[5])
+static void ilk_fixup_spr_cur_wm_latency(struct drm_i915_private *dev_priv,
+u16 wm[5])
 {
-   /* ILK sprite LP0 latency is 1300 ns */
-   if (IS_GEN5(dev_priv))
-   wm[0] = 13;
-}
-
-static void intel_fixup_cur_wm_latency(struct drm_i915_private *dev_priv,
-  uint16_t wm[5])
-{
-   /* ILK cursor LP0 latency is 1300 ns */
+   /* ILK sprite/cursor LP0 latency is 1300 ns */
if (IS_GEN5(dev_priv))
wm[0] = 13;
 }
@@ -3026,8 +3018,8 @@ static void ilk_setup_wm_latency(struct drm_i915_private 
*dev_priv)
memcpy(dev_priv->wm.cur_latency, dev_priv->wm.pri_latency,
   sizeof(dev_priv->wm.pri_latency));
 
-   intel_fixup_spr_wm_latency(dev_priv, dev_priv->wm.spr_latency);
-   intel_fixup_cur_wm_latency(dev_priv, dev_priv->wm.cur_latency);
+   ilk_fixup_spr_cur_wm_latency(dev_priv, dev_priv->wm.spr_latency);
+   ilk_fixup_spr_cur_wm_latency(dev_priv, dev_priv->wm.cur_latency);
 
intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
-- 
2.18.1

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


[Intel-gfx] [PATCH 10/12] drm/i915: Drop the funky ilk wm setup

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

Currently we try to disable the wm code entirely for ilk if the BIOS
doesn't provide proper latency values. Now that we have real fallbacks
in place we should be able to alawys rely on the wm code instead.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eb324a784f8f..3493da7f102b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5590,8 +5590,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
 */
intel_color_load_luts(_config->base);
 
-   if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(old_intel_state, 
pipe_config);
+   dev_priv->display.initial_watermarks(old_intel_state, pipe_config);
intel_enable_pipe(pipe_config);
 
if (pipe_config->has_pch_encoder)
@@ -5738,8 +5737,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_transcoder_func(pipe_config);
 
-   if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(old_intel_state, 
pipe_config);
+   dev_priv->display.initial_watermarks(old_intel_state, pipe_config);
 
if (INTEL_GEN(dev_priv) >= 11)
icl_pipe_mbus_enable(intel_crtc);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 62334e413220..7bd29bba81c1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9389,22 +9389,10 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
dev_priv->display.compute_global_watermarks = skl_compute_wm;
} else if (HAS_PCH_SPLIT(dev_priv)) {
ilk_setup_wm_latency(dev_priv);
-
-   if ((IS_GEN5(dev_priv) && dev_priv->wm.pri_latency[1] &&
-dev_priv->wm.spr_latency[1] && 
dev_priv->wm.cur_latency[1]) ||
-   (!IS_GEN5(dev_priv) && dev_priv->wm.pri_latency[0] &&
-dev_priv->wm.spr_latency[0] && 
dev_priv->wm.cur_latency[0])) {
-   dev_priv->display.compute_pipe_wm = ilk_compute_pipe_wm;
-   dev_priv->display.compute_intermediate_wm =
-   ilk_compute_intermediate_wm;
-   dev_priv->display.initial_watermarks =
-   ilk_initial_watermarks;
-   dev_priv->display.optimize_watermarks =
-   ilk_optimize_watermarks;
-   } else {
-   DRM_DEBUG_KMS("Failed to read display plane latency. "
- "Disable CxSR\n");
-   }
+   dev_priv->display.compute_pipe_wm = ilk_compute_pipe_wm;
+   dev_priv->display.compute_intermediate_wm = 
ilk_compute_intermediate_wm;
+   dev_priv->display.initial_watermarks = ilk_initial_watermarks;
+   dev_priv->display.optimize_watermarks = ilk_optimize_watermarks;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
vlv_setup_wm_latency(dev_priv);
dev_priv->display.compute_pipe_wm = vlv_compute_pipe_wm;
-- 
2.18.1

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


[Intel-gfx] [PATCH 00/12] drm/i915: Clean up the wm mem latency stuff

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

Currently we store the watermark memory latency values in three
different units (.1 usec, .5 usec, and 1 usec). Let's make things
less confusing by picking .1 usec as the one true unit and unify
all platforms around that. And I've included some other cleanups
related to this latency stuff.

Ville Syrjälä (12):
  drm/i915: Store all wm memory latency values in .1 usec units
  drm/i915: Use the spr/cur latencies on vlv/chv/g4x
  drm/i915: Eliminate skl_latency[]
  drm/i915: Add dev_priv->wm.num_levels and use it everywhere
  drm/i915: Add DEFINE_SNPRINTF_ARRAY()
  drm/i915: Make the WM memory latency print more compact
  drm/i915: Eliminate redundant ilk sprite/cursor wm fixup code
  drm/i915: Split skl+ and ilk+ read_wm_latency()
  drm/i915: Sanitize wm latency values for ilk+
  drm/i915: Drop the funky ilk wm setup
  drm/i915: Allow LP3 watermarks on ILK
  drm/i915: Remove the remnants of the ilk+ LP0 wm hack

 drivers/gpu/drm/i915/i915_debugfs.c  |  82 +---
 drivers/gpu/drm/i915/i915_drv.h  |  26 +-
 drivers/gpu/drm/i915/i915_utils.h|  16 +
 drivers/gpu/drm/i915/intel_display.c |  12 +-
 drivers/gpu/drm/i915/intel_dp.c  |  17 +-
 drivers/gpu/drm/i915/intel_pm.c  | 587 ++-
 6 files changed, 349 insertions(+), 391 deletions(-)

-- 
2.18.1

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


[Intel-gfx] [PATCH 11/12] drm/i915: Allow LP3 watermarks on ILK

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

ILK already has the watermark registers for the LP3 level so
bump num_levels to 4. The BIOS still does not provide memory
latency values for for LP3 though so it will not be used
unless the latency values are overridden via debugfs.

This also requires that we check for latency==0 zero when
computing the watermarks so that we keep disabling any wm
level which isn't supposed to be used. The behaviour now matches
that of the g4x/vlv wm code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7bd29bba81c1..dd5edd984fb5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2537,6 +2537,9 @@ static uint32_t ilk_compute_pri_wm(const struct 
intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
 
+   if (latency == 0)
+   return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
 
@@ -2564,6 +2567,9 @@ static uint32_t ilk_compute_spr_wm(const struct 
intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
 
+   if (latency == 0)
+   return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
 
@@ -2585,6 +2591,9 @@ static uint32_t ilk_compute_cur_wm(const struct 
intel_crtc_state *cstate,
int latency = intel_plane_wm_latency(plane, level);
int cpp;
 
+   if (latency == 0)
+   return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
 
@@ -2953,10 +2962,8 @@ static void ilk_setup_wm_latency(struct drm_i915_private 
*dev_priv)
 {
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
dev_priv->wm.num_levels = 5;
-   else if (INTEL_GEN(dev_priv) >= 6)
-   dev_priv->wm.num_levels = 4;
else
-   dev_priv->wm.num_levels = 3;
+   dev_priv->wm.num_levels = 4;
 
ilk_read_wm_latency(dev_priv, dev_priv->wm.pri_latency);
ilk_fixup_wm_latency_units(dev_priv, dev_priv->wm.pri_latency);
-- 
2.18.1

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


[Intel-gfx] [PATCH 12/12] drm/i915: Remove the remnants of the ilk+ LP0 wm hack

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

In the past we couldn't properly reject the operation if the level 0
watermarks exceeded the limits, thus we had a hack to clamp the values.
commit 86c8bbbeb8d1 ("drm/i915: Calculate ILK-style watermarks during
atomic check (v3)") changed the behaviour to fail the operation
instead, but neglected to remove all the code for the hack.
Remove the leftovers.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 28 +---
 1 file changed, 1 insertion(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dd5edd984fb5..0dce22fcda2d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2746,8 +2746,6 @@ static bool ilk_validate_wm_level(int level,
  const struct ilk_wm_maximums *max,
  struct intel_wm_level *result)
 {
-   bool ret;
-
/* already determined to be invalid? */
if (!result->enable)
return false;
@@ -2756,31 +2754,7 @@ static bool ilk_validate_wm_level(int level,
 result->spr_val <= max->spr &&
 result->cur_val <= max->cur;
 
-   ret = result->enable;
-
-   /*
-* HACK until we can pre-compute everything,
-* and thus fail gracefully if LP0 watermarks
-* are exceeded...
-*/
-   if (level == 0 && !result->enable) {
-   if (result->pri_val > max->pri)
-   DRM_DEBUG_KMS("Primary WM%d too large %u (max %u)\n",
- level, result->pri_val, max->pri);
-   if (result->spr_val > max->spr)
-   DRM_DEBUG_KMS("Sprite WM%d too large %u (max %u)\n",
- level, result->spr_val, max->spr);
-   if (result->cur_val > max->cur)
-   DRM_DEBUG_KMS("Cursor WM%d too large %u (max %u)\n",
- level, result->cur_val, max->cur);
-
-   result->pri_val = min_t(uint32_t, result->pri_val, max->pri);
-   result->spr_val = min_t(uint32_t, result->spr_val, max->spr);
-   result->cur_val = min_t(uint32_t, result->cur_val, max->cur);
-   result->enable = true;
-   }
-
-   return ret;
+   return result->enable;
 }
 
 static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv,
-- 
2.18.1

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


[Intel-gfx] [PATCH 01/12] drm/i915: Store all wm memory latency values in .1 usec units

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

In order to simplify the code let's store all memory latency values in
0.1 usec units. This limits the platform specific units to the initial
setup code for the most part.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  12 ---
 drivers/gpu/drm/i915/i915_drv.h |  14 +--
 drivers/gpu/drm/i915/intel_pm.c | 149 
 3 files changed, 87 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 00c551d3e409..9e0cb995801f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3807,18 +3807,6 @@ static void wm_latency_show(struct seq_file *m, const 
uint16_t wm[8])
for (level = 0; level < num_levels; level++) {
unsigned int latency = wm[level];
 
-   /*
-* - WM1+ latency values in 0.5us units
-* - latencies are in us on gen9/vlv/chv
-*/
-   if (INTEL_GEN(dev_priv) >= 9 ||
-   IS_VALLEYVIEW(dev_priv) ||
-   IS_CHERRYVIEW(dev_priv) ||
-   IS_G4X(dev_priv))
-   latency *= 10;
-   else if (level > 0)
-   latency *= 5;
-
seq_printf(m, "WM%d %u (%u.%u usec)\n",
   level, wm[level], latency / 10, latency % 10);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 794a8a03c7e6..e57b8cb8fa4d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1906,22 +1906,10 @@ struct drm_i915_private {
} sagv_status;
 
struct {
-   /*
-* Raw watermark latency values:
-* in 0.1us units for WM0,
-* in 0.5us units for WM1+.
-*/
-   /* primary */
+   /* Watermark memory latency values in 0.1 us units */
uint16_t pri_latency[5];
-   /* sprite */
uint16_t spr_latency[5];
-   /* cursor */
uint16_t cur_latency[5];
-   /*
-* Raw watermark memory latency values
-* for SKL for all 8 levels
-* in 1us units.
-*/
uint16_t skl_latency[8];
 
/* current hardware state */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1392aa56a55a..f871a6f152c3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -801,6 +801,27 @@ static int intel_wm_num_levels(struct drm_i915_private 
*dev_priv)
return dev_priv->wm.max_level + 1;
 }
 
+static int intel_plane_wm_latency(struct intel_plane *plane,
+ int level)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   return dev_priv->wm.skl_latency[level];
+
+   if (HAS_GMCH_DISPLAY(dev_priv))
+   return dev_priv->wm.pri_latency[level];
+
+   switch (plane->id) {
+   case PLANE_PRIMARY:
+   return dev_priv->wm.pri_latency[level];
+   case PLANE_CURSOR:
+   return dev_priv->wm.cur_latency[level];
+   default:
+   return dev_priv->wm.spr_latency[level];
+   }
+}
+
 static bool intel_wm_plane_visible(const struct intel_crtc_state *crtc_state,
   const struct intel_plane_state *plane_state)
 {
@@ -1039,10 +1060,10 @@ static void vlv_write_wm_values(struct drm_i915_private 
*dev_priv,
 
 static void g4x_setup_wm_latency(struct drm_i915_private *dev_priv)
 {
-   /* all latencies in usec */
-   dev_priv->wm.pri_latency[G4X_WM_LEVEL_NORMAL] = 5;
-   dev_priv->wm.pri_latency[G4X_WM_LEVEL_SR] = 12;
-   dev_priv->wm.pri_latency[G4X_WM_LEVEL_HPLL] = 35;
+   /* all latencies in .1 usec */
+   dev_priv->wm.pri_latency[G4X_WM_LEVEL_NORMAL] = 50;
+   dev_priv->wm.pri_latency[G4X_WM_LEVEL_SR] = 120;
+   dev_priv->wm.pri_latency[G4X_WM_LEVEL_HPLL] = 350;
 
dev_priv->wm.max_level = G4X_WM_LEVEL_HPLL;
 }
@@ -1097,7 +1118,7 @@ static uint16_t g4x_compute_wm(const struct 
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_display_mode *adjusted_mode =
_state->base.adjusted_mode;
-   unsigned int latency = dev_priv->wm.pri_latency[level] * 10;
+   int latency = intel_plane_wm_latency(plane, level);
unsigned int clock, htotal, cpp, width, wm;
 
if (latency == 0)
@@ -1586,14 +1607,14 @@ static unsigned int vlv_wm_method2(unsigned int 
pixel_rate,
 
 static void vlv_setup_wm_latency(struct drm_i915_private *dev_priv)
 {
-   /* all latencies in usec */
-   dev_priv->wm.pri_latency[VLV_WM_LEVEL_PM2] = 3;
+   /* all 

[Intel-gfx] [PATCH 02/12] drm/i915: Use the spr/cur latencies on vlv/chv/g4x

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

Reduce the differences between the platforms by using the spr/cur
watermark latency values on gmch platforms as well. We'll also
print the wm latencies the same way as we do for ilk+.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 +-
 drivers/gpu/drm/i915/intel_pm.c | 63 ++---
 2 files changed, 41 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9e0cb995801f..35b4c49c9bca 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3873,7 +3873,7 @@ static int spr_wm_latency_open(struct inode *inode, 
struct file *file)
 {
struct drm_i915_private *dev_priv = inode->i_private;
 
-   if (HAS_GMCH_DISPLAY(dev_priv))
+   if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv))
return -ENODEV;
 
return single_open(file, spr_wm_latency_show, dev_priv);
@@ -3883,7 +3883,7 @@ static int cur_wm_latency_open(struct inode *inode, 
struct file *file)
 {
struct drm_i915_private *dev_priv = inode->i_private;
 
-   if (HAS_GMCH_DISPLAY(dev_priv))
+   if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv))
return -ENODEV;
 
return single_open(file, cur_wm_latency_show, dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f871a6f152c3..fe522ceae97a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -801,6 +801,27 @@ static int intel_wm_num_levels(struct drm_i915_private 
*dev_priv)
return dev_priv->wm.max_level + 1;
 }
 
+static void intel_print_wm_latency(struct drm_i915_private *dev_priv,
+  const char *name,
+  const uint16_t wm[8])
+{
+   int level, max_level = ilk_wm_max_level(dev_priv);
+
+   for (level = 0; level <= max_level; level++) {
+   unsigned int latency = wm[level];
+
+   if (latency == 0) {
+   DRM_DEBUG_KMS("%s WM%d latency not provided\n",
+ name, level);
+   continue;
+   }
+
+   DRM_DEBUG_KMS("%s WM%d latency %u (%u.%u usec)\n",
+ name, level, wm[level],
+ latency / 10, latency % 10);
+   }
+}
+
 static int intel_plane_wm_latency(struct intel_plane *plane,
  int level)
 {
@@ -809,9 +830,6 @@ static int intel_plane_wm_latency(struct intel_plane *plane,
if (INTEL_GEN(dev_priv) >= 9)
return dev_priv->wm.skl_latency[level];
 
-   if (HAS_GMCH_DISPLAY(dev_priv))
-   return dev_priv->wm.pri_latency[level];
-
switch (plane->id) {
case PLANE_PRIMARY:
return dev_priv->wm.pri_latency[level];
@@ -1066,6 +1084,15 @@ static void g4x_setup_wm_latency(struct drm_i915_private 
*dev_priv)
dev_priv->wm.pri_latency[G4X_WM_LEVEL_HPLL] = 350;
 
dev_priv->wm.max_level = G4X_WM_LEVEL_HPLL;
+
+   memcpy(dev_priv->wm.spr_latency, dev_priv->wm.pri_latency,
+  sizeof(dev_priv->wm.pri_latency));
+   memcpy(dev_priv->wm.cur_latency, dev_priv->wm.pri_latency,
+  sizeof(dev_priv->wm.pri_latency));
+
+   intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
+   intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
+   intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
 }
 
 static int g4x_plane_fifo_size(enum plane_id plane_id, int level)
@@ -1618,6 +1645,15 @@ static void vlv_setup_wm_latency(struct drm_i915_private 
*dev_priv)
 
dev_priv->wm.max_level = VLV_WM_LEVEL_DDR_DVFS;
}
+
+   memcpy(dev_priv->wm.spr_latency, dev_priv->wm.pri_latency,
+  sizeof(dev_priv->wm.pri_latency));
+   memcpy(dev_priv->wm.cur_latency, dev_priv->wm.pri_latency,
+  sizeof(dev_priv->wm.pri_latency));
+
+   intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
+   intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
+   intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
 }
 
 static uint16_t vlv_compute_wm_level(const struct intel_crtc_state *crtc_state,
@@ -2954,27 +2990,6 @@ int ilk_wm_max_level(const struct drm_i915_private 
*dev_priv)
return 2;
 }
 
-static void intel_print_wm_latency(struct drm_i915_private *dev_priv,
-  const char *name,
-  const uint16_t wm[8])
-{
-   int level, max_level = ilk_wm_max_level(dev_priv);
-
-   for (level = 0; level <= max_level; level++) {
-   unsigned int latency = wm[level];
-
-   if (latency == 0) {
-   DRM_DEBUG_KMS("%s WM%d latency not provided\n",
-   

[Intel-gfx] [PATCH 04/12] drm/i915: Add dev_priv->wm.num_levels and use it everywhere

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

Unify our approach to figuring out how many wm levels are supported by
having dev_priv->wm.num_levels. This replaces the older
dev_priv->wm.max_level which was used on some of the platforms. I think
num_levels is less confusing than max_level in most places. The +/-1 is
now mostly isolated to the mempry latency init code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  24 +
 drivers/gpu/drm/i915/i915_drv.h  |   4 +-
 drivers/gpu/drm/i915/intel_display.c |   6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 132 +--
 4 files changed, 70 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4b668f28ec0..461edef71fc2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3790,17 +3790,7 @@ static void wm_latency_show(struct seq_file *m, const 
uint16_t wm[8])
 {
struct drm_i915_private *dev_priv = m->private;
struct drm_device *dev = _priv->drm;
-   int level;
-   int num_levels;
-
-   if (IS_CHERRYVIEW(dev_priv))
-   num_levels = 3;
-   else if (IS_VALLEYVIEW(dev_priv))
-   num_levels = 1;
-   else if (IS_G4X(dev_priv))
-   num_levels = 3;
-   else
-   num_levels = ilk_wm_max_level(dev_priv) + 1;
+   int level, num_levels = dev_priv->wm.num_levels;
 
drm_modeset_lock_all(dev);
 
@@ -3881,20 +3871,10 @@ static ssize_t wm_latency_write(struct file *file, 
const char __user *ubuf,
struct drm_i915_private *dev_priv = m->private;
struct drm_device *dev = _priv->drm;
uint16_t new[8] = { 0 };
-   int num_levels;
-   int level;
+   int level, num_levels = dev_priv->wm.num_levels;
int ret;
char tmp[32];
 
-   if (IS_CHERRYVIEW(dev_priv))
-   num_levels = 3;
-   else if (IS_VALLEYVIEW(dev_priv))
-   num_levels = 1;
-   else if (IS_G4X(dev_priv))
-   num_levels = 3;
-   else
-   num_levels = ilk_wm_max_level(dev_priv) + 1;
-
if (len >= sizeof(tmp))
return -EINVAL;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4dc8826f24b2..3db45ddab925 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1920,8 +1920,6 @@ struct drm_i915_private {
struct g4x_wm_values g4x;
};
 
-   uint8_t max_level;
-
/*
 * Should be held around atomic WM register writing; also
 * protects * intel_crtc->wm.active and
@@ -1929,6 +1927,8 @@ struct drm_i915_private {
 */
struct mutex wm_mutex;
 
+   u8 num_levels;
+
/*
 * Set during HW readout of watermarks/DDB.  Some platforms
 * need to know when we're still using BIOS-provided values
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a145efba9157..eb324a784f8f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11737,7 +11737,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
const enum pipe pipe = intel_crtc->pipe;
-   int plane, level, max_level = ilk_wm_max_level(dev_priv);
+   int plane, level, num_levels = dev_priv->wm.num_levels;
 
if (INTEL_GEN(dev_priv) < 9 || !new_state->active)
return;
@@ -11759,7 +11759,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
sw_plane_wm = _wm->planes[plane];
 
/* Watermarks */
-   for (level = 0; level <= max_level; level++) {
+   for (level = 0; level < num_levels; level++) {
if (skl_wm_level_equals(_plane_wm->wm[level],
_plane_wm->wm[level]))
continue;
@@ -11809,7 +11809,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
sw_plane_wm = _wm->planes[PLANE_CURSOR];
 
/* Watermarks */
-   for (level = 0; level <= max_level; level++) {
+   for (level = 0; level < num_levels; level++) {
if (skl_wm_level_equals(_plane_wm->wm[level],
_plane_wm->wm[level]))
continue;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4bb640acf291..c03d4835d0e0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -796,23 +796,18 @@ static bool is_enabling(int old, int new, int threshold)
return old < threshold && new >= threshold;
 }
 
-static int 

[Intel-gfx] [PATCH 08/12] drm/i915: Split skl+ and ilk+ read_wm_latency()

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

There's no point it having the skl+ and ilk+ codepaths for reading
the wm latency values in the same function. Split them apart.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 197 +---
 1 file changed, 104 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 067dc1ac4521..8289c6378db3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2825,95 +2825,10 @@ hsw_compute_linetime_wm(const struct intel_crtc_state 
*cstate)
   PIPE_WM_LINETIME_TIME(linetime);
 }
 
-static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
- uint16_t wm[8])
+static void ilk_read_wm_latency(struct drm_i915_private *dev_priv,
+   u16 wm[5])
 {
-   if (INTEL_GEN(dev_priv) >= 9) {
-   uint32_t val;
-   int ret, i;
-   int level, num_levels = dev_priv->wm.num_levels;
-
-   /* read the first set of memory latencies[0:3] */
-   val = 0; /* data0 to be programmed to 0 for first set */
-   mutex_lock(_priv->pcu_lock);
-   ret = sandybridge_pcode_read(dev_priv,
-GEN9_PCODE_READ_MEM_LATENCY,
-);
-   mutex_unlock(_priv->pcu_lock);
-
-   if (ret) {
-   DRM_ERROR("SKL Mailbox read error = %d\n", ret);
-   return;
-   }
-
-   wm[0] = val & GEN9_MEM_LATENCY_LEVEL_MASK;
-   wm[1] = (val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) &
-   GEN9_MEM_LATENCY_LEVEL_MASK;
-   wm[2] = (val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) &
-   GEN9_MEM_LATENCY_LEVEL_MASK;
-   wm[3] = (val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
-   GEN9_MEM_LATENCY_LEVEL_MASK;
-
-   /* read the second set of memory latencies[4:7] */
-   val = 1; /* data0 to be programmed to 1 for second set */
-   mutex_lock(_priv->pcu_lock);
-   ret = sandybridge_pcode_read(dev_priv,
-GEN9_PCODE_READ_MEM_LATENCY,
-);
-   mutex_unlock(_priv->pcu_lock);
-   if (ret) {
-   DRM_ERROR("SKL Mailbox read error = %d\n", ret);
-   return;
-   }
-
-   wm[4] = val & GEN9_MEM_LATENCY_LEVEL_MASK;
-   wm[5] = (val >> GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT) &
-   GEN9_MEM_LATENCY_LEVEL_MASK;
-   wm[6] = (val >> GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT) &
-   GEN9_MEM_LATENCY_LEVEL_MASK;
-   wm[7] = (val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
-   GEN9_MEM_LATENCY_LEVEL_MASK;
-
-   /*
-* If a level n (n > 1) has a 0us latency, all levels m (m >= n)
-* need to be disabled. We make sure to sanitize the values out
-* of the punit to satisfy this requirement.
-*/
-   for (level = 1; level < num_levels; level++) {
-   if (wm[level] == 0) {
-   for (i = level + 1; i < num_levels; i++)
-   wm[i] = 0;
-   break;
-   }
-   }
-
-   /*
-* WaWmMemoryReadLatency:skl+,glk
-*
-* punit doesn't take into account the read latency so we need
-* to add 2us to the various latency levels we retrieve from the
-* punit when level 0 response data us 0us.
-*/
-   if (wm[0] == 0) {
-   wm[0] += 2;
-   for (level = 1; level < num_levels; level++) {
-   if (wm[level] == 0)
-   break;
-   wm[level] += 2;
-   }
-   }
-
-   /*
-* WA Level-0 adjustment for 16GB DIMMs: SKL+
-* If we could not get dimm info enable this WA to prevent from
-* any underrun. If not able to get Dimm info assume 16GB dimm
-* to avoid any underrun.
-*/
-   if (!dev_priv->dram_info.valid_dimm ||
-   dev_priv->dram_info.is_16gb_dimm)
-   wm[0] += 1;
-
-   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
uint64_t sskpd = I915_READ64(MCH_SSKPD);
 
wm[0] = (sskpd >> 56) & 0xFF;
@@ 

[Intel-gfx] [PATCH 05/12] drm/i915: Add DEFINE_SNPRINTF_ARRAY()

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

Templatize snprintf_int_array() to allow us to print
different kinds of arrays without having to type all
the boilerplate for the snprintf() loop.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_utils.h | 16 
 drivers/gpu/drm/i915/intel_dp.c   | 17 ++---
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h 
b/drivers/gpu/drm/i915/i915_utils.h
index 5858a43e19da..079aefa20bee 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -161,4 +161,20 @@ static inline const char *enableddisabled(bool v)
return v ? "enabled" : "disabled";
 }
 
+#define DEFINE_SNPRINTF_ARRAY(name, type, values, index, fmt, ...) \
+void name(char *_str, size_t _len, const type *values, int _nelems) \
+{ \
+   int index; \
+   if (_len) \
+   _str[0] = '\0'; \
+   for (index = 0; index < _nelems; index++) { \
+   int _r = snprintf(_str, _len, "%s" fmt, \
+ index ? ", " : "", __VA_ARGS__); \
+   if (_r >= _len) \
+   return; \
+   _str += _r; \
+   _len -= _r; \
+   } \
+}
+
 #endif /* !__I915_UTILS_H */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 13ff89be6ad6..dd8634b40179 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1774,21 +1774,8 @@ intel_dp_set_clock(struct intel_encoder *encoder,
}
 }
 
-static void snprintf_int_array(char *str, size_t len,
-  const int *array, int nelem)
-{
-   int i;
-
-   str[0] = '\0';
-
-   for (i = 0; i < nelem; i++) {
-   int r = snprintf(str, len, "%s%d", i ? ", " : "", array[i]);
-   if (r >= len)
-   return;
-   str += r;
-   len -= r;
-   }
-}
+static DEFINE_SNPRINTF_ARRAY(snprintf_int_array,
+int, array, i, "%d", array[i]);
 
 static void intel_dp_print_rates(struct intel_dp *intel_dp)
 {
-- 
2.18.1

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


[Intel-gfx] [PATCH 03/12] drm/i915: Eliminate skl_latency[]

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

Make SKL+ less special by eliminating the separate skl_latency[]
array and just using the normal pri/spr/cur latency arrays. The
result is 4 bytes larger (3*5+8 vs. 3*8)

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 42 +
 drivers/gpu/drm/i915/i915_drv.h |  8 +++---
 drivers/gpu/drm/i915/intel_pm.c | 16 ++-
 3 files changed, 20 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 35b4c49c9bca..e4b668f28ec0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3817,12 +3817,7 @@ static void wm_latency_show(struct seq_file *m, const 
uint16_t wm[8])
 static int pri_wm_latency_show(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = m->private;
-   const uint16_t *latencies;
-
-   if (INTEL_GEN(dev_priv) >= 9)
-   latencies = dev_priv->wm.skl_latency;
-   else
-   latencies = dev_priv->wm.pri_latency;
+   const u16 *latencies = dev_priv->wm.pri_latency;
 
wm_latency_show(m, latencies);
 
@@ -3832,12 +3827,7 @@ static int pri_wm_latency_show(struct seq_file *m, void 
*data)
 static int spr_wm_latency_show(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = m->private;
-   const uint16_t *latencies;
-
-   if (INTEL_GEN(dev_priv) >= 9)
-   latencies = dev_priv->wm.skl_latency;
-   else
-   latencies = dev_priv->wm.spr_latency;
+   const u16 *latencies = dev_priv->wm.spr_latency;
 
wm_latency_show(m, latencies);
 
@@ -3847,12 +3837,7 @@ static int spr_wm_latency_show(struct seq_file *m, void 
*data)
 static int cur_wm_latency_show(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = m->private;
-   const uint16_t *latencies;
-
-   if (INTEL_GEN(dev_priv) >= 9)
-   latencies = dev_priv->wm.skl_latency;
-   else
-   latencies = dev_priv->wm.cur_latency;
+   const u16 *latencies = dev_priv->wm.cur_latency;
 
wm_latency_show(m, latencies);
 
@@ -3940,12 +3925,7 @@ static ssize_t pri_wm_latency_write(struct file *file, 
const char __user *ubuf,
 {
struct seq_file *m = file->private_data;
struct drm_i915_private *dev_priv = m->private;
-   uint16_t *latencies;
-
-   if (INTEL_GEN(dev_priv) >= 9)
-   latencies = dev_priv->wm.skl_latency;
-   else
-   latencies = dev_priv->wm.pri_latency;
+   u16 *latencies = dev_priv->wm.pri_latency;
 
return wm_latency_write(file, ubuf, len, offp, latencies);
 }
@@ -3955,12 +3935,7 @@ static ssize_t spr_wm_latency_write(struct file *file, 
const char __user *ubuf,
 {
struct seq_file *m = file->private_data;
struct drm_i915_private *dev_priv = m->private;
-   uint16_t *latencies;
-
-   if (INTEL_GEN(dev_priv) >= 9)
-   latencies = dev_priv->wm.skl_latency;
-   else
-   latencies = dev_priv->wm.spr_latency;
+   u16 *latencies = dev_priv->wm.spr_latency;
 
return wm_latency_write(file, ubuf, len, offp, latencies);
 }
@@ -3970,12 +3945,7 @@ static ssize_t cur_wm_latency_write(struct file *file, 
const char __user *ubuf,
 {
struct seq_file *m = file->private_data;
struct drm_i915_private *dev_priv = m->private;
-   uint16_t *latencies;
-
-   if (INTEL_GEN(dev_priv) >= 9)
-   latencies = dev_priv->wm.skl_latency;
-   else
-   latencies = dev_priv->wm.cur_latency;
+   u16 *latencies = dev_priv->wm.cur_latency;
 
return wm_latency_write(file, ubuf, len, offp, latencies);
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e57b8cb8fa4d..4dc8826f24b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1907,10 +1907,10 @@ struct drm_i915_private {
 
struct {
/* Watermark memory latency values in 0.1 us units */
-   uint16_t pri_latency[5];
-   uint16_t spr_latency[5];
-   uint16_t cur_latency[5];
-   uint16_t skl_latency[8];
+   /* Watermark memory latency values in .1 us units */
+   u16 pri_latency[8];
+   u16 spr_latency[8];
+   u16 cur_latency[8];
 
/* current hardware state */
union {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fe522ceae97a..4bb640acf291 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -827,9 +827,6 @@ static int intel_plane_wm_latency(struct intel_plane *plane,
 {
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
 
-   if (INTEL_GEN(dev_priv) >= 9)
-   return dev_priv->wm.skl_latency[level];
-
switch (plane->id) {

[Intel-gfx] [PATCH 06/12] drm/i915: Make the WM memory latency print more compact

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

Print all the latency values on a single line.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c03d4835d0e0..9fe5a390caa9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -796,25 +796,22 @@ static bool is_enabling(int old, int new, int threshold)
return old < threshold && new >= threshold;
 }
 
+static DEFINE_SNPRINTF_ARRAY(snprintf_wm_array,
+u16, wm, level, "%d.%d",
+wm[level] / 10, wm[level] % 10);
+
 static void intel_print_wm_latency(struct drm_i915_private *dev_priv,
   const char *name,
   const uint16_t wm[8])
 {
-   int level, num_levels = dev_priv->wm.num_levels;
+   char str[64];
 
-   for (level = 0; level < num_levels; level++) {
-   unsigned int latency = wm[level];
+   if ((drm_debug & DRM_UT_KMS) == 0)
+   return;
 
-   if (latency == 0) {
-   DRM_ERROR("%s WM%d latency not provided\n",
- name, level);
-   continue;
-   }
+   snprintf_wm_array(str, sizeof(str), wm, dev_priv->wm.num_levels);
 
-   DRM_DEBUG_KMS("%s WM%d latency %u (%u.%u usec)\n",
- name, level, wm[level],
- latency / 10, latency % 10);
-   }
+   DRM_DEBUG_KMS("%s: %s (usec)", name, str);
 }
 
 static int intel_plane_wm_latency(struct intel_plane *plane,
-- 
2.18.1

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


[Intel-gfx] [PATCH 09/12] drm/i915: Sanitize wm latency values for ilk+

2018-10-10 Thread Ville Syrjala
From: Ville Syrjälä 

For skl+ we disable all wm levels with a decreasing memory latency
value. Let's generalize the same code to work for all platoforms,
and let's use it for ilk-bdw as well since those platforms also
read the latency values from a scratch register.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 58 -
 1 file changed, 42 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8289c6378db3..62334e413220 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2825,6 +2825,37 @@ hsw_compute_linetime_wm(const struct intel_crtc_state 
*cstate)
   PIPE_WM_LINETIME_TIME(linetime);
 }
 
+static void intel_sanitize_wm_latency(struct drm_i915_private *dev_priv,
+ u16 *wm)
+{
+   int level, num_levels = dev_priv->wm.num_levels;
+
+   /*
+* If we don't have WM0 latency, assume
+* 5 usec and disable all WM1+ levels.
+* 5 usec seems like a safe(ish) fallback value.
+*/
+   if (WARN(wm[0] == 0, "WM0 memory latency value is zero")) {
+   wm[0] = 50;
+
+   for (level = 1; level < num_levels; level++)
+   wm[level] = 0;
+   return;
+   }
+
+   /* Make sure the latencies are non-decreasing */
+   for (level = 1; level < num_levels; level++) {
+   if (wm[level] < wm[level - 1]) {
+   WARN(wm[level] != 0,
+"Decreasing WM memory latency value(s)");
+
+   for (; level < num_levels; level++)
+   wm[level] = 0;
+   break;
+   }
+   }
+}
+
 static void ilk_read_wm_latency(struct drm_i915_private *dev_priv,
u16 wm[5])
 {
@@ -2888,8 +2919,11 @@ static bool ilk_increase_wm_latency(struct 
drm_i915_private *dev_priv,
/* WM1+ latencies must be multiples of .5 usec */
min = roundup(min, 5);
 
-   for (level = 1; level < num_levels; level++)
+   for (level = 1; level < num_levels; level++) {
+   if (wm[level] == 0)
+   break;
wm[level] = max(wm[level], min);
+   }
 
return true;
 }
@@ -2935,6 +2969,10 @@ static void ilk_setup_wm_latency(struct drm_i915_private 
*dev_priv)
ilk_fixup_spr_cur_wm_latency(dev_priv, dev_priv->wm.spr_latency);
ilk_fixup_spr_cur_wm_latency(dev_priv, dev_priv->wm.cur_latency);
 
+   intel_sanitize_wm_latency(dev_priv, dev_priv->wm.pri_latency);
+   intel_sanitize_wm_latency(dev_priv, dev_priv->wm.spr_latency);
+   intel_sanitize_wm_latency(dev_priv, dev_priv->wm.cur_latency);
+
intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
@@ -2946,8 +2984,7 @@ static void ilk_setup_wm_latency(struct drm_i915_private 
*dev_priv)
 static void skl_read_wm_latency(struct drm_i915_private *dev_priv,
u16 wm[8])
 {
-   int level, num_levels = dev_priv->wm.num_levels;
-   int ret, i;
+   int ret;
u32 val;
 
/* read the first set of memory latencies[0:3] */
@@ -2990,19 +3027,6 @@ static void skl_read_wm_latency(struct drm_i915_private 
*dev_priv,
GEN9_MEM_LATENCY_LEVEL_MASK;
wm[7] = (val >> GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT) &
GEN9_MEM_LATENCY_LEVEL_MASK;
-
-   /*
-* If a level n (n > 1) has a 0us latency, all levels m (m >= n)
-* need to be disabled. We make sure to sanitize the values out
-* of the punit to satisfy this requirement.
-*/
-   for (level = 1; level < num_levels; level++) {
-   if (wm[level] == 0) {
-   for (i = level + 1; i < num_levels; i++)
-   wm[i] = 0;
-   break;
-   }
-   }
 }
 
 static void skl_fixup_wm_latency_units(struct drm_i915_private *dev_priv,
@@ -3058,6 +3082,8 @@ static void skl_setup_wm_latency(struct drm_i915_private 
*dev_priv)
 
skl_wm_latency_wa(dev_priv, dev_priv->wm.pri_latency);
 
+   intel_sanitize_wm_latency(dev_priv, dev_priv->wm.pri_latency);
+
memcpy(dev_priv->wm.spr_latency, dev_priv->wm.pri_latency,
   sizeof(dev_priv->wm.pri_latency));
memcpy(dev_priv->wm.cur_latency, dev_priv->wm.pri_latency,
-- 
2.18.1

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


[Intel-gfx] [PATCH] drm/i915/selftests: Check for hangs mid context execution tests

2018-10-10 Thread Chris Wilson
Use the live_test struct to record the reset count before and compare it
at the end of the test to assert that no mystery hang occurred during the
test.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/selftests/i915_gem_context.c | 22 ++-
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 913c0f83f86a..ea165a644d79 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -531,10 +531,11 @@ static int igt_ctx_exec(void *arg)
 {
struct drm_i915_private *i915 = arg;
struct drm_i915_gem_object *obj = NULL;
+   unsigned long ncontexts, ndwords, dw;
struct drm_file *file;
IGT_TIMEOUT(end_time);
LIST_HEAD(objects);
-   unsigned long ncontexts, ndwords, dw;
+   struct live_test t;
int err = -ENODEV;
 
/*
@@ -552,6 +553,10 @@ static int igt_ctx_exec(void *arg)
 
mutex_lock(>drm.struct_mutex);
 
+   err = begin_live_test(, i915, __func__, "");
+   if (err)
+   goto out_unlock;
+
ncontexts = 0;
ndwords = 0;
dw = 0;
@@ -616,7 +621,7 @@ static int igt_ctx_exec(void *arg)
}
 
 out_unlock:
-   if (igt_flush_test(i915, I915_WAIT_LOCKED))
+   if (end_live_test())
err = -EIO;
mutex_unlock(>drm.struct_mutex);
 
@@ -628,13 +633,14 @@ static int igt_ctx_readonly(void *arg)
 {
struct drm_i915_private *i915 = arg;
struct drm_i915_gem_object *obj = NULL;
+   struct i915_gem_context *ctx;
+   struct i915_hw_ppgtt *ppgtt;
+   unsigned long ndwords, dw;
struct drm_file *file;
I915_RND_STATE(prng);
IGT_TIMEOUT(end_time);
LIST_HEAD(objects);
-   struct i915_gem_context *ctx;
-   struct i915_hw_ppgtt *ppgtt;
-   unsigned long ndwords, dw;
+   struct live_test t;
int err = -ENODEV;
 
/*
@@ -649,6 +655,10 @@ static int igt_ctx_readonly(void *arg)
 
mutex_lock(>drm.struct_mutex);
 
+   err = begin_live_test(, i915, __func__, "");
+   if (err)
+   goto out_unlock;
+
ctx = i915_gem_create_context(i915, file->driver_priv);
if (IS_ERR(ctx)) {
err = PTR_ERR(ctx);
@@ -721,7 +731,7 @@ static int igt_ctx_readonly(void *arg)
}
 
 out_unlock:
-   if (igt_flush_test(i915, I915_WAIT_LOCKED))
+   if (end_live_test())
err = -EIO;
mutex_unlock(>drm.struct_mutex);
 
-- 
2.19.1

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: rename intel_modes.c to intel_connector.c

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: rename intel_modes.c to 
intel_connector.c
URL   : https://patchwork.freedesktop.org/series/50786/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4960 -> Patchwork_10411 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50786/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s4-devices:
  fi-kbl-7500u:   PASS -> DMESG-WARN (fdo#107139, fdo#105128)

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-peppy:   PASS -> DMESG-WARN (fdo#102614)
  fi-byt-clapper: PASS -> FAIL (fdo#103167)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS


  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362


== Participating hosts (46 -> 42) ==

  Additional (1): fi-pnv-d510 
  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-icl-u2 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4960 -> Patchwork_10411

  CI_DRM_4960: 7ae91656412c0a8f7987eb6478dc03cc0486bc59 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10411: 1ebeea3775dc55052bae9f0745abad140dc96191 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1ebeea3775dc drm/i915: move intel connector specific functions to 
intel_connector.c
e0eec3a3fbb6 drm/i915: rename intel_modes.c to intel_connector.c

== Logs ==

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


[Intel-gfx] [CI] drm/i915: Inject a failure point when registering a connector

2018-10-10 Thread Chris Wilson
Check we can handle a late display load failure where the final act of
registering the connector fails.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Acked-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_connector.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index d56f50a6f5a0..598d5cb9b657 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -107,8 +107,15 @@ int intel_connector_register(struct drm_connector 
*connector)
if (ret)
goto err;
 
+   if (i915_inject_load_failure()) {
+   ret = -EFAULT;
+   goto err_backlight;
+   }
+
return 0;
 
+err_backlight:
+   intel_backlight_device_unregister(intel_connector);
 err:
return ret;
 }
-- 
2.19.1

___
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: Inject a failure point when registering a connector

2018-10-10 Thread Patchwork
== Series Details ==

Series: drm/i915: Inject a failure point when registering a connector
URL   : https://patchwork.freedesktop.org/series/50797/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4960 -> Patchwork_10410 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/50797/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_frontbuffer_tracking@basic:
  fi-byt-clapper: PASS -> FAIL (fdo#103167)

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
  fi-byt-clapper: PASS -> FAIL (fdo#107362)


 Possible fixes 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS


  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362


== Participating hosts (46 -> 42) ==

  Additional (1): fi-pnv-d510 
  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-icl-u2 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4960 -> Patchwork_10410

  CI_DRM_4960: 7ae91656412c0a8f7987eb6478dc03cc0486bc59 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10410: 99ac75c0b2af76357a37ed691e22de5e40f3da9c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

99ac75c0b2af drm/i915: Inject a failure point when registering a connector

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915: rename intel_modes.c to intel_connector.c

2018-10-10 Thread Jani Nikula
On Wed, 10 Oct 2018, Ville Syrjälä  wrote:
> On Wed, Oct 10, 2018 at 10:52:04AM +0300, Jani Nikula wrote:
>> The common denominator here seems to be connector more than
>> modes. Prepare for moving more connector functions to the same place. No
>> functional changes.
>> 
>> Signed-off-by: Jani Nikula 
>
> Series is
> Reviewed-by: Ville Syrjälä 

Thanks, pushed to dinq.

BR,
Jani.


>
>> ---
>>  drivers/gpu/drm/i915/Makefile  |  2 +-
>>  .../gpu/drm/i915/{intel_modes.c => intel_connector.c}  |  0
>>  drivers/gpu/drm/i915/intel_drv.h   | 18 
>> --
>>  3 files changed, 9 insertions(+), 11 deletions(-)
>>  rename drivers/gpu/drm/i915/{intel_modes.c => intel_connector.c} (100%)
>> 
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index ef1480c14e4e..48cae0eae3f9 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -113,6 +113,7 @@ i915-y += intel_audio.o \
>>intel_bios.o \
>>intel_cdclk.o \
>>intel_color.o \
>> +  intel_connector.o \
>>intel_display.o \
>>intel_dpio_phy.o \
>>intel_dpll_mgr.o \
>> @@ -121,7 +122,6 @@ i915-y += intel_audio.o \
>>intel_frontbuffer.o \
>>intel_hdcp.o \
>>intel_hotplug.o \
>> -  intel_modes.o \
>>intel_overlay.o \
>>intel_psr.o \
>>intel_sideband.o \
>> diff --git a/drivers/gpu/drm/i915/intel_modes.c 
>> b/drivers/gpu/drm/i915/intel_connector.c
>> similarity index 100%
>> rename from drivers/gpu/drm/i915/intel_modes.c
>> rename to drivers/gpu/drm/i915/intel_connector.c
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 4b8fec74ad49..bc373f82c0d2 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1668,6 +1668,14 @@ unsigned int i9xx_plane_max_stride(struct intel_plane 
>> *plane,
>> u32 pixel_format, u64 modifier,
>> unsigned int rotation);
>>  
>> +/* intel_connector.c */
>> +int intel_connector_update_modes(struct drm_connector *connector,
>> + struct edid *edid);
>> +int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter 
>> *adapter);
>> +void intel_attach_force_audio_property(struct drm_connector *connector);
>> +void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
>> +void intel_attach_aspect_ratio_property(struct drm_connector *connector);
>> +
>>  /* intel_csr.c */
>>  void intel_csr_ucode_init(struct drm_i915_private *);
>>  void intel_csr_load_program(struct drm_i915_private *);
>> @@ -1864,16 +1872,6 @@ void intel_lvds_init(struct drm_i915_private 
>> *dev_priv);
>>  struct intel_encoder *intel_get_lvds_encoder(struct drm_device *dev);
>>  bool intel_is_dual_link_lvds(struct drm_device *dev);
>>  
>> -
>> -/* intel_modes.c */
>> -int intel_connector_update_modes(struct drm_connector *connector,
>> - struct edid *edid);
>> -int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter 
>> *adapter);
>> -void intel_attach_force_audio_property(struct drm_connector *connector);
>> -void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
>> -void intel_attach_aspect_ratio_property(struct drm_connector *connector);
>> -
>> -
>>  /* intel_overlay.c */
>>  void intel_setup_overlay(struct drm_i915_private *dev_priv);
>>  void intel_cleanup_overlay(struct drm_i915_private *dev_priv);
>> -- 
>> 2.11.0
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH] drm/i915: Inject a failure point when registering a connector

2018-10-10 Thread Chris Wilson
Quoting Jani Nikula (2018-10-10 13:10:51)
> On Wed, 10 Oct 2018, Chris Wilson  wrote:
> > Check we can handle a late display load failure where the final act of
> > registering the connector fails.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Cc: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> 
> Acked-by: Jani Nikula 
> 
> Though this'll need to be rebased as soon as I get CI results and merge
> [1].

Yup, and that's being optimistic the error paths are foolproof :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Inject a failure point when registering a connector

2018-10-10 Thread Jani Nikula
On Wed, 10 Oct 2018, Chris Wilson  wrote:
> Check we can handle a late display load failure where the final act of
> registering the connector fails.
>
> Signed-off-by: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 

Acked-by: Jani Nikula 

Though this'll need to be rebased as soon as I get CI results and merge
[1].

BR,
Jani.



[1] 
http://patchwork.freedesktop.org/patch/msgid/20181010075205.7713-2-jani.nik...@intel.com


> ---
>  drivers/gpu/drm/i915/intel_display.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index fd27b9b0b4d8..c24314da741b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15867,8 +15867,15 @@ int intel_connector_register(struct drm_connector 
> *connector)
>   if (ret)
>   goto err;
>  
> + if (i915_inject_load_failure()) {
> + ret = -EFAULT;
> + goto err_backlight;
> + }
> +
>   return 0;
>  
> +err_backlight:
> + intel_backlight_device_unregister(intel_connector);
>  err:
>   return ret;
>  }

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


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: rename intel_modes.c to intel_connector.c

2018-10-10 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: rename intel_modes.c to 
intel_connector.c
URL   : https://patchwork.freedesktop.org/series/50786/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4958_full -> Patchwork_10409_full =

== Summary - WARNING ==

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

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS
  shard-snb:  SKIP -> PASS +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_suspend@shrink:
  shard-skl:  PASS -> INCOMPLETE (fdo#106886)

igt@gem_eio@in-flight-internal-10ms:
  shard-glk:  PASS -> FAIL (fdo#107799)

igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
  shard-hsw:  NOTRUN -> DMESG-WARN (fdo#107956)

igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
  shard-skl:  NOTRUN -> FAIL (fdo#105458)

igt@kms_cursor_crc@cursor-128x128-sliding:
  shard-apl:  PASS -> FAIL (fdo#103232) +1

igt@kms_cursor_crc@cursor-128x128-suspend:
  shard-skl:  PASS -> INCOMPLETE (fdo#104108) +1
  shard-apl:  PASS -> INCOMPLETE (fdo#103927)

igt@kms_cursor_crc@cursor-256x256-sliding:
  shard-glk:  PASS -> FAIL (fdo#103232)

igt@kms_cursor_crc@cursor-64x64-random:
  shard-skl:  NOTRUN -> FAIL (fdo#103232)

igt@kms_cursor_crc@cursor-64x64-suspend:
  shard-apl:  PASS -> FAIL (fdo#103232, fdo#103191)

igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
  shard-glk:  PASS -> DMESG-WARN (fdo#106538, fdo#105763) +1

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@plain-flip-ts-check-interruptible:
  shard-skl:  PASS -> FAIL (fdo#100368)

igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render:
  shard-skl:  PASS -> FAIL (fdo#103167)

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
  shard-glk:  PASS -> FAIL (fdo#103167) +3

igt@kms_frontbuffer_tracking@fbc-stridechange:
  shard-skl:  NOTRUN -> FAIL (fdo#105683)

igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-render:
  shard-skl:  PASS -> FAIL (fdo#105682)

igt@kms_plane@pixel-format-pipe-c-planes:
  shard-skl:  NOTRUN -> DMESG-FAIL (fdo#106885, fdo#103166)

{igt@kms_plane_alpha_blend@pipe-c-alpha-7efc}:
  shard-skl:  NOTRUN -> FAIL (fdo#108146)

{igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb}:
  shard-skl:  NOTRUN -> FAIL (fdo#108145) +2

igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
  shard-apl:  PASS -> FAIL (fdo#103166) +2

igt@kms_psr@suspend:
  shard-skl:  PASS -> INCOMPLETE (fdo#107773)

igt@kms_rotation_crc@exhaust-fences:
  shard-skl:  NOTRUN -> DMESG-WARN (fdo#105748)

igt@kms_setmode@basic:
  shard-kbl:  PASS -> FAIL (fdo#99912)

igt@perf_pmu@rc6-runtime-pm-long:
  shard-skl:  PASS -> FAIL (fdo#105010)


 Possible fixes 

igt@kms_cursor_crc@cursor-128x42-onscreen:
  shard-apl:  FAIL (fdo#103232) -> PASS

igt@kms_cursor_crc@cursor-128x42-random:
  shard-hsw:  INCOMPLETE (fdo#103540) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt:
  shard-apl:  INCOMPLETE (fdo#103927) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
  shard-apl:  FAIL (fdo#103167) -> PASS

igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
  shard-glk:  FAIL (fdo#103167) -> PASS +1

igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
  shard-apl:  FAIL (fdo#103166) -> PASS +1

igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
  shard-glk:  FAIL (fdo#103166) -> PASS +1


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

  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  

  1   2   >