[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Pass intel_context to i915_request_create() (rev2)
== 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 -> SK
[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
== 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
== 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
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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_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()
[Intel-gfx] [PATCH v5 3/5] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+
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(&execlists->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_th
[Intel-gfx] [PATCH v5 1/5] drm/i915: Add engine reset count in get-reset-stats ioctl
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(&dev_priv->gpu_error); - else + for_each_engine(engine, dev_priv, id) + args->reset_engine_count += + i915_reset_engine_count(&dev_priv->gpu_error, + engine); + } else { args->reset_count = 0; + args->reset_engine_count = 0; + } args->batch_active = atomic_read(&ctx->guilty_count); args->batch_pending = atomic_read(&ctx->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+
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 99d
[Intel-gfx] [PATCH v5 5/5] drm/i915: Watchdog timeout: Include threshold value in error state
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(&ctx->guilty_count); e->active = atomic_read(&ctx->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 ? &ctx->ppgtt->vm : &ggtt->vm; - record_context(&ee->context, ctx); + record_context(&ee->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
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
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 = *value_in
[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP2.2 Phase II (rev4)
== 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] * igt@kms_plane_a
Re: [Intel-gfx] [PATCH] drm/i915/guc: Support for extended GuC notification messages
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(&guc->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, &msg, 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(&guc->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)
== 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
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
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 = &pipe_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
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 = &pipe_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
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 = &crtc_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, &clock); } @@ -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(&pipe_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
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(&encoder->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, &pipe_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 = &pipe_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 = &pipe_config->dpll_hw_state; + int link_clock; - if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) { - link_clock = cnl_calc_wrpll_link(dev_priv, pll_id); + if (pl
[Intel-gfx] [PATCH v2 4/5] drm/i915/icl: use previous pll hw readout
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
== 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
== 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
== 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
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
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
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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_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 = &drv->states[i]; > + > + if (!strcmp(state->name, name)) > + return state->exit_latency ? > + state->exit_latency - 1 : 0; > + } Mind if I say yuck?
[Intel-gfx] [PATCH] drm/i915: Mark AML 0x87CA as ULX
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
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
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 skl_dpl
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: use previous pll hw readout
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
== 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
== 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
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)
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
== 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 * ig
[Intel-gfx] RMW considered harmful (was: Re: [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports)
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
== 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
== 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
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, ¶m) == 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, ¶m), -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, ¶m), 0); > + > + param.value = to_user_pointer(engines - 1); > + igt_assert_eq(__gem_context_set_param(i915, ¶m), -EFAULT); > + > + param.value = to_user_pointer(engines) - 1; > + igt_assert_eq(__gem_context_set_param(i915, ¶m), -EFAULT); > + > + param.value = to_user_pointer(engines) - param.size + 1; ^ just a blank more than necessary > + idx = 0; > + memset(&engines, 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, &execbuf), 0); why aren't you using simply gem_execbuf()? > + execbuf.flags = j; > + err =__gem_execbuf(i915, &execbuf); > + 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, &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
== 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
== 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
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
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
== 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 [fdo#1092
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Replace preempt_client lookup with engine->preempt_context
== 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
== 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 * igt@kms_busy@extended-p
Re: [Intel-gfx] [PATCH] drm/edid: Remove defunct EDID_QUIRK_FIRST_DETAILED_PREFERRED
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)
== 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 * igt@kms_atomic_transition@1x-modeset-transition
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: GuC suspend path cleanup (rev2)
== 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
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
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
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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_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 = &drv->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(&dev_priv->i945gm_vblank.work, + i945gm_vblank_work_func); + + dev_priv->i945gm_vblank.c3_disable_latency = + cstate_disable_latency("C3"); + pm_qos_add_request(&dev_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(&dev_priv->i945gm_vblank.work); + pm_qos_remove_request(&dev_priv->i945gm_vblank.pm_qos); +} + static void ibx_irq_reset(struct drm_i915_private *dev_priv) { if (HAS_PCH_NOP(dev_priv)) @@ -4525,6 +46
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/selftests: Calculate maximum ring size for preemption chain
== 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 * igt@kms_flip@2x-modeset-vs
[Intel-gfx] [CI 4/6] drm/i915/ehl: EHL outputs are different from ICL
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
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
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", &combo_pll_funcs, DPLL_ID_ICL_DPLL0, 0 }, + { "DPLL 1", &combo_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 = &ehl_pll_mgr; + else if (INTEL_GEN(dev_priv) >= 11) dpll_mgr = &icl_pll_mgr; else if (IS_CANNONLAKE(dev_priv)) dpll_mgr = &cnl_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
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
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
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(&intel_coffeelake_gt2_info), INTEL_CNL_IDS(&intel_cannonlake_info), INTEL_ICL_11_IDS(&intel_icelake_11_info), + INTEL_EHL_IDS(&intel_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
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 Graph
Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
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
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
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
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"
== 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
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"
== 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
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, ¶m) == 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, ¶m), -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(&engines, 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, &execbuf), 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, &execbuf); > > + 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, &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"
== 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
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, &wp, &wm, &wm); > > + skl_compute_plane_wm(crtc_state, level, &wp, &wm, &wm); > > 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
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, &connector->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, &connector->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
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Introduce private PAT management"
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"
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 = &ppat->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(&entry->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 = &i915->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 = &ppat->entries[i]; - if (score == INTEL_PPAT_PERFECT_MATCH) { - kref_get(&entry->ref); - return entry; - } - best_score = score; - } - scanned++; - } - - if (scanned == ppat->max_entries) { - if (!entry) - return ERR_PTR(-ENOSPC); - - kref_get(&entry->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(&ppat->entries[index].re
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/8] drm/i915/psr: Remove partial PSR support on multiple transcoders
== 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
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
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
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
> -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
== 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
> -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(&dev_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
== 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
== 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
== 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
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
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(&dev_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
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
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
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 = &plane_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
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, > &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.
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
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
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 = &plane_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.
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
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, &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
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(&crtc->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(&crtc->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 t
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/icl: Ungate ddi clocks before IO enable
== 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
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
>-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(&crtc->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, >> + &crtc->config- >>multi_segment_gamma_lut, >> + sizeof(struct >multi_segment_gamma_lut), >> + &multi_segment_lut, >> + &crtc->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
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
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(&crtc->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
== 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