[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Pass intel_context to i915_request_create() (rev2)

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915: Pass intel_context to i915_request_create() (rev2)
URL   : https://patchwork.freedesktop.org/series/58380/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5793_full -> Patchwork_12568_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-clear:
- shard-snb:  PASS -> INCOMPLETE [fdo#105411]

  * igt@gem_exec_parallel@bsd1:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +117

  * igt@gem_mocs_settings@mocs-settings-bsd1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +4

  * igt@gem_pwrite@huge-gtt-fbr:
- shard-iclb: NOTRUN -> SKIP [fdo#109290]

  * igt@gem_softpin@evict-snoop-interruptible:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +19

  * igt@gem_stolen@stolen-copy:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- shard-skl:  PASS -> INCOMPLETE [fdo#107807] +1

  * igt@i915_pm_rpm@pc8-residency:
- shard-iclb: NOTRUN -> SKIP [fdo#109293]

  * igt@kms_available_modes_crc@available_mode_test_crc:
- shard-skl:  NOTRUN -> FAIL [fdo#106641]

  * igt@kms_busy@basic-modeset-f:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +1

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-d:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +11

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_chamelium@dp-edid-change-during-suspend:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +3

  * igt@kms_cursor_crc@cursor-512x512-onscreen:
- shard-iclb: NOTRUN -> SKIP [fdo#109279]

  * igt@kms_cursor_legacy@cursorb-vs-flipb-atomic-transitions-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +2

  * igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-untiled:
- shard-skl:  PASS -> FAIL [fdo#108472]

  * igt@kms_draw_crc@draw-method-xrgb-mmap-wc-ytiled:
- shard-skl:  PASS -> FAIL [fdo#103184] +1

  * igt@kms_force_connector_basic@prune-stale-modes:
- shard-iclb: NOTRUN -> SKIP [fdo#109285]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +8

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +4

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108]

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-gtt:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247]

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-gtt:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +18

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> FAIL [fdo#109247] +3

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-iclb: PASS -> FAIL [fdo#109247] +19

  * igt@kms_frontbuffer_tracking@psr-2p-pri-indfb-multidraw:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +67

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-apl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +1

  * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
- shard-apl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-glk:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  NOTRUN -> FAIL [fdo#107815]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-transparant-fb:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@cursor_mmap_gtt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +4

  * igt@kms_psr@psr2_no_drrs:
- shard-iclb: PASS -> SKIP [fdo#109441] +1

  * igt@kms_psr@psr2_primary_mmap_gtt:
- shard-iclb: NOTRUN -> 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/icl: Assign genlock CRTC pointer in all slave CRTC states for tiled displays

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/icl: Assign genlock CRTC pointer in 
all slave CRTC states for tiled displays
URL   : https://patchwork.freedesktop.org/series/58393/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5792_full -> Patchwork_12567_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@preempt-other-chain-blt:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +35

  * igt@gem_pread@stolen-uncached:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +62

  * igt@gem_wait@write-wait-bsd1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +7

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-iclb: NOTRUN -> FAIL [fdo#107847]

  * igt@i915_pm_rpm@i2c:
- shard-iclb: PASS -> DMESG-WARN [fdo#109982]

  * igt@i915_pm_rps@reset:
- shard-iclb: NOTRUN -> FAIL [fdo#108059] +1

  * igt@kms_atomic_transition@3x-modeset-transitions-fencing:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-apl:  PASS -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-newfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-e:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-glk:  PASS -> DMESG-WARN [fdo#110222]

  * igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +7

  * igt@kms_dp_dsc@basic-dsc-enable-dp:
- shard-iclb: NOTRUN -> SKIP [fdo#109349]

  * igt@kms_force_connector_basic@force-edid:
- shard-iclb: NOTRUN -> SKIP [fdo#109285]

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-render:
- shard-iclb: PASS -> FAIL [fdo#103167] +1

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#108040]

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#109247] +22

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +16

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247]

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-blt:
- shard-iclb: NOTRUN -> FAIL [fdo#109247] +1

  * igt@kms_pipe_b_c_ivb@from-pipe-c-to-b-with-3-lanes:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-apl:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-skl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_scaling@pipe-c-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_psr@psr2_dpms:
- shard-iclb: PASS -> SKIP [fdo#109441] +2

  * igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]

  * igt@kms_psr@sprite_render:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +1

  * igt@kms_setmode@basic:
- shard-kbl:  PASS -> FAIL [fdo#99912]

  * igt@kms_universal_plane@disable-primary-vs-flip-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4

  * igt@perf_pmu@semaphore-wait-vcs1:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +60

  * igt@prime_nv_pcopy@test1_micro:
- shard-iclb: NOTRUN -> SKIP [fdo#109291] +1

  * igt@prime_vgem@fence-read-hang:
- shard-iclb: NOTRUN -> SKIP [fdo#109295]

  * igt@v3d_get_bo_offset@get-bad-handle:
- shard-iclb: NOTRUN -> SKIP [fdo#109315]

  
 Possible fixes 

  * igt@gem_busy@close-race:
- shard-apl:  FAIL -> PASS

  * igt@gem_create@create-clear:
- shard-snb:  INCOMPLETE [fdo#105411] 

[Intel-gfx] ✗ Fi.CI.BAT: failure for GEN8+ GPU Watchdog Reset Support

2019-03-22 Thread Patchwork
== Series Details ==

Series: GEN8+ GPU Watchdog Reset Support
URL   : https://patchwork.freedesktop.org/series/58443/
State : failure

== Summary ==

Applying: drm/i915: Add engine reset count in get-reset-stats ioctl
Applying: drm/i915: Watchdog timeout: IRQ handler for gen8+
Applying: drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
Applying: drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/i915_gem_context.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0004 drm/i915: Watchdog timeout: DRM kernel interface to set 
the timeout
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

___
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: Disable C3 when enabling vblank interrupts on i945gm

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 09:08:35PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-03-22 18:08:03)
> > From: Ville Syrjälä 
> > 
> > The AGPBUSY thing doesn't work on i945gm anymore. This means
> > the gmch is incapable of waking the CPU from C3 when an interrupt
> > is generated. The interrupts just get postponed indefinitely until
> > something wakes up the CPU. This is rather annoying for vblank
> > interrupts as we are unable to maintain a steady framerate
> > unless the machine is sufficiently loaded to stay out of C3.
> > 
> > To combat this let's use pm_qos to prevent C3 whenever vblank
> > interrupts are enabled. To maintain reasonable amount of powersaving
> > we will attempt to limit this to C3 only while leaving C1 and C2
> > enabled.
> 
> Interesting compromise. Frankly, I had considered pm_qos in an
> all-or-nothing approach, partly because finding the C transitions is a
> bit opaque.
>  
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30364
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  8 +++
> >  drivers/gpu/drm/i915/i915_irq.c | 88 +
> >  2 files changed, 96 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index f723b15527f8..0c736f8ca1b2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2042,6 +2042,14 @@ struct drm_i915_private {
> > struct i915_vma *scratch;
> > } gt;
> >  
> > +   /* For i945gm vblank irq vs. C3 workaround */
> > +   struct {
> > +   struct work_struct work;
> > +   struct pm_qos_request pm_qos;
> > +   u8 c3_disable_latency;
> 
> Ok, looks a bit tight, but checks out.
> 
> > +   u8 enabled;
> > +   } i945gm_vblank;
> > +
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 2f788291cfe0..33386f0acab3 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -30,6 +30,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -3131,6 +3132,16 @@ static int i8xx_enable_vblank(struct drm_device 
> > *dev, unsigned int pipe)
> > return 0;
> >  }
> >  
> > +static int i945gm_enable_vblank(struct drm_device *dev, unsigned int pipe)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(dev);
> > +
> > +   if (dev_priv->i945gm_vblank.enabled++ == 0)
> > +   schedule_work(_priv->i945gm_vblank.work);
> 
> I was thinking u8, isn't that a bit dangerous. But the max counter here
> should be num_pipes. Hmm, is the vblank spinlock local to a pipe? Nope,
> dev->vbl_lock.
> 
> > +
> > +   return i8xx_enable_vblank(dev, pipe);
> > +}
> > +
> >  static int i965_enable_vblank(struct drm_device *dev, unsigned int pipe)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > @@ -3195,6 +3206,16 @@ static void i8xx_disable_vblank(struct drm_device 
> > *dev, unsigned int pipe)
> > spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> >  }
> >  
> > +static void i945gm_disable_vblank(struct drm_device *dev, unsigned int 
> > pipe)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(dev);
> > +
> > +   i8xx_disable_vblank(dev, pipe);
> > +
> > +   if (--dev_priv->i945gm_vblank.enabled == 0)
> > +   schedule_work(_priv->i945gm_vblank.work);
> > +}
> > +
> >  static void i965_disable_vblank(struct drm_device *dev, unsigned int pipe)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > @@ -3228,6 +3249,60 @@ static void gen8_disable_vblank(struct drm_device 
> > *dev, unsigned int pipe)
> > spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> >  }
> >  
> > +static void i945gm_vblank_work_func(struct work_struct *work)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   container_of(work, struct drm_i915_private, 
> > i945gm_vblank.work);
> > +
> > +   /*
> > +* Vblank interrupts fail to wake up the device from C3,
> > +* hence we want to prevent C3 usage while vblank interrupts
> > +* are enabled.
> > +*/
> > +   pm_qos_update_request(_priv->i945gm_vblank.pm_qos,
> > + dev_priv->i945gm_vblank.enabled ?
> > + dev_priv->i945gm_vblank.c3_disable_latency :
> > + PM_QOS_DEFAULT_VALUE);
> 
> Worker is required as the update may block.
> 
> I'd prefer that as READ_ONCE(dev_priv->i945gm_vblank.enabled)

Yeah, that does seem appropriate.

> 
> > +}
> > +
> > +static int cstate_disable_latency(const char *name)
> > +{
> > +   const struct cpuidle_driver *drv;
> > +   int i;
> > +
> > +   drv = cpuidle_get_driver();
> > +   if 

[Intel-gfx] [PATCH v5 3/5] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

2019-03-22 Thread Carlos Santa
From: Michel Thierry 

Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.

v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_start. Request space of
combined start_watchdog, bb_start and stop_watchdog to avoid any error
after emitting bb_start.

v3: There were too many req->engine in emit_bb_start.
Use GEM_BUG_ON instead of returning a very late EINVAL in the remote
case of watchdog misprogramming; set correct LRI cmd size in
emit_stop_watchdog. (Chris)

v4: Rebase.
v5: use to_intel_context instead of ctx->engine.
v6: Rebase.
v7: Rebase,
Store gpu watchdog capability in engine flag (Tvrtko)
Store WATCHDOG_DISABLE magic # in engine (Tvrtko)
No need to declare emit_{start|stop}_watchdog as vfuncs (Tvrtko)
Replace flag watchdog_running with enable_watchdog (Tvrtko)
Emit a single MI_NOOP by conditionally checking whether the #
of emitted OPs is odd (Tvrtko)
v8: Rebase

Cc: Chris Wilson 
Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/intel_context_types.h |  4 +
 drivers/gpu/drm/i915/intel_engine_cs.c |  2 +
 drivers/gpu/drm/i915/intel_engine_types.h  | 17 -
 drivers/gpu/drm/i915/intel_lrc.c   | 89 +-
 drivers/gpu/drm/i915/intel_lrc.h   |  2 +
 5 files changed, 106 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_context_types.h 
b/drivers/gpu/drm/i915/intel_context_types.h
index 6dc9b4b9067b..e56fc263568e 100644
--- a/drivers/gpu/drm/i915/intel_context_types.h
+++ b/drivers/gpu/drm/i915/intel_context_types.h
@@ -51,6 +51,10 @@ struct intel_context {
u64 lrc_desc;
 
atomic_t pin_count;
+   /** watchdog_threshold: hw watchdog threshold value,
+* in clock counts
+*/
+   u32 watchdog_threshold;
struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
 
/**
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 88cf0fc07623..d4ea07b70904 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -324,6 +324,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
if (engine->context_size)
DRIVER_CAPS(dev_priv)->has_logical_contexts = true;
 
+   engine->watchdog_disable_id = get_watchdog_disable(engine);
+
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
 
diff --git a/drivers/gpu/drm/i915/intel_engine_types.h 
b/drivers/gpu/drm/i915/intel_engine_types.h
index c4f66b774e7c..1f99b536471d 100644
--- a/drivers/gpu/drm/i915/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/intel_engine_types.h
@@ -260,6 +260,7 @@ struct intel_engine_cs {
unsigned int guc_id;
intel_engine_mask_t mask;
 
+   u32 watchdog_disable_id;
u8 uabi_class;
 
u8 class;
@@ -422,10 +423,12 @@ struct intel_engine_cs {
 
struct intel_engine_hangcheck hangcheck;
 
-#define I915_ENGINE_NEEDS_CMD_PARSER BIT(0)
-#define I915_ENGINE_SUPPORTS_STATS   BIT(1)
-#define I915_ENGINE_HAS_PREEMPTION   BIT(2)
-#define I915_ENGINE_HAS_SEMAPHORES   BIT(3)
+#define I915_ENGINE_NEEDS_CMD_PARSER  BIT(0)
+#define I915_ENGINE_SUPPORTS_STATSBIT(1)
+#define I915_ENGINE_HAS_PREEMPTIONBIT(2)
+#define I915_ENGINE_HAS_SEMAPHORESBIT(3)
+#define I915_ENGINE_SUPPORTS_WATCHDOG BIT(4)
+
unsigned int flags;
 
/*
@@ -509,6 +512,12 @@ intel_engine_has_semaphores(const struct intel_engine_cs 
*engine)
return engine->flags & I915_ENGINE_HAS_SEMAPHORES;
 }
 
+static inline bool
+intel_engine_supports_watchdog(const struct intel_engine_cs *engine)
+{
+   return engine->flags & I915_ENGINE_SUPPORTS_WATCHDOG;
+}
+
 #define instdone_slice_mask(dev_priv__) \
(IS_GEN(dev_priv__, 7) ? \
 1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 85785a94f6ae..78ea54a5dbc3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2036,16 +2036,75 @@ static void execlists_reset_finish(struct 
intel_engine_cs *engine)
  atomic_read(>tasklet.count));
 }
 
+static u32 *gen8_emit_start_watchdog(struct i915_request *rq, u32 *cs)
+{
+   struct intel_engine_cs *engine = rq->engine;
+   struct i915_gem_context *ctx = rq->gem_context;
+   struct intel_context *ce = intel_context_lookup(ctx, engine);
+
+   GEM_BUG_ON(!intel_engine_supports_watchdog(engine));
+
+   /*
+* watchdog register must never be programmed to zero. This would
+* cause the watchdog counter to exceed and not allow the engine to
+* go into IDLE state
+*/
+   GEM_BUG_ON(ce->watchdog_threshold == 

[Intel-gfx] [PATCH v5 1/5] drm/i915: Add engine reset count in get-reset-stats ioctl

2019-03-22 Thread Carlos Santa
From: Michel Thierry 

Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.

To start the discussion, include just a total engine reset count. If it
is deemed useful, it can be extended to report each engine separately.

Our igt's gem_reset_stats test will need changes to ignore the pad field,
since it can now return reset_engine_count.

v2: s/engine_reset/reset_engine/, use union in uapi to not break compatibility.
v3: Keep rejecting attempts to use pad as input (Antonio)
v4: Rebased.
v5: Rebased.
Get rid of the union to store pad/engine count (Chris)

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Antonio Argenziano 
Cc: Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
 include/uapi/drm/i915_drm.h |  4 
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 21208a865380..9625b5f7faf7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1350,6 +1350,8 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_reset_stats *args = data;
struct i915_gem_context *ctx;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
int ret;
 
if (args->flags || args->pad)
@@ -1368,10 +1370,16 @@ int i915_gem_context_reset_stats_ioctl(struct 
drm_device *dev,
 * we should wrap the hangstats with a seqlock.
 */
 
-   if (capable(CAP_SYS_ADMIN))
+   if (capable(CAP_SYS_ADMIN)) {
args->reset_count = i915_reset_count(_priv->gpu_error);
-   else
+   for_each_engine(engine, dev_priv, id)
+   args->reset_engine_count +=
+   i915_reset_engine_count(_priv->gpu_error,
+   engine);
+   } else {
args->reset_count = 0;
+   args->reset_engine_count = 0;
+   }
 
args->batch_active = atomic_read(>guilty_count);
args->batch_pending = atomic_read(>active_count);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index aa2d4c73a97d..5e7bc6412880 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1459,6 +1459,9 @@ struct drm_i915_reset_stats {
/* All resets since boot/module reload, for all contexts */
__u32 reset_count;
 
+   /* Engine resets since boot/module reload, for all contexts */
+   __u32 reset_engine_count;
+
/* Number of batches lost when active in GPU, for this context */
__u32 batch_active;
 
@@ -1466,6 +1469,7 @@ struct drm_i915_reset_stats {
__u32 batch_pending;
 
__u32 pad;
+
 };
 
 struct drm_i915_gem_userptr {
-- 
2.17.1

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

[Intel-gfx] [PATCH v5 2/5] drm/i915: Watchdog timeout: IRQ handler for gen8+

2019-03-22 Thread Carlos Santa
From: Michel Thierry 

*** General ***

Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang detection
is to implement the interrupt handling support as well as watchdog command
emission before and after the emitted batch buffer start instruction in the
ring buffer.

The principle of the hang detection mechanism is as follows:

1. Once the decision has been made to enable watchdog timeout for a
particular batch buffer and the driver is in the process of emitting the
batch buffer start instruction into the ring buffer it also emits a
watchdog timer start instruction before and a watchdog timer cancellation
instruction after the batch buffer start instruction in the ring buffer.

2. Once the GPU execution reaches the watchdog timer start instruction
the hardware watchdog counter is started by the hardware. The counter
keeps counting until either reaching a previously configured threshold
value or the timer cancellation instruction is executed.

2a. If the counter reaches the threshold value the hardware fires a
watchdog interrupt that is picked up by the watchdog interrupt handler.
This means that a hang has been detected and the driver needs to deal with
it the same way it would deal with a engine hang detected by the periodic
hang checker. The only difference between the two is that we already blamed
the active request (to ensure an engine reset).

2b. If the batch buffer completes and the execution reaches the watchdog
cancellation instruction before the watchdog counter reaches its
threshold value the watchdog is cancelled and nothing more comes of it.
No hang is detected.

Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog counter getting disabled,
resulting in watchdog being triggered following preemption (e.g. when
watchdog had been enabled in the low priority batch). The driver will
need to explicitly disable the watchdog counter as part of the
preemption sequence.

*** This patch introduces: ***

1. IRQ handler code for watchdog timeout allowing direct hang recovery
based on hardware-driven hang detection, which then integrates directly
with the hang recovery path. This is independent of having per-engine reset
or just full gpu reset.

2. Watchdog specific register information.

Currently the render engine and all available media engines support
watchdog timeout (VECS is only supported in GEN9). The specifications elude
to the BCS engine being supported but that is currently not supported by
this commit.

Note that the value to stop the counter is different between render and
non-render engines in GEN8; GEN9 onwards it's the same.

v2: Move irq handler to tasklet, arm watchdog for a 2nd time to check
against false-positives.

v3: Don't use high priority tasklet, use engine_last_submit while
checking for false-positives. From GEN9 onwards, the stop counter bit is
the same for all engines.

v4: Remove unnecessary brackets, use current_seqno to mark the request
as guilty in the hangcheck/capture code.

v5: Rebased after RESET_ENGINEs flag.

v6: Don't capture error state in case of watchdog timeout. The capture
process is time consuming and this will align to what happens when we
use GuC to handle the watchdog timeout. (Chris)

v7: Rebase.

v8: Rebase, use HZ to reschedule.

v9: Rebase, get forcewake domains in function (no longer in execlists
struct).

v10: Rebase.

v11: Rebase,
 remove extra braces (Tvrtko),
 implement watchdog_to_clock_counts helper (Tvrtko),
 Move tasklet_kill(watchdog_tasklet) inside intel_engines (Tvrtko),
 Use a global heartbeat seqno instead of engine seqno (Chris)
 Make all engines checks all class based checks (Tvrtko)

v12: Rebase,
 Reset immediately upon entering the IRQ (Chris)
 Make reset_engine_to_str a helper (Tvrtko)
 Rename watchdog_irq_handler as watchdog_tasklet (Tvrtko)
 Let the compiler itself do the inline (Tvrtko)

v13: Rebase
v14: Rebase, skip checking for the guilty seqno in the tasklet (Tvrtko)

Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_gpu_error.h |  4 ++
 drivers/gpu/drm/i915/i915_irq.c   | 14 --
 drivers/gpu/drm/i915/i915_reg.h   |  6 +++
 drivers/gpu/drm/i915/i915_reset.c | 20 +
 drivers/gpu/drm/i915/i915_reset.h |  6 +++
 drivers/gpu/drm/i915/intel_engine_cs.c|  1 +
 drivers/gpu/drm/i915/intel_engine_types.h |  5 +++
 drivers/gpu/drm/i915/intel_hangcheck.c| 11 +
 drivers/gpu/drm/i915/intel_lrc.c  | 52 +++
 9 files changed, 107 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 

[Intel-gfx] [PATCH v5 5/5] drm/i915: Watchdog timeout: Include threshold value in error state

2019-03-22 Thread Carlos Santa
From: Michel Thierry 

Save the watchdog threshold (in us) as part of the engine state.

v2: Only do it for gen8+ (and prevent a missing-case warn).
v3: use ctx->__engine.
v4: Rebase.
v5: Rebase.
v6: Rebase, use intel_context_lookup()

Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/i915_gpu_error.c | 14 ++
 drivers/gpu/drm/i915/i915_gpu_error.h |  1 +
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5324397c3801..5dbb3938e159 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3118,6 +3118,8 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
+u32 watchdog_to_us(struct drm_i915_private *i915, u32 value_in_clock_counts);
+
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);
 int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 26bac517e383..1f8d29bf00d0 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -454,9 +454,11 @@ static void error_print_context(struct 
drm_i915_error_state_buf *m,
const char *header,
const struct drm_i915_error_context *ctx)
 {
-   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, prio %d, guilty %d 
active %d\n",
+   err_printf(m, "%s%s[%d] user_handle %d hw_id %d, prio %d, guilty %d 
active %d, watchdog %dus\n",
   header, ctx->comm, ctx->pid, ctx->handle, ctx->hw_id,
-  ctx->sched_attr.priority, ctx->guilty, ctx->active);
+  ctx->sched_attr.priority, ctx->guilty, ctx->active,
+  INTEL_GEN(m->i915) >= 8 ?
+   watchdog_to_us(m->i915, ctx->watchdog_threshold) : 0);
 }
 
 static void error_print_engine(struct drm_i915_error_state_buf *m,
@@ -1316,8 +1318,11 @@ static void error_record_engine_execlists(struct 
intel_engine_cs *engine,
 }
 
 static void record_context(struct drm_i915_error_context *e,
-  struct i915_gem_context *ctx)
+  struct i915_gem_context *ctx,
+  u32 engine_id)
 {
+   struct drm_i915_private *dev_priv = ctx->i915;
+
if (ctx->pid) {
struct task_struct *task;
 
@@ -1335,6 +1340,7 @@ static void record_context(struct drm_i915_error_context 
*e,
e->sched_attr = ctx->sched;
e->guilty = atomic_read(>guilty_count);
e->active = atomic_read(>active_count);
+   e->watchdog_threshold = intel_context_lookup(ctx, 
dev_priv->engine[engine_id])->watchdog_threshold;
 }
 
 static void request_record_user_bo(struct i915_request *request,
@@ -1418,7 +1424,7 @@ static void gem_record_rings(struct i915_gpu_state *error)
 
ee->vm = ctx->ppgtt ? >ppgtt->vm : >vm;
 
-   record_context(>context, ctx);
+   record_context(>context, ctx, engine->id);
 
/* We need to copy these to an anonymous buffer
 * as the simplest method to avoid being overwritten
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 6cf6a8679b26..439a31f5db3b 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -120,6 +120,7 @@ struct i915_gpu_state {
u32 hw_id;
int active;
int guilty;
+   int watchdog_threshold;
struct i915_sched_attr sched_attr;
} context;
 
-- 
2.17.1

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

[Intel-gfx] [PATCH v5 0/5] GEN8+ GPU Watchdog Reset Support

2019-03-22 Thread Carlos Santa
This is a rebased on the original patch series from Michel Thierry:
https://patchwork.freedesktop.org/series/21868

Note that this series is only limited to the GPU Watchdog timeout for
execlists as it leaves out support for GuC based submissions for later.

PATCH v5 of this series was tested from userspace through an IGT
test gem_watchdog --run-subtest basic-bsd1 that is is not in upstream
yet.

The corresponding changes on the i965 media userspace are also under
review: https://github.com/intel/intel-vaapi-driver/pull/429/files

Michel Thierry (5):
  drm/i915: Add engine reset count in get-reset-stats ioctl
  drm/i915: Watchdog timeout: IRQ handler for gen8+
  drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
  drm/i915: Watchdog timeout: DRM kernel interface to set the timeout
  drm/i915: Watchdog timeout: Include threshold value in error state

 drivers/gpu/drm/i915/i915_drv.h|   5 +
 drivers/gpu/drm/i915/i915_gem_context.c| 162 -
 drivers/gpu/drm/i915/i915_gpu_error.c  |  14 +-
 drivers/gpu/drm/i915/i915_gpu_error.h  |   5 +
 drivers/gpu/drm/i915/i915_irq.c|  14 +-
 drivers/gpu/drm/i915/i915_reg.h|   6 +
 drivers/gpu/drm/i915/i915_reset.c  |  20 +++
 drivers/gpu/drm/i915/i915_reset.h  |   6 +
 drivers/gpu/drm/i915/intel_context_types.h |   4 +
 drivers/gpu/drm/i915/intel_engine_cs.c |   3 +
 drivers/gpu/drm/i915/intel_engine_types.h  |  22 ++-
 drivers/gpu/drm/i915/intel_hangcheck.c |  11 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 141 +-
 drivers/gpu/drm/i915/intel_lrc.h   |   2 +
 include/uapi/drm/i915_drm.h|  21 +++
 15 files changed, 410 insertions(+), 26 deletions(-)

-- 
2.17.1

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

[Intel-gfx] [PATCH v5 4/5] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

2019-03-22 Thread Carlos Santa
From: Michel Thierry 

Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.

The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.

[1] 
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk

v2: Fixed get api to return values in microseconds. Threshold updated to
be per context engine. Check for u32 overflow. Capture ctx threshold
value in error state.

v3: Add a way to get array size, short-cut to disable all thresholds,
return EFAULT / EINVAL as needed. Move the capture of the threshold
value in the error state into a new patch. BXT has a different
timestamp base (because why not?).

v4: Checking if watchdog is available should be the first thing to
do, instead of giving false hopes to abi users; remove unnecessary & in
set_watchdog; ignore args->size in getparam.

v5: GEN9-LP platforms have a different crystal clock frequency, use the
right timestamp base for them (magic 8-ball predicts this will change
again later on, so future-proof it). (Daniele)

v6: Rebase, no more mutex BLK in getparam_ioctl.

v7: use to_intel_context instead of ctx->engine.

v8: Rebase, remove extra mutex from i915_gem_context_set_watchdog (Tvrtko),
Update UAPI to use engine class while keeping thresholds per
engine class (Michel).

v9: Rebase,
Remove outdated comment from the commit message (Tvrtko)
Use the engine->flag to verify for gpu watchdog support (Tvrtko)
Use the standard copy_to_user() instead (Tvrtko)
Use the correct type when declaring engine class iterator (Tvrtko)
Remove yet another unncessary mutex_lock (Tvrtko)

v10: Rebase,
Document uAPI struct drm_i915_watchdog_timeout and use it (Tvrtko)
Let the compiler takes care of inlines (Tvrtko)
Make watchdog_to_clock_counts more robust (Tvrtko)

Cc: Antonio Argenziano 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Michel Thierry 
Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h |   3 +
 drivers/gpu/drm/i915/i915_gem_context.c | 150 
 include/uapi/drm/i915_drm.h |  17 +++
 3 files changed, 170 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c65c2e6649df..5324397c3801 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1598,6 +1598,9 @@ struct drm_i915_private {
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
965 */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
 
+   /* Command stream timestamp base - helps define watchdog threshold */
+   u32 cs_timestamp_base;
+
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
unsigned int max_cdclk_freq;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 9625b5f7faf7..cfd33ca5c13f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -878,6 +878,149 @@ int i915_gem_context_destroy_ioctl(struct drm_device 
*dev, void *data,
return 0;
 }
 
+/*
+ * BDW, CHV & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But BXT/GLK Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ *
+ * Future-proofing, some day it won't be as simple as just GEN & IS_LP.
+ */
+#define GEN8_TIMESTAMP_CNTS_PER_USEC 12
+#define GEN9_LP_TIMESTAMP_CNTS_PER_USEC 19
+u32 cs_timestamp_in_us(struct drm_i915_private *i915)
+{
+   u32 cs_timestamp_base = i915->cs_timestamp_base;
+
+   if (cs_timestamp_base)
+   return cs_timestamp_base;
+
+   switch (INTEL_GEN(i915)) {
+   default:
+   MISSING_CASE(INTEL_GEN(i915));
+   /* fall through */
+   case 9:
+   cs_timestamp_base = IS_GEN9_LP(i915) ?
+   GEN9_LP_TIMESTAMP_CNTS_PER_USEC :
+   GEN8_TIMESTAMP_CNTS_PER_USEC;
+   break;
+   case 8:
+   cs_timestamp_base = GEN8_TIMESTAMP_CNTS_PER_USEC;
+   break;
+   }
+
+   i915->cs_timestamp_base = cs_timestamp_base;
+   return cs_timestamp_base;
+}
+
+u32 watchdog_to_us(struct drm_i915_private *i915, u32 value_in_clock_counts)
+{
+   return value_in_clock_counts / cs_timestamp_in_us(i915);
+}
+
+int watchdog_to_clock_counts(struct drm_i915_private *i915, u32 *value_in_us)
+{
+   u64 threshold = 

[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP2.2 Phase II (rev4)

2019-03-22 Thread Patchwork
== Series Details ==

Series: HDCP2.2 Phase II (rev4)
URL   : https://patchwork.freedesktop.org/series/57232/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5792_full -> Patchwork_12566_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * {igt@kms_content_protection@type1} (NEW):
- shard-iclb: NOTRUN -> SKIP +3

  
New tests
-

  New tests have been introduced between CI_DRM_5792_full and 
Patchwork_12566_full:

### New IGT tests (4) ###

  * igt@kms_content_protection@content_type_change:
- Statuses : 6 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_content_protection@srm:
- Statuses : 5 skip(s)
- Exec time: [0.0, 0.01] s

  * igt@kms_content_protection@type1:
- Statuses : 6 skip(s)
- Exec time: [0.0, 0.00] s

  * igt@kms_content_protection@type1_mei_interface:
- Statuses : 6 skip(s)
- Exec time: [0.00, 0.01] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@vcs1-s3:
- shard-glk:  NOTRUN -> SKIP [fdo#109271] +26

  * igt@gem_exec_schedule@preempt-other-chain-blt:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +39

  * igt@gem_pread@stolen-uncached:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +74

  * igt@gem_wait@write-wait-bsd1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +7

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-iclb: NOTRUN -> FAIL [fdo#107847]

  * igt@i915_pm_rpm@debugfs-forcewake-user:
- shard-skl:  PASS -> INCOMPLETE [fdo#107807]

  * igt@i915_pm_rpm@gem-execbuf-stress-extra-wait:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@i915_pm_rpm@i2c:
- shard-iclb: PASS -> DMESG-WARN [fdo#109982]

  * igt@i915_pm_rps@reset:
- shard-iclb: NOTRUN -> FAIL [fdo#108059] +1

  * igt@kms_atomic_transition@3x-modeset-transitions-fencing:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-apl:  PASS -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-newfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-kbl:  PASS -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-e:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5

  * igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * {igt@kms_content_protection@type1_mei_interface} (NEW):
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +3

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +6

  * igt@kms_dp_dsc@basic-dsc-enable-dp:
- shard-iclb: NOTRUN -> SKIP [fdo#109349]

  * igt@kms_flip_tiling@flip-to-x-tiled:
- shard-iclb: PASS -> FAIL [fdo#108134]

  * igt@kms_force_connector_basic@force-edid:
- shard-iclb: NOTRUN -> SKIP [fdo#109285]

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt:
- shard-iclb: NOTRUN -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +65

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-gtt:
- shard-iclb: NOTRUN -> FAIL [fdo#109247]

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +4

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +16

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-cpu:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247]

  * igt@kms_frontbuffer_tracking@fbcpsr-suspend:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#106978]

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#109247] +19

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-glk:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * 

Re: [Intel-gfx] [PATCH] drm/i915/guc: Support for extended GuC notification messages

2019-03-22 Thread Daniele Ceraolo Spurio



On 3/21/19 5:00 AM, Michal Wajdeczko wrote:

GuC may send notification messages with payload larger than
single u32. Prepare driver to accept longer messages.



Reviewed-by: Daniele Ceraolo Spurio 

To give a bit more context, for example the RESET_COMPLETE G2H will 
provide the engine class in the second dword.


Daniele


Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Vinay Belgaumkar 
Cc: Michal Winiarski 
Cc: Tomasz Lis 
---
  drivers/gpu/drm/i915/intel_guc.c| 14 +++---
  drivers/gpu/drm/i915/intel_guc.h|  3 ++-
  drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
  3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index a59448a56f55..f2b4eaee8d52 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -484,17 +484,25 @@ void intel_guc_to_host_event_handler_mmio(struct 
intel_guc *guc)
spin_unlock(>irq_lock);
enable_rpm_wakeref_asserts(dev_priv);
  
-	intel_guc_to_host_process_recv_msg(guc, msg);

+   intel_guc_to_host_process_recv_msg(guc, , 1);
  }
  
-void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg)

+int intel_guc_to_host_process_recv_msg(struct intel_guc *guc,
+  const u32 *payload, u32 len)
  {
+   u32 msg;
+
+   if (unlikely(!len))
+   return -EPROTO;
+
/* Make sure to handle only enabled messages */
-   msg &= guc->msg_enabled_mask;
+   msg = payload[0] & guc->msg_enabled_mask;
  
  	if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |

   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
intel_guc_log_handle_flush_event(>log);
+
+   return 0;
  }
  
  int intel_guc_sample_forcewake(struct intel_guc *guc)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 77ec1bd4df5a..2c59ff8d9f39 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -165,7 +165,8 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len,
  void intel_guc_to_host_event_handler(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_nop(struct intel_guc *guc);
  void intel_guc_to_host_event_handler_mmio(struct intel_guc *guc);
-void intel_guc_to_host_process_recv_msg(struct intel_guc *guc, u32 msg);
+int intel_guc_to_host_process_recv_msg(struct intel_guc *guc,
+  const u32 *payload, u32 len);
  int intel_guc_sample_forcewake(struct intel_guc *guc);
  int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset);
  int intel_guc_suspend(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index 79ddb8088311..dde1dc0d6e69 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -701,14 +701,15 @@ static void ct_process_request(struct intel_guc_ct *ct,
   u32 action, u32 len, const u32 *payload)
  {
struct intel_guc *guc = ct_to_guc(ct);
+   int ret;
  
  	CT_DEBUG_DRIVER("CT: request %x %*ph\n", action, 4 * len, payload);
  
  	switch (action) {

case INTEL_GUC_ACTION_DEFAULT:
-   if (unlikely(len < 1))
+   ret = intel_guc_to_host_process_recv_msg(guc, payload, len);
+   if (unlikely(ret))
goto fail_unexpected;
-   intel_guc_to_host_process_recv_msg(guc, *payload);
break;
  
  	default:



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

[Intel-gfx] ✓ Fi.CI.BAT: success for Do not re-read dpll registers (rev2)

2019-03-22 Thread Patchwork
== Series Details ==

Series: Do not re-read dpll registers (rev2)
URL   : https://patchwork.freedesktop.org/series/58382/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5797 -> Patchwork_12581


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] +55

  * igt@gem_exec_basic@readonly-bsd:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76

  * igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720]

  * igt@kms_busy@basic-flip-a:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@basic-flip-c:
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-byt-j1900:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] +62
- fi-byt-j1900:   NOTRUN -> SKIP [fdo#109271] +52

  * igt@kms_chamelium@hdmi-edid-read:
- fi-blb-e6850:   NOTRUN -> SKIP [fdo#109271] +20

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850:   NOTRUN -> INCOMPLETE [fdo#107718]

  * igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   INCOMPLETE [fdo#107718] -> PASS

  * igt@gem_tiled_pread_basic:
- fi-ilk-650: FAIL -> PASS

  
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (33 -> 31)
--

  Additional (5): fi-bsw-n3050 fi-byt-j1900 fi-apl-guc fi-pnv-d510 fi-bsw-kefka 
  Missing(7): fi-kbl-soraka fi-hsw-4770r fi-ilk-m540 fi-hsw-4200u 
fi-kbl-7500u fi-ctg-p8600 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5797 -> Patchwork_12581

  CI_DRM_5797: 00cb3798a5d008c3f824fe7c89c663dba66155c3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4899: ba96339c238180b38d05d7fa2dca772d49eee332 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12581: 9281ea7c419da76f66e3d3d1cd758fe4854a6caf @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9281ea7c419d drm/i915/icl: reduce pll_id scope and use enum type
5cdcb4247748 drm/i915/icl: use previous pll hw readout
91cd09daaeea drm/i915/cnl: use previous pll hw readout
55c41b91d0b8 drm/i915/bxt: make bxt_calc_pll_link() similar to skl
065a927f3bab drm/i915/skl: use previous pll hw readout

== Logs ==

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

[Intel-gfx] [PATCH v2 0/5] Do not re-read dpll registers

2019-03-22 Thread Lucas De Marchi
v2 of https://patchwork.freedesktop.org/series/58382/

Instead of re-reading the registers we just read on the hw state
readout, use the values saved on intel_shared_dpll. Besides not doing
the MMIO, this helps on sharing code since we don't have to
differentiate e.g. ICL and CNL because they have different registers for
the same thing.

Lucas De Marchi (5):
  drm/i915/skl: use previous pll hw readout
  drm/i915/bxt: make bxt_calc_pll_link() similar to skl
  drm/i915/cnl: use previous pll hw readout
  drm/i915/icl: use previous pll hw readout
  drm/i915/icl: reduce pll_id scope and use enum type

 drivers/gpu/drm/i915/icl_dsi.c   |   5 +-
 drivers/gpu/drm/i915/intel_ddi.c | 160 +--
 drivers/gpu/drm/i915/intel_drv.h |   2 +-
 3 files changed, 70 insertions(+), 97 deletions(-)

-- 
2.20.1

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

[Intel-gfx] [PATCH v2 1/5] drm/i915/skl: use previous pll hw readout

2019-03-22 Thread Lucas De Marchi
By the time skl_ddi_clock_get() is called - and thus
skl_calc_wrpll_link() - we've just got the hw state from the pll
registers. We don't need to read them again: we can rather reuse what
was cached in the dpll_hw_state.

v2: rename state variable to pll_state, make argument const in
skl_calc_wrpll_link() and remove not useful warning (from Ville)

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 50 ++--
 1 file changed, 21 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 933df3a57a8a..15f143c2ed6e 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1240,24 +1240,15 @@ static int hsw_ddi_calc_wrpll_link(struct 
drm_i915_private *dev_priv,
return (refclk * n * 100) / (p * r);
 }
 
-static int skl_calc_wrpll_link(struct drm_i915_private *dev_priv,
-  enum intel_dpll_id pll_id)
+static int skl_calc_wrpll_link(const struct intel_dpll_hw_state *pll_state)
 {
-   i915_reg_t cfgcr1_reg, cfgcr2_reg;
-   u32 cfgcr1_val, cfgcr2_val;
u32 p0, p1, p2, dco_freq;
 
-   cfgcr1_reg = DPLL_CFGCR1(pll_id);
-   cfgcr2_reg = DPLL_CFGCR2(pll_id);
+   p0 = pll_state->cfgcr2 & DPLL_CFGCR2_PDIV_MASK;
+   p2 = pll_state->cfgcr2 & DPLL_CFGCR2_KDIV_MASK;
 
-   cfgcr1_val = I915_READ(cfgcr1_reg);
-   cfgcr2_val = I915_READ(cfgcr2_reg);
-
-   p0 = cfgcr2_val & DPLL_CFGCR2_PDIV_MASK;
-   p2 = cfgcr2_val & DPLL_CFGCR2_KDIV_MASK;
-
-   if (cfgcr2_val &  DPLL_CFGCR2_QDIV_MODE(1))
-   p1 = (cfgcr2_val & DPLL_CFGCR2_QDIV_RATIO_MASK) >> 8;
+   if (pll_state->cfgcr2 &  DPLL_CFGCR2_QDIV_MODE(1))
+   p1 = (pll_state->cfgcr2 & DPLL_CFGCR2_QDIV_RATIO_MASK) >> 8;
else
p1 = 1;
 
@@ -1292,10 +1283,11 @@ static int skl_calc_wrpll_link(struct drm_i915_private 
*dev_priv,
break;
}
 
-   dco_freq = (cfgcr1_val & DPLL_CFGCR1_DCO_INTEGER_MASK) * 24 * 1000;
+   dco_freq = (pll_state->cfgcr1 & DPLL_CFGCR1_DCO_INTEGER_MASK)
+   * 24 * 1000;
 
-   dco_freq += (((cfgcr1_val & DPLL_CFGCR1_DCO_FRACTION_MASK) >> 9) * 24 *
-   1000) / 0x8000;
+   dco_freq += (((pll_state->cfgcr1 & DPLL_CFGCR1_DCO_FRACTION_MASK) >> 9)
+* 24 * 1000) / 0x8000;
 
if (WARN_ON(p0 == 0 || p1 == 0 || p2 == 0))
return 0;
@@ -1544,22 +1536,22 @@ static void cnl_ddi_clock_get(struct intel_encoder 
*encoder,
 }
 
 static void skl_ddi_clock_get(struct intel_encoder *encoder,
-   struct intel_crtc_state *pipe_config)
+ struct intel_crtc_state *pipe_config)
 {
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   int link_clock = 0;
-   u32 dpll_ctl1;
-   enum intel_dpll_id pll_id;
-
-   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
+   struct intel_dpll_hw_state *pll_state;
+   int link_clock;
 
-   dpll_ctl1 = I915_READ(DPLL_CTRL1);
+   /*
+* ctrl1 register is already shifted for each pll, just use 0 to get
+* the internal shift for each field
+*/
+   pll_state = _config->dpll_hw_state;
 
-   if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(pll_id)) {
-   link_clock = skl_calc_wrpll_link(dev_priv, pll_id);
+   if (pll_state->ctrl1 & DPLL_CTRL1_HDMI_MODE(0)) {
+   link_clock = skl_calc_wrpll_link(pll_state);
} else {
-   link_clock = dpll_ctl1 & DPLL_CTRL1_LINK_RATE_MASK(pll_id);
-   link_clock >>= DPLL_CTRL1_LINK_RATE_SHIFT(pll_id);
+   link_clock = pll_state->ctrl1 & DPLL_CTRL1_LINK_RATE_MASK(0);
+   link_clock >>= DPLL_CTRL1_LINK_RATE_SHIFT(0);
 
switch (link_clock) {
case DPLL_CTRL1_LINK_RATE_810:
-- 
2.20.1

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

[Intel-gfx] [PATCH v2 5/5] drm/i915/icl: reduce pll_id scope and use enum type

2019-03-22 Thread Lucas De Marchi
Now that pll_id is not used anymore for combophy, reduce its scope.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9e4d58759910..00919119a1d0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1456,12 +1456,13 @@ static void icl_ddi_clock_get(struct intel_encoder 
*encoder,
struct intel_dpll_hw_state *pll_state = _config->dpll_hw_state;
enum port port = encoder->port;
int link_clock;
-   u32 pll_id;
 
-   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
if (intel_port_is_combophy(dev_priv, port)) {
link_clock = cnl_calc_wrpll_link(dev_priv, pll_state);
} else {
+   enum intel_dpll_id pll_id = intel_get_shared_dpll_id(dev_priv,
+   pipe_config->shared_dpll);
+
if (pll_id == DPLL_ID_ICL_TBTPLL)
link_clock = icl_calc_tbt_pll_link(dev_priv, port);
else
-- 
2.20.1

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

[Intel-gfx] [PATCH v2 2/5] drm/i915/bxt: make bxt_calc_pll_link() similar to skl

2019-03-22 Thread Lucas De Marchi
Rename state to pll_state and use it as the argument to
bxt_calc_pll_link(), similar to how it's done in the skl variant.

The WARN_ON(!crtc_state->shared_dpll) is not very useful, so remove it
as well.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 15f143c2ed6e..ef282693bbac 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1631,24 +1631,17 @@ static void hsw_ddi_clock_get(struct intel_encoder 
*encoder,
ddi_dotclock_get(pipe_config);
 }
 
-static int bxt_calc_pll_link(struct intel_crtc_state *crtc_state)
+static int bxt_calc_pll_link(const struct intel_dpll_hw_state *pll_state)
 {
-   struct intel_dpll_hw_state *state;
struct dpll clock;
 
-   /* For DDI ports we always use a shared PLL. */
-   if (WARN_ON(!crtc_state->shared_dpll))
-   return 0;
-
-   state = _state->dpll_hw_state;
-
clock.m1 = 2;
-   clock.m2 = (state->pll0 & PORT_PLL_M2_MASK) << 22;
-   if (state->pll3 & PORT_PLL_M2_FRAC_ENABLE)
-   clock.m2 |= state->pll2 & PORT_PLL_M2_FRAC_MASK;
-   clock.n = (state->pll1 & PORT_PLL_N_MASK) >> PORT_PLL_N_SHIFT;
-   clock.p1 = (state->ebb0 & PORT_PLL_P1_MASK) >> PORT_PLL_P1_SHIFT;
-   clock.p2 = (state->ebb0 & PORT_PLL_P2_MASK) >> PORT_PLL_P2_SHIFT;
+   clock.m2 = (pll_state->pll0 & PORT_PLL_M2_MASK) << 22;
+   if (pll_state->pll3 & PORT_PLL_M2_FRAC_ENABLE)
+   clock.m2 |= pll_state->pll2 & PORT_PLL_M2_FRAC_MASK;
+   clock.n = (pll_state->pll1 & PORT_PLL_N_MASK) >> PORT_PLL_N_SHIFT;
+   clock.p1 = (pll_state->ebb0 & PORT_PLL_P1_MASK) >> PORT_PLL_P1_SHIFT;
+   clock.p2 = (pll_state->ebb0 & PORT_PLL_P2_MASK) >> PORT_PLL_P2_SHIFT;
 
return chv_calc_dpll_params(10, );
 }
@@ -1656,7 +1649,8 @@ static int bxt_calc_pll_link(struct intel_crtc_state 
*crtc_state)
 static void bxt_ddi_clock_get(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config)
 {
-   pipe_config->port_clock = bxt_calc_pll_link(pipe_config);
+   pipe_config->port_clock =
+   bxt_calc_pll_link(_config->dpll_hw_state);
 
ddi_dotclock_get(pipe_config);
 }
-- 
2.20.1

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

[Intel-gfx] [PATCH v2 3/5] drm/i915/cnl: use previous pll hw readout

2019-03-22 Thread Lucas De Marchi
By the time cnl_ddi_clock_get() is called we've just got the hw state
from the pll registers. We don't need to read them again: we can rather
reuse what was cached in the dpll_hw_state.

This also affects the code for ICL since it partially reuses the CNL
code. However the more intricate part on ICL is left for another patch.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/icl_dsi.c   |  5 ++--
 drivers/gpu/drm/i915/intel_ddi.c | 44 
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 3 files changed, 19 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 92440ff48f93..1395338c6772 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1179,11 +1179,10 @@ static void gen11_dsi_get_config(struct intel_encoder 
*encoder,
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
-   u32 pll_id;
 
/* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */
-   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
-   pipe_config->port_clock = cnl_calc_wrpll_link(dev_priv, pll_id);
+   pipe_config->port_clock =
+   cnl_calc_wrpll_link(dev_priv, _config->dpll_hw_state);
pipe_config->base.adjusted_mode.crtc_clock = intel_dsi->pclk;
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
 }
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ef282693bbac..687ba9fe146e 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1296,24 +1296,15 @@ static int skl_calc_wrpll_link(const struct 
intel_dpll_hw_state *pll_state)
 }
 
 int cnl_calc_wrpll_link(struct drm_i915_private *dev_priv,
-   enum intel_dpll_id pll_id)
+   struct intel_dpll_hw_state *pll_state)
 {
-   u32 cfgcr0, cfgcr1;
u32 p0, p1, p2, dco_freq, ref_clock;
 
-   if (INTEL_GEN(dev_priv) >= 11) {
-   cfgcr0 = I915_READ(ICL_DPLL_CFGCR0(pll_id));
-   cfgcr1 = I915_READ(ICL_DPLL_CFGCR1(pll_id));
-   } else {
-   cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
-   cfgcr1 = I915_READ(CNL_DPLL_CFGCR1(pll_id));
-   }
+   p0 = pll_state->cfgcr1 & DPLL_CFGCR1_PDIV_MASK;
+   p2 = pll_state->cfgcr1 & DPLL_CFGCR1_KDIV_MASK;
 
-   p0 = cfgcr1 & DPLL_CFGCR1_PDIV_MASK;
-   p2 = cfgcr1 & DPLL_CFGCR1_KDIV_MASK;
-
-   if (cfgcr1 & DPLL_CFGCR1_QDIV_MODE(1))
-   p1 = (cfgcr1 & DPLL_CFGCR1_QDIV_RATIO_MASK) >>
+   if (pll_state->cfgcr1 & DPLL_CFGCR1_QDIV_MODE(1))
+   p1 = (pll_state->cfgcr1 & DPLL_CFGCR1_QDIV_RATIO_MASK) >>
DPLL_CFGCR1_QDIV_RATIO_SHIFT;
else
p1 = 1;
@@ -1348,9 +1339,10 @@ int cnl_calc_wrpll_link(struct drm_i915_private 
*dev_priv,
 
ref_clock = cnl_hdmi_pll_ref_clock(dev_priv);
 
-   dco_freq = (cfgcr0 & DPLL_CFGCR0_DCO_INTEGER_MASK) * ref_clock;
+   dco_freq = (pll_state->cfgcr0 & DPLL_CFGCR0_DCO_INTEGER_MASK)
+   * ref_clock;
 
-   dco_freq += (((cfgcr0 & DPLL_CFGCR0_DCO_FRACTION_MASK) >>
+   dco_freq += (((pll_state->cfgcr0 & DPLL_CFGCR0_DCO_FRACTION_MASK) >>
  DPLL_CFGCR0_DCO_FRACTION_SHIFT) * ref_clock) / 0x8000;
 
if (WARN_ON(p0 == 0 || p1 == 0 || p2 == 0))
@@ -1463,13 +1455,14 @@ static void icl_ddi_clock_get(struct intel_encoder 
*encoder,
  struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_dpll_hw_state *pll_state = _config->dpll_hw_state;
enum port port = encoder->port;
-   int link_clock = 0;
+   int link_clock;
u32 pll_id;
 
pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
if (intel_port_is_combophy(dev_priv, port)) {
-   link_clock = cnl_calc_wrpll_link(dev_priv, pll_id);
+   link_clock = cnl_calc_wrpll_link(dev_priv, pll_state);
} else {
if (pll_id == DPLL_ID_ICL_TBTPLL)
link_clock = icl_calc_tbt_pll_link(dev_priv, port);
@@ -1485,18 +1478,13 @@ static void cnl_ddi_clock_get(struct intel_encoder 
*encoder,
  struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   int link_clock = 0;
-   u32 cfgcr0;
-   enum intel_dpll_id pll_id;
-
-   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
-
-   cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
+   struct intel_dpll_hw_state *pll_state = _config->dpll_hw_state;
+   int link_clock;
 
-   if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
-   link_clock = cnl_calc_wrpll_link(dev_priv, pll_id);
+   if (pll_state->cfgcr0 & 

[Intel-gfx] [PATCH v2 4/5] drm/i915/icl: use previous pll hw readout

2019-03-22 Thread Lucas De Marchi
By the time icl_ddi_clock_get() is called we've just got the hw state
from the pll registers. We don't need to read them again: we can rather
reuse what was cached in the dpll_hw_state.

While at it, s/refclk/ref_clock/ just to be consistent with the name
used in code nearby.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 37 
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 687ba9fe146e..9e4d58759910 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1374,25 +1374,21 @@ static int icl_calc_tbt_pll_link(struct 
drm_i915_private *dev_priv,
 }
 
 static int icl_calc_mg_pll_link(struct drm_i915_private *dev_priv,
-   enum port port)
+   const struct intel_dpll_hw_state *pll_state)
 {
-   enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
-   u32 mg_pll_div0, mg_clktop_hsclkctl;
-   u32 m1, m2_int, m2_frac, div1, div2, refclk;
+   u32 m1, m2_int, m2_frac, div1, div2, ref_clock;
u64 tmp;
 
-   refclk = dev_priv->cdclk.hw.ref;
-
-   mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
-   mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
+   ref_clock = dev_priv->cdclk.hw.ref;
 
-   m1 = I915_READ(MG_PLL_DIV1(tc_port)) & MG_PLL_DIV1_FBPREDIV_MASK;
-   m2_int = mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
-   m2_frac = (mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
- (mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
- MG_PLL_DIV0_FBDIV_FRAC_SHIFT : 0;
+   m1 = pll_state->mg_pll_div1 & MG_PLL_DIV1_FBPREDIV_MASK;
+   m2_int = pll_state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
+   m2_frac = (pll_state->mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
+   (pll_state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
+   MG_PLL_DIV0_FBDIV_FRAC_SHIFT : 0;
 
-   switch (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
+   switch (pll_state->mg_clktop2_hsclkctl &
+   MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
case MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_2:
div1 = 2;
break;
@@ -1406,12 +1402,14 @@ static int icl_calc_mg_pll_link(struct drm_i915_private 
*dev_priv,
div1 = 7;
break;
default:
-   MISSING_CASE(mg_clktop_hsclkctl);
+   MISSING_CASE(pll_state->mg_clktop2_hsclkctl);
return 0;
}
 
-   div2 = (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
+   div2 = (pll_state->mg_clktop2_hsclkctl &
+   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_SHIFT;
+
/* div2 value of 0 is same as 1 means no div */
if (div2 == 0)
div2 = 1;
@@ -1420,8 +1418,8 @@ static int icl_calc_mg_pll_link(struct drm_i915_private 
*dev_priv,
 * Adjust the original formula to delay the division by 2^22 in order to
 * minimize possible rounding errors.
 */
-   tmp = (u64)m1 * m2_int * refclk +
- (((u64)m1 * m2_frac * refclk) >> 22);
+   tmp = (u64)m1 * m2_int * ref_clock +
+ (((u64)m1 * m2_frac * ref_clock) >> 22);
tmp = div_u64(tmp, 5 * div1 * div2);
 
return tmp;
@@ -1467,10 +1465,11 @@ static void icl_ddi_clock_get(struct intel_encoder 
*encoder,
if (pll_id == DPLL_ID_ICL_TBTPLL)
link_clock = icl_calc_tbt_pll_link(dev_priv, port);
else
-   link_clock = icl_calc_mg_pll_link(dev_priv, port);
+   link_clock = icl_calc_mg_pll_link(dev_priv, pll_state);
}
 
pipe_config->port_clock = link_clock;
+
ddi_dotclock_get(pipe_config);
 }
 
-- 
2.20.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 drm/i915: Add not fenceable reason to not enable FBC

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915: Add not fenceable reason to not enable FBC
URL   : https://patchwork.freedesktop.org/series/58390/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5792_full -> Patchwork_12565_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@preempt-other-chain-blt:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +35

  * igt@gem_exec_schedule@promotion-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +4

  * igt@gem_pread@stolen-uncached:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +70

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-iclb: NOTRUN -> FAIL [fdo#107847]

  * igt@i915_pm_rps@reset:
- shard-iclb: NOTRUN -> FAIL [fdo#108059]

  * igt@kms_atomic_transition@3x-modeset-transitions-fencing:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +1

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-apl:  PASS -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-newfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-e:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-glk:  PASS -> DMESG-WARN [fdo#110222]

  * igt@kms_chamelium@hdmi-crc-single:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +7

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-iclb: PASS -> FAIL [fdo#103355]

  * igt@kms_dp_dsc@basic-dsc-enable-dp:
- shard-iclb: NOTRUN -> SKIP [fdo#109349]

  * igt@kms_flip@plain-flip-fb-recreate:
- shard-skl:  PASS -> FAIL [fdo#100368]

  * igt@kms_force_connector_basic@force-edid:
- shard-iclb: NOTRUN -> SKIP [fdo#109285]

  * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +77

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +4

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-move:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +9

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247]

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#109247] +27

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-render:
- shard-iclb: NOTRUN -> FAIL [fdo#109247]

  * igt@kms_pipe_b_c_ivb@from-pipe-c-to-b-with-3-lanes:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145] / [fdo#108590]
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-skl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_scaling@pipe-c-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_psr@cursor_mmap_gtt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +5

  * igt@kms_psr@no_drrs:
- shard-iclb: PASS -> FAIL [fdo#108341]

  * igt@kms_psr@primary_blt:
- shard-iclb: NOTRUN -> FAIL [fdo#107383] / [fdo#110215]

  * igt@kms_psr@psr2_dpms:
- shard-iclb: PASS -> SKIP [fdo#109441] +2

  * igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]

  * igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl:  PASS -> FAIL [fdo#109016]

  * igt@kms_universal_plane@disable-primary-vs-flip-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-iclb: PASS -> FAIL [fdo#104894]

  * igt@prime_nv_pcopy@test1_micro:
- shard-iclb: NOTRUN -> SKIP [fdo#109291] +1

  * igt@prime_vgem@fence-read-hang:
- shard-iclb: NOTRUN -> SKIP [fdo#109295]

  
 Possible fixes 

  * igt@gem_busy@close-race:
- shard-apl:  FAIL -> PASS

  * igt@gem_create@create-clear:
- shard-snb: 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Mark AML 0x87CA as ULX

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915: Mark AML 0x87CA as ULX
URL   : https://patchwork.freedesktop.org/series/58440/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5797 -> Patchwork_12580


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] +55

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109315] +17

  * igt@gem_exec_basic@basic-bsd2:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109276] +7

  * igt@gem_exec_basic@readonly-bsd:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76

  * igt@gem_exec_parse@basic-rejected:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109289] +1

  * igt@gem_exec_store@basic-bsd2:
- fi-hsw-4770:NOTRUN -> SKIP [fdo#109271] +41

  * igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50

  * igt@i915_selftest@live_contexts:
- fi-icl-u3:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-a:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@basic-flip-c:
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] +62
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109284] +8

  * igt@kms_force_connector_basic@force-edid:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109285] +3

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  NOTRUN -> FAIL [fdo#103167]

  
 Possible fixes 

  * igt@gem_tiled_pread_basic:
- fi-ilk-650: FAIL -> PASS

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315


Participating hosts (33 -> 33)
--

  Additional (6): fi-bsw-n3050 fi-apl-guc fi-hsw-4770 fi-icl-u3 fi-pnv-d510 
fi-bsw-kefka 
  Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-ctg-p8600 
fi-blb-e6850 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5797 -> Patchwork_12580

  CI_DRM_5797: 00cb3798a5d008c3f824fe7c89c663dba66155c3 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4899: ba96339c238180b38d05d7fa2dca772d49eee332 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12580: 75cd96230a2552214a697cddfa93d865f3e4dff1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

75cd96230a25 drm/i915: Mark AML 0x87CA as ULX

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12580/
___
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: Mark AML 0x87CA as ULX

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915: Mark AML 0x87CA as ULX
URL   : https://patchwork.freedesktop.org/series/58440/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Mark AML 0x87CA as ULX
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3577:16: warning: expression 
using sizeof(void)

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

Re: [Intel-gfx] [PATCH] drm/i915: Mark AML 0x87CA as ULX

2019-03-22 Thread Souza, Jose
On Fri, 2019-03-22 at 22:49 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> If I'm reading the spec right AML 0x87CA is a Y SKU, so it
> should be marked as ULX in our old style terminology.

You are right, only the CPU is based on CFL.

Reviewed-by: José Roberto de Souza 

> 
> Cc: sta...@vger.kernel.org
> Cc: José Roberto de Souza 
> Cc: Rodrigo Vivi 
> Cc: Tvrtko Ursulin 
> Fixes: c0c46ca461f1 ("drm/i915/aml: Add new Amber Lake PCI ID")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index f723b15527f8..428279fd88a0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2361,7 +2361,8 @@ static inline unsigned int
> i915_sg_segment_size(void)
>INTEL_DEVID(dev_priv) == 0x5915 || \
>INTEL_DEVID(dev_priv) == 0x591E)
>  #define IS_AML_ULX(dev_priv) (INTEL_DEVID(dev_priv) == 0x591C || \
> -  INTEL_DEVID(dev_priv) == 0x87C0)
> +  INTEL_DEVID(dev_priv) == 0x87C0 || \
> +  INTEL_DEVID(dev_priv) == 0x87CA)
>  #define IS_SKL_GT2(dev_priv) (IS_SKYLAKE(dev_priv) && \
>INTEL_INFO(dev_priv)->gt == 2)
>  #define IS_SKL_GT3(dev_priv) (IS_SKYLAKE(dev_priv) && \


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use vblank_disable_immediate on gen2

2019-03-22 Thread Chris Wilson
Quoting Ville Syrjala (2019-03-22 18:08:04)
> From: Ville Syrjälä 
> 
> The vblank timestamp->counter guesstimator seems to be
> working sufficiently well, so there's no reason not to
> disable vblank interrupts ASAP even on gen2.
> 
> Signed-off-by: Ville Syrjälä 
Acked-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable C3 when enabling vblank interrupts on i945gm

2019-03-22 Thread Chris Wilson
Quoting Ville Syrjala (2019-03-22 18:08:03)
> From: Ville Syrjälä 
> 
> The AGPBUSY thing doesn't work on i945gm anymore. This means
> the gmch is incapable of waking the CPU from C3 when an interrupt
> is generated. The interrupts just get postponed indefinitely until
> something wakes up the CPU. This is rather annoying for vblank
> interrupts as we are unable to maintain a steady framerate
> unless the machine is sufficiently loaded to stay out of C3.
> 
> To combat this let's use pm_qos to prevent C3 whenever vblank
> interrupts are enabled. To maintain reasonable amount of powersaving
> we will attempt to limit this to C3 only while leaving C1 and C2
> enabled.

Interesting compromise. Frankly, I had considered pm_qos in an
all-or-nothing approach, partly because finding the C transitions is a
bit opaque.
 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30364
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  8 +++
>  drivers/gpu/drm/i915/i915_irq.c | 88 +
>  2 files changed, 96 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f723b15527f8..0c736f8ca1b2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2042,6 +2042,14 @@ struct drm_i915_private {
> struct i915_vma *scratch;
> } gt;
>  
> +   /* For i945gm vblank irq vs. C3 workaround */
> +   struct {
> +   struct work_struct work;
> +   struct pm_qos_request pm_qos;
> +   u8 c3_disable_latency;

Ok, looks a bit tight, but checks out.

> +   u8 enabled;
> +   } i945gm_vblank;
> +
> /* perform PHY state sanity checks? */
> bool chv_phy_assert[2];
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 2f788291cfe0..33386f0acab3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -30,6 +30,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3131,6 +3132,16 @@ static int i8xx_enable_vblank(struct drm_device *dev, 
> unsigned int pipe)
> return 0;
>  }
>  
> +static int i945gm_enable_vblank(struct drm_device *dev, unsigned int pipe)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(dev);
> +
> +   if (dev_priv->i945gm_vblank.enabled++ == 0)
> +   schedule_work(_priv->i945gm_vblank.work);

I was thinking u8, isn't that a bit dangerous. But the max counter here
should be num_pipes. Hmm, is the vblank spinlock local to a pipe? Nope,
dev->vbl_lock.

> +
> +   return i8xx_enable_vblank(dev, pipe);
> +}
> +
>  static int i965_enable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -3195,6 +3206,16 @@ static void i8xx_disable_vblank(struct drm_device 
> *dev, unsigned int pipe)
> spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  }
>  
> +static void i945gm_disable_vblank(struct drm_device *dev, unsigned int pipe)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(dev);
> +
> +   i8xx_disable_vblank(dev, pipe);
> +
> +   if (--dev_priv->i945gm_vblank.enabled == 0)
> +   schedule_work(_priv->i945gm_vblank.work);
> +}
> +
>  static void i965_disable_vblank(struct drm_device *dev, unsigned int pipe)
>  {
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -3228,6 +3249,60 @@ static void gen8_disable_vblank(struct drm_device 
> *dev, unsigned int pipe)
> spin_unlock_irqrestore(_priv->irq_lock, irqflags);
>  }
>  
> +static void i945gm_vblank_work_func(struct work_struct *work)
> +{
> +   struct drm_i915_private *dev_priv =
> +   container_of(work, struct drm_i915_private, 
> i945gm_vblank.work);
> +
> +   /*
> +* Vblank interrupts fail to wake up the device from C3,
> +* hence we want to prevent C3 usage while vblank interrupts
> +* are enabled.
> +*/
> +   pm_qos_update_request(_priv->i945gm_vblank.pm_qos,
> + dev_priv->i945gm_vblank.enabled ?
> + dev_priv->i945gm_vblank.c3_disable_latency :
> + PM_QOS_DEFAULT_VALUE);

Worker is required as the update may block.

I'd prefer that as READ_ONCE(dev_priv->i945gm_vblank.enabled)

> +}
> +
> +static int cstate_disable_latency(const char *name)
> +{
> +   const struct cpuidle_driver *drv;
> +   int i;
> +
> +   drv = cpuidle_get_driver();
> +   if (!drv)
> +   return 0;
> +
> +   for (i = 0; i < drv->state_count; i++) {
> +   const struct cpuidle_state *state = >states[i];
> +
> +   if (!strcmp(state->name, name))
> +   return state->exit_latency ?
> +   state->exit_latency - 1 : 0;
> +   }

Mind if I say yuck?

Will only work with the 

[Intel-gfx] [PATCH] drm/i915: Mark AML 0x87CA as ULX

2019-03-22 Thread Ville Syrjala
From: Ville Syrjälä 

If I'm reading the spec right AML 0x87CA is a Y SKU, so it
should be marked as ULX in our old style terminology.

Cc: sta...@vger.kernel.org
Cc: José Roberto de Souza 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Fixes: c0c46ca461f1 ("drm/i915/aml: Add new Amber Lake PCI ID")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f723b15527f8..428279fd88a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2361,7 +2361,8 @@ static inline unsigned int i915_sg_segment_size(void)
 INTEL_DEVID(dev_priv) == 0x5915 || \
 INTEL_DEVID(dev_priv) == 0x591E)
 #define IS_AML_ULX(dev_priv)   (INTEL_DEVID(dev_priv) == 0x591C || \
-INTEL_DEVID(dev_priv) == 0x87C0)
+INTEL_DEVID(dev_priv) == 0x87C0 || \
+INTEL_DEVID(dev_priv) == 0x87CA)
 #define IS_SKL_GT2(dev_priv)   (IS_SKYLAKE(dev_priv) && \
 INTEL_INFO(dev_priv)->gt == 2)
 #define IS_SKL_GT3(dev_priv)   (IS_SKYLAKE(dev_priv) && \
-- 
2.19.2

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: use previous pll hw readout

2019-03-22 Thread Lucas De Marchi

On Fri, Mar 22, 2019 at 12:50:07PM -0700, Lucas De Marchi wrote:

On Fri, Mar 22, 2019 at 03:09:59PM +0200, Ville Syrjälä wrote:

On Thu, Mar 21, 2019 at 03:02:57PM -0700, Lucas De Marchi wrote:

By the time icl_ddi_clock_get() is called we've just got the hw state
from the pll registers. We don't need to read them again: we can rather
reuse what was cached in the dpll_hw_state.

Signed-off-by: Lucas De Marchi 
---
drivers/gpu/drm/i915/intel_ddi.c | 39 +++-
1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fe52af9fa4aa..0ea5a97dfe9d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1372,26 +1372,20 @@ static int icl_calc_tbt_pll_link(struct 
drm_i915_private *dev_priv,
}
}

-static int icl_calc_mg_pll_link(struct drm_i915_private *dev_priv,
-   enum port port)
+
+static int icl_calc_mg_pll_link(struct intel_dpll_hw_state *state, u32 refclk)


Inconsistent with the cnl variant.



see below




{
-   enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
-   u32 mg_pll_div0, mg_clktop_hsclkctl;
-   u32 m1, m2_int, m2_frac, div1, div2, refclk;
+   u32 m1, m2_int, m2_frac, div1, div2;
u64 tmp;

-   refclk = dev_priv->cdclk.hw.ref;


because this one needs the refclk. If i don't add refclk to the
arguments I need to leave dev_priv there and it will still not be
consistent. What do you suggest?


humn.. I should have checked the other patch again. I thought about
always passing the refclk via argument, but that will make it ugly. I
will add dev_priv back.

Lucas De Marchi



Lucas De Marchi


-
-   mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
-   mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
-
-   m1 = I915_READ(MG_PLL_DIV1(tc_port)) & MG_PLL_DIV1_FBPREDIV_MASK;
-   m2_int = mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
-   m2_frac = (mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
- (mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
+   m1 = state->mg_pll_div1 & MG_PLL_DIV1_FBPREDIV_MASK;
+   m2_int = state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
+   m2_frac = (state->mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
+ (state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
  MG_PLL_DIV0_FBDIV_FRAC_SHIFT : 0;

-   switch (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
+   switch (state->mg_clktop2_hsclkctl &
+   MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
case MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_2:
div1 = 2;
break;
@@ -1405,12 +1399,14 @@ static int icl_calc_mg_pll_link(struct drm_i915_private 
*dev_priv,
div1 = 7;
break;
default:
-   MISSING_CASE(mg_clktop_hsclkctl);
+   MISSING_CASE(state->mg_clktop2_hsclkctl);
return 0;
}

-   div2 = (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
+   div2 = (state->mg_clktop2_hsclkctl &
+   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_SHIFT;
+
/* div2 value of 0 is same as 1 means no div */
if (div2 == 0)
div2 = 1;
@@ -1457,9 +1453,6 @@ static void icl_ddi_clock_get(struct intel_encoder 
*encoder,
struct intel_dpll_hw_state *state;
enum port port = encoder->port;
int link_clock = 0;
-   u32 pll_id;
-
-   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);

/* For DDI ports we always use a shared PLL. */
if (WARN_ON(!pipe_config->shared_dpll))
@@ -1470,10 +1463,14 @@ static void icl_ddi_clock_get(struct intel_encoder 
*encoder,
if (intel_port_is_combophy(dev_priv, port)) {
link_clock = cnl_calc_wrpll_link(dev_priv, state);
} else {
+   enum intel_dpll_id pll_id = intel_get_shared_dpll_id(dev_priv,
+   pipe_config->shared_dpll);
+
if (pll_id == DPLL_ID_ICL_TBTPLL)
link_clock = icl_calc_tbt_pll_link(dev_priv, port);
else
-   link_clock = icl_calc_mg_pll_link(dev_priv, port);
+   link_clock = icl_calc_mg_pll_link(
+   state, dev_priv->cdclk.hw.ref);
}

end:
--
2.20.1


--
Ville Syrjälä
Intel

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

Re: [Intel-gfx] [CI 4/4] drm/i915: Skip modeset for cdclk changes if possible

2019-03-22 Thread Imre Deak
On Thu, Mar 21, 2019 at 02:53:00PM -0700, Clinton Taylor wrote:
> 
> On 3/20/19 6:54 AM, Imre Deak wrote:
> > From: Ville Syrjälä 
> > 
> > If we have only a single active pipe and the cdclk change only requires
> > the cd2x divider to be updated bxt+ can do the update with forcing a full
> > modeset on the pipe. Try to hook that up.
> > 
> > v2:
> > - Wait for vblank after an optimized CDCLK change.
> > - Avoid optimization if the pipe needs a modeset (or was disabled).
> > - Split CDCLK change to a pre/post plane update step.
> > v3:
> > - Use correct version of CDCLK state as old state. (Ville)
> > - Remove unused intel_cdclk_can_skip_modeset()
> > v4:
> > - For consistency call intel_set_cdclk_post_plane_update() only during
> >modesets (and not fastsets).
> > 
> > Signed-off-by: Ville Syrjälä 
> > Signed-off-by: Abhay Kumar 
> > Tested-by: Abhay Kumar 
> > Signed-off-by: Imre Deak 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h  |   3 +-
> >   drivers/gpu/drm/i915/i915_reg.h  |   3 +-
> >   drivers/gpu/drm/i915/intel_cdclk.c   | 142 
> > +++
> >   drivers/gpu/drm/i915/intel_display.c |  42 ++-
> >   drivers/gpu/drm/i915/intel_drv.h |  17 -
> >   5 files changed, 170 insertions(+), 37 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 6b10cee4e77f..d8f91525c94c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -277,7 +277,8 @@ struct drm_i915_display_funcs {
> > void (*get_cdclk)(struct drm_i915_private *dev_priv,
> >   struct intel_cdclk_state *cdclk_state);
> > void (*set_cdclk)(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_state *cdclk_state);
> > + const struct intel_cdclk_state *cdclk_state,
> > + enum pipe pipe);
> > int (*get_fifo_size)(struct drm_i915_private *dev_priv,
> >  enum i9xx_plane_id i9xx_plane);
> > int (*compute_pipe_wm)(struct intel_crtc_state *cstate);
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 9b69cec21f7b..12b8170ced96 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9521,7 +9521,8 @@ enum skl_power_gate {
> >   #define  BXT_CDCLK_CD2X_PIPE(pipe)((pipe) << 20)
> >   #define  CDCLK_DIVMUX_CD_OVERRIDE (1 << 19)
> >   #define  BXT_CDCLK_CD2X_PIPE_NONE BXT_CDCLK_CD2X_PIPE(3)
> > -#define  ICL_CDCLK_CD2X_PIPE_NONE  (7 << 19)
> > +#define  ICL_CDCLK_CD2X_PIPE(pipe) ((pipe) << 19)
> 
> Unfortunately bits 21:19 of CDCLK_CTL don't match the pipe enum. This MACRO
> will not work except for PIPE_A.
> 
> Pipe_A is 0x00, PIPE_B is 0x02, PIPE_C is 0x06.

Good catch.

The pipe B and C encodings could be typoed though and I couldn't trigger
any problems with either encodings (i.e. using either 0x1 or 0x2 for
pipe B updates while pipe B was the only pipe enabled). So I opened a
ticket for this in BSpec, let's wait for a clarification on this.

> In BXT only bits 21:20 were used for CD2X pipe select and the pipe enum does
> work.
> 
> 
> -Clint
> 
> 
> 
> > +#define  ICL_CDCLK_CD2X_PIPE_NONE  ICL_CDCLK_CD2X_PIPE(7)
> >   #define  BXT_CDCLK_SSA_PRECHARGE_ENABLE   (1 << 16)
> >   #define  CDCLK_FREQ_DECIMAL_MASK  (0x7ff)
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 5c25626f8cf0..48cc42a7ef4f 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -516,7 +516,8 @@ static void vlv_program_pfi_credits(struct 
> > drm_i915_private *dev_priv)
> >   }
> >   static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_state *cdclk_state)
> > + const struct intel_cdclk_state *cdclk_state,
> > + enum pipe pipe)
> >   {
> > int cdclk = cdclk_state->cdclk;
> > u32 val, cmd = cdclk_state->voltage_level;
> > @@ -598,7 +599,8 @@ static void vlv_set_cdclk(struct drm_i915_private 
> > *dev_priv,
> >   }
> >   static void chv_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_state *cdclk_state)
> > + const struct intel_cdclk_state *cdclk_state,
> > + enum pipe pipe)
> >   {
> > int cdclk = cdclk_state->cdclk;
> > u32 val, cmd = cdclk_state->voltage_level;
> > @@ -697,7 +699,8 @@ static void bdw_get_cdclk(struct drm_i915_private 
> > *dev_priv,
> >   }
> >   static void bdw_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_state *cdclk_state)
> > + const struct intel_cdclk_state *cdclk_state,
> > + enum pipe pipe)
> >   {
> > int cdclk = cdclk_state->cdclk;
> > u32 val;
> > @@ -987,7 +990,8 @@ static void 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: use previous pll hw readout

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 12:50:07PM -0700, Lucas De Marchi wrote:
> On Fri, Mar 22, 2019 at 03:09:59PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 21, 2019 at 03:02:57PM -0700, Lucas De Marchi wrote:
> >> By the time icl_ddi_clock_get() is called we've just got the hw state
> >> from the pll registers. We don't need to read them again: we can rather
> >> reuse what was cached in the dpll_hw_state.
> >>
> >> Signed-off-by: Lucas De Marchi 
> >> ---
> >>  drivers/gpu/drm/i915/intel_ddi.c | 39 +++-
> >>  1 file changed, 18 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index fe52af9fa4aa..0ea5a97dfe9d 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -1372,26 +1372,20 @@ static int icl_calc_tbt_pll_link(struct 
> >> drm_i915_private *dev_priv,
> >>}
> >>  }
> >>
> >> -static int icl_calc_mg_pll_link(struct drm_i915_private *dev_priv,
> >> -  enum port port)
> >> +
> >> +static int icl_calc_mg_pll_link(struct intel_dpll_hw_state *state, u32 
> >> refclk)
> >
> >Inconsistent with the cnl variant.
> 
> 
> see below
> 
> >
> >>  {
> >> -  enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> >> -  u32 mg_pll_div0, mg_clktop_hsclkctl;
> >> -  u32 m1, m2_int, m2_frac, div1, div2, refclk;
> >> +  u32 m1, m2_int, m2_frac, div1, div2;
> >>u64 tmp;
> >>
> >> -  refclk = dev_priv->cdclk.hw.ref;
> 
> because this one needs the refclk. If i don't add refclk to the
> arguments I need to leave dev_priv there and it will still not be
> consistent. What do you suggest?

Didn't cnl pass in the dev_priv also for this exact same reason?

> 
> Lucas De Marchi
> 
> >> -
> >> -  mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
> >> -  mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
> >> -
> >> -  m1 = I915_READ(MG_PLL_DIV1(tc_port)) & MG_PLL_DIV1_FBPREDIV_MASK;
> >> -  m2_int = mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
> >> -  m2_frac = (mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
> >> -(mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
> >> +  m1 = state->mg_pll_div1 & MG_PLL_DIV1_FBPREDIV_MASK;
> >> +  m2_int = state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
> >> +  m2_frac = (state->mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
> >> +(state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
> >>  MG_PLL_DIV0_FBDIV_FRAC_SHIFT : 0;
> >>
> >> -  switch (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
> >> +  switch (state->mg_clktop2_hsclkctl &
> >> +  MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
> >>case MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_2:
> >>div1 = 2;
> >>break;
> >> @@ -1405,12 +1399,14 @@ static int icl_calc_mg_pll_link(struct 
> >> drm_i915_private *dev_priv,
> >>div1 = 7;
> >>break;
> >>default:
> >> -  MISSING_CASE(mg_clktop_hsclkctl);
> >> +  MISSING_CASE(state->mg_clktop2_hsclkctl);
> >>return 0;
> >>}
> >>
> >> -  div2 = (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
> >> +  div2 = (state->mg_clktop2_hsclkctl &
> >> +  MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
> >>MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_SHIFT;
> >> +
> >>/* div2 value of 0 is same as 1 means no div */
> >>if (div2 == 0)
> >>div2 = 1;
> >> @@ -1457,9 +1453,6 @@ static void icl_ddi_clock_get(struct intel_encoder 
> >> *encoder,
> >>struct intel_dpll_hw_state *state;
> >>enum port port = encoder->port;
> >>int link_clock = 0;
> >> -  u32 pll_id;
> >> -
> >> -  pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> >>
> >>/* For DDI ports we always use a shared PLL. */
> >>if (WARN_ON(!pipe_config->shared_dpll))
> >> @@ -1470,10 +1463,14 @@ static void icl_ddi_clock_get(struct intel_encoder 
> >> *encoder,
> >>if (intel_port_is_combophy(dev_priv, port)) {
> >>link_clock = cnl_calc_wrpll_link(dev_priv, state);
> >>} else {
> >> +  enum intel_dpll_id pll_id = intel_get_shared_dpll_id(dev_priv,
> >> +  pipe_config->shared_dpll);
> >> +
> >>if (pll_id == DPLL_ID_ICL_TBTPLL)
> >>link_clock = icl_calc_tbt_pll_link(dev_priv, port);
> >>else
> >> -  link_clock = icl_calc_mg_pll_link(dev_priv, port);
> >> +  link_clock = icl_calc_mg_pll_link(
> >> +  state, dev_priv->cdclk.hw.ref);
> >>}
> >>
> >>  end:
> >> --
> >> 2.20.1
> >
> >-- 
> >Ville Syrjälä
> >Intel

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Disable C3 when enabling vblank interrupts on i945gm

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Disable C3 when enabling vblank 
interrupts on i945gm
URL   : https://patchwork.freedesktop.org/series/58427/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5796 -> Patchwork_12579


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   PASS -> DMESG-WARN [fdo#108965]

  * igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_exec_basic@readonly-bsd1:
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] +57

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@i915_selftest@live_uncore:
- fi-ivb-3770:PASS -> DMESG-FAIL [fdo#110210]

  * igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  PASS -> FAIL [fdo#103167]

  
 Possible fixes 

  * igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm:  DMESG-FAIL -> PASS

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   DMESG-WARN [fdo#107709] -> PASS

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#110210]: https://bugs.freedesktop.org/show_bug.cgi?id=110210


Participating hosts (40 -> 35)
--

  Additional (2): fi-bwr-2160 fi-snb-2520m 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5796 -> Patchwork_12579

  CI_DRM_5796: 2165d3631bdb91a7b80110b1f76633a19666d0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4899: ba96339c238180b38d05d7fa2dca772d49eee332 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12579: 096380bc0b9ba1e91b43b2b5ec713e0fb28cbd93 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

096380bc0b9b drm/i915: Use vblank_disable_immediate on gen2
f7715f80c822 drm/i915: Disable C3 when enabling vblank interrupts on i945gm

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12579/
___
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/2] drm/i915: Disable C3 when enabling vblank interrupts on i945gm

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Disable C3 when enabling vblank 
interrupts on i945gm
URL   : https://patchwork.freedesktop.org/series/58427/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Disable C3 when enabling vblank interrupts on i945gm
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3575:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3583:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Use vblank_disable_immediate on gen2
Okay!

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: use previous pll hw readout

2019-03-22 Thread Lucas De Marchi

On Fri, Mar 22, 2019 at 03:09:59PM +0200, Ville Syrjälä wrote:

On Thu, Mar 21, 2019 at 03:02:57PM -0700, Lucas De Marchi wrote:

By the time icl_ddi_clock_get() is called we've just got the hw state
from the pll registers. We don't need to read them again: we can rather
reuse what was cached in the dpll_hw_state.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_ddi.c | 39 +++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fe52af9fa4aa..0ea5a97dfe9d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1372,26 +1372,20 @@ static int icl_calc_tbt_pll_link(struct 
drm_i915_private *dev_priv,
}
 }

-static int icl_calc_mg_pll_link(struct drm_i915_private *dev_priv,
-   enum port port)
+
+static int icl_calc_mg_pll_link(struct intel_dpll_hw_state *state, u32 refclk)


Inconsistent with the cnl variant.



see below




 {
-   enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
-   u32 mg_pll_div0, mg_clktop_hsclkctl;
-   u32 m1, m2_int, m2_frac, div1, div2, refclk;
+   u32 m1, m2_int, m2_frac, div1, div2;
u64 tmp;

-   refclk = dev_priv->cdclk.hw.ref;


because this one needs the refclk. If i don't add refclk to the
arguments I need to leave dev_priv there and it will still not be
consistent. What do you suggest?

Lucas De Marchi


-
-   mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
-   mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
-
-   m1 = I915_READ(MG_PLL_DIV1(tc_port)) & MG_PLL_DIV1_FBPREDIV_MASK;
-   m2_int = mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
-   m2_frac = (mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
- (mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
+   m1 = state->mg_pll_div1 & MG_PLL_DIV1_FBPREDIV_MASK;
+   m2_int = state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
+   m2_frac = (state->mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
+ (state->mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
  MG_PLL_DIV0_FBDIV_FRAC_SHIFT : 0;

-   switch (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
+   switch (state->mg_clktop2_hsclkctl &
+   MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK) {
case MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_2:
div1 = 2;
break;
@@ -1405,12 +1399,14 @@ static int icl_calc_mg_pll_link(struct drm_i915_private 
*dev_priv,
div1 = 7;
break;
default:
-   MISSING_CASE(mg_clktop_hsclkctl);
+   MISSING_CASE(state->mg_clktop2_hsclkctl);
return 0;
}

-   div2 = (mg_clktop_hsclkctl & MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
+   div2 = (state->mg_clktop2_hsclkctl &
+   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK) >>
MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_SHIFT;
+
/* div2 value of 0 is same as 1 means no div */
if (div2 == 0)
div2 = 1;
@@ -1457,9 +1453,6 @@ static void icl_ddi_clock_get(struct intel_encoder 
*encoder,
struct intel_dpll_hw_state *state;
enum port port = encoder->port;
int link_clock = 0;
-   u32 pll_id;
-
-   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);

/* For DDI ports we always use a shared PLL. */
if (WARN_ON(!pipe_config->shared_dpll))
@@ -1470,10 +1463,14 @@ static void icl_ddi_clock_get(struct intel_encoder 
*encoder,
if (intel_port_is_combophy(dev_priv, port)) {
link_clock = cnl_calc_wrpll_link(dev_priv, state);
} else {
+   enum intel_dpll_id pll_id = intel_get_shared_dpll_id(dev_priv,
+   pipe_config->shared_dpll);
+
if (pll_id == DPLL_ID_ICL_TBTPLL)
link_clock = icl_calc_tbt_pll_link(dev_priv, port);
else
-   link_clock = icl_calc_mg_pll_link(dev_priv, port);
+   link_clock = icl_calc_mg_pll_link(
+   state, dev_priv->cdclk.hw.ref);
}

 end:
--
2.20.1


--
Ville Syrjälä
Intel

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

Re: [Intel-gfx] RMW considered harmful (was: Re: [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports)

2019-03-22 Thread Manasi Navare
On Fri, Mar 22, 2019 at 09:28:01PM +0200, Jani Nikula wrote:
> On Fri, 22 Mar 2019, Ville Syrjälä  wrote:
> > On Fri, Mar 22, 2019 at 11:44:21AM -0700, Manasi Navare wrote:
> >> On Fri, Mar 22, 2019 at 08:09:50PM +0200, Ville Syrjälä wrote:
> >> > In that case there is no point in doing a rmw.
> >> 
> >> But isnt it always a good idea to do rmw? I mean what if the master
> >> select was set to something else earlier?
> >
> > RMW is the root of many evils. It should be avoided unless there is a
> > really compelling reason to use it.
> 
> Hear, hear!
> 
> We have the software state that we want to write to the hardware. If we
> use RMW to do this, it might all work by coincidence due to the old
> values in the registers, or it might just as well break by coincidence
> due to some garbage in the registers.
> 
> In most cases, there should only be one place that writes a particular
> display register during modeset. Sometimes this isn't possible, and RMW
> is required.
> 
> Some registers also have reserved bits potentially used by the hardware
> that must not be changed, and RMW is required. These are documented in
> bspec.
> 
> BR,
> Jani.
>

Thanks for the explanation. It does make sense now that we are doing a full
modeset, we should just be then writing the value directly?
The only concern I have is that say DSI code sets this somewhere els ein the 
modeset path,
then we would need to modify this to do RMW or always make sure DSI also
uses the same function for writing to this reg.
What do you suggest doing now?

Manasi
 
> 
> -- 
> 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: failure for drm/i915: stop storing the media fuse

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915: stop storing the media fuse
URL   : https://patchwork.freedesktop.org/series/58387/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12564_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12564_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12564_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_12564_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_atomic_transition@plane-toggle-modeset-transition:
- shard-iclb: PASS -> INCOMPLETE +1

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +150

  * igt@gem_pwrite@stolen-normal:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@gem_stolen@stolen-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +2

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107807]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_chamelium@hdmi-hpd-storm:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  PASS -> FAIL [fdo#105363]

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-apl:  PASS -> FAIL [fdo#102887] / [fdo#105363]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbc-indfb-scaledprimary:
- shard-iclb: PASS -> FAIL [fdo#103167] +6

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-iclb: PASS -> FAIL [fdo#103167] / [fdo#105682]

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt:
- shard-iclb: PASS -> FAIL [fdo#109247] +26

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +28

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +14

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +3

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_psr@primary_mmap_cpu:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +4

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: PASS -> SKIP [fdo#109441] +5

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-apl:  PASS -> FAIL [fdo#104894] +2

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-iclb: PASS -> FAIL [fdo#104894]

  * igt@perf@unprivileged-single-ctx-counters:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  
 Possible fixes 

  * igt@gem_tiled_pread_pwrite:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS

  * 

[Intel-gfx] RMW considered harmful (was: Re: [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports)

2019-03-22 Thread Jani Nikula
On Fri, 22 Mar 2019, Ville Syrjälä  wrote:
> On Fri, Mar 22, 2019 at 11:44:21AM -0700, Manasi Navare wrote:
>> On Fri, Mar 22, 2019 at 08:09:50PM +0200, Ville Syrjälä wrote:
>> > In that case there is no point in doing a rmw.
>> 
>> But isnt it always a good idea to do rmw? I mean what if the master
>> select was set to something else earlier?
>
> RMW is the root of many evils. It should be avoided unless there is a
> really compelling reason to use it.

Hear, hear!

We have the software state that we want to write to the hardware. If we
use RMW to do this, it might all work by coincidence due to the old
values in the registers, or it might just as well break by coincidence
due to some garbage in the registers.

In most cases, there should only be one place that writes a particular
display register during modeset. Sometimes this isn't possible, and RMW
is required.

Some registers also have reserved bits potentially used by the hardware
that must not be changed, and RMW is required. These are documented in
bspec.

BR,
Jani.


-- 
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.BAT: success for series starting with [CI,1/6] drm/i915/ehl: Add EHL platform info and PCI IDs

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/6] drm/i915/ehl: Add EHL platform info and 
PCI IDs
URL   : https://patchwork.freedesktop.org/series/58425/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5796 -> Patchwork_12578


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_uncore:
- fi-ivb-3770:PASS -> DMESG-FAIL [fdo#110210]

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  PASS -> FAIL [fdo#103167]

  
 Possible fixes 

  * igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm:  DMESG-FAIL -> PASS
- fi-bdw-gvtdvm:  DMESG-FAIL -> PASS

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


Participating hosts (40 -> 31)
--

  Missing(9): fi-hsw-4770r fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-bsw-kefka fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5796 -> Patchwork_12578

  CI_DRM_5796: 2165d3631bdb91a7b80110b1f76633a19666d0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4899: ba96339c238180b38d05d7fa2dca772d49eee332 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12578: 0e3c093323649e5ea523b609f38155ee0728d61b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0e3c09332364 drm/i915/ehl: Add Support for DMC on EHL
5ea686e180be drm/i915/ehl: Set proper eu slice/subslice parameters for EHL
9e7a5fbe8211 drm/i915/ehl: EHL outputs are different from ICL
1219fe0a83ce drm/i915/ehl: Add dpll mgr
468627082ba5 drm/i915/ehl: Add ElkhartLake platform
53f2a89ae9a7 drm/i915/ehl: Add EHL platform info and PCI IDs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12578/
___
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 [CI,1/6] drm/i915/ehl: Add EHL platform info and PCI IDs

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/6] drm/i915/ehl: Add EHL platform info and 
PCI IDs
URL   : https://patchwork.freedesktop.org/series/58425/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/ehl: Add EHL platform info and PCI IDs
Okay!

Commit: drm/i915/ehl: Add ElkhartLake platform
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3575:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3576:16: warning: expression 
using sizeof(void)

Commit: drm/i915/ehl: Add dpll mgr
Okay!

Commit: drm/i915/ehl: EHL outputs are different from ICL
Okay!

Commit: drm/i915/ehl: Set proper eu slice/subslice parameters for EHL
Okay!

Commit: drm/i915/ehl: Add Support for DMC on EHL
Okay!

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

Re: [Intel-gfx] [PATCH i-g-t 22/24] i915: Add gem_ctx_engines

2019-03-22 Thread Andi Shyti
Hi Chris,

sorry for the late reply, I got 5 version of this same patch and
I couldn't figure out what was what :)

Could you please add some versioning or note if version is
the same?

Some nits and questions

> +static bool has_context_engines(int i915)
> +{
> + struct drm_i915_gem_context_param param = {
> + .ctx_id = 0,
> + .param = I915_CONTEXT_PARAM_ENGINES,
> + };
> + return __gem_context_set_param(i915, ) == 0;
> +}

I had it and removed it so many times in gem_engine_topology,
shall I put it back and we take it from there? (maybe in the
future).

[...]
> + igt_assert_eq(__gem_context_set_param(i915, ), -ENOENT);
> +
> + mprotect(engines, 4096, PROT_READ);

(from the last review) mprotect can fail, do we care?

[...]
> + engines->extensions = 0;
> + igt_assert_eq(__gem_context_set_param(i915, ), 0);
> +
> + param.value = to_user_pointer(engines - 1);
> + igt_assert_eq(__gem_context_set_param(i915, ), -EFAULT);
> +
> + param.value = to_user_pointer(engines) - 1;
> + igt_assert_eq(__gem_context_set_param(i915, ), -EFAULT);
> +
> + param.value = to_user_pointer(engines) - param.size +  1;
  ^
just a blank more than necessary

> + idx = 0;
> + memset(, 0, sizeof(engines));
> + for_each_engine_class_instance(i915, e) {
> + engines.class_instance[idx].engine_class = e->class;
> + engines.class_instance[idx].engine_instance = e->instance;
> + idx++;
> + }
> + idx *= sizeof(*engines.class_instance);
> + p.size = base + idx;

(I normally review from bottom to top) You used at least three
different ways to calculate param's size (some unclear to who
is new to igt some more clear).

Does it make sense to have a global define and we keep it
consistent?

 p.size = SIZEOF_CTX_PARAM(idx);

it's a piece of code that I think it will be ussed a lot.

> + /* Unadulterated I915_EXEC_DEFAULT should work */
> + execbuf.flags = 0;
> + igt_assert_eq(__gem_execbuf(i915, ), 0);

why aren't you using simply gem_execbuf()?

> + execbuf.flags = j;
> + err =__gem_execbuf(i915, );
> + if (j == i) {
> + igt_assert_f(err == 0,
> +  "Failed to report the 
> valid engine for slot %d\n",
> +  i);
> + } else {
> + igt_assert_f(err == -EINVAL,
> +  "Failed to report an 
> invalid engine for slot %d (valid at %d)\n",
> +  j, i);
> + }
> + }
> +
> + do_ioctl(i915, DRM_IOCTL_I915_GEM_BUSY, );
> + if (i != -1) {
> + igt_assert_eq(busy.busy, 1 << (e->class + 16));
> + } else {
> + igt_assert_eq(busy.busy, 0);
> + }
> +

(from the last review) this is not kernel style, not that I care
much, but I thought you did.

You can add Reviewed-by: Andi Shyti 

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/6] drm/i915/ehl: Add EHL platform info and PCI IDs

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/6] drm/i915/ehl: Add EHL platform info and 
PCI IDs
URL   : https://patchwork.freedesktop.org/series/58425/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
53f2a89ae9a7 drm/i915/ehl: Add EHL platform info and PCI IDs
-:63: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#63: FILE: include/drm/i915_pciids.h:502:
+#define INTEL_EHL_IDS(info) \
+   INTEL_VGA_DEVICE(0x4500, info), \
+   INTEL_VGA_DEVICE(0x4571, info), \
+   INTEL_VGA_DEVICE(0x4551, info), \
+   INTEL_VGA_DEVICE(0x4541, info)

-:63: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible 
side-effects?
#63: FILE: include/drm/i915_pciids.h:502:
+#define INTEL_EHL_IDS(info) \
+   INTEL_VGA_DEVICE(0x4500, info), \
+   INTEL_VGA_DEVICE(0x4571, info), \
+   INTEL_VGA_DEVICE(0x4551, info), \
+   INTEL_VGA_DEVICE(0x4541, info)

total: 1 errors, 0 warnings, 1 checks, 32 lines checked
468627082ba5 drm/i915/ehl: Add ElkhartLake platform
1219fe0a83ce drm/i915/ehl: Add dpll mgr
-:17: WARNING:BAD_SIGN_OFF: Duplicate signature
#17: 
Signed-off-by: Rodrigo Vivi 

total: 0 errors, 1 warnings, 0 checks, 28 lines checked
9e7a5fbe8211 drm/i915/ehl: EHL outputs are different from ICL
5ea686e180be drm/i915/ehl: Set proper eu slice/subslice parameters for EHL
0e3c09332364 drm/i915/ehl: Add Support for DMC on EHL

___
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/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED
URL   : https://patchwork.freedesktop.org/series/58424/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5796 -> Patchwork_12577


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_exec_basic@readonly-bsd1:
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] +57

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u2:  PASS -> INCOMPLETE [fdo#108569]
- fi-skl-iommu:   PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]

  * igt@i915_selftest@live_uncore:
- fi-ivb-3770:PASS -> DMESG-FAIL [fdo#110210]

  * igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  PASS -> FAIL [fdo#103167]
- fi-icl-u2:  PASS -> FAIL [fdo#103167]

  * igt@runner@aborted:
- fi-skl-iommu:   NOTRUN -> FAIL [fdo#104108] / [fdo#108602]

  
 Possible fixes 

  * igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm:  DMESG-FAIL -> PASS

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   DMESG-WARN [fdo#107709] -> PASS

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
  [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#110210]: https://bugs.freedesktop.org/show_bug.cgi?id=110210


Participating hosts (40 -> 34)
--

  Additional (2): fi-bwr-2160 fi-snb-2520m 
  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-blb-e6850 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5796 -> Patchwork_12577

  CI_DRM_5796: 2165d3631bdb91a7b80110b1f76633a19666d0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4899: ba96339c238180b38d05d7fa2dca772d49eee332 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12577: 43521ec74d9d1fc7b1b61b8ec723de95b33b6ab0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

43521ec74d9d drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 11:44:21AM -0700, Manasi Navare wrote:
> On Fri, Mar 22, 2019 at 08:09:50PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 22, 2019 at 10:58:01AM -0700, Manasi Navare wrote:
> > > On Fri, Mar 22, 2019 at 03:16:03PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Mar 22, 2019 at 11:34:25AM +0200, Jani Nikula wrote:
> > > > > On Thu, 21 Mar 2019, Manasi Navare  wrote:
> > > > > > In case of tiled displays where different tiles are displayed across
> > > > > > different ports, we need to synchronize the transcoders involved.
> > > > > > This patch implements the transcoder port sync feature for
> > > > > > synchronizing one master transcoder with one or more slave
> > > > > > transcoders. This is only enbaled in slave transcoder
> > > > > > and the master transcoder is unaware that it is operating
> > > > > > in this mode.
> > > > > > This has been tested with tiled display connected to ICL.
> > > > > >
> > > > > > Cc: Daniel Vetter 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Cc: Maarten Lankhorst 
> > > > > > Cc: Matt Roper 
> > > > > > Cc: Jani Nikula 
> > > > > > Signed-off-by: Manasi Navare 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_display.c | 59 
> > > > > > 
> > > > > >  1 file changed, 59 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > > index 9980a4ed8c9c..16b46a3cb3bd 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > > @@ -4009,6 +4009,62 @@ static void icl_set_pipe_chicken(struct 
> > > > > > intel_crtc *crtc)
> > > > > > I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> > > > > >  }
> > > > > >  
> > > > > > +static void icl_set_transcoder_port_sync(struct intel_atomic_state 
> > > > > > *old_intel_state,
> > > > > > +const struct intel_crtc_state 
> > > > > > *crtc_state)
> > > > > > +{
> > > > > > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > > > > > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > > > +   struct intel_crtc_state *genlock_crtc_state = NULL;
> > > > > > +   enum transcoder genlock_transcoder;
> > > > > > +   u32 trans_ddi_func_ctl2_val;
> > > > > > +   u8 master_select;
> > > > > > +
> > > > > > +   /*
> > > > > > +* Port Sync Mode cannot be enabled for DP MST
> > > > > > +*/
> > > > > > +   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > > > > > +   return;
> > > > > > +
> > > > > > +   /*
> > > > > > +* Configure the master select and enable Transcoder Port Sync 
> > > > > > for
> > > > > > +* Slave CRTCs transcoder.
> > > > > > +*/
> > > > > > +   if (!crtc_state->genlock_crtc)
> > > > > > +   return;
> > > > > > +
> > > > > > +   genlock_crtc_state = 
> > > > > > intel_atomic_get_new_crtc_state(old_intel_state,
> > > > > > +
> > > > > > crtc_state->genlock_crtc);
> > > > > > +   if (WARN_ON(!genlock_crtc_state))
> > > > > > +   return;
> > > > > > +
> > > > > > +   genlock_transcoder = genlock_crtc_state->cpu_transcoder;
> > > > > > +   switch (genlock_transcoder) {
> > > > > > +   case TRANSCODER_A:
> > > > > > +   master_select = 1;
> > > > > > +   break;
> > > > > > +   case TRANSCODER_B:
> > > > > > +   master_select = 2;
> > > > > > +   break;
> > > > > > +   case TRANSCODER_C:
> > > > > > +   master_select = 3;
> > > > > > +   break;
> > > > > > +   case TRANSCODER_EDP:
> > > > > > +   default:
> > > > > > +   master_select = 0;
> > > > > > +   break;
> > > > > > +   }
> > > > > > +   /* Set the master select bits for Tranascoder Port Sync */
> > > > > > +   trans_ddi_func_ctl2_val = 
> > > > > > I915_READ(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder));
> > > > > > +   trans_ddi_func_ctl2_val |= 
> > > > > > (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> > > > > > +   PORT_SYNC_MODE_MASTER_SELECT_MASK) 
> > > > > > <<
> > > > > > +   PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> > > > > 
> > > > > This doesn't do what you think it does. ITYM,
> > > > > 
> > > > >   val = I915_READ();
> > > > > val &= ~FOO_MASK;
> > > > > val |= FOO_BAR;
> > > > 
> > > > Also we alreayd have a place where we write this registers. Is there
> > > > some magic requirement why these bits can't be set there along with
> > > > eveyrthing else?
> > > 
> > > We only write the bits of TRANS_DDI_FUNC_CTL currently but these bits
> > > are written to TRANS_DDI_FUNC_CTL2 and need to be written before enabling
> > > the transcoder.
> > > Thats why I created this separate function here to set the bits in 
> > > TRANS_DDI_FUNC_CTL2
> > 
> > In that case there is no point in doing a rmw.
> 
> But isnt it always a good idea to do rmw? I mean what if the master select 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports

2019-03-22 Thread Manasi Navare
On Fri, Mar 22, 2019 at 08:09:50PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 22, 2019 at 10:58:01AM -0700, Manasi Navare wrote:
> > On Fri, Mar 22, 2019 at 03:16:03PM +0200, Ville Syrjälä wrote:
> > > On Fri, Mar 22, 2019 at 11:34:25AM +0200, Jani Nikula wrote:
> > > > On Thu, 21 Mar 2019, Manasi Navare  wrote:
> > > > > In case of tiled displays where different tiles are displayed across
> > > > > different ports, we need to synchronize the transcoders involved.
> > > > > This patch implements the transcoder port sync feature for
> > > > > synchronizing one master transcoder with one or more slave
> > > > > transcoders. This is only enbaled in slave transcoder
> > > > > and the master transcoder is unaware that it is operating
> > > > > in this mode.
> > > > > This has been tested with tiled display connected to ICL.
> > > > >
> > > > > Cc: Daniel Vetter 
> > > > > Cc: Ville Syrjälä 
> > > > > Cc: Maarten Lankhorst 
> > > > > Cc: Matt Roper 
> > > > > Cc: Jani Nikula 
> > > > > Signed-off-by: Manasi Navare 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_display.c | 59 
> > > > > 
> > > > >  1 file changed, 59 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 9980a4ed8c9c..16b46a3cb3bd 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -4009,6 +4009,62 @@ static void icl_set_pipe_chicken(struct 
> > > > > intel_crtc *crtc)
> > > > >   I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> > > > >  }
> > > > >  
> > > > > +static void icl_set_transcoder_port_sync(struct intel_atomic_state 
> > > > > *old_intel_state,
> > > > > +  const struct intel_crtc_state 
> > > > > *crtc_state)
> > > > > +{
> > > > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > > > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > > + struct intel_crtc_state *genlock_crtc_state = NULL;
> > > > > + enum transcoder genlock_transcoder;
> > > > > + u32 trans_ddi_func_ctl2_val;
> > > > > + u8 master_select;
> > > > > +
> > > > > + /*
> > > > > +  * Port Sync Mode cannot be enabled for DP MST
> > > > > +  */
> > > > > + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > > > > + return;
> > > > > +
> > > > > + /*
> > > > > +  * Configure the master select and enable Transcoder Port Sync 
> > > > > for
> > > > > +  * Slave CRTCs transcoder.
> > > > > +  */
> > > > > + if (!crtc_state->genlock_crtc)
> > > > > + return;
> > > > > +
> > > > > + genlock_crtc_state = 
> > > > > intel_atomic_get_new_crtc_state(old_intel_state,
> > > > > +  
> > > > > crtc_state->genlock_crtc);
> > > > > + if (WARN_ON(!genlock_crtc_state))
> > > > > + return;
> > > > > +
> > > > > + genlock_transcoder = genlock_crtc_state->cpu_transcoder;
> > > > > + switch (genlock_transcoder) {
> > > > > + case TRANSCODER_A:
> > > > > + master_select = 1;
> > > > > + break;
> > > > > + case TRANSCODER_B:
> > > > > + master_select = 2;
> > > > > + break;
> > > > > + case TRANSCODER_C:
> > > > > + master_select = 3;
> > > > > + break;
> > > > > + case TRANSCODER_EDP:
> > > > > + default:
> > > > > + master_select = 0;
> > > > > + break;
> > > > > + }
> > > > > + /* Set the master select bits for Tranascoder Port Sync */
> > > > > + trans_ddi_func_ctl2_val = 
> > > > > I915_READ(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder));
> > > > > + trans_ddi_func_ctl2_val |= 
> > > > > (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> > > > > + PORT_SYNC_MODE_MASTER_SELECT_MASK) 
> > > > > <<
> > > > > + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> > > > 
> > > > This doesn't do what you think it does. ITYM,
> > > > 
> > > > val = I915_READ();
> > > > val &= ~FOO_MASK;
> > > > val |= FOO_BAR;
> > > 
> > > Also we alreayd have a place where we write this registers. Is there
> > > some magic requirement why these bits can't be set there along with
> > > eveyrthing else?
> > 
> > We only write the bits of TRANS_DDI_FUNC_CTL currently but these bits
> > are written to TRANS_DDI_FUNC_CTL2 and need to be written before enabling
> > the transcoder.
> > Thats why I created this separate function here to set the bits in 
> > TRANS_DDI_FUNC_CTL2
> 
> In that case there is no point in doing a rmw.

But isnt it always a good idea to do rmw? I mean what if the master select was 
set to something else
earlier?

Also could you look at the patch 1 of this series that assigns the genlock crtc 
pointer?

Manasi

> 
> -- 
> Ville Syrjälä
> Intel

[Intel-gfx] ✗ Fi.CI.IGT: failure for Do not re-read dpll registers

2019-03-22 Thread Patchwork
== Series Details ==

Series: Do not re-read dpll registers
URL   : https://patchwork.freedesktop.org/series/58382/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12562_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12562_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12562_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_12562_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_blt@cold-min:
- shard-iclb: PASS -> INCOMPLETE +1

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +120

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276]

  * igt@i915_pm_rpm@basic-pci-d3-state:
- shard-skl:  PASS -> INCOMPLETE [fdo#107807]

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107807]

  * igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]

  * igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-iclb: PASS -> FAIL [fdo#103355]

  * igt@kms_cursor_legacy@pipe-c-single-bo:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +19

  * igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  PASS -> FAIL [fdo#102887] / [fdo#105363]

  * igt@kms_flip_tiling@flip-x-tiled:
- shard-iclb: PASS -> FAIL [fdo#108303]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#108040]

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#103841] / 
[fdo#105079] / [fdo#105602]

  * igt@kms_frontbuffer_tracking@fbc-tilingchange:
- shard-iclb: PASS -> FAIL [fdo#103167] +6

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-rte:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247]

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +28

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +8
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen:
- shard-iclb: PASS -> FAIL [fdo#109247] +22

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@psr2_basic:
- shard-iclb: PASS -> SKIP [fdo#109441] +4

  * igt@kms_psr@sprite_mmap_gtt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> INCOMPLETE [fdo#103665]

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  PASS -> DMESG-FAIL [fdo#105763]

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Replace preempt_client lookup with engine->preempt_context

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: Replace preempt_client lookup with engine->preempt_context
URL   : https://patchwork.freedesktop.org/series/58422/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5796 -> Patchwork_12576


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_exec_basic@readonly-bsd1:
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] +57

  * igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  PASS -> FAIL [fdo#103167]

  
 Possible fixes 

  * igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm:  DMESG-FAIL -> PASS

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   DMESG-WARN [fdo#107709] -> PASS

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720


Participating hosts (40 -> 36)
--

  Additional (2): fi-bwr-2160 fi-snb-2520m 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus 


Build changes
-

* Linux: CI_DRM_5796 -> Patchwork_12576

  CI_DRM_5796: 2165d3631bdb91a7b80110b1f76633a19666d0f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4899: ba96339c238180b38d05d7fa2dca772d49eee332 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12576: ea79030ce533e6fb1b4f2560f17e46778af1298a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ea79030ce533 drm/i915/guc: Replace preempt_client lookup with 
engine->preempt_context

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12576/
___
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: set vdbox/vebox enable masks on all gens

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915: set vdbox/vebox enable masks on all gens
URL   : https://patchwork.freedesktop.org/series/58381/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12561_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries_display_off:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108]

  * igt@gem_eio@suspend:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / 
[fdo#105079] / [fdo#105602]

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +142

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276]

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +11

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_color@pipe-a-legacy-gamma:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +20

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-iclb: PASS -> FAIL [fdo#103355]

  * igt@kms_flip@2x-flip-vs-suspend-interruptible:
- shard-glk:  PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103313] / [fdo#103558] / 
[fdo#105602] +5

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-iclb: PASS -> FAIL [fdo#103167] / [fdo#105682]
- shard-kbl:  PASS -> DMESG-WARN [fdo#103313] / [fdo#103558]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#108040]

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#109247] +33

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +28

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +8
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@primary_page_flip:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2

  * igt@kms_psr@psr2_basic:
- shard-iclb: PASS -> SKIP [fdo#109441] +2

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> INCOMPLETE [fdo#103665]

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  PASS -> DMESG-FAIL [fdo#105763]

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  
 Possible fixes 

  * igt@gem_tiled_pread_pwrite:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> PASS

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-skl:  INCOMPLETE [fdo#107807] -> PASS

  * igt@i915_suspend@fence-restore-untiled:
- shard-apl:  DMESG-WARN [fdo#108566] -> PASS +1

  * 

Re: [Intel-gfx] [PATCH] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

2019-03-22 Thread Jani Nikula
On Fri, 22 Mar 2019, Ville Syrjala  wrote:
> From: Ville Syrjälä 
>
> Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
> Its counterpart in f86EdidModes.c is properly hooked up but somehow
> that functionality was lost when it was copied into the kernel.
>
> The concensus seems to be that this quirk is a bit misguided
> anyway so let's nuke the leftovers.
>
> For posterity here are some links to known cases:
> * Proview AY765C
>   https://bugs.freedesktop.org/show_bug.cgi?id=15160
> * Unknown Acer
>   https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
>   reference from xf86EdidModes.c)
> * Peacock Ergovision 19 (only in xf86EdidModes.c)
>   https://bugzilla.redhat.com/show_bug.cgi?id=492359
> * Philips 107p5 CRT
>   "Reported on xorg@ with pastebin", didn't find the mail(s)
>
> Cc: Adam Jackson 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/drm_edid.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fa39592ebc0a..2c22ea446075 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -68,8 +68,6 @@
>   * maximum size and use that.
>   */
>  #define EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE (1 << 4)
> -/* Monitor forgot to set the first detailed is preferred bit. */
> -#define EDID_QUIRK_FIRST_DETAILED_PREFERRED  (1 << 5)
>  /* use +hsync +vsync for detailed mode */
>  #define EDID_QUIRK_DETAILED_SYNC_PP  (1 << 6)
>  /* Force reduced-blanking timings for detailed modes */
> @@ -107,8 +105,6 @@ static const struct edid_quirk {
>   { "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
>   /* Acer F51 */
>   { "API", 0x7602, EDID_QUIRK_PREFER_LARGE_60 },
> - /* Unknown Acer */
> - { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>  
>   /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
>   { "AEO", 0, EDID_QUIRK_FORCE_6BPC },
> @@ -145,12 +141,6 @@ static const struct edid_quirk {
>   { "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
>   { "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
>  
> - /* Philips 107p5 CRT */
> - { "PHL", 57364, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> -
> - /* Proview AY765C */
> - { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
> -
>   /* Samsung SyncMaster 205BW.  Note: irony */
>   { "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
>   /* Samsung SyncMaster 22[5-6]BW */

-- 
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 drm/i915/icl: Fix clockgating issue when using scalars (rev3)

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915/icl: Fix clockgating issue when using scalars (rev3)
URL   : https://patchwork.freedesktop.org/series/58081/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12560_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_media_vme:
- shard-apl:  PASS -> FAIL [fdo#109612]

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +121

  * igt@gem_pwrite@stolen-normal:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@gem_stolen@stolen-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +2

  * igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_chamelium@hdmi-hpd-storm:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-iclb: PASS -> FAIL [fdo#103355]

  * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_draw_crc@draw-method-xrgb-pwrite-untiled:
- shard-snb:  PASS -> SKIP [fdo#109271] +2

  * igt@kms_flip@flip-vs-suspend:
- shard-skl:  NOTRUN -> INCOMPLETE [fdo#109507]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
- shard-iclb: PASS -> FAIL [fdo#103167] +3

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +20

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-iclb: PASS -> FAIL [fdo#109247] +19

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@cursor_blt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: PASS -> SKIP [fdo#109441] +6

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  PASS -> DMESG-FAIL [fdo#105763]

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_vblank@pipe-a-ts-continuation-idle-hang:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-apl:  PASS -> FAIL [fdo#104894]

  * igt@perf@unprivileged-single-ctx-counters:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  
 Possible fixes 

  * igt@gem_mmap_gtt@hang:
- shard-iclb: FAIL [fdo#109677] -> PASS

  * igt@gem_tiled_pread_pwrite:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: DMESG-WARN [fdo#108686] -> PASS

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> PASS

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-skl:  INCOMPLETE [fdo#107807] -> PASS

  * igt@i915_suspend@fence-restore-untiled:
- shard-apl:  DMESG-WARN [fdo#108566] -> PASS +1

  * 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: GuC suspend path cleanup (rev2)

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915/guc: GuC suspend path cleanup (rev2)
URL   : https://patchwork.freedesktop.org/series/58370/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12558_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +1

  * igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-iclb: PASS -> INCOMPLETE [fdo#109801]

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +117

  * igt@gem_pwrite@stolen-normal:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@gem_stolen@stolen-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@gem_tiled_fence_blits@normal:
- shard-iclb: PASS -> TIMEOUT [fdo#109673]

  * igt@i915_pm_rpm@drm-resources-equal:
- shard-skl:  PASS -> INCOMPLETE [fdo#107807]

  * igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]

  * igt@i915_suspend@sysfs-reader:
- shard-kbl:  PASS -> INCOMPLETE [fdo#103665]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_chamelium@hdmi-hpd-storm:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-iclb: PASS -> FAIL [fdo#103355]

  * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]

  * igt@kms_flip@flip-vs-suspend:
- shard-skl:  NOTRUN -> INCOMPLETE [fdo#109507]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +6

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +28

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +1

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +2

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#109247] +21

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +3

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@psr2_cursor_blt:
- shard-iclb: PASS -> SKIP [fdo#109441] +2

  * igt@kms_psr@sprite_mmap_gtt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +5

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> FAIL [fdo#109016]

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  PASS -> DMESG-FAIL [fdo#105763]

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@perf@unprivileged-single-ctx-counters:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  * igt@runner@aborted:
- shard-iclb: NOTRUN -> FAIL [fdo#109593]

  
 Possible fixes 

  * igt@gem_mmap_gtt@hang:
- shard-iclb: FAIL [fdo#109677] -> PASS

  * igt@gem_tiled_pread_pwrite:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: DMESG-WARN [fdo#108686] -> PASS

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> PASS

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-skl:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 10:58:01AM -0700, Manasi Navare wrote:
> On Fri, Mar 22, 2019 at 03:16:03PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 22, 2019 at 11:34:25AM +0200, Jani Nikula wrote:
> > > On Thu, 21 Mar 2019, Manasi Navare  wrote:
> > > > In case of tiled displays where different tiles are displayed across
> > > > different ports, we need to synchronize the transcoders involved.
> > > > This patch implements the transcoder port sync feature for
> > > > synchronizing one master transcoder with one or more slave
> > > > transcoders. This is only enbaled in slave transcoder
> > > > and the master transcoder is unaware that it is operating
> > > > in this mode.
> > > > This has been tested with tiled display connected to ICL.
> > > >
> > > > Cc: Daniel Vetter 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Matt Roper 
> > > > Cc: Jani Nikula 
> > > > Signed-off-by: Manasi Navare 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 59 
> > > >  1 file changed, 59 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 9980a4ed8c9c..16b46a3cb3bd 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -4009,6 +4009,62 @@ static void icl_set_pipe_chicken(struct 
> > > > intel_crtc *crtc)
> > > > I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> > > >  }
> > > >  
> > > > +static void icl_set_transcoder_port_sync(struct intel_atomic_state 
> > > > *old_intel_state,
> > > > +const struct intel_crtc_state 
> > > > *crtc_state)
> > > > +{
> > > > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > > > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > +   struct intel_crtc_state *genlock_crtc_state = NULL;
> > > > +   enum transcoder genlock_transcoder;
> > > > +   u32 trans_ddi_func_ctl2_val;
> > > > +   u8 master_select;
> > > > +
> > > > +   /*
> > > > +* Port Sync Mode cannot be enabled for DP MST
> > > > +*/
> > > > +   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > > > +   return;
> > > > +
> > > > +   /*
> > > > +* Configure the master select and enable Transcoder Port Sync 
> > > > for
> > > > +* Slave CRTCs transcoder.
> > > > +*/
> > > > +   if (!crtc_state->genlock_crtc)
> > > > +   return;
> > > > +
> > > > +   genlock_crtc_state = 
> > > > intel_atomic_get_new_crtc_state(old_intel_state,
> > > > +
> > > > crtc_state->genlock_crtc);
> > > > +   if (WARN_ON(!genlock_crtc_state))
> > > > +   return;
> > > > +
> > > > +   genlock_transcoder = genlock_crtc_state->cpu_transcoder;
> > > > +   switch (genlock_transcoder) {
> > > > +   case TRANSCODER_A:
> > > > +   master_select = 1;
> > > > +   break;
> > > > +   case TRANSCODER_B:
> > > > +   master_select = 2;
> > > > +   break;
> > > > +   case TRANSCODER_C:
> > > > +   master_select = 3;
> > > > +   break;
> > > > +   case TRANSCODER_EDP:
> > > > +   default:
> > > > +   master_select = 0;
> > > > +   break;
> > > > +   }
> > > > +   /* Set the master select bits for Tranascoder Port Sync */
> > > > +   trans_ddi_func_ctl2_val = 
> > > > I915_READ(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder));
> > > > +   trans_ddi_func_ctl2_val |= 
> > > > (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> > > > +   PORT_SYNC_MODE_MASTER_SELECT_MASK) 
> > > > <<
> > > > +   PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> > > 
> > > This doesn't do what you think it does. ITYM,
> > > 
> > >   val = I915_READ();
> > > val &= ~FOO_MASK;
> > > val |= FOO_BAR;
> > 
> > Also we alreayd have a place where we write this registers. Is there
> > some magic requirement why these bits can't be set there along with
> > eveyrthing else?
> 
> We only write the bits of TRANS_DDI_FUNC_CTL currently but these bits
> are written to TRANS_DDI_FUNC_CTL2 and need to be written before enabling
> the transcoder.
> Thats why I created this separate function here to set the bits in 
> TRANS_DDI_FUNC_CTL2

In that case there is no point in doing a rmw.

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

[Intel-gfx] [PATCH 2/2] drm/i915: Use vblank_disable_immediate on gen2

2019-03-22 Thread Ville Syrjala
From: Ville Syrjälä 

The vblank timestamp->counter guesstimator seems to be
working sufficiently well, so there's no reason not to
disable vblank interrupts ASAP even on gen2.

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

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 33386f0acab3..a5aff4de5fb0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4642,13 +4642,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
else if (INTEL_GEN(dev_priv) >= 3)
dev->driver->get_vblank_counter = i915_get_vblank_counter;
 
-   /*
-* Opt out of the vblank disable timer on everything except gen2.
-* Gen2 doesn't have a hardware frame counter and so depends on
-* vblank interrupts to produce sane vblank seuquence numbers.
-*/
-   if (!IS_GEN(dev_priv, 2))
-   dev->vblank_disable_immediate = true;
+   dev->vblank_disable_immediate = true;
 
/* Most platforms treat the display irq block as an always-on
 * power domain. vlv/chv can disable it at runtime and need
-- 
2.19.2

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

[Intel-gfx] [PATCH 1/2] drm/i915: Disable C3 when enabling vblank interrupts on i945gm

2019-03-22 Thread Ville Syrjala
From: Ville Syrjälä 

The AGPBUSY thing doesn't work on i945gm anymore. This means
the gmch is incapable of waking the CPU from C3 when an interrupt
is generated. The interrupts just get postponed indefinitely until
something wakes up the CPU. This is rather annoying for vblank
interrupts as we are unable to maintain a steady framerate
unless the machine is sufficiently loaded to stay out of C3.

To combat this let's use pm_qos to prevent C3 whenever vblank
interrupts are enabled. To maintain reasonable amount of powersaving
we will attempt to limit this to C3 only while leaving C1 and C2
enabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30364
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h |  8 +++
 drivers/gpu/drm/i915/i915_irq.c | 88 +
 2 files changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f723b15527f8..0c736f8ca1b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2042,6 +2042,14 @@ struct drm_i915_private {
struct i915_vma *scratch;
} gt;
 
+   /* For i945gm vblank irq vs. C3 workaround */
+   struct {
+   struct work_struct work;
+   struct pm_qos_request pm_qos;
+   u8 c3_disable_latency;
+   u8 enabled;
+   } i945gm_vblank;
+
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2f788291cfe0..33386f0acab3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -30,6 +30,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3131,6 +3132,16 @@ static int i8xx_enable_vblank(struct drm_device *dev, 
unsigned int pipe)
return 0;
 }
 
+static int i945gm_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (dev_priv->i945gm_vblank.enabled++ == 0)
+   schedule_work(_priv->i945gm_vblank.work);
+
+   return i8xx_enable_vblank(dev, pipe);
+}
+
 static int i965_enable_vblank(struct drm_device *dev, unsigned int pipe)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3195,6 +3206,16 @@ static void i8xx_disable_vblank(struct drm_device *dev, 
unsigned int pipe)
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 }
 
+static void i945gm_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   i8xx_disable_vblank(dev, pipe);
+
+   if (--dev_priv->i945gm_vblank.enabled == 0)
+   schedule_work(_priv->i945gm_vblank.work);
+}
+
 static void i965_disable_vblank(struct drm_device *dev, unsigned int pipe)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3228,6 +3249,60 @@ static void gen8_disable_vblank(struct drm_device *dev, 
unsigned int pipe)
spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 }
 
+static void i945gm_vblank_work_func(struct work_struct *work)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(work, struct drm_i915_private, i945gm_vblank.work);
+
+   /*
+* Vblank interrupts fail to wake up the device from C3,
+* hence we want to prevent C3 usage while vblank interrupts
+* are enabled.
+*/
+   pm_qos_update_request(_priv->i945gm_vblank.pm_qos,
+ dev_priv->i945gm_vblank.enabled ?
+ dev_priv->i945gm_vblank.c3_disable_latency :
+ PM_QOS_DEFAULT_VALUE);
+}
+
+static int cstate_disable_latency(const char *name)
+{
+   const struct cpuidle_driver *drv;
+   int i;
+
+   drv = cpuidle_get_driver();
+   if (!drv)
+   return 0;
+
+   for (i = 0; i < drv->state_count; i++) {
+   const struct cpuidle_state *state = >states[i];
+
+   if (!strcmp(state->name, name))
+   return state->exit_latency ?
+   state->exit_latency - 1 : 0;
+   }
+
+   return 0;
+}
+
+static void i945gm_vblank_work_init(struct drm_i915_private *dev_priv)
+{
+   INIT_WORK(_priv->i945gm_vblank.work,
+ i945gm_vblank_work_func);
+
+   dev_priv->i945gm_vblank.c3_disable_latency =
+   cstate_disable_latency("C3");
+   pm_qos_add_request(_priv->i945gm_vblank.pm_qos,
+  PM_QOS_CPU_DMA_LATENCY,
+  PM_QOS_DEFAULT_VALUE);
+}
+
+static void i945gm_vblank_work_fini(struct drm_i915_private *dev_priv)
+{
+   cancel_work_sync(_priv->i945gm_vblank.work);
+   pm_qos_remove_request(_priv->i945gm_vblank.pm_qos);
+}
+
 static void ibx_irq_reset(struct drm_i915_private *dev_priv)
 {
if (HAS_PCH_NOP(dev_priv))
@@ -4525,6 +4600,9 @@ void intel_irq_init(struct 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/selftests: Calculate maximum ring size for preemption chain

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/2] drm/i915/selftests: Calculate maximum 
ring size for preemption chain
URL   : https://patchwork.freedesktop.org/series/58376/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12557_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +126

  * igt@gem_pwrite@stolen-normal:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@gem_stolen@stolen-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@gem_tiled_fence_blits@normal:
- shard-iclb: PASS -> TIMEOUT [fdo#109673]

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +2

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-iclb: PASS -> DMESG-WARN [fdo#109638]

  * igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]

  * igt@kms_atomic_transition@plane-all-modeset-transition:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_chamelium@hdmi-hpd-storm:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-skl:  NOTRUN -> INCOMPLETE [fdo#104108]

  * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw:  PASS -> INCOMPLETE [fdo#103540]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
- shard-iclb: PASS -> FAIL [fdo#103167] +8

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-iclb: PASS -> FAIL [fdo#109247] +5

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +28

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@cursor_mmap_gtt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215]

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: PASS -> SKIP [fdo#109441] +3

  * igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl:  NOTRUN -> FAIL [fdo#109016]

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-iclb: PASS -> FAIL [fdo#104894]

  * igt@perf@unprivileged-single-ctx-counters:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  
 Possible fixes 

  * igt@gem_tiled_pread_pwrite:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS

  * igt@gem_tiled_swapping@non-threaded:
- shard-iclb: DMESG-WARN [fdo#108686] -> PASS

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> PASS

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-skl:  INCOMPLETE [fdo#107807] -> PASS

  * igt@i915_suspend@fence-restore-untiled:
- shard-apl:  DMESG-WARN [fdo#108566] -> PASS +1

  * igt@kms_atomic_transition@1x-modeset-transitions:
- shard-iclb: INCOMPLETE -> PASS

  * 

[Intel-gfx] [CI 4/6] drm/i915/ehl: EHL outputs are different from ICL

2019-03-22 Thread Rodrigo Vivi
From: Bob Paauwe 

Configure the correct set of outputs for EHL. EHL has three DDI's
plus DSI.

Cc: Lucas De Marchi 
Signed-off-by: Bob Paauwe 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_display.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7c15b428ff84..008560ef4db0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14713,7 +14713,12 @@ static void intel_setup_outputs(struct 
drm_i915_private *dev_priv)
if (!HAS_DISPLAY(dev_priv))
return;
 
-   if (INTEL_GEN(dev_priv) >= 11) {
+   if (IS_ELKHARTLAKE(dev_priv)) {
+   intel_ddi_init(dev_priv, PORT_A);
+   intel_ddi_init(dev_priv, PORT_B);
+   intel_ddi_init(dev_priv, PORT_C);
+   icl_dsi_init(dev_priv);
+   } else if (INTEL_GEN(dev_priv) >= 11) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
intel_ddi_init(dev_priv, PORT_C);
-- 
2.20.1

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

[Intel-gfx] [CI 5/6] drm/i915/ehl: Set proper eu slice/subslice parameters for EHL

2019-03-22 Thread Rodrigo Vivi
From: Bob Paauwe 

EHL has a different number of subslices.

Cc: Lucas De Marchi 
Signed-off-by: Bob Paauwe 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_device_info.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index db00110cbb2e..e0ac908bb4e9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -156,9 +156,15 @@ static void gen11_sseu_info_init(struct drm_i915_private 
*dev_priv)
u8 eu_en;
int s;
 
-   sseu->max_slices = 1;
-   sseu->max_subslices = 8;
-   sseu->max_eus_per_subslice = 8;
+   if (IS_ELKHARTLAKE(dev_priv)) {
+   sseu->max_slices = 1;
+   sseu->max_subslices = 4;
+   sseu->max_eus_per_subslice = 8;
+   } else {
+   sseu->max_slices = 1;
+   sseu->max_subslices = 8;
+   sseu->max_eus_per_subslice = 8;
+   }
 
s_en = I915_READ(GEN11_GT_SLICE_ENABLE) & GEN11_GT_S_ENA_MASK;
ss_en = ~I915_READ(GEN11_GT_SUBSLICE_DISABLE);
-- 
2.20.1

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

[Intel-gfx] [CI 3/6] drm/i915/ehl: Add dpll mgr

2019-03-22 Thread Rodrigo Vivi
From: Lucas De Marchi 

Elkhart Lake has a different set of PLLs as compared to Ice Lake,
although programming them is very similar.

v2: Rebase on top of s/icl_pll_funcs/combo_pll_funcs

Signed-off-by: Lucas De Marchi 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index dfe6a7114d56..eeb659946203 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -3245,6 +3245,18 @@ static const struct intel_dpll_mgr icl_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
 };
 
+static const struct dpll_info ehl_plls[] = {
+   { "DPLL 0", _pll_funcs, DPLL_ID_ICL_DPLL0, 0 },
+   { "DPLL 1", _pll_funcs, DPLL_ID_ICL_DPLL1, 0 },
+   { },
+};
+
+static const struct intel_dpll_mgr ehl_pll_mgr = {
+   .dpll_info = ehl_plls,
+   .get_dpll = icl_get_dpll,
+   .dump_hw_state = icl_dump_hw_state,
+};
+
 /**
  * intel_shared_dpll_init - Initialize shared DPLLs
  * @dev: drm device
@@ -3258,7 +3270,9 @@ void intel_shared_dpll_init(struct drm_device *dev)
const struct dpll_info *dpll_info;
int i;
 
-   if (INTEL_GEN(dev_priv) >= 11)
+   if (IS_ELKHARTLAKE(dev_priv))
+   dpll_mgr = _pll_mgr;
+   else if (INTEL_GEN(dev_priv) >= 11)
dpll_mgr = _pll_mgr;
else if (IS_CANNONLAKE(dev_priv))
dpll_mgr = _pll_mgr;
-- 
2.20.1

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

[Intel-gfx] [CI 2/6] drm/i915/ehl: Add ElkhartLake platform

2019-03-22 Thread Rodrigo Vivi
From: Bob Paauwe 

Add ElkhartLake as a unique platform as there are some differences
between it and Icelake.

Signed-off-by: Bob Paauwe 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 drivers/gpu/drm/i915/i915_pci.c  | 2 +-
 drivers/gpu/drm/i915/intel_device_info.c | 1 +
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f723b15527f8..eff0e9aa353d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2323,6 +2323,7 @@ static inline unsigned int i915_sg_segment_size(void)
 #define IS_COFFEELAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_COFFEELAKE)
 #define IS_CANNONLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_CANNONLAKE)
 #define IS_ICELAKE(dev_priv)   IS_PLATFORM(dev_priv, INTEL_ICELAKE)
+#define IS_ELKHARTLAKE(dev_priv)   IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
 #define IS_MOBILE(dev_priv)(INTEL_INFO(dev_priv)->is_mobile)
 #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index fa99d68cbe7d..a7e1611af26d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -732,7 +732,7 @@ static const struct intel_device_info intel_icelake_11_info 
= {
 
 static const struct intel_device_info intel_elkhartlake_info = {
GEN11_FEATURES,
-   PLATFORM(INTEL_ICELAKE),
+   PLATFORM(INTEL_ELKHARTLAKE),
.is_alpha_support = 1,
.engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0),
.ppgtt_size = 36,
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index eddf83807957..db00110cbb2e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -57,6 +57,7 @@ static const char * const platform_names[] = {
PLATFORM_NAME(COFFEELAKE),
PLATFORM_NAME(CANNONLAKE),
PLATFORM_NAME(ICELAKE),
+   PLATFORM_NAME(ELKHARTLAKE),
 };
 #undef PLATFORM_NAME
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 6234570a9b17..98acefaacec9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -73,6 +73,7 @@ enum intel_platform {
INTEL_CANNONLAKE,
/* gen11 */
INTEL_ICELAKE,
+   INTEL_ELKHARTLAKE,
INTEL_MAX_PLATFORMS
 };
 
-- 
2.20.1

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

[Intel-gfx] [CI 6/6] drm/i915/ehl: Add Support for DMC on EHL

2019-03-22 Thread Rodrigo Vivi
From: Anusha Srivatsa 

EHL uses the same firmware as ICL.

Cc: Bob Paauwe 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Bob Paauwe 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/intel_csr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index e8ac04c33e29..862a8f686ef5 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -486,7 +486,7 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) >= 12) {
/* Allow to load fw via parameter using the last known size */
csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
-   } else if (IS_ICELAKE(dev_priv)) {
+   } else if (IS_GEN(dev_priv, 11)) {
csr->fw_path = ICL_CSR_PATH;
csr->required_version = ICL_CSR_VERSION_REQUIRED;
csr->max_fw_size = ICL_CSR_MAX_FW_SIZE;
-- 
2.20.1

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

[Intel-gfx] [CI 1/6] drm/i915/ehl: Add EHL platform info and PCI IDs

2019-03-22 Thread Rodrigo Vivi
From: James Ausmus 

Add known EHL PCI IDs.

v2 (Rodrigo): Removed x86 early quirk. To be sent in a separated
  patch cc'ing the appropriated list and maintainers for
  proper ack.
v3: (Rodrigo): - Removed .num_pipes = 3 that is coming since GEN&_FEATURES.
   - Added ppgtt type and size after rework from Bob and Chris
v4: (Rodrigo): - remove ppgtt type added on v3. Jose pointed it is not
 needed.

Cc: Bob Paauwe 
Cc: Chris Wilson 
Cc: José Roberto de Souza 
Signed-off-by: James Ausmus 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Bob Paauwe 
Reviewed-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_pci.c | 9 +
 include/drm/i915_pciids.h   | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7a6054eadb8e..fa99d68cbe7d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -730,6 +730,14 @@ static const struct intel_device_info 
intel_icelake_11_info = {
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
 };
 
+static const struct intel_device_info intel_elkhartlake_info = {
+   GEN11_FEATURES,
+   PLATFORM(INTEL_ICELAKE),
+   .is_alpha_support = 1,
+   .engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0),
+   .ppgtt_size = 36,
+};
+
 #undef GEN
 #undef PLATFORM
 
@@ -799,6 +807,7 @@ static const struct pci_device_id pciidlist[] = {
INTEL_CML_GT2_IDS(_coffeelake_gt2_info),
INTEL_CNL_IDS(_cannonlake_info),
INTEL_ICL_11_IDS(_icelake_11_info),
+   INTEL_EHL_IDS(_elkhartlake_info),
{0, 0, 0}
 };
 MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 291b5e3fa59c..c7cdbfc4d033 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -498,4 +498,11 @@
INTEL_VGA_DEVICE(0x8A70, info), \
INTEL_VGA_DEVICE(0x8A53, info)
 
+/* EHL */
+#define INTEL_EHL_IDS(info) \
+   INTEL_VGA_DEVICE(0x4500, info), \
+   INTEL_VGA_DEVICE(0x4571, info), \
+   INTEL_VGA_DEVICE(0x4551, info), \
+   INTEL_VGA_DEVICE(0x4541, info)
+
 #endif /* _I915_PCIIDS_H */
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports

2019-03-22 Thread Manasi Navare
On Fri, Mar 22, 2019 at 03:16:03PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 22, 2019 at 11:34:25AM +0200, Jani Nikula wrote:
> > On Thu, 21 Mar 2019, Manasi Navare  wrote:
> > > In case of tiled displays where different tiles are displayed across
> > > different ports, we need to synchronize the transcoders involved.
> > > This patch implements the transcoder port sync feature for
> > > synchronizing one master transcoder with one or more slave
> > > transcoders. This is only enbaled in slave transcoder
> > > and the master transcoder is unaware that it is operating
> > > in this mode.
> > > This has been tested with tiled display connected to ICL.
> > >
> > > Cc: Daniel Vetter 
> > > Cc: Ville Syrjälä 
> > > Cc: Maarten Lankhorst 
> > > Cc: Matt Roper 
> > > Cc: Jani Nikula 
> > > Signed-off-by: Manasi Navare 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 59 
> > >  1 file changed, 59 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 9980a4ed8c9c..16b46a3cb3bd 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4009,6 +4009,62 @@ static void icl_set_pipe_chicken(struct intel_crtc 
> > > *crtc)
> > >   I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> > >  }
> > >  
> > > +static void icl_set_transcoder_port_sync(struct intel_atomic_state 
> > > *old_intel_state,
> > > +  const struct intel_crtc_state 
> > > *crtc_state)
> > > +{
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + struct intel_crtc_state *genlock_crtc_state = NULL;
> > > + enum transcoder genlock_transcoder;
> > > + u32 trans_ddi_func_ctl2_val;
> > > + u8 master_select;
> > > +
> > > + /*
> > > +  * Port Sync Mode cannot be enabled for DP MST
> > > +  */
> > > + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > > + return;
> > > +
> > > + /*
> > > +  * Configure the master select and enable Transcoder Port Sync for
> > > +  * Slave CRTCs transcoder.
> > > +  */
> > > + if (!crtc_state->genlock_crtc)
> > > + return;
> > > +
> > > + genlock_crtc_state = intel_atomic_get_new_crtc_state(old_intel_state,
> > > +  
> > > crtc_state->genlock_crtc);
> > > + if (WARN_ON(!genlock_crtc_state))
> > > + return;
> > > +
> > > + genlock_transcoder = genlock_crtc_state->cpu_transcoder;
> > > + switch (genlock_transcoder) {
> > > + case TRANSCODER_A:
> > > + master_select = 1;
> > > + break;
> > > + case TRANSCODER_B:
> > > + master_select = 2;
> > > + break;
> > > + case TRANSCODER_C:
> > > + master_select = 3;
> > > + break;
> > > + case TRANSCODER_EDP:
> > > + default:
> > > + master_select = 0;
> > > + break;
> > > + }
> > > + /* Set the master select bits for Tranascoder Port Sync */
> > > + trans_ddi_func_ctl2_val = 
> > > I915_READ(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder));
> > > + trans_ddi_func_ctl2_val |= (PORT_SYNC_MODE_MASTER_SELECT(master_select) 
> > > &
> > > + PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> > > + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> > 
> > This doesn't do what you think it does. ITYM,
> > 
> > val = I915_READ();
> > val &= ~FOO_MASK;
> > val |= FOO_BAR;
> 
> Also we alreayd have a place where we write this registers. Is there
> some magic requirement why these bits can't be set there along with
> eveyrthing else?

We only write the bits of TRANS_DDI_FUNC_CTL currently but these bits
are written to TRANS_DDI_FUNC_CTL2 and need to be written before enabling
the transcoder.
Thats why I created this separate function here to set the bits in 
TRANS_DDI_FUNC_CTL2

Manasi

> 
> > 
> > Please actually use just "val" for the variable, the long name just
> > makes this all harder to read.
> > 
> > BR,
> > Jani.
> > 
> > 
> > > + /* Enable Transcoder Port Sync */
> > > + trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
> > > +
> > > + I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> > > +trans_ddi_func_ctl2_val);
> > > +}
> > > +
> > >  static void intel_update_pipe_config(const struct intel_crtc_state 
> > > *old_crtc_state,
> > >const struct intel_crtc_state 
> > > *new_crtc_state)
> > >  {
> > > @@ -5960,6 +6016,9 @@ static void haswell_crtc_enable(struct 
> > > intel_crtc_state *pipe_config,
> > >   if (!transcoder_is_dsi(cpu_transcoder))
> > >   intel_set_pipe_timings(pipe_config);
> > >  
> > > + if (INTEL_GEN(dev_priv) >= 11)
> > > + icl_set_transcoder_port_sync(old_intel_state, pipe_config);
> > > +
> > >   intel_set_pipe_src_size(pipe_config);
> > >  
> > >   if (cpu_transcoder != TRANSCODER_EDP &&
> > 
> > -- 
> > Jani Nikula, Intel Open Source 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports

2019-03-22 Thread Manasi Navare
On Fri, Mar 22, 2019 at 11:34:25AM +0200, Jani Nikula wrote:
> On Thu, 21 Mar 2019, Manasi Navare  wrote:
> > In case of tiled displays where different tiles are displayed across
> > different ports, we need to synchronize the transcoders involved.
> > This patch implements the transcoder port sync feature for
> > synchronizing one master transcoder with one or more slave
> > transcoders. This is only enbaled in slave transcoder
> > and the master transcoder is unaware that it is operating
> > in this mode.
> > This has been tested with tiled display connected to ICL.
> >
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: Maarten Lankhorst 
> > Cc: Matt Roper 
> > Cc: Jani Nikula 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 59 
> >  1 file changed, 59 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9980a4ed8c9c..16b46a3cb3bd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4009,6 +4009,62 @@ static void icl_set_pipe_chicken(struct intel_crtc 
> > *crtc)
> > I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> >  }
> >  
> > +static void icl_set_transcoder_port_sync(struct intel_atomic_state 
> > *old_intel_state,
> > +const struct intel_crtc_state 
> > *crtc_state)
> > +{
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +   struct intel_crtc_state *genlock_crtc_state = NULL;
> > +   enum transcoder genlock_transcoder;
> > +   u32 trans_ddi_func_ctl2_val;
> > +   u8 master_select;
> > +
> > +   /*
> > +* Port Sync Mode cannot be enabled for DP MST
> > +*/
> > +   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > +   return;
> > +
> > +   /*
> > +* Configure the master select and enable Transcoder Port Sync for
> > +* Slave CRTCs transcoder.
> > +*/
> > +   if (!crtc_state->genlock_crtc)
> > +   return;
> > +
> > +   genlock_crtc_state = intel_atomic_get_new_crtc_state(old_intel_state,
> > +
> > crtc_state->genlock_crtc);
> > +   if (WARN_ON(!genlock_crtc_state))
> > +   return;
> > +
> > +   genlock_transcoder = genlock_crtc_state->cpu_transcoder;
> > +   switch (genlock_transcoder) {
> > +   case TRANSCODER_A:
> > +   master_select = 1;
> > +   break;
> > +   case TRANSCODER_B:
> > +   master_select = 2;
> > +   break;
> > +   case TRANSCODER_C:
> > +   master_select = 3;
> > +   break;
> > +   case TRANSCODER_EDP:
> > +   default:
> > +   master_select = 0;
> > +   break;
> > +   }
> > +   /* Set the master select bits for Tranascoder Port Sync */
> > +   trans_ddi_func_ctl2_val = 
> > I915_READ(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder));
> > +   trans_ddi_func_ctl2_val |= (PORT_SYNC_MODE_MASTER_SELECT(master_select) 
> > &
> > +   PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> > +   PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> 
> This doesn't do what you think it does. ITYM,
> 
>   val = I915_READ();
> val &= ~FOO_MASK;
> val |= FOO_BAR;

Ah, yes I should use the mask to clear the value and then OR the new value.
Will make this change, thanks for pointing this out.

> 
> Please actually use just "val" for the variable, the long name just
> makes this all harder to read.

Okay will change the variable name to val.

Regards
Manasi
> 
> BR,
> Jani.
> 
> 
> > +   /* Enable Transcoder Port Sync */
> > +   trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
> > +
> > +   I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> > +  trans_ddi_func_ctl2_val);
> > +}
> > +
> >  static void intel_update_pipe_config(const struct intel_crtc_state 
> > *old_crtc_state,
> >  const struct intel_crtc_state 
> > *new_crtc_state)
> >  {
> > @@ -5960,6 +6016,9 @@ static void haswell_crtc_enable(struct 
> > intel_crtc_state *pipe_config,
> > if (!transcoder_is_dsi(cpu_transcoder))
> > intel_set_pipe_timings(pipe_config);
> >  
> > +   if (INTEL_GEN(dev_priv) >= 11)
> > +   icl_set_transcoder_port_sync(old_intel_state, pipe_config);
> > +
> > intel_set_pipe_src_size(pipe_config);
> >  
> > if (cpu_transcoder != TRANSCODER_EDP &&
> 
> -- 
> 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] [PATCH] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED

2019-03-22 Thread Ville Syrjala
From: Ville Syrjälä 

Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.

The concensus seems to be that this quirk is a bit misguided
anyway so let's nuke the leftovers.

For posterity here are some links to known cases:
* Proview AY765C
  https://bugs.freedesktop.org/show_bug.cgi?id=15160
* Unknown Acer
  https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
  reference from xf86EdidModes.c)
* Peacock Ergovision 19 (only in xf86EdidModes.c)
  https://bugzilla.redhat.com/show_bug.cgi?id=492359
* Philips 107p5 CRT
  "Reported on xorg@ with pastebin", didn't find the mail(s)

Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fa39592ebc0a..2c22ea446075 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -68,8 +68,6 @@
  * maximum size and use that.
  */
 #define EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE   (1 << 4)
-/* Monitor forgot to set the first detailed is preferred bit. */
-#define EDID_QUIRK_FIRST_DETAILED_PREFERRED(1 << 5)
 /* use +hsync +vsync for detailed mode */
 #define EDID_QUIRK_DETAILED_SYNC_PP(1 << 6)
 /* Force reduced-blanking timings for detailed modes */
@@ -107,8 +105,6 @@ static const struct edid_quirk {
{ "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 },
/* Acer F51 */
{ "API", 0x7602, EDID_QUIRK_PREFER_LARGE_60 },
-   /* Unknown Acer */
-   { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
 
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
@@ -145,12 +141,6 @@ static const struct edid_quirk {
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
 
-   /* Philips 107p5 CRT */
-   { "PHL", 57364, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
-
-   /* Proview AY765C */
-   { "PTS", 765, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
-
/* Samsung SyncMaster 205BW.  Note: irony */
{ "SAM", 541, EDID_QUIRK_DETAILED_SYNC_PP },
/* Samsung SyncMaster 22[5-6]BW */
-- 
2.19.2

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

[Intel-gfx] [PATCH] drm/i915/guc: Replace preempt_client lookup with engine->preempt_context

2019-03-22 Thread Chris Wilson
Circumvent the dance we currently perform to find the preempt_client and
lookup its HW context for this engine, as we know we have already pinned
the preempt_context on the engine.

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

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index c4ad73980988..30dd6706a1d2 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -567,7 +567,7 @@ static void inject_preempt_context(struct work_struct *work)
 preempt_work[engine->id]);
struct intel_guc_client *client = guc->preempt_client;
struct guc_stage_desc *stage_desc = __get_stage_desc(client);
-   struct intel_context *ce = intel_context_lookup(client->owner, engine);
+   struct intel_context *ce = engine->preempt_context;
u32 data[7];
 
if (!ce->ring->emit) { /* recreate upon load/resume */
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 3/8] drm/i915/psr: Make all PSR register relative to mmio base

2019-03-22 Thread Dhinakaran Pandiyan
On Fri, 2019-03-22 at 11:15 +0200, Jani Nikula wrote:
> On Thu, 21 Mar 2019, José Roberto de Souza  wrote:
> > Right now it have a mix of PSR registers that are relative to PSR
> > mmio base and other register with a hardcoded address, lets keep it
> > consistented and have it all relative to mmio base.
> 
> This is not strictly limited to this patch, but an overall trend. The
> thing that really bugs me with this is losing more of the actual
> absolute mmio addresses from the file. When you're seeking to add a new
> register, you can't trivially grep for it in the file anymore. Not all
> of our register names match the spec (and the spec occasionally also
> changes register names) so being able to find the offset is important.

Fully agreed.

I think we can do something along the lines of  

#define _HSW_PSR_OFFSET BDW_EDP_PSR_BASE - HSW_PSR_PSR_BASE
#define _BDW_PSR_CTL 0x6f800

_MMIO_HSW_ADJUST(pipe, reg)  IS_HASWELL(dev_priv) ?
MMIO_TRANS2((pipe), reg - _HSW_PSR_OFFSET) :
MMIO_TRANS2((pipe), reg)

#define EDP_PSR_CTL(pipe) _MMIO_HSW_ADJUST((pipe), _BDW_PSR_CTL)


I'd like at least BDW+ addresses to be in the code.

-DK

> 
> When we added the macros that use ->pipe_offsets and ->trans_offsets, we
> took care to have at least one of the offsets in the file. I'm wondering
> if we could do something like that here as well.
> 
> BR,
> Jani.
> 
> 
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 11 ---
> >  1 file changed, 4 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 28728399e607..e1ed2ba1c315 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4326,7 +4326,7 @@ enum {
> >  #define   EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1 << 16) /* Reserved in
> > ICL+ */
> >  #define   EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1 << 15) /* SKL+ */
> >  
> > -#define EDP_PSR2_CTL   _MMIO(0x6f900)
> > +#define EDP_PSR2_CTL   _MMIO(dev_priv->psr.mmio_base +
> > 0x100)
> >  #define   EDP_PSR2_ENABLE  (1 << 31)
> >  #define   EDP_SU_TRACK_ENABLE  (1 << 30)
> >  #define   EDP_Y_COORDINATE_VALID   (1 << 26) /* GLK and CNL+ */
> > @@ -4344,7 +4344,7 @@ enum {
> >  #define   EDP_PSR2_IDLE_FRAME_MASK 0xf
> >  #define   EDP_PSR2_IDLE_FRAME_SHIFT0
> >  
> > -#define PSR_EVENT  _MMIO(0x6F848)
> > +#define PSR_EVENT  _MMIO(dev_priv->psr.mmio_base +
> > 0x48)
> >  #define  PSR_EVENT_PSR2_WD_TIMER_EXPIRE(1 << 17)
> >  #define  PSR_EVENT_PSR2_DISABLED   (1 << 16)
> >  #define  PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN  (1 << 15)
> > @@ -4362,14 +4362,11 @@ enum {
> >  #define  PSR_EVENT_LPSP_MODE_EXIT  (1 << 1)
> >  #define  PSR_EVENT_PSR_DISABLE (1 << 0)
> >  
> > -#define EDP_PSR2_STATUS_MMIO(0x6f940)
> > +#define EDP_PSR2_STATUS_MMIO(dev_priv->psr.mmio_base +
> > 0x140)
> >  #define EDP_PSR2_STATUS_STATE_MASK (0xf << 28)
> >  #define EDP_PSR2_STATUS_STATE_SHIFT28
> >  
> > -#define _PSR2_SU_STATUS_0  0x6F914
> > -#define _PSR2_SU_STATUS_1  0x6F918
> > -#define _PSR2_SU_STATUS_2  0x6F91C
> > -#define _PSR2_SU_STATUS(index) _MMIO(_PICK_EVEN((index),
> > _PSR2_SU_STATUS_0, _PSR2_SU_STATUS_1))
> > +#define _PSR2_SU_STATUS(index) _MMIO(dev_priv->psr.mmio_base +
> > 0x114 + (index) * 4)
> >  #define PSR2_SU_STATUS(frame)  (_PSR2_SU_STATUS((frame) / 3))
> >  #define PSR2_SU_STATUS_SHIFT(frame)(((frame) % 3) * 10)
> >  #define PSR2_SU_STATUS_MASK(frame) (0x3ff << PSR2_SU_STATUS_SHIFT(frame))
> 
> 

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "drm/i915: Introduce private PAT management"

2019-03-22 Thread Patchwork
== Series Details ==

Series: Revert "drm/i915: Introduce private PAT management"
URL   : https://patchwork.freedesktop.org/series/58421/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_5795 -> Patchwork_12575


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_12575 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_12575, 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/58421/revisions/1/mbox/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s3:
- fi-bsw-kefka:   NOTRUN -> TIMEOUT
- fi-bsw-n3050:   NOTRUN -> TIMEOUT

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-bxt-j4205:   PASS -> TIMEOUT

  * igt@gem_render_tiled_blits@basic:
- fi-apl-guc: PASS -> FAIL

  * igt@gem_ringfill@basic-default-interruptible:
- fi-bsw-kefka:   NOTRUN -> FAIL +6

  * igt@gem_sync@basic-all:
- fi-bxt-j4205:   PASS -> FAIL +3

  * igt@kms_frontbuffer_tracking@basic:
- fi-bsw-n3050:   NOTRUN -> FAIL +9

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g:   NOTRUN -> FAIL [fdo#108094]

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] +56

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109315] +17

  * igt@gem_exec_basic@basic-bsd2:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109276] +7

  * igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_exec_basic@readonly-bsd:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76

  * igt@gem_exec_basic@readonly-bsd1:
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] +57

  * igt@gem_exec_gttfill@basic:
- fi-skl-gvtdvm:  NOTRUN -> SKIP [fdo#109271] +41

  * igt@gem_exec_parse@basic-rejected:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109289] +1

  * igt@gem_exec_suspend@basic-s3:
- fi-icl-u3:  NOTRUN -> FAIL [fdo#103375]

  * igt@i915_selftest@live_contexts:
- fi-icl-u3:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   NOTRUN -> DMESG-WARN [fdo#107709]

  * igt@i915_selftest@live_uncore:
- fi-ivb-3770:PASS -> DMESG-FAIL [fdo#110210]

  * igt@kms_busy@basic-flip-a:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] +63
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109284] +8

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   NOTRUN -> SKIP [fdo#109271] +45
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109285] +3

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  PASS -> FAIL [fdo#103167]
- fi-bdw-gvtdvm:  PASS -> FAIL [fdo#103167]
- fi-bdw-5557u:   PASS -> FAIL [fdo#103167]

  * igt@runner@aborted:
- fi-bsw-kefka:   NOTRUN -> FAIL [fdo#107709]

  
 Possible fixes 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   DMESG-WARN [fdo#108965] -> PASS

  
 Warnings 

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569]

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make sure we have enough memory bandwidth on ICL

2019-03-22 Thread Ville Syrjälä
On Wed, Mar 20, 2019 at 11:46:35PM +0200, Ville Syrjala wrote:
> + /*
> +  * Try to muzzle SAGV to prevent it from
> +  * messing up the memory controller readout.
> +  */
> + intel_disable_sagv(dev_priv);
> +
> + /*
> +  * Magic sleep to avoid observing very high DDR clock.
> +  * Not sure what's going on but on a system with DDR4-3200
> +  * clock of 4800 MT/s is often observed here. A short
> +  * sleep manages to hide that.. Is that actually
> +  * the "min latency" SAGV point?. Maybe the SA clocks
> +  * things way up when there is no memory traffic?
> +  * But polling the register never seems to show this
> +  * except during i915 unload/load. Sleeping before the
> +  * SAGV disable usually returns 2133 MT/s.
> +  *
> +  * FIXME what is going on?
> +  */
> + msleep(5);

Argh. Looks like this isn't working on the ci machines. We get

<7>[   12.419386] [drm:i915_driver_load [i915]] SAGV 0 DCLK=64 tRP=15 tRDPRE=8 
tRAS=35 tRCD=15 tRC=50
<7>[   12.419417] [drm:i915_driver_load [i915]] SAGV 1 DCLK=64 tRP=15 tRDPRE=8 
tRAS=35 tRCD=15 tRC=50
<7>[   12.419447] [drm:i915_driver_load [i915]] SAGV 2 DCLK=64 tRP=15 tRDPRE=8 
tRAS=35 tRCD=15 tRC=50

Which would indicate 2133 MT/s even though the machines have
3200 MT/s memory (at least according to DMI).

-- 
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.SPARSE: warning for Revert "drm/i915: Introduce private PAT management"

2019-03-22 Thread Patchwork
== Series Details ==

Series: Revert "drm/i915: Introduce private PAT management"
URL   : https://patchwork.freedesktop.org/series/58421/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: Revert "drm/i915: Introduce private PAT management"
-drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using 
sizeof(void)
-drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:348:14: warning: expression using 
sizeof(void)
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3575:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression 
using sizeof(void)

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

Re: [Intel-gfx] [PATCH i-g-t 22/24] i915: Add gem_ctx_engines

2019-03-22 Thread Chris Wilson
Quoting Andi Shyti (2019-03-22 16:40:07)
> Hi Chris,
> 
> sorry for the late reply, I got 5 version of this same patch and
> I couldn't figure out what was what :)
> 
> Could you please add some versioning or note if version is
> the same?
> 
> Some nits and questions
> 
> > +static bool has_context_engines(int i915)
> > +{
> > + struct drm_i915_gem_context_param param = {
> > + .ctx_id = 0,
> > + .param = I915_CONTEXT_PARAM_ENGINES,
> > + };
> > + return __gem_context_set_param(i915, ) == 0;
> > +}
> 
> I had it and removed it so many times in gem_engine_topology,
> shall I put it back and we take it from there? (maybe in the
> future).
> 
> [...]
> > + igt_assert_eq(__gem_context_set_param(i915, ), -ENOENT);
> > +
> > + mprotect(engines, 4096, PROT_READ);
> 
> (from the last review) mprotect can fail, do we care?

Debatable, yes we care as we won't get the expected faults in the next
tests, but do we want to call this the test failure? I want something
other than igt_require/igt_assert!

> > + idx = 0;
> > + memset(, 0, sizeof(engines));
> > + for_each_engine_class_instance(i915, e) {
> > + engines.class_instance[idx].engine_class = e->class;
> > + engines.class_instance[idx].engine_instance = e->instance;
> > + idx++;
> > + }
> > + idx *= sizeof(*engines.class_instance);
> > + p.size = base + idx;
> 
> (I normally review from bottom to top) You used at least three
> different ways to calculate param's size (some unclear to who
> is new to igt some more clear).
> 
> Does it make sense to have a global define and we keep it
> consistent?
> 
>  p.size = SIZEOF_CTX_PARAM(idx);

Definitely not shouting about it. I honestly believe that a plethora
of styles within tests is a good thing, and everything using the same
code pattern reduces the amount of test serendipity.

While this is a bit of trivial math and should not affect the outcome in
anyway, I quite like having bits and pieces fall naturally out of the
code because the code should also be an example of different ways it
might be used.

> it's a piece of code that I think it will be ussed a lot.
> 
> > + /* Unadulterated I915_EXEC_DEFAULT should work */
> > + execbuf.flags = 0;
> > + igt_assert_eq(__gem_execbuf(i915, ), 0);
> 
> why aren't you using simply gem_execbuf()?

So the style matched the open calls to __gem_execbuf() later.

> > + execbuf.flags = j;
> > + err =__gem_execbuf(i915, );
> > + if (j == i) {
> > + igt_assert_f(err == 0,
> > +  "Failed to report the 
> > valid engine for slot %d\n",
> > +  i);
> > + } else {
> > + igt_assert_f(err == -EINVAL,
> > +  "Failed to report an 
> > invalid engine for slot %d (valid at %d)\n",
> > +  j, i);
> > + }
> > + }
> > +
> > + do_ioctl(i915, DRM_IOCTL_I915_GEM_BUSY, );
> > + if (i != -1) {
> > + igt_assert_eq(busy.busy, 1 << (e->class + 
> > 16));
> > + } else {
> > + igt_assert_eq(busy.busy, 0);
> > + }
> > +
> 
> (from the last review) this is not kernel style, not that I care
> much, but I thought you did.

Indeed, _we_ do care ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "drm/i915: Introduce private PAT management"

2019-03-22 Thread Patchwork
== Series Details ==

Series: Revert "drm/i915: Introduce private PAT management"
URL   : https://patchwork.freedesktop.org/series/58421/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a3e8095440a5 Revert "drm/i915: Introduce private PAT management"
-:275: WARNING:LONG_LINE_COMMENT: line over 100 characters
#275: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:2928:
+ GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) |  /* for 
something pointing to ptes? */

-:277: WARNING:LONG_LINE_COMMENT: line over 100 characters
#277: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:2930:
+ GEN8_PPAT(3, GEN8_PPAT_UC) |  /* Uncached 
objects, mostly for scanout */

total: 0 errors, 2 warnings, 0 checks, 380 lines checked

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

Re: [Intel-gfx] [PATCH] drm/i915: Really calculate the cursor ddb based on the highest enabled wm level

2019-03-22 Thread Ville Syrjälä
On Thu, Mar 21, 2019 at 01:20:51PM -0700, Rodrigo Vivi wrote:
> On Thu, Mar 21, 2019 at 07:51:28PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > I added the loop but neglected to actually pass the level to the
> > function. So we were just looping 8 times calculating the exact
> > same thing every time.
> > 
> > Fixes: df331de3f8aa ("drm/i915: Allocate enough DDB for the cursor")
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Rodrigo Vivi 

Thanks. Pushed.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index fcd3baff8b65..eaf0793ebf60 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3953,7 +3953,7 @@ skl_cursor_allocation(const struct intel_crtc_state 
> > *crtc_state,
> > WARN_ON(ret);
> >  
> > for (level = 0; level <= max_level; level++) {
> > -   skl_compute_plane_wm(crtc_state, 7, , , );
> > +   skl_compute_plane_wm(crtc_state, level, , , );
> > if (wm.min_ddb_alloc == U16_MAX)
> > break;
> >  
> > -- 
> > 2.19.2
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Refactor EDID fixed mode search

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 10:32:40AM +0200, Jani Nikula wrote:
> On Thu, 21 Mar 2019, Ville Syrjala  wrote:
> > From: Ville Syrjälä 
> >
> > Both LVDS and eDP have the same code to look up the preferred mode
> > from the connector probed_modes list. Move the code to a common
> > location.
> >
> > Signed-off-by: Ville Syrjälä 
> 
> This series is something I've been meaning to do for ages.

I think I had these more or less typed up for a few years now.
Finally got an excuse (the bug) to finish them ;)

Series pushed to dinq. Thanks for the reviews/acks everyone.

> Thanks for
> doing it. Others beat me to review, I only glanced through. On the
> series,
> 
> Acked-by: Jani Nikula 
> 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c| 13 +++--
> >  drivers/gpu/drm/i915/intel_drv.h   |  2 ++
> >  drivers/gpu/drm/i915/intel_lvds.c  | 14 +++---
> >  drivers/gpu/drm/i915/intel_panel.c | 27 +++
> >  4 files changed, 35 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 7c043e8f6298..5096e99ffaad 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -7057,7 +7057,6 @@ static bool intel_edp_init_connector(struct intel_dp 
> > *intel_dp,
> > struct drm_display_mode *fixed_mode = NULL;
> > struct drm_display_mode *downclock_mode = NULL;
> > bool has_dpcd;
> > -   struct drm_display_mode *scan;
> > enum pipe pipe = INVALID_PIPE;
> > intel_wakeref_t wakeref;
> > struct edid *edid;
> > @@ -7110,15 +7109,9 @@ static bool intel_edp_init_connector(struct intel_dp 
> > *intel_dp,
> > }
> > intel_connector->edid = edid;
> >  
> > -   /* prefer fixed mode from EDID if available */
> > -   list_for_each_entry(scan, >probed_modes, head) {
> > -   if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
> > -   fixed_mode = drm_mode_duplicate(dev, scan);
> > -   downclock_mode = intel_dp_drrs_init(
> > -   intel_connector, fixed_mode);
> > -   break;
> > -   }
> > -   }
> > +   fixed_mode = intel_panel_edid_fixed_mode(intel_connector);
> > +   if (fixed_mode)
> > +   downclock_mode = intel_dp_drrs_init(intel_connector, 
> > fixed_mode);
> >  
> > /* fallback to VBT if available for eDP */
> > if (!fixed_mode && dev_priv->vbt.lfp_lvds_vbt_mode) {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 4d7ae579fc92..4d45ed6aa097 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -2158,6 +2158,8 @@ extern struct drm_display_mode 
> > *intel_find_panel_downclock(
> > struct drm_i915_private *dev_priv,
> > struct drm_display_mode *fixed_mode,
> > struct drm_connector *connector);
> > +struct drm_display_mode *
> > +intel_panel_edid_fixed_mode(struct intel_connector *connector);
> >  
> >  #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
> >  int intel_backlight_device_register(struct intel_connector *connector);
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
> > b/drivers/gpu/drm/i915/intel_lvds.c
> > index 845792aa0abe..0686ad1f12df 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -810,7 +810,6 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
> > struct intel_connector *intel_connector;
> > struct drm_connector *connector;
> > struct drm_encoder *encoder;
> > -   struct drm_display_mode *scan; /* *modes, *bios_mode; */
> > struct drm_display_mode *fixed_mode = NULL;
> > struct drm_display_mode *downclock_mode = NULL;
> > struct edid *edid;
> > @@ -949,16 +948,9 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
> > }
> > intel_connector->edid = edid;
> >  
> > -   list_for_each_entry(scan, >probed_modes, head) {
> > -   if (scan->type & DRM_MODE_TYPE_PREFERRED) {
> > -   DRM_DEBUG_KMS("using preferred mode from EDID: ");
> > -   drm_mode_debug_printmodeline(scan);
> > -
> > -   fixed_mode = drm_mode_duplicate(dev, scan);
> > -   if (fixed_mode)
> > -   goto out;
> > -   }
> > -   }
> > +   fixed_mode = intel_panel_edid_fixed_mode(intel_connector);
> > +   if (fixed_mode)
> > +   goto out;
> >  
> > /* Failed to get EDID, what about VBT? */
> > if (dev_priv->vbt.lfp_lvds_vbt_mode) {
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index edd5540639b0..f42137512010 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -99,6 +99,33 @@ intel_find_panel_downclock(struct drm_i915_private 
> > *dev_priv,
> > return NULL;
> >  }
> >  
> 

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Introduce private PAT management"

2019-03-22 Thread Chris Wilson
Quoting Michał Winiarski (2019-03-22 16:20:37)
> This reverts commit 4395890a48551982549d222d1923e2833dac47cf.
> 
> It's been over a year since this was merged, and the actual users of
> intel_ppat_get / intel_ppat_put never materialized.
> 
> Time to remove it!
> 
> Fixes: 4395890a4855 ("drm/i915: Introduce private PAT management")
> Signed-off-by: Michał Winiarski 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: Zhi Wang 

All the magic numbers seem to be intact,
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] Revert "drm/i915: Introduce private PAT management"

2019-03-22 Thread Michał Winiarski
This reverts commit 4395890a48551982549d222d1923e2833dac47cf.

It's been over a year since this was merged, and the actual users of
intel_ppat_get / intel_ppat_put never materialized.

Time to remove it!

Fixes: 4395890a4855 ("drm/i915: Introduce private PAT management")
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_drv.h |   2 -
 drivers/gpu/drm/i915/i915_gem_gtt.c | 278 
 drivers/gpu/drm/i915/i915_gem_gtt.h |  36 
 3 files changed, 40 insertions(+), 276 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fefcb39aefc4..d29a3f23f80f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1656,8 +1656,6 @@ struct drm_i915_private {
DECLARE_HASHTABLE(mm_structs, 7);
struct mutex mm_lock;
 
-   struct intel_ppat ppat;
-
/* Kernel Modesetting */
 
struct intel_crtc *plane_to_crtc_mapping[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b9e0e3a00223..c773fa65b4c6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2881,203 +2881,26 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, 
u64 size)
return 0;
 }
 
-static struct intel_ppat_entry *
-__alloc_ppat_entry(struct intel_ppat *ppat, unsigned int index, u8 value)
+static void cnl_setup_private_ppat(struct drm_i915_private *dev_priv)
 {
-   struct intel_ppat_entry *entry = >entries[index];
-
-   GEM_BUG_ON(index >= ppat->max_entries);
-   GEM_BUG_ON(test_bit(index, ppat->used));
-
-   entry->ppat = ppat;
-   entry->value = value;
-   kref_init(>ref);
-   set_bit(index, ppat->used);
-   set_bit(index, ppat->dirty);
-
-   return entry;
-}
-
-static void __free_ppat_entry(struct intel_ppat_entry *entry)
-{
-   struct intel_ppat *ppat = entry->ppat;
-   unsigned int index = entry - ppat->entries;
-
-   GEM_BUG_ON(index >= ppat->max_entries);
-   GEM_BUG_ON(!test_bit(index, ppat->used));
-
-   entry->value = ppat->clear_value;
-   clear_bit(index, ppat->used);
-   set_bit(index, ppat->dirty);
-}
-
-/**
- * intel_ppat_get - get a usable PPAT entry
- * @i915: i915 device instance
- * @value: the PPAT value required by the caller
- *
- * The function tries to search if there is an existing PPAT entry which
- * matches with the required value. If perfectly matched, the existing PPAT
- * entry will be used. If only partially matched, it will try to check if
- * there is any available PPAT index. If yes, it will allocate a new PPAT
- * index for the required entry and update the HW. If not, the partially
- * matched entry will be used.
- */
-const struct intel_ppat_entry *
-intel_ppat_get(struct drm_i915_private *i915, u8 value)
-{
-   struct intel_ppat *ppat = >ppat;
-   struct intel_ppat_entry *entry = NULL;
-   unsigned int scanned, best_score;
-   int i;
-
-   GEM_BUG_ON(!ppat->max_entries);
-
-   scanned = best_score = 0;
-   for_each_set_bit(i, ppat->used, ppat->max_entries) {
-   unsigned int score;
-
-   score = ppat->match(ppat->entries[i].value, value);
-   if (score > best_score) {
-   entry = >entries[i];
-   if (score == INTEL_PPAT_PERFECT_MATCH) {
-   kref_get(>ref);
-   return entry;
-   }
-   best_score = score;
-   }
-   scanned++;
-   }
-
-   if (scanned == ppat->max_entries) {
-   if (!entry)
-   return ERR_PTR(-ENOSPC);
-
-   kref_get(>ref);
-   return entry;
-   }
-
-   i = find_first_zero_bit(ppat->used, ppat->max_entries);
-   entry = __alloc_ppat_entry(ppat, i, value);
-   ppat->update_hw(i915);
-   return entry;
-}
-
-static void release_ppat(struct kref *kref)
-{
-   struct intel_ppat_entry *entry =
-   container_of(kref, struct intel_ppat_entry, ref);
-   struct drm_i915_private *i915 = entry->ppat->i915;
-
-   __free_ppat_entry(entry);
-   entry->ppat->update_hw(i915);
-}
-
-/**
- * intel_ppat_put - put back the PPAT entry got from intel_ppat_get()
- * @entry: an intel PPAT entry
- *
- * Put back the PPAT entry got from intel_ppat_get(). If the PPAT index of the
- * entry is dynamically allocated, its reference count will be decreased. Once
- * the reference count becomes into zero, the PPAT index becomes free again.
- */
-void intel_ppat_put(const struct intel_ppat_entry *entry)
-{
-   struct intel_ppat *ppat = entry->ppat;
-   unsigned int index = entry - ppat->entries;
-
-   GEM_BUG_ON(!ppat->max_entries);
-
-   kref_put(>entries[index].ref, release_ppat);
-}
-
-static void 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/8] drm/i915/psr: Remove partial PSR support on multiple transcoders

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [1/8] drm/i915/psr: Remove partial PSR support on 
multiple transcoders
URL   : https://patchwork.freedesktop.org/series/58373/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12556_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@reset-stress:
- shard-snb:  PASS -> FAIL [fdo#109661]

  * igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-iclb: PASS -> INCOMPLETE [fdo#109801]

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +114

  * igt@gem_pwrite@stolen-normal:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@gem_stolen@stolen-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@gem_tiled_blits@interruptible:
- shard-iclb: PASS -> TIMEOUT [fdo#109673]

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +2

  * igt@i915_pm_rpm@i2c:
- shard-skl:  PASS -> INCOMPLETE [fdo#107807] +1

  * igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +9

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_chamelium@hdmi-hpd-storm:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw:  PASS -> FAIL [fdo#103355]

  * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  PASS -> INCOMPLETE [fdo#109507]

  * igt@kms_flip@plain-flip-fb-recreate:
- shard-skl:  PASS -> FAIL [fdo#100368]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#108040]

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +8

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +28

  * igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
- shard-skl:  NOTRUN -> FAIL [fdo#105683]

  * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#109247] +19

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-kbl:  PASS -> DMESG-WARN [fdo#103313]

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@cursor_mmap_gtt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +3

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: PASS -> SKIP [fdo#109441] +5

  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl:  PASS -> DMESG-FAIL [fdo#105763]

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@perf@blocking:
- shard-iclb: PASS -> FAIL [fdo#108587]

  * igt@perf@unprivileged-single-ctx-counters:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  
 Possible fixes 

  * igt@gem_tiled_pread_pwrite:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> PASS

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-skl:  INCOMPLETE 

Re: [Intel-gfx] [v2 2/2] drm/i915/icl: Fix port disable sequence for mipi-dsi

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 03:37:35PM +, Kulkarni, Vandita wrote:
> 
> 
> > -Original Message-
> > From: Ville Syrjälä 
> > Sent: Friday, March 22, 2019 8:02 PM
> > To: Kulkarni, Vandita 
> > Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> > Subject: Re: [Intel-gfx] [v2 2/2] drm/i915/icl: Fix port disable sequence 
> > for mipi-
> > dsi
> > 
> > On Fri, Mar 22, 2019 at 05:43:52PM +0530, Vandita Kulkarni wrote:
> > > Re-enable clock gating of DDI clocks.
> > >
> > > v2: Fix the default ddi clk state for mipi-dsi (Imre)
> > >
> > > Fixes: 1026bea00381 (drm/i915/icl: Ungate DSI clocks)
> > > Signed-off-by: Vandita Kulkarni 
> > > ---
> > >  drivers/gpu/drm/i915/icl_dsi.c   | 2 +-
> > >  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> > >  2 files changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/icl_dsi.c
> > > b/drivers/gpu/drm/i915/icl_dsi.c index 6a5b9fa..5caf41f 100644
> > > --- a/drivers/gpu/drm/i915/icl_dsi.c
> > > +++ b/drivers/gpu/drm/i915/icl_dsi.c
> > > @@ -1124,7 +1124,7 @@ static void gen11_dsi_disable_port(struct
> > intel_encoder *encoder)
> > >   DRM_ERROR("DDI port:%c buffer not idle\n",
> > > port_name(port));
> > >   }
> > > - gen11_dsi_ungate_clocks(encoder);
> > > + gen11_dsi_gate_clocks(encoder);
> > >  }
> > >
> > >  static void gen11_dsi_disable_io_power(struct intel_encoder *encoder)
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 933df3a..17a03fa 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -2821,10 +2821,10 @@ void icl_sanitize_encoder_pll_mapping(struct
> > intel_encoder *encoder)
> > >   return;
> > >   }
> > >   /*
> > > -  * DSI ports should have their DDI clock ungated when disabled
> > > -  * and gated when enabled.
> > > +  * For MIPI DSI we unagate the clocks later as part of
> > > +  * enable sequence. Keep them gated by default.
> > >*/
> > > - ddi_clk_needed = !encoder->base.crtc;
> > > + ddi_clk_needed = false;
> > 
> > Should that be true?
> No. False. 
> We are comparing ddi_clk_needed with clock ungated which is false for mipi 
> dsi. 
> So we do nothing in this function if it is already gated, and gate it if we 
> have ungated = true.

The comment is confusing me. Should it be something more like this?

/*
 * With DSI the clocks are always gated
 * except during the enable/disable sequence.
 */

> 
> Regards,
> Vandita
> 
> > 
> > >   }
> > >
> > >   val = I915_READ(DPCLKA_CFGCR0_ICL);
> > > --
> > > 1.9.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > --
> > Ville Syrjälä
> > Intel

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

Re: [Intel-gfx] [RFC v1 1/7] drm/i915: Add gamma mode property

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 03:42:43PM +, Brian Starkey wrote:
> On Fri, Mar 22, 2019 at 04:02:57PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 22, 2019 at 01:39:04PM +, Brian Starkey wrote:
> > > Hi,
> > > 
> > > On Fri, Mar 22, 2019 at 01:06:01PM +, Shankar, Uma wrote:
> > > > 
> > > > 
> > > > >-Original Message-
> > > > >From: Roper, Matthew D
> > > > >Sent: Friday, March 22, 2019 2:50 AM
> > > > >To: Shankar, Uma 
> > > > >Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
> > > > >; Syrjala, Ville 
> > > > >; Sharma,
> > > > >Shashank 
> > > > >Subject: Re: [RFC v1 1/7] drm/i915: Add gamma mode property
> > > > >
> > > > >On Tue, Mar 19, 2019 at 02:00:12PM +0530, Uma Shankar wrote:
> > > > >> Gen platforms support multiple gamma modes, currently it's hard coded
> > > > >> to operate only in 1 specific mode.
> > > > >> This patch adds a property to make gamma mode programmable.
> > > > >> User can select which mode should be used for a particular usecase or
> > > > >> scenario.
> > > > >>
> > > > >> Signed-off-by: Uma Shankar 
> > > > >
> > > > >I haven't reviewed the series in depth, but I'm a bit confused on how 
> > > > >userspace would
> > > > >approach using this property.  This seems to be exposing hardware 
> > > > >implementation
> > > > >details that I wouldn't expect userspace to need to worry about (plus 
> > > > >I don't think any
> > > > >of the property values here convey any specific meaning to someone who 
> > > > >hasn't read
> > > > >the Intel bspec/PRM).  E.g., why does userspace care about "split 
> > > > >gamma" when the
> > > > >driver takes care of the programming details and userspace never sees 
> > > > >the actual way
> > > > >the registers are laid out and written?
> > > > >My understanding is that what really matters is how many table entries 
> > > > >there are for
> > > > >userspace to fill in, what input range(s) they cover, and how the bits 
> > > > >of each table
> > > > >entry are interpreted.  I think we'd want to handle this in a 
> > > > >vendor-agnostic way in the
> > > > >DRM core if possible; most of the display servers that get used these 
> > > > >days are cross-
> > > > >platform and probably won't want to add Intel-specific logic (or 
> > > > >platform-specific
> > > > >logic if we wind up with a different set of options on future Intel 
> > > > >platforms).
> > > > 
> > > > Ok, will try to re-structure this to make it vendor agnostic way. Also 
> > > > will add enough
> > > > documentation for the usage of the property. 
> > > > 
> > > > @Ville- What do you recommend or suggest for these interfaces.
> > > 
> > > Just to add to the conversation - some of our HW has fixed LUTs, which
> > > isn't really very well exposed by the current UAPI. We do it by having
> > > the kernel driver just look at the userspace-provided blob, and it if
> > > matches the fixed curve we accept it.
> > 
> > So you just have say "Use the sRGB curve" bit in some register etc.?
> 
> Yep, precisely. In the future, maybe multiple fixed LUTs to choose
> from.
> 
> > 
> > I think we should be able to integrate that somehow into my design:
> > https://github.com/vsyrjala/linux/commit/1aab7625dca77b831e05e32af17904c21300ff95
> >
> > 
> > Eg. just add a new DRM_MODE_LUT_FIXED_CURVE flag, and then I suppose
> > just add another member into the struct to indicate which curve it
> > is. And we could embed the fixed blob ID in there as well. That way
> > userspace wouldn't even have to actually get the blob for the curve.
> 
> Yeah that (ENUM | BLOB) API let's us be quite "rich" with the
> interface, so it certainly could fit in there.
> 
> If I understand the code correctly, each value in the enum list is the
> ID of a blob, and userspace can query that blob to figure out what the
> entry means (instead of needing _really really long_ descriptive
> strings).
> 
> I wonder if that property type in general is a little _too_ rich. I
> worry that it would be easy to just defer loads of vendor-specific
> detail into the blob, making the API look "generic" on the surface,
> when really it's effectively a list of vendor-defined (void *)s.
> 
> ...that said, in some cases vendor-defined (void *)s is what we might
> want (e.g. scaler coefficient tables).
> 
> Still looks like a neat idea, perhaps just needs some policy.

Yeah, I couldn't come up with anything better really. The options that
I see are as you say really long descriptive string, or we'd have to
update all userspace whenever a new enum value is added so that it
can decide what to do with it.

If we go with this idea, then I would definitely want to NAK any patch
that tries to abuse this for "we just need to expose these random
piles of hardware specific data".

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

Re: [Intel-gfx] [RFC v1 1/7] drm/i915: Add gamma mode property

2019-03-22 Thread Brian Starkey
On Fri, Mar 22, 2019 at 04:02:57PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 22, 2019 at 01:39:04PM +, Brian Starkey wrote:
> > Hi,
> > 
> > On Fri, Mar 22, 2019 at 01:06:01PM +, Shankar, Uma wrote:
> > > 
> > > 
> > > >-Original Message-
> > > >From: Roper, Matthew D
> > > >Sent: Friday, March 22, 2019 2:50 AM
> > > >To: Shankar, Uma 
> > > >Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
> > > >; Syrjala, Ville ; 
> > > >Sharma,
> > > >Shashank 
> > > >Subject: Re: [RFC v1 1/7] drm/i915: Add gamma mode property
> > > >
> > > >On Tue, Mar 19, 2019 at 02:00:12PM +0530, Uma Shankar wrote:
> > > >> Gen platforms support multiple gamma modes, currently it's hard coded
> > > >> to operate only in 1 specific mode.
> > > >> This patch adds a property to make gamma mode programmable.
> > > >> User can select which mode should be used for a particular usecase or
> > > >> scenario.
> > > >>
> > > >> Signed-off-by: Uma Shankar 
> > > >
> > > >I haven't reviewed the series in depth, but I'm a bit confused on how 
> > > >userspace would
> > > >approach using this property.  This seems to be exposing hardware 
> > > >implementation
> > > >details that I wouldn't expect userspace to need to worry about (plus I 
> > > >don't think any
> > > >of the property values here convey any specific meaning to someone who 
> > > >hasn't read
> > > >the Intel bspec/PRM).  E.g., why does userspace care about "split gamma" 
> > > >when the
> > > >driver takes care of the programming details and userspace never sees 
> > > >the actual way
> > > >the registers are laid out and written?
> > > >My understanding is that what really matters is how many table entries 
> > > >there are for
> > > >userspace to fill in, what input range(s) they cover, and how the bits 
> > > >of each table
> > > >entry are interpreted.  I think we'd want to handle this in a 
> > > >vendor-agnostic way in the
> > > >DRM core if possible; most of the display servers that get used these 
> > > >days are cross-
> > > >platform and probably won't want to add Intel-specific logic (or 
> > > >platform-specific
> > > >logic if we wind up with a different set of options on future Intel 
> > > >platforms).
> > > 
> > > Ok, will try to re-structure this to make it vendor agnostic way. Also 
> > > will add enough
> > > documentation for the usage of the property. 
> > > 
> > > @Ville- What do you recommend or suggest for these interfaces.
> > 
> > Just to add to the conversation - some of our HW has fixed LUTs, which
> > isn't really very well exposed by the current UAPI. We do it by having
> > the kernel driver just look at the userspace-provided blob, and it if
> > matches the fixed curve we accept it.
> 
> So you just have say "Use the sRGB curve" bit in some register etc.?

Yep, precisely. In the future, maybe multiple fixed LUTs to choose
from.

> 
> I think we should be able to integrate that somehow into my design:
> https://github.com/vsyrjala/linux/commit/1aab7625dca77b831e05e32af17904c21300ff95
>
> 
> Eg. just add a new DRM_MODE_LUT_FIXED_CURVE flag, and then I suppose
> just add another member into the struct to indicate which curve it
> is. And we could embed the fixed blob ID in there as well. That way
> userspace wouldn't even have to actually get the blob for the curve.

Yeah that (ENUM | BLOB) API let's us be quite "rich" with the
interface, so it certainly could fit in there.

If I understand the code correctly, each value in the enum list is the
ID of a blob, and userspace can query that blob to figure out what the
entry means (instead of needing _really really long_ descriptive
strings).

I wonder if that property type in general is a little _too_ rich. I
worry that it would be easy to just defer loads of vendor-specific
detail into the blob, making the API look "generic" on the surface,
when really it's effectively a list of vendor-defined (void *)s.

...that said, in some cases vendor-defined (void *)s is what we might
want (e.g. scaler coefficient tables).

Still looks like a neat idea, perhaps just needs some policy.

Thanks,
-Brian

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

Re: [Intel-gfx] [v2 2/2] drm/i915/icl: Fix port disable sequence for mipi-dsi

2019-03-22 Thread Kulkarni, Vandita


> -Original Message-
> From: Ville Syrjälä 
> Sent: Friday, March 22, 2019 8:02 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [Intel-gfx] [v2 2/2] drm/i915/icl: Fix port disable sequence for 
> mipi-
> dsi
> 
> On Fri, Mar 22, 2019 at 05:43:52PM +0530, Vandita Kulkarni wrote:
> > Re-enable clock gating of DDI clocks.
> >
> > v2: Fix the default ddi clk state for mipi-dsi (Imre)
> >
> > Fixes: 1026bea00381 (drm/i915/icl: Ungate DSI clocks)
> > Signed-off-by: Vandita Kulkarni 
> > ---
> >  drivers/gpu/drm/i915/icl_dsi.c   | 2 +-
> >  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/icl_dsi.c
> > b/drivers/gpu/drm/i915/icl_dsi.c index 6a5b9fa..5caf41f 100644
> > --- a/drivers/gpu/drm/i915/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/icl_dsi.c
> > @@ -1124,7 +1124,7 @@ static void gen11_dsi_disable_port(struct
> intel_encoder *encoder)
> > DRM_ERROR("DDI port:%c buffer not idle\n",
> >   port_name(port));
> > }
> > -   gen11_dsi_ungate_clocks(encoder);
> > +   gen11_dsi_gate_clocks(encoder);
> >  }
> >
> >  static void gen11_dsi_disable_io_power(struct intel_encoder *encoder)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 933df3a..17a03fa 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2821,10 +2821,10 @@ void icl_sanitize_encoder_pll_mapping(struct
> intel_encoder *encoder)
> > return;
> > }
> > /*
> > -* DSI ports should have their DDI clock ungated when disabled
> > -* and gated when enabled.
> > +* For MIPI DSI we unagate the clocks later as part of
> > +* enable sequence. Keep them gated by default.
> >  */
> > -   ddi_clk_needed = !encoder->base.crtc;
> > +   ddi_clk_needed = false;
> 
> Should that be true?
No. False. 
We are comparing ddi_clk_needed with clock ungated which is false for mipi dsi. 
So we do nothing in this function if it is already gated, and gate it if we 
have ungated = true.

Regards,
Vandita

> 
> > }
> >
> > val = I915_READ(DPCLKA_CFGCR0_ICL);
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Handle YUV subpixel support better

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Handle YUV subpixel support better
URL   : https://patchwork.freedesktop.org/series/58415/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5795 -> Patchwork_12574


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g:   NOTRUN -> FAIL [fdo#108094]

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-skl-6700k2:  NOTRUN -> SKIP [fdo#109271] +41

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] +55

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109315] +17

  * igt@gem_exec_basic@basic-bsd2:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109276] +7

  * igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_exec_basic@readonly-bsd:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76

  * igt@gem_exec_basic@readonly-bsd1:
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] +57

  * igt@gem_exec_gttfill@basic:
- fi-skl-gvtdvm:  NOTRUN -> SKIP [fdo#109271] +41

  * igt@gem_exec_parse@basic-rejected:
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109289] +1

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   PASS -> INCOMPLETE [fdo#107718]

  * igt@i915_selftest@live_contexts:
- fi-icl-u3:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-a:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-bsw-kefka:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-snb-2520m:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-bsw-n3050:   NOTRUN -> SKIP [fdo#109271] +62
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109284] +8

  * igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275:   NOTRUN -> SKIP [fdo#109271] +45
- fi-icl-u3:  NOTRUN -> SKIP [fdo#109285] +3

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  NOTRUN -> FAIL [fdo#103167]

  
 Possible fixes 

  * igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g:   DMESG-WARN [fdo#108965] -> PASS

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315


Participating hosts (33 -> 35)
--

  Additional (10): fi-skl-gvtdvm fi-bsw-n3050 fi-bwr-2160 fi-snb-2520m 
fi-kbl-x1275 fi-icl-u3 fi-pnv-d510 fi-bsw-kefka fi-skl-lmem fi-skl-6700k2 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan 
fi-ctg-p8600 fi-bdw-samus fi-skl-6600u 


Build changes
-

* Linux: CI_DRM_5795 -> Patchwork_12574

  CI_DRM_5795: 9b13e20521f1b66a20161bd3afd6727f383db604 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4899: ba96339c238180b38d05d7fa2dca772d49eee332 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12574: b0ef46492fd51bec7c1deabdedc48f1b308c3a52 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b0ef46492fd5 drm/i915: Reject rotation for some hdr formats
429898f76420 drm/i915: Reject Yf tiling for HDR formats, v2.
26e8aad601f1 drm/i915: Handle YUV subpixel support better

== Logs ==

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

Re: [Intel-gfx] [v2 1/2] drm/i915/icl: Ungate ddi clocks before IO enable

2019-03-22 Thread Kulkarni, Vandita


> -Original Message-
> From: Ville Syrjälä 
> Sent: Friday, March 22, 2019 8:03 PM
> To: Kulkarni, Vandita 
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani 
> Subject: Re: [Intel-gfx] [v2 1/2] drm/i915/icl: Ungate ddi clocks before IO 
> enable
> 
> On Fri, Mar 22, 2019 at 05:43:51PM +0530, Vandita Kulkarni wrote:
> > IO enable sequencing needs ddi clocks enabled.
> > These clocks will be gated at a later point in the enable sequence.
> >
> > v2: Fix the commit header (uma)
> >
> > Signed-off-by: Vandita Kulkarni 
> > Reviewed-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/icl_dsi.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/icl_dsi.c
> > b/drivers/gpu/drm/i915/icl_dsi.c index beb30d9..6a5b9fa 100644
> > --- a/drivers/gpu/drm/i915/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/icl_dsi.c
> > @@ -589,6 +589,13 @@ static void gen11_dsi_map_pll(struct intel_encoder
> *encoder,
> > val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
> > }
> > I915_WRITE(DPCLKA_CFGCR0_ICL, val);
> > +
> > +   val = I915_READ(DPCLKA_CFGCR0_ICL);
> 
> This read looks totally redundant.
Yes, it should have written what is in val already. thanks for the review. Will 
remove it.

Regards,
Vandita
> 
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   val &= ~DPCLKA_CFGCR0_DDI_CLK_OFF(port);
> > +   }
> > +   I915_WRITE(DPCLKA_CFGCR0_ICL, val);
> > +
> > POSTING_READ(DPCLKA_CFGCR0_ICL);
> >
> > mutex_unlock(_priv->dpll_lock);
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Really calculate the cursor ddb based on the highest enabled wm level

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915: Really calculate the cursor ddb based on the highest enabled 
wm level
URL   : https://patchwork.freedesktop.org/series/58372/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5791_full -> Patchwork_12555_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-clear:
- shard-hsw:  PASS -> INCOMPLETE [fdo#103540]

  * igt@gem_pwrite@big-cpu-fbr:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] +116

  * igt@gem_pwrite@stolen-normal:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] +21

  * igt@gem_stolen@stolen-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109277]

  * igt@i915_hangman@error-state-capture-bsd2:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +2

  * igt@i915_pm_rpm@system-suspend-modeset:
- shard-skl:  PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] / 
[fdo#107807]

  * igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]

  * igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl:  NOTRUN -> DMESG-WARN [fdo#110222] +2

  * igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-apl:  NOTRUN -> DMESG-WARN [fdo#110222]

  * igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-skl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12

  * igt@kms_busy@extended-modeset-hang-oldfb-render-f:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +3

  * igt@kms_busy@extended-pageflip-hang-newfb-render-c:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6

  * igt@kms_chamelium@hdmi-hpd-storm:
- shard-iclb: NOTRUN -> SKIP [fdo#109284]

  * igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-skl:  NOTRUN -> INCOMPLETE [fdo#104108]

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw:  PASS -> FAIL [fdo#103355]

  * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +1

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  PASS -> FAIL [fdo#105363]

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-apl:  PASS -> INCOMPLETE [fdo#103927]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-glk:  PASS -> FAIL [fdo#103167]

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
- shard-iclb: PASS -> FAIL [fdo#103167] / [fdo#105682]

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-pwrite:
- shard-snb:  NOTRUN -> SKIP [fdo#109271] +36

  * igt@kms_frontbuffer_tracking@fbc-stridechange:
- shard-iclb: PASS -> FAIL [fdo#103167] +6

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#109247] +16

  * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-apl:  NOTRUN -> SKIP [fdo#109271] +28

  * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247] +1

  * igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +2

  * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-skl:  NOTRUN -> FAIL [fdo#108145] +2

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-kbl:  NOTRUN -> FAIL [fdo#108145]

  * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk:  PASS -> FAIL [fdo#108145] +1

  * igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl:  NOTRUN -> FAIL [fdo#107815] / [fdo#108145]

  * igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-glk:  PASS -> SKIP [fdo#109271] / [fdo#109278] +1

  * igt@kms_psr@primary_blt:
- shard-iclb: PASS -> FAIL [fdo#107383] / [fdo#110215] +2

  * igt@kms_psr@psr2_basic:
- shard-iclb: PASS -> SKIP [fdo#109441] +3

  * igt@kms_universal_plane@universal-plane-gen9-features-pipe-d:
- shard-kbl:  NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@perf@unprivileged-single-ctx-counters:
- shard-iclb: NOTRUN -> SKIP [fdo#109289]

  
 Possible fixes 

  * igt@gem_tiled_pread_pwrite:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS

  * igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> PASS

  * igt@i915_pm_rpm@reg-read-ioctl:
- shard-skl:  INCOMPLETE [fdo#107807] -> PASS

  * igt@i915_suspend@fence-restore-untiled:
- shard-apl:  DMESG-WARN [fdo#108566] -> PASS +1

  * igt@kms_atomic_transition@1x-modeset-transitions:
- shard-iclb: INCOMPLETE -> PASS

  * 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: Handle YUV subpixel support better

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Handle YUV subpixel support better
URL   : https://patchwork.freedesktop.org/series/58415/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Handle YUV subpixel support better
+drivers/gpu/drm/i915/intel_sprite.c:299:31: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_sprite.c:299:31: warning: expression using 
sizeof(void)

Commit: drm/i915: Reject Yf tiling for HDR formats, v2.
Okay!

Commit: drm/i915: Reject rotation for some hdr formats
Okay!

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Handle YUV subpixel support better

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Handle YUV subpixel support better
URL   : https://patchwork.freedesktop.org/series/58415/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
26e8aad601f1 drm/i915: Handle YUV subpixel support better
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#9: 
Y41x formats is a 4:4:4 format, so it can be addressed with pixel level 
accuracy.

-:51: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#51: FILE: drivers/gpu/drm/i915/intel_sprite.c:299:
+   hsub = vsub = max(fb->format->hsub, fb->format->vsub);

total: 0 errors, 1 warnings, 1 checks, 44 lines checked
429898f76420 drm/i915: Reject Yf tiling for HDR formats, v2.
b0ef46492fd5 drm/i915: Reject rotation for some hdr formats

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Skip object locking around a no-op set-domain ioctl

2019-03-22 Thread Chris Wilson
Quoting Ville Syrjälä (2019-03-22 14:28:37)
> On Thu, Mar 21, 2019 at 04:19:08PM +, Chris Wilson wrote:
> > If we are already in the desired write domain of a set-domain ioctl,
> > then there is nothing for us to do and we can quickly return back to
> > userspace, avoiding any lock contention. By recognising that the
> > write_domain is always a subset of the read_domains, and excluding the
> > no-op case of requiring 0 read_domains in the ioctl, we can infer if the
> > current write_domain matches the target read_domains, there is nothing
> > for us to do.
> > 
> > Secondary aspect of this is that we undo the arbitrary fetching and
> > potential flushing of all pages for a set-domain(.write=CPU) call on a
> > fresh object -- which was introduced simply because we do the get-pages
> > before taking the struct_mutex.
> > 
> > References: 40e62d5d6be8 ("drm/i915: Acquire the backing storage outside of 
> > struct_mutex in set-domain")
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 26 +++---
> >  1 file changed, 23 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 72374e952e4b..36f557002005 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1484,17 +1484,37 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, 
> > void *data,
> >   if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
> >   return -EINVAL;
> >  
> > - /* Having something in the write domain implies it's in the read
> > + /*
> > +  * Having something in the write domain implies it's in the read
> >* domain, and only that read domain.  Enforce that in the request.
> >*/
> > - if (write_domain != 0 && read_domains != write_domain)
> > + if (write_domain && read_domains != write_domain)
> >   return -EINVAL;
> >  
> > + if (!read_domains)
> > + return 0;
> 
> Hopefully no one is relying on read_domains==0 meaning cpu domain.
> That seems to be how this was handled before.

Hopefully not. None of the userspace has tried that, and I hope that the
idea of write_domain==0 meaning don't set a write_domain has conditioned
everyone into not using it.

> Or maybe we want -EIVNAL here?

Introducing new -EINVAL is also risky.

Hmm. So in case of trouble we should

if (!read_domains)
read_domain = DOMAIN_CPU.

Hopefully no one even notices such a subtle ABI change. Bugzilla watch
out!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v2 1/2] drm/i915/icl: Ungate ddi clocks before IO enable

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 05:43:51PM +0530, Vandita Kulkarni wrote:
> IO enable sequencing needs ddi clocks enabled.
> These clocks will be gated at a later point in
> the enable sequence.
> 
> v2: Fix the commit header (uma)
> 
> Signed-off-by: Vandita Kulkarni 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/icl_dsi.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index beb30d9..6a5b9fa 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -589,6 +589,13 @@ static void gen11_dsi_map_pll(struct intel_encoder 
> *encoder,
>   val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
>   }
>   I915_WRITE(DPCLKA_CFGCR0_ICL, val);
> +
> + val = I915_READ(DPCLKA_CFGCR0_ICL);

This read looks totally redundant.

> + for_each_dsi_port(port, intel_dsi->ports) {
> + val &= ~DPCLKA_CFGCR0_DDI_CLK_OFF(port);
> + }
> + I915_WRITE(DPCLKA_CFGCR0_ICL, val);
> +
>   POSTING_READ(DPCLKA_CFGCR0_ICL);
>  
>   mutex_unlock(_priv->dpll_lock);
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [v2 2/2] drm/i915/icl: Fix port disable sequence for mipi-dsi

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 05:43:52PM +0530, Vandita Kulkarni wrote:
> Re-enable clock gating of DDI clocks.
> 
> v2: Fix the default ddi clk state for mipi-dsi (Imre)
> 
> Fixes: 1026bea00381 (drm/i915/icl: Ungate DSI clocks)
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/icl_dsi.c   | 2 +-
>  drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index 6a5b9fa..5caf41f 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1124,7 +1124,7 @@ static void gen11_dsi_disable_port(struct intel_encoder 
> *encoder)
>   DRM_ERROR("DDI port:%c buffer not idle\n",
> port_name(port));
>   }
> - gen11_dsi_ungate_clocks(encoder);
> + gen11_dsi_gate_clocks(encoder);
>  }
>  
>  static void gen11_dsi_disable_io_power(struct intel_encoder *encoder)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 933df3a..17a03fa 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2821,10 +2821,10 @@ void icl_sanitize_encoder_pll_mapping(struct 
> intel_encoder *encoder)
>   return;
>   }
>   /*
> -  * DSI ports should have their DDI clock ungated when disabled
> -  * and gated when enabled.
> +  * For MIPI DSI we unagate the clocks later as part of
> +  * enable sequence. Keep them gated by default.
>*/
> - ddi_clk_needed = !encoder->base.crtc;
> + ddi_clk_needed = false;

Should that be true?

>   }
>  
>   val = I915_READ(DPCLKA_CFGCR0_ICL);
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Skip object locking around a no-op set-domain ioctl

2019-03-22 Thread Ville Syrjälä
On Thu, Mar 21, 2019 at 04:19:08PM +, Chris Wilson wrote:
> If we are already in the desired write domain of a set-domain ioctl,
> then there is nothing for us to do and we can quickly return back to
> userspace, avoiding any lock contention. By recognising that the
> write_domain is always a subset of the read_domains, and excluding the
> no-op case of requiring 0 read_domains in the ioctl, we can infer if the
> current write_domain matches the target read_domains, there is nothing
> for us to do.
> 
> Secondary aspect of this is that we undo the arbitrary fetching and
> potential flushing of all pages for a set-domain(.write=CPU) call on a
> fresh object -- which was introduced simply because we do the get-pages
> before taking the struct_mutex.
> 
> References: 40e62d5d6be8 ("drm/i915: Acquire the backing storage outside of 
> struct_mutex in set-domain")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 26 +++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 72374e952e4b..36f557002005 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1484,17 +1484,37 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, 
> void *data,
>   if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
>   return -EINVAL;
>  
> - /* Having something in the write domain implies it's in the read
> + /*
> +  * Having something in the write domain implies it's in the read
>* domain, and only that read domain.  Enforce that in the request.
>*/
> - if (write_domain != 0 && read_domains != write_domain)
> + if (write_domain && read_domains != write_domain)
>   return -EINVAL;
>  
> + if (!read_domains)
> + return 0;

Hopefully no one is relying on read_domains==0 meaning cpu domain.
That seems to be how this was handled before.

Or maybe we want -EIVNAL here?

> +
>   obj = i915_gem_object_lookup(file, args->handle);
>   if (!obj)
>   return -ENOENT;
>  
> - /* Try to flush the object off the GPU without holding the lock.
> + /*
> +  * Already in the desired target write domain? Nothing for us to!
> +  *
> +  * We apply a little bit of cunning here to catch a broader set of
> +  * no-ops. If obj->write_domain is set, we must be in the same
> +  * obj->read_domains, and only that domain. Therefore, if that
> +  * obj->write_domain matches the request read_domains, we are
> +  * already in the same read/write domain and can skip the operation,
> +  * without having to further check the requested write_domain.
> +  */
> + if (READ_ONCE(obj->write_domain) == read_domains) {
> + err = 0;
> + goto out;
> + }

Hard to argue with that logic. 

Haven't paid too much attention to this area lately but this
makes sense to me.

Reviewed-by: Ville Syrjälä 

> +
> + /*
> +  * Try to flush the object off the GPU without holding the lock.
>* We will repeat the flush holding the lock in the normal manner
>* to catch cases where we are gazumped.
>*/
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Handle YUV subpixel support better

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 02:59:52PM +0100, Maarten Lankhorst wrote:
> Y41x formats is a 4:4:4 format, so it can be addressed with pixel level 
> accuracy.
> Meanwhile it seems that while rotating YUYV 4:2:2 formats need a multiple of 2
> for width and height, otherwise corruption occurs.
> 
> For YUV 4:2:2, the spec says that w/h should always be even, but we get
> away with odd height while unrotated. When rotating it seems corruption
> occurs with an odd x/y, and w/h should always be even.
> Just to be completely paranoid, reject odd x/y w/h when rotating 90/270.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 3f2055f70d05..aca987356194 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -269,7 +269,8 @@ int intel_plane_check_src_coordinates(struct 
> intel_plane_state *plane_state)
>  {
>   const struct drm_framebuffer *fb = plane_state->base.fb;
>   struct drm_rect *src = _state->base.src;
> - u32 src_x, src_y, src_w, src_h;
> + u32 src_x, src_y, src_w, src_h, hsub, vsub;
> + bool rotated = drm_rotation_90_or_270(plane_state->base.rotation);
>  
>   /*
>* Hardware doesn't handle subpixel coordinates.
> @@ -287,18 +288,26 @@ int intel_plane_check_src_coordinates(struct 
> intel_plane_state *plane_state)
>   src->y1 = src_y << 16;
>   src->y2 = (src_y + src_h) << 16;
>  
> - if (fb->format->is_yuv &&
> - (src_x & 1 || src_w & 1)) {
> - DRM_DEBUG_KMS("src x/w (%u, %u) must be a multiple of 2 for YUV 
> planes\n",
> -   src_x, src_w);
> + if (!fb->format->is_yuv)
> + return 0;
> +
> + /* YUV specific checks */
> + if (!rotated) {
> + hsub = fb->format->hsub;
> + vsub = fb->format->vsub;
> + } else {

This could maybe use a comment of some sort. But can't think of one
right now so meh.

Reviewed-by: Ville Syrjälä 

> + hsub = vsub = max(fb->format->hsub, fb->format->vsub);
> + }
> +
> + if (src_x % hsub || src_w % hsub) {
> + DRM_DEBUG_KMS("src x/w (%u, %u) must be a multiple of %u for 
> %sYUV planes\n",
> +   src_x, src_w, hsub, rotated ? "rotated " : "");
>   return -EINVAL;
>   }
>  
> - if (fb->format->is_yuv &&
> - fb->format->num_planes > 1 &&
> - (src_y & 1 || src_h & 1)) {
> - DRM_DEBUG_KMS("src y/h (%u, %u) must be a multiple of 2 for 
> planar YUV planes\n",
> -   src_y, src_h);
> + if (src_y % vsub || src_h % vsub) {
> + DRM_DEBUG_KMS("src y/h (%u, %u) must be a multiple of %u for 
> %sYUV planes\n",
> +   src_y, src_h, vsub, rotated ? "rotated " : "");
>   return -EINVAL;
>   }
>  
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Reject rotation for some hdr formats

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 02:59:54PM +0100, Maarten Lankhorst wrote:
> 90/270 rotation is not supported for Y21x and the 12/16 bits XVYU formats,
> reject support for them.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 36ee39ec3687..65de7387bf1b 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1531,6 +1531,11 @@ static int skl_plane_check_fb(const struct 
> intel_crtc_state *crtc_state,
>   case DRM_FORMAT_XBGR16161616F:
>   case DRM_FORMAT_ARGB16161616F:
>   case DRM_FORMAT_ABGR16161616F:
> + case DRM_FORMAT_Y210:
> + case DRM_FORMAT_Y212:
> + case DRM_FORMAT_Y216:
> + case DRM_FORMAT_XVYU12_16161616:
> + case DRM_FORMAT_XVYU16161616:
>   DRM_DEBUG_KMS("Unsupported pixel format %s for 
> 90/270!\n",
> drm_get_format_name(fb->format->format,
> _name));
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Reject Yf tiling for HDR formats, v2.

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 02:59:53PM +0100, Maarten Lankhorst wrote:
> This was missing in the original addition of those formats, but in
> PLANE_SIZE description it's mentioned that 8 cpp formats are not
> valid with Yf tiling. Reject this case properly.
> 
> Also reject Y21x Yf tiling support this is also not supported.
> 
> Changes since v1:
> - Reject Y21x as well.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index aca987356194..36ee39ec3687 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -2107,12 +2107,7 @@ static bool skl_plane_format_mod_supported(struct 
> drm_plane *_plane,
>   case DRM_FORMAT_P010:
>   case DRM_FORMAT_P012:
>   case DRM_FORMAT_P016:
> - case DRM_FORMAT_Y210:
> - case DRM_FORMAT_Y212:
> - case DRM_FORMAT_Y216:
>   case DRM_FORMAT_XVYU2101010:
> - case DRM_FORMAT_XVYU12_16161616:
> - case DRM_FORMAT_XVYU16161616:
>   if (modifier == I915_FORMAT_MOD_Yf_TILED)
>   return true;
>   /* fall through */
> @@ -2121,6 +2116,11 @@ static bool skl_plane_format_mod_supported(struct 
> drm_plane *_plane,
>   case DRM_FORMAT_ABGR16161616F:
>   case DRM_FORMAT_XRGB16161616F:
>   case DRM_FORMAT_ARGB16161616F:
> + case DRM_FORMAT_Y210:
> + case DRM_FORMAT_Y212:
> + case DRM_FORMAT_Y216:
> + case DRM_FORMAT_XVYU12_16161616:
> + case DRM_FORMAT_XVYU16161616:
>   if (modifier == DRM_FORMAT_MOD_LINEAR ||
>   modifier == I915_FORMAT_MOD_X_TILED ||
>   modifier == I915_FORMAT_MOD_Y_TILED)
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [RFC v1 1/7] drm/i915: Add gamma mode property

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 01:39:04PM +, Brian Starkey wrote:
> Hi,
> 
> On Fri, Mar 22, 2019 at 01:06:01PM +, Shankar, Uma wrote:
> > 
> > 
> > >-Original Message-
> > >From: Roper, Matthew D
> > >Sent: Friday, March 22, 2019 2:50 AM
> > >To: Shankar, Uma 
> > >Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
> > >; Syrjala, Ville ; 
> > >Sharma,
> > >Shashank 
> > >Subject: Re: [RFC v1 1/7] drm/i915: Add gamma mode property
> > >
> > >On Tue, Mar 19, 2019 at 02:00:12PM +0530, Uma Shankar wrote:
> > >> Gen platforms support multiple gamma modes, currently it's hard coded
> > >> to operate only in 1 specific mode.
> > >> This patch adds a property to make gamma mode programmable.
> > >> User can select which mode should be used for a particular usecase or
> > >> scenario.
> > >>
> > >> Signed-off-by: Uma Shankar 
> > >
> > >I haven't reviewed the series in depth, but I'm a bit confused on how 
> > >userspace would
> > >approach using this property.  This seems to be exposing hardware 
> > >implementation
> > >details that I wouldn't expect userspace to need to worry about (plus I 
> > >don't think any
> > >of the property values here convey any specific meaning to someone who 
> > >hasn't read
> > >the Intel bspec/PRM).  E.g., why does userspace care about "split gamma" 
> > >when the
> > >driver takes care of the programming details and userspace never sees the 
> > >actual way
> > >the registers are laid out and written?
> > >My understanding is that what really matters is how many table entries 
> > >there are for
> > >userspace to fill in, what input range(s) they cover, and how the bits of 
> > >each table
> > >entry are interpreted.  I think we'd want to handle this in a 
> > >vendor-agnostic way in the
> > >DRM core if possible; most of the display servers that get used these days 
> > >are cross-
> > >platform and probably won't want to add Intel-specific logic (or 
> > >platform-specific
> > >logic if we wind up with a different set of options on future Intel 
> > >platforms).
> > 
> > Ok, will try to re-structure this to make it vendor agnostic way. Also will 
> > add enough
> > documentation for the usage of the property. 
> > 
> > @Ville- What do you recommend or suggest for these interfaces.
> 
> Just to add to the conversation - some of our HW has fixed LUTs, which
> isn't really very well exposed by the current UAPI. We do it by having
> the kernel driver just look at the userspace-provided blob, and it if
> matches the fixed curve we accept it.

So you just have say "Use the sRGB curve" bit in some register etc.?

I think we should be able to integrate that somehow into my design:
https://github.com/vsyrjala/linux/commit/1aab7625dca77b831e05e32af17904c21300ff95
   

Eg. just add a new DRM_MODE_LUT_FIXED_CURVE flag, and then I suppose
just add another member into the struct to indicate which curve it
is. And we could embed the fixed blob ID in there as well. That way
userspace wouldn't even have to actually get the blob for the curve.

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

[Intel-gfx] [PATCH 1/3] drm/i915: Handle YUV subpixel support better

2019-03-22 Thread Maarten Lankhorst
Y41x formats is a 4:4:4 format, so it can be addressed with pixel level 
accuracy.
Meanwhile it seems that while rotating YUYV 4:2:2 formats need a multiple of 2
for width and height, otherwise corruption occurs.

For YUV 4:2:2, the spec says that w/h should always be even, but we get
away with odd height while unrotated. When rotating it seems corruption
occurs with an odd x/y, and w/h should always be even.
Just to be completely paranoid, reject odd x/y w/h when rotating 90/270.

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

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 3f2055f70d05..aca987356194 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -269,7 +269,8 @@ int intel_plane_check_src_coordinates(struct 
intel_plane_state *plane_state)
 {
const struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_rect *src = _state->base.src;
-   u32 src_x, src_y, src_w, src_h;
+   u32 src_x, src_y, src_w, src_h, hsub, vsub;
+   bool rotated = drm_rotation_90_or_270(plane_state->base.rotation);
 
/*
 * Hardware doesn't handle subpixel coordinates.
@@ -287,18 +288,26 @@ int intel_plane_check_src_coordinates(struct 
intel_plane_state *plane_state)
src->y1 = src_y << 16;
src->y2 = (src_y + src_h) << 16;
 
-   if (fb->format->is_yuv &&
-   (src_x & 1 || src_w & 1)) {
-   DRM_DEBUG_KMS("src x/w (%u, %u) must be a multiple of 2 for YUV 
planes\n",
- src_x, src_w);
+   if (!fb->format->is_yuv)
+   return 0;
+
+   /* YUV specific checks */
+   if (!rotated) {
+   hsub = fb->format->hsub;
+   vsub = fb->format->vsub;
+   } else {
+   hsub = vsub = max(fb->format->hsub, fb->format->vsub);
+   }
+
+   if (src_x % hsub || src_w % hsub) {
+   DRM_DEBUG_KMS("src x/w (%u, %u) must be a multiple of %u for 
%sYUV planes\n",
+ src_x, src_w, hsub, rotated ? "rotated " : "");
return -EINVAL;
}
 
-   if (fb->format->is_yuv &&
-   fb->format->num_planes > 1 &&
-   (src_y & 1 || src_h & 1)) {
-   DRM_DEBUG_KMS("src y/h (%u, %u) must be a multiple of 2 for 
planar YUV planes\n",
- src_y, src_h);
+   if (src_y % vsub || src_h % vsub) {
+   DRM_DEBUG_KMS("src y/h (%u, %u) must be a multiple of %u for 
%sYUV planes\n",
+ src_y, src_h, vsub, rotated ? "rotated " : "");
return -EINVAL;
}
 
-- 
2.20.1

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

[Intel-gfx] [PATCH 2/3] drm/i915: Reject Yf tiling for HDR formats, v2.

2019-03-22 Thread Maarten Lankhorst
This was missing in the original addition of those formats, but in
PLANE_SIZE description it's mentioned that 8 cpp formats are not
valid with Yf tiling. Reject this case properly.

Also reject Y21x Yf tiling support this is also not supported.

Changes since v1:
- Reject Y21x as well.

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

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index aca987356194..36ee39ec3687 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -2107,12 +2107,7 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
-   case DRM_FORMAT_Y210:
-   case DRM_FORMAT_Y212:
-   case DRM_FORMAT_Y216:
case DRM_FORMAT_XVYU2101010:
-   case DRM_FORMAT_XVYU12_16161616:
-   case DRM_FORMAT_XVYU16161616:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -2121,6 +2116,11 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
case DRM_FORMAT_ABGR16161616F:
case DRM_FORMAT_XRGB16161616F:
case DRM_FORMAT_ARGB16161616F:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_XVYU12_16161616:
+   case DRM_FORMAT_XVYU16161616:
if (modifier == DRM_FORMAT_MOD_LINEAR ||
modifier == I915_FORMAT_MOD_X_TILED ||
modifier == I915_FORMAT_MOD_Y_TILED)
-- 
2.20.1

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

[Intel-gfx] [PATCH 3/3] drm/i915: Reject rotation for some hdr formats

2019-03-22 Thread Maarten Lankhorst
90/270 rotation is not supported for Y21x and the 12/16 bits XVYU formats,
reject support for them.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 36ee39ec3687..65de7387bf1b 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1531,6 +1531,11 @@ static int skl_plane_check_fb(const struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_XBGR16161616F:
case DRM_FORMAT_ARGB16161616F:
case DRM_FORMAT_ABGR16161616F:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_XVYU12_16161616:
+   case DRM_FORMAT_XVYU16161616:
DRM_DEBUG_KMS("Unsupported pixel format %s for 
90/270!\n",
  drm_get_format_name(fb->format->format,
  _name));
-- 
2.20.1

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

Re: [Intel-gfx] [RFC v1 3/7] drm/i915: Add Support for Multi Segment Gamma Mode

2019-03-22 Thread Ville Syrjälä
On Wed, Mar 20, 2019 at 05:03:16PM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: Syrjala, Ville
> >Sent: Tuesday, March 19, 2019 10:29 PM
> >To: Lankhorst, Maarten 
> >Cc: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> >Sharma, Shashank ; Roper, Matthew D
> >
> >Subject: Re: [RFC v1 3/7] drm/i915: Add Support for Multi Segment Gamma Mode
> >
> >On Tue, Mar 19, 2019 at 10:46:27AM +0200, Lankhorst, Maarten wrote:
> >> tis 2019-03-19 klockan 14:00 +0530 skrev Uma Shankar:
> >> > Multi Segment Gamma Mode is added in Gen11+ platforms.
> >> > Added a property interface to enable that.
> >> >
> >> > Signed-off-by: Uma Shankar 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_drv.h|  1 +
> >> >  drivers/gpu/drm/i915/intel_color.c | 23 +++
> >> >  include/uapi/drm/i915_drm.h| 14 ++
> >> >  3 files changed, 38 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> > b/drivers/gpu/drm/i915/i915_drv.h index 02231ae..f20d418 100644
> >> > --- a/drivers/gpu/drm/i915/i915_drv.h
> >> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> > @@ -1736,6 +1736,7 @@ struct drm_i915_private {
> >> >  struct drm_property *force_audio_property;
> >> >
> >> >  struct drm_property *gamma_mode_property;
> >> > +struct drm_property *multi_segment_gamma_mode_property;
> >>
> >> Seems to me both properties should be part of drm core?
> 
> Sure Maarten, we can move gamma_mode property to drm.
> 
> >>
> >> >  /* hda/i915 audio component */
> >> >  struct i915_audio_component *audio_component; diff --git
> >> > a/drivers/gpu/drm/i915/intel_color.c
> >> > b/drivers/gpu/drm/i915/intel_color.c
> >> > index 9d43d19..399d63d 100644
> >> > --- a/drivers/gpu/drm/i915/intel_color.c
> >> > +++ b/drivers/gpu/drm/i915/intel_color.c
> >> > @@ -149,6 +149,26 @@ static bool crtc_state_is_legacy_gamma(const
> >> > struct intel_crtc_state *crtc_state
> >> >  drm_object_attach_property(>base.base, prop, 0);  }
> >> >
> >> > +void
> >> > +intel_attach_multi_segment_gamma_mode_property(struct intel_crtc
> >> > *crtc)
> >> > +{
> >> > +struct drm_device *dev = crtc->base.dev;
> >> > +struct drm_i915_private *dev_priv = to_i915(dev);
> >> > +struct drm_property *prop;
> >> > +
> >> > +prop = dev_priv->multi_segment_gamma_mode_property;
> >> > +if (!prop) {
> >> > +prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> >> > +   "Multi-segment Gamma",
> >> > 0);
> >> > +if (!prop)
> >> > +return;
> >> > +
> >> > +dev_priv->multi_segment_gamma_mode_property = prop;
> >> > +}
> >> > +
> >> > +drm_object_attach_property(>base.base, prop, 0); }
> >> > +
> >> >  /*
> >> >   * When using limited range, multiply the matrix given by userspace
> >> > by
> >> >   * the matrix that we would use for the limited range.
> >> > @@ -953,4 +973,7 @@ void intel_color_init(struct intel_crtc *crtc)
> >> > INTEL_INFO(dev_priv)-
> >> > >color.gamma_lut_size);
> >> >
> >> >  intel_attach_gamma_mode_property(crtc);
> >> > +
> >> > +if (INTEL_GEN(dev_priv) >= 11)
> >> > +intel_attach_multi_segment_gamma_mode_property(crtc)
> >> > ;
> >> >  }
> >> > diff --git a/include/uapi/drm/i915_drm.h
> >> > b/include/uapi/drm/i915_drm.h index aa2d4c7..8f1974e 100644
> >> > --- a/include/uapi/drm/i915_drm.h
> >> > +++ b/include/uapi/drm/i915_drm.h
> >> > @@ -1842,6 +1842,20 @@ struct drm_i915_query_topology_info {
> >> >  __u8 data[];
> >> >  };
> >> >
> >> > +/*
> >> > + * Structure for muti segmented gamma lut  */ struct
> >> > +multi_segment_gamma_lut {
> >> > +/* Number of Lut Segments */
> >> > +__u8 segment_cnt;
> >> > +/* Precison of LUT entries in bits */
> >> > +__u8 precision_bits;
> >> > +/* Pointer having number of LUT elements in each segment */
> >> > +__u32 *segment_lut_cnt_ptr;
> >> > +/* Pointer to store exact lut values for each segment */
> >> > +__u32 *segment_lut_ptr;
> >> > +};
> >> >
> >> And perhaps a variation of this as description for all gamma mode
> >> types.
> >
> >This is my old idea how to represent fancier LUTs:
> >https://github.com/vsyrjala/linux/commit/1aab7625dca77b831e05e32af17904c2130
> >0ff95
> >https://github.com/vsyrjala/linux/commit/74ffa5d441702c53830f6d71bb687bb0ae5a
> >a58f
> >
> >Each distinct segment of the curve would be just described by a fixed size 
> >range
> >descriptor, and the entire blob would be made up of however many of those are
> >needed.
> >
> >That way we don't even need any multi-segment uapi for setting up the LUT. 
> >The blob
> >for that would just contain as many entries as the LUT needs in that 
> >specific mode.
> 
> Hi Ville,
> This also sounds good.  What is your suggestion on this. Any 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/icl: Ungate ddi clocks before IO enable

2019-03-22 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/2] drm/i915/icl: Ungate ddi clocks before IO 
enable
URL   : https://patchwork.freedesktop.org/series/58408/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5794 -> Patchwork_12573


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> SKIP [fdo#109315] +17

  * igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_exec_basic@gtt-bsd1:
- fi-bxt-j4205:   NOTRUN -> SKIP [fdo#109271] +47

  * igt@gem_exec_basic@gtt-bsd2:
- fi-kbl-7500u:   NOTRUN -> SKIP [fdo#109271] +9

  * igt@gem_exec_basic@readonly-bsd:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76

  * igt@gem_exec_basic@readonly-bsd1:
- fi-icl-u2:  NOTRUN -> SKIP [fdo#109276] +7

  * igt@gem_exec_parse@basic-allowed:
- fi-icl-u2:  NOTRUN -> SKIP [fdo#109289] +1

  * igt@i915_selftest@live_contexts:
- fi-icl-u2:  NOTRUN -> DMESG-FAIL [fdo#108569]

  * igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-byt-j1900:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   NOTRUN -> DMESG-WARN [fdo#103841]

  * igt@kms_chamelium@dp-hpd-fast:
- fi-icl-u2:  NOTRUN -> SKIP [fdo#109316] +2

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> SKIP [fdo#109271] +52

  * igt@kms_chamelium@vga-edid-read:
- fi-hsw-4770r:   NOTRUN -> SKIP [fdo#109271] +45
- fi-icl-u2:  NOTRUN -> SKIP [fdo#109309] +1

  * igt@kms_force_connector_basic@prune-stale-modes:
- fi-icl-u2:  NOTRUN -> SKIP [fdo#109285] +3

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> FAIL [fdo#103841]

  
 Possible fixes 

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   DMESG-WARN [fdo#107709] -> PASS

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3:  FAIL [fdo#103167] -> PASS

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
  [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#109316]: https://bugs.freedesktop.org/show_bug.cgi?id=109316


Participating hosts (32 -> 32)
--

  Additional (7): fi-hsw-4770r fi-byt-j1900 fi-icl-u2 fi-bwr-2160 fi-kbl-7500u 
fi-bxt-j4205 fi-pnv-d510 
  Missing(7): fi-bsw-n3050 fi-hsw-4200u fi-ctg-p8600 fi-hsw-4770 fi-gdg-551 
fi-byt-n2820 fi-skl-6700k2 


Build changes
-

* Linux: CI_DRM_5794 -> Patchwork_12573

  CI_DRM_5794: 487d6c295c12d99c218b489ab39618831d7d31d6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4898: be2f88cd36fd4ba836d9f2453e90673c86649489 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12573: 2004974083969c5dd4765a27f5be3ea1f7c1c523 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

200497408396 drm/i915/icl: Fix port disable sequence for mipi-dsi
357d05936372 drm/i915/icl: Ungate ddi clocks before IO enable

== Logs ==

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

Re: [Intel-gfx] [RFC v1 1/7] drm/i915: Add gamma mode property

2019-03-22 Thread Brian Starkey
Hi,

On Fri, Mar 22, 2019 at 01:06:01PM +, Shankar, Uma wrote:
> 
> 
> >-Original Message-
> >From: Roper, Matthew D
> >Sent: Friday, March 22, 2019 2:50 AM
> >To: Shankar, Uma 
> >Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
> >; Syrjala, Ville ; 
> >Sharma,
> >Shashank 
> >Subject: Re: [RFC v1 1/7] drm/i915: Add gamma mode property
> >
> >On Tue, Mar 19, 2019 at 02:00:12PM +0530, Uma Shankar wrote:
> >> Gen platforms support multiple gamma modes, currently it's hard coded
> >> to operate only in 1 specific mode.
> >> This patch adds a property to make gamma mode programmable.
> >> User can select which mode should be used for a particular usecase or
> >> scenario.
> >>
> >> Signed-off-by: Uma Shankar 
> >
> >I haven't reviewed the series in depth, but I'm a bit confused on how 
> >userspace would
> >approach using this property.  This seems to be exposing hardware 
> >implementation
> >details that I wouldn't expect userspace to need to worry about (plus I 
> >don't think any
> >of the property values here convey any specific meaning to someone who 
> >hasn't read
> >the Intel bspec/PRM).  E.g., why does userspace care about "split gamma" 
> >when the
> >driver takes care of the programming details and userspace never sees the 
> >actual way
> >the registers are laid out and written?
> >My understanding is that what really matters is how many table entries there 
> >are for
> >userspace to fill in, what input range(s) they cover, and how the bits of 
> >each table
> >entry are interpreted.  I think we'd want to handle this in a 
> >vendor-agnostic way in the
> >DRM core if possible; most of the display servers that get used these days 
> >are cross-
> >platform and probably won't want to add Intel-specific logic (or 
> >platform-specific
> >logic if we wind up with a different set of options on future Intel 
> >platforms).
> 
> Ok, will try to re-structure this to make it vendor agnostic way. Also will 
> add enough
> documentation for the usage of the property. 
> 
> @Ville- What do you recommend or suggest for these interfaces.

Just to add to the conversation - some of our HW has fixed LUTs, which
isn't really very well exposed by the current UAPI. We do it by having
the kernel driver just look at the userspace-provided blob, and it if
matches the fixed curve we accept it.

I thought one way to expose this would be to have kernel-created blobs
representing the fixed LUTs, which userspace could query to figure out
what LUTs were available.

That might not need to interact with the proposals here, but perhaps
if there's going to be some kind kind of gamma-mode enumeration, fixed
LUTs could be considered there, too.

Cheers,
-Brian

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

Re: [Intel-gfx] [RFC v1 7/7] drm/i915: Add multi segment gamma for icl

2019-03-22 Thread Shankar, Uma


>-Original Message-
>From: Roper, Matthew D
>Sent: Friday, March 22, 2019 3:34 AM
>To: Shankar, Uma 
>Cc: intel-gfx@lists.freedesktop.org; Lankhorst, Maarten
>; Syrjala, Ville ; 
>Sharma,
>Shashank 
>Subject: Re: [RFC v1 7/7] drm/i915: Add multi segment gamma for icl
>
>On Tue, Mar 19, 2019 at 02:00:18PM +0530, Uma Shankar wrote:
>> Added support for ICL platform multi segment gamma capabilties and
>> attached the property, exposing the same to userspace.
>>
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/gpu/drm/i915/intel_color.c | 22 +-
>>  1 file changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index 7733c256..1e9f784 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -1011,6 +1011,8 @@ int intel_color_check(struct intel_crtc_state
>> *crtc_state)  void intel_color_init(struct intel_crtc *crtc)  {
>>  struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +struct multi_segment_gamma_lut multi_segment_lut;
>> +
>>
>>  drm_mode_crtc_set_gamma_size(>base, 256);
>>
>> @@ -1049,6 +1051,24 @@ void intel_color_init(struct intel_crtc *crtc)
>>
>>  intel_attach_gamma_mode_property(crtc);
>>
>> -if (INTEL_GEN(dev_priv) >= 11)
>> +if (IS_ICELAKE(dev_priv)) {
>
>Is it intentional to limit this specifically to Icelake?  This is basically 
>the opposite of the
>type of generalization that we've been moving toward with patches like
>
>commit 2dd24a9c2c8d767a976da37d59680f09b9d111ab
>Author: Rodrigo Vivi 
>Date:   Fri Mar 8 13:42:58 2019 -0800
>
>drm/i915/gen11+: First assume next platforms will inherit stuff
>
>Also, we already support another gen11 platform (or will once the mailing list 
>patches
>land) in the form of EHL; is there any reason that this shouldn't apply to it?

Yeah, it will/can-be re-used for future platforms with no/some slight changes. 
I will modify this
to align to our overall feature enabling plans in driver.

>
>> +multi_segment_lut.segment_cnt = 3;
>> +multi_segment_lut.precision_bits = 16;
>> +multi_segment_lut.segment_lut_cnt_ptr = kzalloc(3 * sizeof(int),
>> +GFP_KERNEL);
>> +if (!multi_segment_lut.segment_lut_cnt_ptr)
>> +return;
>> +multi_segment_lut.segment_lut_cnt_ptr[0] = 9;
>> +multi_segment_lut.segment_lut_cnt_ptr[1] = 256;
>> +multi_segment_lut.segment_lut_cnt_ptr[2] = 256;
>
>On this patch and the previous one we have a few magic numbers representing how
>the segmented gamma is laid out.  Can we move stuff like this into the device 
>info
>structure and then just setup the appropriate userspace properties on any 
>platform
>that has the device info fields filled in (i.e., the same way we do the basic 
>color
>management properties)?

Sure, I can move it to platform device info structures and make it transparent 
here.

Regards,
Uma Shankar
>
>Matt
>
>> +
>>  intel_attach_multi_segment_gamma_mode_property(crtc);
>> +
>> +drm_property_replace_global_blob(crtc->base.dev,
>> + >config-
>>multi_segment_gamma_lut,
>> + sizeof(struct
>multi_segment_gamma_lut),
>> + _segment_lut,
>> + >base.base,
>> + dev_priv-
>>multi_segment_gamma_mode_property);
>> +}
>>  }
>> --
>> 1.9.1
>>
>
>--
>Matt Roper
>Graphics Software Engineer
>IoTG Platform Enabling & Development
>Intel Corporation
>(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports

2019-03-22 Thread Ville Syrjälä
On Fri, Mar 22, 2019 at 11:34:25AM +0200, Jani Nikula wrote:
> On Thu, 21 Mar 2019, Manasi Navare  wrote:
> > In case of tiled displays where different tiles are displayed across
> > different ports, we need to synchronize the transcoders involved.
> > This patch implements the transcoder port sync feature for
> > synchronizing one master transcoder with one or more slave
> > transcoders. This is only enbaled in slave transcoder
> > and the master transcoder is unaware that it is operating
> > in this mode.
> > This has been tested with tiled display connected to ICL.
> >
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: Maarten Lankhorst 
> > Cc: Matt Roper 
> > Cc: Jani Nikula 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 59 
> >  1 file changed, 59 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9980a4ed8c9c..16b46a3cb3bd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4009,6 +4009,62 @@ static void icl_set_pipe_chicken(struct intel_crtc 
> > *crtc)
> > I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> >  }
> >  
> > +static void icl_set_transcoder_port_sync(struct intel_atomic_state 
> > *old_intel_state,
> > +const struct intel_crtc_state 
> > *crtc_state)
> > +{
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > +   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +   struct intel_crtc_state *genlock_crtc_state = NULL;
> > +   enum transcoder genlock_transcoder;
> > +   u32 trans_ddi_func_ctl2_val;
> > +   u8 master_select;
> > +
> > +   /*
> > +* Port Sync Mode cannot be enabled for DP MST
> > +*/
> > +   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > +   return;
> > +
> > +   /*
> > +* Configure the master select and enable Transcoder Port Sync for
> > +* Slave CRTCs transcoder.
> > +*/
> > +   if (!crtc_state->genlock_crtc)
> > +   return;
> > +
> > +   genlock_crtc_state = intel_atomic_get_new_crtc_state(old_intel_state,
> > +
> > crtc_state->genlock_crtc);
> > +   if (WARN_ON(!genlock_crtc_state))
> > +   return;
> > +
> > +   genlock_transcoder = genlock_crtc_state->cpu_transcoder;
> > +   switch (genlock_transcoder) {
> > +   case TRANSCODER_A:
> > +   master_select = 1;
> > +   break;
> > +   case TRANSCODER_B:
> > +   master_select = 2;
> > +   break;
> > +   case TRANSCODER_C:
> > +   master_select = 3;
> > +   break;
> > +   case TRANSCODER_EDP:
> > +   default:
> > +   master_select = 0;
> > +   break;
> > +   }
> > +   /* Set the master select bits for Tranascoder Port Sync */
> > +   trans_ddi_func_ctl2_val = 
> > I915_READ(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder));
> > +   trans_ddi_func_ctl2_val |= (PORT_SYNC_MODE_MASTER_SELECT(master_select) 
> > &
> > +   PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> > +   PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> 
> This doesn't do what you think it does. ITYM,
> 
>   val = I915_READ();
> val &= ~FOO_MASK;
> val |= FOO_BAR;

Also we alreayd have a place where we write this registers. Is there
some magic requirement why these bits can't be set there along with
eveyrthing else?

> 
> Please actually use just "val" for the variable, the long name just
> makes this all harder to read.
> 
> BR,
> Jani.
> 
> 
> > +   /* Enable Transcoder Port Sync */
> > +   trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
> > +
> > +   I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> > +  trans_ddi_func_ctl2_val);
> > +}
> > +
> >  static void intel_update_pipe_config(const struct intel_crtc_state 
> > *old_crtc_state,
> >  const struct intel_crtc_state 
> > *new_crtc_state)
> >  {
> > @@ -5960,6 +6016,9 @@ static void haswell_crtc_enable(struct 
> > intel_crtc_state *pipe_config,
> > if (!transcoder_is_dsi(cpu_transcoder))
> > intel_set_pipe_timings(pipe_config);
> >  
> > +   if (INTEL_GEN(dev_priv) >= 11)
> > +   icl_set_transcoder_port_sync(old_intel_state, pipe_config);
> > +
> > intel_set_pipe_src_size(pipe_config);
> >  
> > if (cpu_transcoder != TRANSCODER_EDP &&
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
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 v3] drm/i915/icl: Fix clockgating issue when using scalers

2019-03-22 Thread Ville Syrjälä
On Thu, Mar 21, 2019 at 02:44:31PM -0700, Radhakrishna Sripada wrote:
> Fixes the clock-gating issue when pipe scaling is enabled.
> (Lineage #2006604312)
> 
> V2: Fix typo in headline(Chris)
> Handle the non double buffered nature of the register(Ville)
> V3: Fix checkpatch warning. BAT failure for V2 on gen3 looks unrelated.
> 
> Cc: Chris Wilson 
> Cc: Ville Syrjala 
> Cc: Rodrigo Vivi 
> Cc: Aditya Swarup 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 43 +---
>  1 file changed, 27 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7c15b428ff84..cfa19ae12e22 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -469,13 +469,22 @@ static const struct intel_limit intel_limits_bxt = {
>  static void
>  skl_wa_clkgate(struct drm_i915_private *dev_priv, int pipe, bool enable)
>  {
> + u32 val = 0;
> +
> + /*
> +  * Wa_2006604312:icl
> +  */
> + if (IS_ICELAKE(dev_priv))
> + val = DPFR_GATING_DIS;
> + else
> + val = DUPS1_GATING_DIS | DUPS2_GATING_DIS;
> +
> + /* WA Display #0827: Gen9:all */

You're now conflating two workaround and splitting their implementation
between two functions in a confusing way. Better to keep them separate
IMO.

>   if (enable)
> - I915_WRITE(CLKGATE_DIS_PSL(pipe),
> -DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> + I915_WRITE(CLKGATE_DIS_PSL(pipe), val);
>   else
>   I915_WRITE(CLKGATE_DIS_PSL(pipe),
> -I915_READ(CLKGATE_DIS_PSL(pipe)) &
> -~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> +I915_READ(CLKGATE_DIS_PSL(pipe)) & ~val);
>  }
>  
>  static bool
> @@ -5481,14 +5490,18 @@ static bool hsw_post_update_enable_ips(const struct 
> intel_crtc_state *old_crtc_s
>   return !old_crtc_state->ips_enabled;
>  }
>  
> -static bool needs_nv12_wa(struct drm_i915_private *dev_priv,
> -   const struct intel_crtc_state *crtc_state)
> +static bool skl_needs_clk_wa(struct drm_i915_private *dev_priv,
> +  const struct intel_crtc_state *crtc_state)
>  {
> - if (!crtc_state->nv12_planes)
> - return false;
> -
>   /* WA Display #0827: Gen9:all */
> - if (IS_GEN(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
> + if (!!crtc_state->nv12_planes && IS_GEN(dev_priv, 9) &&
> + !IS_GEMINILAKE(dev_priv))
> + return true;
> +
> + /*
> +  * Wa_2006604312:icl
> +  */
> + if (IS_ICELAKE(dev_priv) && crtc_state->pch_pfit.enabled)
>   return true;
>  
>   return false;
> @@ -5527,9 +5540,8 @@ static void intel_post_plane_update(struct 
> intel_crtc_state *old_crtc_state)
>   intel_post_enable_primary(>base, pipe_config);
>   }
>  
> - /* Display WA 827 */
> - if (needs_nv12_wa(dev_priv, old_crtc_state) &&
> - !needs_nv12_wa(dev_priv, pipe_config)) {
> + if (skl_needs_clk_wa(dev_priv, old_crtc_state) &&
> + !skl_needs_clk_wa(dev_priv, pipe_config)) {
>   skl_wa_clkgate(dev_priv, crtc->pipe, false);
>   }
>  }
> @@ -5566,9 +5578,8 @@ static void intel_pre_plane_update(struct 
> intel_crtc_state *old_crtc_state,
>   intel_set_cpu_fifo_underrun_reporting(dev_priv, 
> crtc->pipe, false);
>   }
>  
> - /* Display WA 827 */
> - if (!needs_nv12_wa(dev_priv, old_crtc_state) &&
> - needs_nv12_wa(dev_priv, pipe_config)) {
> + if (!skl_needs_clk_wa(dev_priv, old_crtc_state) &&
> + skl_needs_clk_wa(dev_priv, pipe_config)) {
>   skl_wa_clkgate(dev_priv, crtc->pipe, true);
>   }
>  
> -- 
> 2.20.0.rc2.7.g965798d1f299

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: iterate over child devices to initialize ddi_port_info

2019-03-22 Thread Patchwork
== Series Details ==

Series: drm/i915/bios: iterate over child devices to initialize ddi_port_info
URL   : https://patchwork.freedesktop.org/series/58407/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5794 -> Patchwork_12572


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_basic@gtt-bsd:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] +103

  * igt@gem_exec_basic@gtt-bsd1:
- fi-bxt-j4205:   NOTRUN -> SKIP [fdo#109271] +47

  * igt@gem_exec_basic@gtt-bsd2:
- fi-kbl-7500u:   NOTRUN -> SKIP [fdo#109271] +9

  * igt@gem_exec_basic@readonly-bsd:
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76

  * igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50

  * igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720]

  * igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182] +1

  * igt@kms_busy@basic-flip-c:
- fi-bwr-2160:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-byt-j1900:   NOTRUN -> SKIP [fdo#109271] / [fdo#109278]

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   NOTRUN -> DMESG-WARN [fdo#103841]

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900:   NOTRUN -> SKIP [fdo#109271] +52

  * igt@kms_chamelium@vga-edid-read:
- fi-hsw-4770r:   NOTRUN -> SKIP [fdo#109271] +45

  * igt@runner@aborted:
- fi-kbl-7500u:   NOTRUN -> FAIL [fdo#103841]

  
 Possible fixes 

  * igt@i915_selftest@live_evict:
- fi-bsw-kefka:   DMESG-WARN [fdo#107709] -> PASS

  * igt@i915_selftest@live_uncore:
- fi-ivb-3770:DMESG-FAIL [fdo#110210] -> PASS

  
  [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
  [fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
  [fdo#110210]: https://bugs.freedesktop.org/show_bug.cgi?id=110210


Participating hosts (32 -> 36)
--

  Additional (7): fi-hsw-4770r fi-byt-j1900 fi-bwr-2160 fi-apl-guc fi-kbl-7500u 
fi-bxt-j4205 fi-pnv-d510 
  Missing(3): fi-ctg-p8600 fi-hsw-4770 fi-hsw-4200u 


Build changes
-

* Linux: CI_DRM_5794 -> Patchwork_12572

  CI_DRM_5794: 487d6c295c12d99c218b489ab39618831d7d31d6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4898: be2f88cd36fd4ba836d9f2453e90673c86649489 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12572: d2b88ed60256bc87d88c67f6e31bc19a9a25e791 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d2b88ed60256 drm/i915/bios: iterate over child devices to initialize 
ddi_port_info

== Logs ==

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

  1   2   >