Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
> -Original Message-
> From: Souza, Jose
> Sent: Friday, March 20, 2020 12:36 AM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Khor, Swee Aun
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot
> for audio
> codec init
>
> On Wed, 2020-03-18 at 17:00 +0530, Uma Shankar wrote:
> > If external monitors are connected during boot up, driver uses the
> > same mode programmed by BIOS and avoids a full modeset.
> > This results in display audio codec left uninitialized and display
> > audio fails to work till user triggers a modeset.
> >
> > This patch fixes the same by triggering a modeset at boot.
>
> We had the same issue for PSR, take a look to the fix:
> commit 33e059a2e4df454359f642f2235af39de9d3e914
> drm/i915/psr: Force PSR probe only after full initialization
>
> Maybe make this even more generic.
Yeah this looks to dealing with almost a similar need. Thanks for pointing this
out,
will try to come up with a generalized solution.
Regards,
Uma Shankar
> >
> > Cc: Ville Syrjälä
> > Cc: Maarten Lankhorst
> > Cc: Kai Vehmanen
> > Signed-off-by: Uma Shankar
> > Signed-off-by: SweeAun Khor
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 4
> > drivers/gpu/drm/i915/display/intel_display.c | 8
> > drivers/gpu/drm/i915/i915_drv.h | 3 +++
> > 3 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 73d0f4648c06..ba380afa73a6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3704,6 +3704,10 @@ static void intel_ddi_update_pipe(struct
> > intel_encoder *encoder,
> > const struct intel_crtc_state
> > *crtc_state,
> > const struct drm_connector_state
> > *conn_state)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +
> > + /* Clear the bootflag */
> > + dev_priv->bootflag = false;
> >
> > if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state); diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8f23c4d51c33..a1487539495f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -14751,6 +14751,10 @@ static int intel_atomic_check(struct
> > drm_device *dev,
> > if (new_crtc_state->hw.mode.private_flags !=
> > old_crtc_state->hw.mode.private_flags)
> > new_crtc_state->uapi.mode_changed = true;
> > +
> > + /* Set mode_change to init audio code once at boot */
> > + if (dev_priv->bootflag && new_crtc_state->hw.active)
> > + new_crtc_state->uapi.mode_changed = true;
> > }
> >
> > ret = drm_atomic_helper_check_modeset(dev, &state->base); @@
> > -17655,11 +17659,15 @@ static void intel_update_fdi_pll_freq(struct
> > drm_i915_private *dev_priv)
> >
> > static int intel_initial_commit(struct drm_device *dev) {
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > struct drm_atomic_state *state = NULL;
> > struct drm_modeset_acquire_ctx ctx;
> > struct intel_crtc *crtc;
> > int ret = 0;
> >
> > + /* Set Flag to trigger modeset for audio codec init */
> > + dev_priv->bootflag = true;
> > +
> > state = drm_atomic_state_alloc(dev);
> > if (!state)
> > return -ENOMEM;
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index a7ea1d855359..207196f9632b
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1210,6 +1210,9 @@ struct drm_i915_private {
> > * NOTE: This is the dri1/ums dungeon, don't add stuff here.
> > Your patch
> > * will be rejected. Instead look for a better place.
> > */
> > +
> > + /* Flag to trigger modeset for Audio codec init once during
> > boot */
> > + bool bootflag;
> > };
> >
> > static inline struct drm_i915_private *to_i915(const struct
> > drm_device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Adjust PM QoS response frequency based on GPU load.
Francisco Jerez writes:
> Francisco Jerez writes:
>
>> Chris Wilson writes:
>>
>>> Quoting Francisco Jerez (2020-03-10 21:41:55)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index b9b3f78f1324..a5d7a80b826d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1577,6 +1577,11 @@ static void execlists_submit_ports(struct
intel_engine_cs *engine)
/* we need to manually load the submit queue */
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
+
+ if (execlists_num_ports(execlists) > 1 &&
>>> pending[1] is always defined, the minimum submission is one slot, with
>>> pending[1] as the sentinel NULL.
>>>
+ execlists->pending[1] &&
+ !atomic_xchg(&execlists->overload, 1))
+ intel_gt_pm_active_begin(&engine->i915->gt);
>>>
>>> engine->gt
>>>
>>
>> Applied your suggestions above locally, will probably wait to have a few
>> more changes batched up before sending a v2.
>>
}
static bool ctx_single_port_submission(const struct intel_context *ce)
@@ -2213,6 +2218,12 @@ cancel_port_requests(struct intel_engine_execlists
* const execlists)
clear_ports(execlists->inflight, ARRAY_SIZE(execlists->inflight));
WRITE_ONCE(execlists->active, execlists->inflight);
+
+ if (atomic_xchg(&execlists->overload, 0)) {
+ struct intel_engine_cs *engine =
+ container_of(execlists, typeof(*engine),
execlists);
+ intel_gt_pm_active_end(&engine->i915->gt);
+ }
}
static inline void
@@ -2386,6 +2397,9 @@ static void process_csb(struct intel_engine_cs
*engine)
/* port0 completed, advanced to port1 */
trace_ports(execlists, "completed",
execlists->active);
+ if (atomic_xchg(&execlists->overload, 0))
+ intel_gt_pm_active_end(&engine->i915->gt);
>>>
>>> So this looses track if we preempt a dual-ELSP submission with a
>>> single-ELSP submission (and never go back to dual).
>>>
>>
>> Yes, good point. You're right that if a dual-ELSP submission gets
>> preempted by a single-ELSP submission "overload" will remain signaled
>> until the first completion interrupt arrives (e.g. from the preempting
>> submission).
>>
>>> If you move this to the end of the loop and check
>>>
>>> if (!execlists->active[1] && atomic_xchg(&execlists->overload, 0))
>>> intel_gt_pm_active_end(engine->gt);
>>>
>>> so that it covers both preemption/promotion and completion.
>>>
>>
>> That sounds reasonable.
>>
>>> However, that will fluctuate quite rapidly. (And runs the risk of
>>> exceeding the sentinel.)
>>>
>>> An alternative approach would be to couple along
>>> schedule_in/schedule_out
>>>
>>> atomic_set(overload, -1);
>>>
>>> __execlists_schedule_in:
>>> if (!atomic_fetch_inc(overload)
>>> intel_gt_pm_active_begin(engine->gt);
>>> __execlists_schedule_out:
>>> if (!atomic_dec_return(overload)
>>> intel_gt_pm_active_end(engine->gt);
>>>
>>> which would mean we are overloaded as soon as we try to submit an
>>> overlapping ELSP.
>>>
>>
>> That sounds good to me too, and AFAICT would have roughly the same
>> behavior as this metric except for the preemption corner case you
>> mention above. I'll try this and verify that I get approximately the
>> same performance numbers.
>>
>
> This suggestion seems to lead to some minor regressions, I'm
> investigating the issue. Will send a v2 as soon as I have something
> along the lines of what you suggested running with equivalent
> performance to v1.
I think I've figured out why both of the alternatives we were talking
about above lead to a couple percent regressions in latency-sensitive
workloads: In some scenarios it's possible for execlist_dequeue() to
execute after the GPU has gone idle, but before we've processed the
corresponding CSB entries, particularly when called from the
submit_queue() path. In that case __execlists_schedule_in() will think
that the next request is overlapping, and tell CPU power management to
relax, even though the GPU is starving intermittently.
How about we do the same:
| if (atomic_xchg(&execlists->overload, 0))
| intel_gt_pm_active_end(engine->gt);
as in this patch from process_csb() in response to each completion CSB
entry, which ensures that the system is considered non-GPU-bound as soon
as the first context completes. Subsequently if another CSB entry
signals a dual-ELSP active-to-idle transition or a dual-ELSP preemption
we call intel_gt_pm_active_begin() directly from process_csb(). If we
hit a single-ELSP preemption CSB entry we call intel_gt_pm_active_end()
instead,
Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
On Wed, 11 Mar 2020 13:36:35 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/vgpu.c
>
> between commit:
>
> 04d6067f1f19 ("drm/i915/gvt: Fix unnecessary schedule timer when no vGPU
> exits")
>
> from the drm-intel-fixes tree and commit:
>
> 12d5861973c7 ("drm/i915/gvt: Make WARN* drm specific where vgpu ptr is
> available")
>
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/gvt/vgpu.c
> index 345c2aa3b491,abcde8ce1a9a..
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@@ -271,18 -272,12 +272,19 @@@ void intel_gvt_release_vgpu(struct inte
> void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu)
> {
> struct intel_gvt *gvt = vgpu->gvt;
> + struct drm_i915_private *i915 = gvt->gt->i915;
>
> - WARN(vgpu->active, "vGPU is still active!\n");
> -mutex_lock(&vgpu->vgpu_lock);
> -
> + drm_WARN(&i915->drm, vgpu->active, "vGPU is still active!\n");
>
> +/*
> + * remove idr first so later clean can judge if need to stop
> + * service if no active vgpu.
> + */
> +mutex_lock(&gvt->lock);
> +idr_remove(&gvt->vgpu_idr, vgpu->id);
> +mutex_unlock(&gvt->lock);
> +
> +mutex_lock(&vgpu->vgpu_lock);
> intel_gvt_debugfs_remove_vgpu(vgpu);
> intel_vgpu_clean_sched_policy(vgpu);
> intel_vgpu_clean_submission(vgpu);
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpTZhbgqZRPF.pgp
Description: OpenPGP digital signature
___
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/display/fbc: Make fences a nice-to-have for GEN9+
== Series Details == Series: drm/i915/display/fbc: Make fences a nice-to-have for GEN9+ URL : https://patchwork.freedesktop.org/series/74890/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17029_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17029_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17029_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_17029_full: ### IGT changes ### Possible regressions * igt@kms_fbcon_fbt@fbc: - shard-glk: [PASS][1] -> [FAIL][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-glk9/igt@kms_fbcon_...@fbc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-glk4/igt@kms_fbcon_...@fbc.html * igt@kms_frontbuffer_tracking@fbc-tilingchange: - shard-iclb: [PASS][3] -> [FAIL][4] +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb2/igt@kms_frontbuffer_track...@fbc-tilingchange.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-iclb3/igt@kms_frontbuffer_track...@fbc-tilingchange.html - shard-tglb: [PASS][5] -> [FAIL][6] +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb5/igt@kms_frontbuffer_track...@fbc-tilingchange.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-tglb3/igt@kms_frontbuffer_track...@fbc-tilingchange.html * igt@kms_hdr@static-toggle-dpms: - shard-tglb: NOTRUN -> [SKIP][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-tglb6/igt@kms_...@static-toggle-dpms.html Known issues Here are the changes found in Patchwork_17029_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-kbl: [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +5 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl6/igt@gem_ctx_isolat...@bcs0-s3.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-kbl7/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([i915#1402]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb5/igt@gem_ctx_persiste...@close-replace-race.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-tglb7/igt@gem_ctx_persiste...@close-replace-race.html - shard-kbl: [PASS][12] -> [INCOMPLETE][13] ([i915#1402]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl7/igt@gem_ctx_persiste...@close-replace-race.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-kbl6/igt@gem_ctx_persiste...@close-replace-race.html - shard-skl: [PASS][14] -> [INCOMPLETE][15] ([i915#1402]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-skl5/igt@gem_ctx_persiste...@close-replace-race.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-skl5/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#112080]) +14 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-iclb5/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#109276] / [i915#677]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd2.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109276]) +8 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_sched...@out-order-bsd2.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-iclb5/igt@gem_exec_sched...@out-order-bsd2.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][22] -> [SKIP][23] ([i915#677]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb5/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/shard-iclb2/igt@gem_exec
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: add OA interrupt support (rev7)
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev7)
URL : https://patchwork.freedesktop.org/series/54280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8161 -> Patchwork_17030
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17030/index.html
Known issues
Here are the changes found in Patchwork_17030 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-icl-dsi: [INCOMPLETE][1] ([i915#189]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8161/fi-icl-dsi/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17030/fi-icl-dsi/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- {fi-ehl-1}: [INCOMPLETE][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8161/fi-ehl-1/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17030/fi-ehl-1/igt@i915_selftest@l...@execlists.html
- fi-kbl-soraka: [INCOMPLETE][5] ([fdo#112259] / [i915#656]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8161/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17030/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#112259]: https://bugs.freedesktop.org/show_bug.cgi?id=112259
[i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
[i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
Participating hosts (36 -> 40)
--
Additional (7): fi-bdw-5557u fi-kbl-7560u fi-bsw-n3050 fi-ivb-3770
fi-cfl-8109u fi-blb-e6850 fi-skl-6600u
Missing(3): fi-byt-clapper fi-bsw-cyan fi-bwr-2160
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8161 -> Patchwork_17030
CI-20190529: 20190529
CI_DRM_8161: b2b8d8634bf653904ef3268ca7ccedf51f6405af @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17030: 4bfbbb959b1f835f6857b7b5320171291e0ebc3e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4bfbbb959b1f drm/i915/perf: add new open param to configure polling of OA buffer
3874f27479a6 drm/i915/perf: move pollin setup to non hw specific code
d7bd4aaf5bf3 drm/i915/perf: rework aging tail workaround
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17030/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: add OA interrupt support (rev7)
== Series Details == Series: drm/i915/perf: add OA interrupt support (rev7) URL : https://patchwork.freedesktop.org/series/54280/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/perf: rework aging tail workaround Okay! Commit: drm/i915/perf: move pollin setup to non hw specific code -O:drivers/gpu/drm/i915/i915_perf.c:1423:15: warning: memset with byte count of 16777216 -O:drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1423:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1477:15: warning: memset with byte count of 16777216 Commit: drm/i915/perf: add new open param to configure polling of OA buffer 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 drm/i915/perf: add OA interrupt support (rev7)
== Series Details ==
Series: drm/i915/perf: add OA interrupt support (rev7)
URL : https://patchwork.freedesktop.org/series/54280/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d7bd4aaf5bf3 drm/i915/perf: rework aging tail workaround
-:125: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#125: FILE: drivers/gpu/drm/i915/i915_perf.c:481:
+ if (hw_tail == stream->oa_buffer.aging_tail &&
+ (now - stream->oa_buffer.aging_timestamp) > OA_TAIL_MARGIN_NSEC) {
total: 0 errors, 0 warnings, 1 checks, 350 lines checked
3874f27479a6 drm/i915/perf: move pollin setup to non hw specific code
4bfbbb959b1f drm/i915/perf: add new open param to configure polling of OA buffer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Test over 32k long stride length on icl+ (rev2)
== Series Details ==
Series: Test over 32k long stride length on icl+ (rev2)
URL : https://patchwork.freedesktop.org/series/74884/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17028_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17028_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17028_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_17028_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_schedule@pi-userfault-render:
- shard-glk: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-glk8/igt@gem_exec_sched...@pi-userfault-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/shard-glk3/igt@gem_exec_sched...@pi-userfault-render.html
* igt@gem_exec_whisper@basic-fds-priority:
- shard-iclb: [PASS][3] -> [TIMEOUT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb7/igt@gem_exec_whis...@basic-fds-priority.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/shard-iclb5/igt@gem_exec_whis...@basic-fds-priority.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy-gup@gtt:
- shard-hsw: NOTRUN -> [DMESG-WARN][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/shard-hsw2/igt@gem_userptr_blits@map-fixed-invalidate-busy-...@gtt.html
* {igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0} (NEW):
- shard-iclb: NOTRUN -> [SKIP][6] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/shard-iclb2/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_hdr@static-toggle-dpms:
- shard-tglb: NOTRUN -> [SKIP][7] +4 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/shard-tglb1/igt@kms_...@static-toggle-dpms.html
New tests
-
New tests have been introduced between CI_DRM_8160_full and
Patchwork_17028_full:
### New IGT tests (16) ###
* igt@kms_big_fb@linear-max-hw-stride-32bpp-rotate-0:
- Statuses : 8 pass(s)
- Exec time: [1.35, 3.90] s
* igt@kms_big_fb@linear-max-hw-stride-32bpp-rotate-180:
- Statuses : 8 pass(s)
- Exec time: [1.31, 3.89] s
* igt@kms_big_fb@linear-max-hw-stride-64bpp-rotate-0:
- Statuses : 6 pass(s)
- Exec time: [1.40, 3.48] s
* igt@kms_big_fb@linear-max-hw-stride-64bpp-rotate-180:
- Statuses : 8 pass(s)
- Exec time: [1.38, 3.35] s
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0:
- Statuses : 6 pass(s)
- Exec time: [1.48, 3.89] s
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180:
- Statuses : 7 pass(s)
- Exec time: [1.34, 2.16] s
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0:
- Statuses : 6 pass(s)
- Exec time: [1.39, 3.42] s
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180:
- Statuses : 2 pass(s)
- Exec time: [1.54, 1.92] s
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0:
- Statuses : 5 pass(s) 2 skip(s)
- Exec time: [0.0, 4.15] s
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180:
- Statuses : 6 pass(s) 2 skip(s)
- Exec time: [0.0, 4.08] s
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0:
- Statuses : 5 pass(s) 3 skip(s)
- Exec time: [0.0, 2.00] s
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180:
- Statuses : 5 pass(s) 2 skip(s)
- Exec time: [0.0, 3.54] s
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 4.08] s
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180:
- Statuses : 5 pass(s) 1 skip(s)
- Exec time: [0.0, 3.99] s
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_17028_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@rcs0-s3:
- shard-apl: [PASS][8] -> [DMESG-WARN][9] ([i915#180])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html
* igt@gem_ctx_persistence@close-replace-race:
- shard-kbl: [PASS][10] -> [INCOMPLETE][11] ([i915#1402])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kb
[Intel-gfx] [PATCH 3/3] drm/i915/perf: add new open param to configure polling of OA buffer
From: Lionel Landwerlin
This new parameter let's the application choose how often the OA
buffer should be checked on the CPU side for data availability. Longer
polling period tend to reduce CPU overhead if the application does not
care about somewhat real time data collection.
v2: Allow disabling polling completely with 0 value (Lionel)
v3: Version the new parameter (Joonas)
v4: Rebase (Umesh)
v5: Make poll delay value of 0 invalid (Umesh)
v6:
- Describe poll_oa_period (Ashutosh)
- Fix comment for new poll parameter (Lionel)
- Drop open_flags in read_properties_unlocked (Lionel)
- Rename uapi parameter (Ashutosh)
Signed-off-by: Lionel Landwerlin
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 32 --
drivers/gpu/drm/i915/i915_perf_types.h | 6 +
include/uapi/drm/i915_drm.h| 13 +++
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 22a1a7300180..83de9fbca203 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -248,11 +248,11 @@
#define OA_TAIL_MARGIN_NSEC10ULL
#define INVALID_TAIL_PTR 0x
-/* frequency for checking whether the OA unit has written new reports to the
- * circular OA buffer...
+/* The default frequency for checking whether the OA unit has written new
+ * reports to the circular OA buffer...
*/
-#define POLL_FREQUENCY 200
-#define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
+#define DEFAULT_POLL_FREQUENCY_HZ 200
+#define DEFAULT_POLL_PERIOD_NS (NSEC_PER_SEC / DEFAULT_POLL_FREQUENCY_HZ)
/* for sysctl proc_dointvec_minmax of dev.i915.perf_stream_paranoid */
static u32 i915_perf_stream_paranoid = true;
@@ -339,6 +339,8 @@ static const struct i915_oa_format
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
* @sseu: internal SSEU configuration computed either from the userspace
*specified configuration in the opening parameters or a default value
*(see get_default_sseu_config())
+ * @poll_oa_period: The period in nanoseconds at which the CPU will check for
OA
+ * data availability
*
* As read_properties_unlocked() enumerates and validates the properties given
* to open a stream of metrics the configuration is built up in the structure
@@ -361,6 +363,8 @@ struct perf_open_properties {
bool has_sseu;
struct intel_sseu sseu;
+
+ u64 poll_oa_period;
};
struct i915_oa_config_bo {
@@ -2603,7 +2607,7 @@ static void i915_oa_stream_enable(struct i915_perf_stream
*stream)
if (stream->periodic)
hrtimer_start(&stream->poll_check_timer,
- ns_to_ktime(POLL_PERIOD),
+ ns_to_ktime(stream->poll_oa_period),
HRTIMER_MODE_REL_PINNED);
}
@@ -3038,7 +3042,8 @@ static enum hrtimer_restart oa_poll_check_timer_cb(struct
hrtimer *hrtimer)
wake_up(&stream->poll_wq);
}
- hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
+ hrtimer_forward_now(hrtimer,
+ ns_to_ktime(stream->poll_oa_period));
return HRTIMER_RESTART;
}
@@ -3427,6 +3432,7 @@ i915_perf_open_ioctl_locked(struct i915_perf *perf,
stream->perf = perf;
stream->ctx = specific_ctx;
+ stream->poll_oa_period = props->poll_oa_period;
ret = i915_oa_stream_init(stream, param, props);
if (ret)
@@ -3505,6 +3511,7 @@ static int read_properties_unlocked(struct i915_perf
*perf,
int ret;
memset(props, 0, sizeof(struct perf_open_properties));
+ props->poll_oa_period = DEFAULT_POLL_PERIOD_NS;
if (!n_props) {
DRM_DEBUG("No i915 perf properties given\n");
@@ -3637,6 +3644,14 @@ static int read_properties_unlocked(struct i915_perf
*perf,
props->has_sseu = true;
break;
}
+ case DRM_I915_PERF_PROP_POLL_OA_PERIOD:
+ if (value < 10 /* 100us */) {
+ DRM_DEBUG("OA availability timer too small
(%lluns < 100us)\n",
+ value);
+ return -EINVAL;
+ }
+ props->poll_oa_period = value;
+ break;
case DRM_I915_PERF_PROP_MAX:
MISSING_CASE(id);
return -EINVAL;
@@ -4419,8 +4434,11 @@ int i915_perf_ioctl_version(void)
* 4: Add DRM_I915_PERF_PROP_ALLOWED_SSEU to limit what contexts can
*be run for the duration of the performance recording based on
*their SSEU configuration.
+*
+* 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls the
+*interval for the hrtimer used to check for OA data.
*/
- return 4;
+ return 5
[Intel-gfx] [PATCH 2/3] drm/i915/perf: move pollin setup to non hw specific code
From: Lionel Landwerlin
This isn't really gen specific stuff, so just move it to the common
code.
v2: Rebase (Umesh)
v3: Remove comment, pollin is a per stream state already (Ashutosh)
Signed-off-by: Lionel Landwerlin
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index c1429d3acaf9..22a1a7300180 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1421,8 +1421,6 @@ static void gen7_init_oa_buffer(struct i915_perf_stream
*stream)
* memory...
*/
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
-
- stream->pollin = false;
}
static void gen8_init_oa_buffer(struct i915_perf_stream *stream)
@@ -1477,8 +1475,6 @@ static void gen8_init_oa_buffer(struct i915_perf_stream
*stream)
* memory...
*/
memset(stream->oa_buffer.vaddr, 0, OA_BUFFER_SIZE);
-
- stream->pollin = false;
}
static void gen12_init_oa_buffer(struct i915_perf_stream *stream)
@@ -1534,8 +1530,6 @@ static void gen12_init_oa_buffer(struct i915_perf_stream
*stream)
*/
memset(stream->oa_buffer.vaddr, 0,
stream->oa_buffer.vma->size);
-
- stream->pollin = false;
}
static int alloc_oa_buffer(struct i915_perf_stream *stream)
@@ -2603,6 +2597,8 @@ static void gen12_oa_enable(struct i915_perf_stream
*stream)
*/
static void i915_oa_stream_enable(struct i915_perf_stream *stream)
{
+ stream->pollin = false;
+
stream->perf->ops.oa_enable(stream);
if (stream->periodic)
@@ -3026,12 +3022,8 @@ static ssize_t i915_perf_read(struct file *file,
* effectively ensures we back off until the next hrtimer callback
* before reporting another EPOLLIN event.
*/
- if (ret >= 0 || ret == -EAGAIN) {
- /* Maybe make ->pollin per-stream state if we support multiple
-* concurrent streams in the future.
-*/
+ if (ret >= 0 || ret == -EAGAIN)
stream->pollin = false;
- }
return ret;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915/perf: add OA interrupt support
Hi all, This is a revival of an earlier patch series submitted by Lionel Landwerlin - https://patchwork.freedesktop.org/series/54280/ The patches enable interrupt support for the perf OA unit in i915, further details can be found in the orignal series linked above. v2: (Umesh) - This series will split into 2. This revision will only support the addition of poll delay parameter to perf OA. If needed a future revision will incorporate interrupt support. Regards, Umesh Lionel Landwerlin (3): drm/i915/perf: rework aging tail workaround drm/i915/perf: move pollin setup to non hw specific code drm/i915/perf: add new open param to configure polling of OA buffer drivers/gpu/drm/i915/i915_perf.c | 243 +++-- drivers/gpu/drm/i915/i915_perf_types.h | 35 ++-- include/uapi/drm/i915_drm.h| 13 ++ 3 files changed, 143 insertions(+), 148 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/perf: rework aging tail workaround
From: Lionel Landwerlin
We're about to introduce an options to open the perf stream, giving
the user ability to configure how often it wants the kernel to poll
the OA registers for available data.
Right now the workaround against the OA tail pointer race condition
requires at least twice the internal kernel polling timer to make any
data available.
This changes introduce checks on the OA data written into the circular
buffer to make as much data as possible available on the first
iteration of the polling timer.
v2: Use OA_TAKEN macro without the gtt_offset (Lionel)
v3: (Umesh)
- Rebase
- Change report to report32 from below review
https://patchwork.freedesktop.org/patch/330704/?series=66697&rev=1
v4: (Ashutosh, Lionel)
- Fix checkpatch errors
- Fix aging_timestamp initialization
- Check for only one valid landed report
- Fix check for unlanded report
Signed-off-by: Lionel Landwerlin
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 197 ++---
drivers/gpu/drm/i915/i915_perf_types.h | 29 ++--
2 files changed, 96 insertions(+), 130 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3222f6cd8255..c1429d3acaf9 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -223,26 +223,17 @@
*
* Although this can be observed explicitly while copying reports to userspace
* by checking for a zeroed report-id field in tail reports, we want to account
- * for this earlier, as part of the oa_buffer_check to avoid lots of redundant
- * read() attempts.
- *
- * In effect we define a tail pointer for reading that lags the real tail
- * pointer by at least %OA_TAIL_MARGIN_NSEC nanoseconds, which gives enough
- * time for the corresponding reports to become visible to the CPU.
- *
- * To manage this we actually track two tail pointers:
- * 1) An 'aging' tail with an associated timestamp that is tracked until we
- * can trust the corresponding data is visible to the CPU; at which point
- * it is considered 'aged'.
- * 2) An 'aged' tail that can be used for read()ing.
- *
- * The two separate pointers let us decouple read()s from tail pointer aging.
- *
- * The tail pointers are checked and updated at a limited rate within a hrtimer
- * callback (the same callback that is used for delivering EPOLLIN events)
- *
- * Initially the tails are marked invalid with %INVALID_TAIL_PTR which
- * indicates that an updated tail pointer is needed.
+ * for this earlier, as part of the oa_buffer_check_unlocked to avoid lots of
+ * redundant read() attempts.
+ *
+ * We workaround this issue in oa_buffer_check_unlocked() by reading the
reports
+ * in the OA buffer, starting from the tail reported by the HW until we find 2
+ * consecutive reports with their first 2 dwords of not at 0. Those dwords are
+ * also set to 0 once read and the whole buffer is cleared upon OA buffer
+ * initialization. The first dword is the reason for this report while the
+ * second is the timestamp, making the chances of having those 2 fields at 0
+ * fairly unlikely. A more detailed explanation is available in
+ * oa_buffer_check_unlocked().
*
* Most of the implementation details for this workaround are in
* oa_buffer_check_unlocked() and _append_oa_reports()
@@ -465,10 +456,10 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream
*stream)
*/
static bool oa_buffer_check_unlocked(struct i915_perf_stream *stream)
{
+ u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
int report_size = stream->oa_buffer.format_size;
unsigned long flags;
- unsigned int aged_idx;
- u32 head, hw_tail, aged_tail, aging_tail;
+ u32 hw_tail;
u64 now;
/* We have to consider the (unlikely) possibility that read() errors
@@ -477,16 +468,6 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
*/
spin_lock_irqsave(&stream->oa_buffer.ptr_lock, flags);
- /* NB: The head we observe here might effectively be a little out of
-* date (between head and tails[aged_idx].offset if there is currently
-* a read() in progress.
-*/
- head = stream->oa_buffer.head;
-
- aged_idx = stream->oa_buffer.aged_tail_idx;
- aged_tail = stream->oa_buffer.tails[aged_idx].offset;
- aging_tail = stream->oa_buffer.tails[!aged_idx].offset;
-
hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
/* The tail pointer increases in 64 byte increments,
@@ -496,64 +477,64 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
now = ktime_get_mono_fast_ns();
- /* Update the aged tail
-*
-* Flip the tail pointer available for read()s once the aging tail is
-* old enough to trust that the corresponding data will be visible to
-* the CPU...
-*
-* Do this before updating the aging pointer in case we may be abl
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences (rev2)
== Series Details == Series: series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences (rev2) URL : https://patchwork.freedesktop.org/series/74851/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17027_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17027_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17027_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_17027_full: ### IGT changes ### Possible regressions * igt@kms_hdr@static-toggle-dpms: - shard-tglb: NOTRUN -> [SKIP][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-tglb6/igt@kms_...@static-toggle-dpms.html Known issues Here are the changes found in Patchwork_17027_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [PASS][2] -> [INCOMPLETE][3] ([i915#1402]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb5/igt@gem_ctx_persiste...@close-replace-race.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-tglb3/igt@gem_ctx_persiste...@close-replace-race.html - shard-kbl: [PASS][4] -> [INCOMPLETE][5] ([i915#1402]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl7/igt@gem_ctx_persiste...@close-replace-race.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-kbl4/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#110841]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][8] -> [SKIP][9] ([fdo#112080]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-iclb3/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#109276] / [i915#677]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd2.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109276]) +5 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_sched...@out-order-bsd2.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-iclb3/igt@gem_exec_sched...@out-order-bsd2.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][14] -> [SKIP][15] ([i915#677]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb3/igt@gem_exec_sched...@pi-shared-iova-bsd.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#112146]) +5 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb3/igt@gem_exec_sched...@wide-bsd.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-iclb1/igt@gem_exec_sched...@wide-bsd.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][18] -> [FAIL][19] ([i915#96]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy: - shard-glk: [PASS][20] -> [FAIL][21] ([IGT#5] / [i915#697]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-glk1/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/shard-glk3/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][22] -> [FAIL][23] ([i915#7
Re: [Intel-gfx] [PATCH 1/3] drm/dp: DRM DP helper for reading Ignore MSA from DPCD
On Thu, Mar 19, 2020 at 11:59:38AM +0200, Jani Nikula wrote:
> On Tue, 17 Mar 2020, Manasi Navare wrote:
> > DP sink device sets the Ignore MSA bit in its
> > DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
> > ignore the MSA video timing paramaters and its ability to support
> > seamless video timing change over a range of timing exposed by
> > DisplayID and EDID.
> > This is required for the sink to indicate that it is Adaptive sync
> > capable.
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Cc: Nicholas Kazlauskas
> > Signed-off-by: Manasi Navare
> > ---
> > include/drm/drm_dp_helper.h | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index c6119e4c169a..ccd6e2e988b9 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -1315,6 +1315,14 @@ drm_dp_alternate_scrambler_reset_cap(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
> > DP_ALTERNATE_SCRAMBLER_RESET_CAP;
> > }
> >
> > +/* Ignore MSA timing for Adaptive Sync support on DP 1.4 */
> > +static inline bool
> > +drm_dp_sink_is_capable_without_timing_msa(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])
>
> From the department of nitpicks, if you read the name of the function
> aloud, what does it actually mean?
>
> Is sink capable of *what*?
As per the DP 1.4 spec, it says this indicates sink's ability to ignore MSA
video timing
parameters to support seamless video timing change over range of timing exposed
in DisplayID and
legacy EDID. This query should occur before enabling dynamic video timing change
of incoming video stream without valid MSA video timing params.
May be i rename it as: drm_dp_sink_capable_video_without_timing_msa() ?
Manasi
>
> BR,
> Jani.
>
>
> > +{
> > + return dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> > + DP_MSA_TIMING_PAR_IGNORED;
> > +}
> > +
> > /*
> > * DisplayPort AUX channel
> > */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm: Create a drm_connector_helper_funcs hook for Adaptive Sync support
On Thu, Mar 19, 2020 at 12:07:37PM +0200, Jani Nikula wrote:
> On Tue, 17 Mar 2020, Manasi Navare wrote:
> > This patch adds a hook in drm_connector_helper_funcs to get the
> > support of the driver for adaptive sync functionality.
> >
> > This can be called in the connector probe helper function after
> > the connector detect() and get_modes() hooks to also
> > query the adaptive sync support of the driver.
>
> I can obviously see that from the patch. But this does not explain at
> all *why* we need another hook to begin with, and why it neeeds to be
> called from ->fill_modes that is set to
> drm_helper_probe_single_connector_modes().
>
This needs to be called after get_modes that ends up populating the
monitor range after parsing the EDID.
I could have just modified the get_modes hook in the driver to set the
vrr capabilities but that doesnt go with the definition of get_modes() hook
which is purely to obtain modes from edid.
So i added a separate hook which will always return the vrr capabilities if this
hook exists in the driver everytime a connector probe happens.
Would you suggest this elsewhere or some other design?
I am open to better placement of this hook or reusing some other hook or
other suggestions for getting the vrr capabilities in the driver
Manasi
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Cc: Nicholas Kazlauskas
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_probe_helper.c | 4
> > include/drm/drm_modeset_helper_vtables.h | 16
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 576b4b7dcd89..4403817bfb02 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -482,6 +482,10 @@ int drm_helper_probe_single_connector_modes(struct
> > drm_connector *connector,
> >
> > count = (*connector_funcs->get_modes)(connector);
> >
> > + /* Get the Adaptive Sync Support if helper exists */
> > + if (*connector_funcs->get_adaptive_sync_support)
> > + (**connector_funcs->get_adaptive_sync_support)(connector);
> > +
>
> This is in the middle of a sequence figuring out the modes. First
> ->get_modes, then fallback to other mechanisms. Certainly we don't want
> to do something else in the middle.
>
> > /*
> > * Fallback for when DDC probe failed in drm_get_edid() and thus skipped
> > * override/firmware EDID.
> > diff --git a/include/drm/drm_modeset_helper_vtables.h
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 7c20b1c8b6a7..0b203fdd25df 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -1079,6 +1079,22 @@ struct drm_connector_helper_funcs {
> > struct drm_writeback_job *job);
> > void (*cleanup_writeback_job)(struct drm_writeback_connector *connector,
> > struct drm_writeback_job *job);
> > +
> > + /**
> > +* @get_adaptive_sync_support:
> > +*
> > +* This hook is used by the probe helper to get the driver's support
> > +* for adaptive sync or variable refresh rate.
> > +* This is called from drm_helper_probe_single_connector_modes()
> > +* This is called after the @get_modes hook so that the connector modes
> > +* are already obtained and EDID is parsed to obtain the monitor
> > +* range descriptor information.
> > +*
> > +* This hook is optional and defined only for the drivers and on
> > +* connectors that advertise adaptive sync support.
> > +*
> > +*/
> > + void (*get_adaptive_sync_support)(struct drm_connector *connector);
> > };
> >
> > /**
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/dp: intel_dp connector hook for VRR support
On Thu, Mar 19, 2020 at 12:14:28PM +0200, Jani Nikula wrote:
> On Tue, 17 Mar 2020, Manasi Navare wrote:
> > This defines the get_vrr_support hook for intel DP connector
> > VRR support is set to true based on the DPCD ignore MSA and
> > EDID monitor range
>
> Yeah... but what do you use it for?
>
Hi Jani,
My idea of adding the intel_dp->vrr_capable variable was to
store the vrr capability in intel_dp for internal i915 use later when
we decide on vrr crtc states etc and configure the pipe etc for VRR modes.
I added this in a hook that gets called in the connector probe function
right after detect and get_modes() since thats when we will have parse
the EDID monitor range and populated that in drm_display_info struct.
This hook is also needed for us to then set the vrr capable property
for that connector.
But yes no that I rethink on of i actually need something in intel_dp
I feel that I can just get away with crtc_state->vrr_capable
that will be computed in atomic check based on the drm_display_info
and dpcd read there and in this hook we can just set the vrr capable property.
But that would mean duplicating this conditional code in atomic check.
What would be your suggestion?
Cache it here in intel_dp and just use this to set crtc_state->VRR values in
modeset
or set it directly in atomic check?
In terms of reseting it, I can set this to 0 in intel_dp_detect(), if connector
disconnected path
where i reset the dsc_dpcd and dp_compliance variables?
Regards
Manasi
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Cc: Nicholas Kazlauskas
> > Cc: Aditya Swarup
> > Signed-off-by: Manasi Navare
> > ---
> > .../drm/i915/display/intel_display_types.h| 3 +++
> > drivers/gpu/drm/i915/display/intel_dp.c | 19 +++
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 5e00e611f077..cd37ee6db1ff 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1353,6 +1353,9 @@ struct intel_dp {
> >
> > /* Display stream compression testing */
> > bool force_dsc_en;
> > +
> > + /* DP Variable refresh rate/ Adaptive sync support */
> > + bool vrr_capable;
>
> Only set, never read.
>
> > };
> >
> > enum lspcon_vendor {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 0a417cd2af2b..ccf5d868b5c1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5860,6 +5860,24 @@ static int intel_dp_get_modes(struct drm_connector
> > *connector)
> > return 0;
> > }
> >
> > +static void intel_dp_get_vrr_support(struct drm_connector *connector)
> > +{
> > + struct intel_dp *intel_dp =
> > intel_attached_dp(to_intel_connector(connector));
> > + const struct drm_display_info *info = &connector->display_info;
> > + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > +
> > + /*
> > +* DP Sink is capable of Variable refresh video timings if
> > +* Ignore MSA bit is set in DPCD.
> > +* EDID monitor range also should be atleast 10 for reasonable
> > +* Adaptive sync/ VRR end user experience.
> > +*/
> > + if (INTEL_GEN(dev_priv) >= 12 &&
> > + drm_dp_sink_is_capable_without_timing_msa(intel_dp->dpcd) &&
> > + info->monitor_range.max_vfreq - info->monitor_range.min_vfreq > 10)
> > + intel_dp->vrr_capable = true;
>
> So for now this is just a cached value for i915 use. I don't know what
> you'll need it for, but you also don't explain why it needs to be
> *cached* instead of having a helper to tell you based on the above
> data. You only ever set ->vrr_capable to true, but you never reset it
> back to false e.g. when the display is changed on the connector.
>
> Furthermore, because of the placing of the hook call in the previous
> patch, this will only use whatever details ->get_modes gives you, not
> the fallback data.
>
> BR,
> Jani.
>
>
> > +}
> > +
> > static int
> > intel_dp_connector_register(struct drm_connector *connector)
> > {
> > @@ -6756,6 +6774,7 @@ static const struct drm_connector_helper_funcs
> > intel_dp_connector_helper_funcs =
> > .get_modes = intel_dp_get_modes,
> > .mode_valid = intel_dp_mode_valid,
> > .atomic_check = intel_dp_connector_atomic_check,
> > + .get_adaptive_sync_support = intel_dp_get_vrr_support,
> > };
> >
> > static const struct drm_encoder_funcs intel_dp_enc_funcs = {
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
On Thu, Mar 19, 2020 at 06:38:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some new eDP panels don't like to operate at the max parameters, and
> instead we need to go for an optimal confiugration. That unfortunately
> doesn't work with older eDP panels which are generally only guaranteed
> to work at the max parameters.
>
> To solve these two conflicting requirements let's start with the optimal
> setup, and if that fails we start again with the max parameters. The
> downside is probably an extra modeset when we switch strategies but
> I don't see a good way to avoid that.
>
> For a bit of history we first tried to go for the fast+narrow in
> commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> fast and narrow"). but that had to be reverted due to regression
> on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> to max link rate and lane count on eDP"). So now we try to get
> the best of both worlds by using both strategies.
>
> v2: Deal with output_bpp and uapi vs. hw state split
> Reword some comments
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Albert Astals Cid # v5.0 backport
> Cc: Emanuele Panigati # v5.0 backport
> Cc: Matteo Iervasi # v5.0 backport
> Cc: Timo Aaltonen
> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
> References: https://gitlab.freedesktop.org/drm/intel/issues/272
> Signed-off-by: Ville Syrjälä
This approach looks good to me to fallback to max parameters if
it fails the first time.
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 74 ---
> 2 files changed, 66 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 5e00e611f077..ffde0d4af23c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1258,6 +1258,7 @@ struct intel_dp {
> bool link_trained;
> bool has_audio;
> bool reset_link_params;
> + bool use_max_params;
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
> u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ef2e06e292d5..85abcce492ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> {
> int index;
>
> + if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
> + DRM_DEBUG_KMS("Retrying Link training for eDP with max
> parameters\n");
> + intel_dp->use_max_params = true;
> + return 0;
> + }
We need to remove the current check for
intel_dp_can_link_train_fallback_for_edp() right?
Manasi
> +
> index = intel_dp_rate_index(intel_dp->common_rates,
> intel_dp->num_common_rates,
> link_rate);
> @@ -2046,6 +2052,44 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> return -EINVAL;
> }
>
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static int
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> + struct intel_crtc_state *pipe_config,
> + const struct link_config_limits *limits)
> +{
> + const struct drm_display_mode *adjusted_mode =
> &pipe_config->hw.adjusted_mode;
> + int bpp, clock, lane_count;
> + int mode_rate, link_clock, link_avail;
> +
> + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> + int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
> +
> + mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +output_bpp);
> +
> + for (lane_count = limits->min_lane_count;
> + lane_count <= limits->max_lane_count;
> + lane_count <<= 1) {
> + for (clock = limits->min_clock; clock <=
> limits->max_clock; clock++) {
> + link_clock = intel_dp->common_rates[clock];
> + link_avail = intel_dp_max_data_rate(link_clock,
> + lane_count);
> +
> + if (mode_rate <= link_avail) {
> + pipe_config->lane_count = lane_count;
> + pipe_config->pipe_bpp = bpp;
> + pipe_config->port_clock = link_clock;
> +
> + return 0;
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
== Series Details == Series: drm/i915/display/fbc: Make fences a nice-to-have for GEN9+ URL : https://patchwork.freedesktop.org/series/74890/ State : success == Summary == CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17029 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/index.html Known issues Here are the changes found in Patchwork_17029 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] / [i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-cfl-8700k: [PASS][3] -> [DMESG-FAIL][4] ([i915#730] / [i915#933]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html - fi-cml-s: [PASS][5] -> [DMESG-FAIL][6] ([i915#877]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/fi-cml-s/igt@i915_selftest@live@gem_contexts.html - fi-skl-lmem:[PASS][7] -> [INCOMPLETE][8] ([i915#424]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][9] -> [FAIL][10] ([i915#323]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#730]: https://gitlab.freedesktop.org/drm/intel/issues/730 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 [i915#933]: https://gitlab.freedesktop.org/drm/intel/issues/933 Participating hosts (37 -> 40) -- Additional (6): fi-bsw-n3050 fi-byt-j1900 fi-cfl-8109u fi-skl-6600u fi-bsw-nick fi-skl-6700k2 Missing(3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8160 -> Patchwork_17029 CI-20190529: 20190529 CI_DRM_8160: 6ba1729e5025761ab74914f6b8aa3288f493e9c7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17029: e67c9d8b10dcb7678579240a1def62211d79 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e67c9d8b1077 drm/i915/display/fbc: Make fences a nice-to-have for GEN9+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17029/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 6/7] drm/i915/dp: Register definition for DP compliance register
On Thu, Mar 19, 2020 at 06:02:22PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 19, 2020 at 12:09:18PM +0530, Manna, Animesh wrote:
> > On 19-03-2020 01:34, Manasi Navare wrote:
> > > On Wed, Mar 18, 2020 at 12:05:14PM +0530, Animesh Manna wrote:
> > >> DP_COMP_CTL and DP_COMP_PAT register used to program DP
> > >> compliance pattern.
> > >>
> > >> v1: Initial patch.
> > >> v2: used pipe instead of port in macro definition. [Manasi]
> > >> v3: used trans_offset for offset calculation. [Manasi]
> > >>
> > >> Reviewed-by: Manasi Navare
> > >> Signed-off-by: Animesh Manna
> > >> ---
> > >> drivers/gpu/drm/i915/i915_reg.h | 16
> > >> 1 file changed, 16 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > >> b/drivers/gpu/drm/i915/i915_reg.h
> > >> index 309cb7d96b35..8b6c9fbfe74b 100644
> > >> --- a/drivers/gpu/drm/i915/i915_reg.h
> > >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> > >> @@ -9792,6 +9792,22 @@ enum skl_power_gate {
> > >> #define DDI_BUF_BALANCE_LEG_ENABLE(1 << 31)
> > >> #define DDI_BUF_TRANS_HI(port, i) _MMIO(_PORT(port,
> > >> _DDI_BUF_TRANS_A, _DDI_BUF_TRANS_B) + (i) * 8 + 4)
> > >>
> > >> +/* DDI DP Compliance Control */
> > >> +#define _DDI_DP_COMP_CTL_A 0x605F0
> > >> +#define DDI_DP_COMP_CTL(pipe) _MMIO_TRANS2(pipe,
> > >> _DDI_DP_COMP_CTL_A)
> > > Any reason why you couldnt use _MMIO_PIPE2 ?
> >
> > As DP_COMP_CTL is part of transcoder register group, so I choose
> > _MMIO_TRANS2 for calculation. Yes _MMIO_PIPE2 will also work as the offset
> > difference between subsequent pipe is same (0x1000).
>
> The preference is:
> 1. _MMIO_PIPE()/etc. for evenly spaced things
> 2. _MMIO_PIPE2()/etc. for regular but not evenly spaced stuff
> 3. _PICK() where the above two fail
>
> There are probably a few places that do violate that though.
> We should probably fix those to not give people the wrong ideas.
>
So here since the offsets are regular, we could just use _MMIO_PIPE for both
DP_COMP_CTL
and DP_COMP_PAT?
we could define _A and _B and just use _MMIO_PIPE
Animesh, please try to use this as suggested by Ville.
Regards
Manasi
> --
> 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: failure for series starting with [CI,1/2] drm/i915: Use explicit flag to mark unreachable intel_context
== Series Details == Series: series starting with [CI,1/2] drm/i915: Use explicit flag to mark unreachable intel_context URL : https://patchwork.freedesktop.org/series/74880/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17026_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17026_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17026_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_17026_full: ### IGT changes ### Possible regressions * igt@kms_hdr@static-toggle-dpms: - shard-tglb: NOTRUN -> [SKIP][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-tglb6/igt@kms_...@static-toggle-dpms.html Known issues Here are the changes found in Patchwork_17026_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [PASS][2] -> [INCOMPLETE][3] ([i915#1402]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb5/igt@gem_ctx_persiste...@close-replace-race.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-tglb2/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#110841]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#110854]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb4/igt@gem_exec_balan...@smoke.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_parallel@rcs0-contexts: - shard-glk: [PASS][8] -> [INCOMPLETE][9] ([i915#58] / [k.org#198133]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-glk4/igt@gem_exec_paral...@rcs0-contexts.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-glk5/igt@gem_exec_paral...@rcs0-contexts.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#109276] / [i915#677]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd2.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-iclb5/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@pi-common-bsd1: - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109276]) +9 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd1.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][14] -> [SKIP][15] ([i915#677]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb5/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#112146]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-tglb: [PASS][18] -> [FAIL][19] ([i915#644]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb2/igt@gem_pp...@flink-and-close-vma-leak.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-tglb3/igt@gem_pp...@flink-and-close-vma-leak.html - shard-kbl: [PASS][20] -> [FAIL][21] ([i915#644]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/shard-kbl4/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_selftest@live@execlists: - shard-apl: [PASS][22] -> [INCOMPLETE][23] ([fdo#103927] / [i915#656]) [22]: https://intel-gf
[Intel-gfx] ✓ Fi.CI.BAT: success for Test over 32k long stride length on icl+ (rev2)
== Series Details == Series: Test over 32k long stride length on icl+ (rev2) URL : https://patchwork.freedesktop.org/series/74884/ State : success == Summary == CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17028 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/index.html Known issues Here are the changes found in Patchwork_17028 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gem_contexts: - fi-cfl-guc: [PASS][1] -> [DMESG-FAIL][2] ([i915#623]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html - fi-skl-lmem:[PASS][3] -> [INCOMPLETE][4] ([i915#424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#623]: https://gitlab.freedesktop.org/drm/intel/issues/623 Participating hosts (37 -> 35) -- Additional (5): fi-bsw-n3050 fi-byt-j1900 fi-cfl-8109u fi-bsw-nick fi-skl-6700k2 Missing(7): fi-bdw-5557u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ivb-3770 fi-byt-clapper fi-snb-2600 Build changes - * CI: CI-20190529 -> None * IGT: IGT_5523 -> IGTPW_4331 * Linux: CI_DRM_8160 -> Patchwork_17028 CI-20190529: 20190529 CI_DRM_8160: 6ba1729e5025761ab74914f6b8aa3288f493e9c7 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_4331: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4331/index.html IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17028: 62029b8972b3d3b275d26d3c634edc115d739f9a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 62029b8972b3 drm/i915: Allow gen11 to use over 32k long strides == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17028/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
dGFX have local memory so it do not have aperture and do not support
CPU fences but even for iGFX it have a small number of fences.
As replacement for fences to track frontbuffer modifications by CPU
we have a software tracking that is already in used by FBC and PSR.
PSR don't support fences so it shows that this tracking is reliable.
So lets make fences a nice-to-have to activate FBC for GEN9+, this
will allow us to enable FBC for dGFXs and iGFXs even when there is no
available fence.
We do not set fences to rotated planes but FBC only have restrictions
against 16bpp, so adding it here.
Also adding a new check for the tiling format, fences are only set
to X and Y tiled planes but again FBC don't have any restrictions
against tiling so adding linear as supported as well, other formats
should be added after tested but IGT only supports drawing in thse
3 formats.
intel_fbc_hw_tracking_covers_screen() maybe can also have the same
treatment as fences but BSpec is not clear if the size limitation is
for hardware tracking or general use of FBC and I don't have a 5K
display to test it, so keeping as is for safety.
v2:
- Added tiling and pixel format rotation checks
- Changed the GEN version not requiring fences to 11 from 9, DDX
needs some changes but it don't have support for GEN11+
v3:
- Changed back to GEN9+
- Moved GEN test to inside of tiling_is_valid()
v4:
- moved rotation check to its own functions
v5:
- renamed rotations_is_valid to rotation_is_valid
- moved pre-g4x rotation check to rotation_is_valid()
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_fbc.c | 54 +---
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 02be14b693d4..d445f9e50635 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -608,6 +608,19 @@ static bool pixel_format_is_valid(struct drm_i915_private
*dev_priv,
}
}
+static bool rotation_is_valid(struct drm_i915_private *dev_priv,
+ u32 pixel_format, unsigned int rotation)
+{
+ if (INTEL_GEN(dev_priv) >= 9 && pixel_format == DRM_FORMAT_RGB565 &&
+ drm_rotation_90_or_270(rotation))
+ return false;
+ else if (INTEL_GEN(dev_priv) <= 4 && !IS_G4X(dev_priv) &&
+rotation != DRM_MODE_ROTATE_0)
+ return false;
+
+ return true;
+}
+
/*
* For some reason, the hardware tracking starts looking at whatever we
* programmed as the display plane base address register. It does not look at
@@ -642,6 +655,22 @@ static bool intel_fbc_hw_tracking_covers_screen(struct
intel_crtc *crtc)
return effective_w <= max_w && effective_h <= max_h;
}
+static bool tiling_is_valid(struct drm_i915_private *dev_priv,
+ uint64_t modifier)
+{
+ switch (modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ if (INTEL_GEN(dev_priv) >= 9)
+ return true;
+ return false;
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ return true;
+ default:
+ return false;
+ }
+}
+
static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
const struct intel_crtc_state
*crtc_state,
const struct intel_plane_state
*plane_state)
@@ -675,6 +704,7 @@ static void intel_fbc_update_state_cache(struct intel_crtc
*crtc,
cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
+ cache->fb.modifier = fb->modifier;
drm_WARN_ON(&dev_priv->drm, plane_state->flags & PLANE_HAS_FENCE &&
!plane_state->vma->fence);
@@ -748,29 +778,39 @@ static bool intel_fbc_can_activate(struct intel_crtc
*crtc)
return false;
}
- /* The use of a CPU fence is mandatory in order to detect writes
-* by the CPU to the scanout and trigger updates to the FBC.
+ /* The use of a CPU fence is one of two ways to detect writes by the
+* CPU to the scanout and trigger updates to the FBC.
+*
+* The other method is by software tracking(see
+* intel_fbc_invalidate/flush()), it will manually notify FBC and nuke
+* the current compressed buffer and recompress it.
*
* Note that is possible for a tiled surface to be unmappable (and
-* so have no fence associated with it) due to aperture constaints
+* so have no fence associated with it) due to aperture constraints
* at the time of pinning.
*
* FIXME with 90/270 degree rotation we should use the fence on
* the normal GTT view
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
On Wed, 2020-03-18 at 14:44 +0200, Ville Syrjälä wrote:
> On Thu, Mar 12, 2020 at 12:35:56AM +, Souza, Jose wrote:
> > On Thu, 2020-03-05 at 17:33 -0800, José Roberto de Souza wrote:
> > > On Thu, 2020-02-20 at 19:26 +0200, Ville Syrjälä wrote:
> > > > On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza
> > > > wrote:
> > > > > dGFX have local memory so it do not have aperture and do not
> > > > > support
> > > > > CPU fences but even for iGFX it have a small number of
> > > > > fences.
> > > > >
> > > > > As replacement for fences to track frontbuffer modifications
> > > > > by
> > > > > CPU
> > > > > we have a software tracking that is already in used by FBC
> > > > > and
> > > > > PSR.
> > > > > PSR don't support fences so it shows that this tracking is
> > > > > reliable.
> > > > >
> > > > > So lets make fences a nice-to-have to activate FBC for GEN9+,
> > > > > this
> > > > > will allow us to enable FBC for dGFXs and iGFXs even when
> > > > > there
> > > > > is
> > > > > no
> > > > > available fence.
> > > > >
> > > > > We do not set fences to rotated planes but FBC only have
> > > > > restrictions
> > > > > against 16bpp, so adding it here.
> > > > >
> > > > > Also adding a new check for the tiling format, fences are
> > > > > only
> > > > > set
> > > > > to X and Y tiled planes but again FBC don't have any
> > > > > restrictions
> > > > > against tiling so adding linear as supported as well, other
> > > > > formats
> > > > > should be added after tested but IGT only supports drawing in
> > > > > thse
> > > > > 3 formats.
> > > > >
> > > > > intel_fbc_hw_tracking_covers_screen() maybe can also have the
> > > > > same
> > > > > treatment as fences but BSpec is not clear if the size
> > > > > limitation
> > > > > is
> > > > > for hardware tracking or general use of FBC and I don't have
> > > > > a 5K
> > > > > display to test it, so keeping as is for safety.
> > > > >
> > > > > v2:
> > > > > - Added tiling and pixel format rotation checks
> > > > > - Changed the GEN version not requiring fences to 11 from 9,
> > > > > DDX
> > > > > needs some changes but it don't have support for GEN11+
> > > > >
> > > > > v3:
> > > > > - Changed back to GEN9+
> > > > > - Moved GEN test to inside of tiling_is_valid()
> > > > >
> > > > > Cc: Daniel Vetter
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Cc: Ville Syrjälä
> > > > > Signed-off-by: José Roberto de Souza
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_fbc.c | 45
> > > > >
> > > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > > 2 files changed, 39 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > index 1d76e3646a25..a0d1d661a006 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > > @@ -585,7 +585,7 @@ static bool stride_is_valid(struct
> > > > > drm_i915_private *dev_priv,
> > > > > }
> > > > >
> > > > > static bool pixel_format_is_valid(struct drm_i915_private
> > > > > *dev_priv,
> > > > > - u32 pixel_format)
> > > > > + u32 pixel_format, unsigned
> > > > > int
> > > > > rotation)
> > > > > {
> > > > > switch (pixel_format) {
> > > > > case DRM_FORMAT_XRGB:
> > > > > @@ -599,6 +599,9 @@ static bool pixel_format_is_valid(struct
> > > > > drm_i915_private *dev_priv,
> > > > > /* WaFbcOnly1to1Ratio:ctg */
> > > > > if (IS_G4X(dev_priv))
> > > > > return false;
> > > > > + if ((rotation & (DRM_MODE_ROTATE_90 |
> > > > > DRM_MODE_ROTATE_270)) &&
> > > > > + INTEL_GEN(dev_priv) >= 9)
> > > > > + return false;
> > > >
> > > > Would still would prefer a rotations_is_valid() or some such
> > > > thing.
> > >
> > > Like this?
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > index 5e35c894bdf9..692edd45b769 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > @@ -600,15 +600,21 @@ static bool pixel_format_is_valid(struct
> > > drm_i915_private *dev_priv,
> > > /* WaFbcOnly1to1Ratio:ctg */
> > > if (IS_G4X(dev_priv))
> > > return false;
> > > - if ((rotation & (DRM_MODE_ROTATE_90 |
> > > DRM_MODE_ROTATE_270)) &&
> > > - INTEL_GEN(dev_priv) >= 9)
> > > - return false;
> > > return true;
> > > default:
> > > return false;
> > > }
> > > }
> > >
> > > +static bool rotations_is_valid(struct drm_i915_private
> > > *dev_priv,
> > > + u32 pixel_format, unsigned int
> > > rotation)
> > > +{
> > > + if (INTEL
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
On Wed, 2020-03-18 at 15:30 +0200, Ville Syrjälä wrote:
> On Fri, Mar 06, 2020 at 01:32:12AM +, Souza, Jose wrote:
> > On Thu, 2020-02-20 at 19:26 +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza
> > > wrote:
> > > > dGFX have local memory so it do not have aperture and do not
> > > > support
> > > > CPU fences but even for iGFX it have a small number of fences.
> > > >
> > > > As replacement for fences to track frontbuffer modifications by
> > > > CPU
> > > > we have a software tracking that is already in used by FBC and
> > > > PSR.
> > > > PSR don't support fences so it shows that this tracking is
> > > > reliable.
> > > >
> > > > So lets make fences a nice-to-have to activate FBC for GEN9+,
> > > > this
> > > > will allow us to enable FBC for dGFXs and iGFXs even when there
> > > > is
> > > > no
> > > > available fence.
> > > >
> > > > We do not set fences to rotated planes but FBC only have
> > > > restrictions
> > > > against 16bpp, so adding it here.
> > > >
> > > > Also adding a new check for the tiling format, fences are only
> > > > set
> > > > to X and Y tiled planes but again FBC don't have any
> > > > restrictions
> > > > against tiling so adding linear as supported as well, other
> > > > formats
> > > > should be added after tested but IGT only supports drawing in
> > > > thse
> > > > 3 formats.
> > > >
> > > > intel_fbc_hw_tracking_covers_screen() maybe can also have the
> > > > same
> > > > treatment as fences but BSpec is not clear if the size
> > > > limitation
> > > > is
> > > > for hardware tracking or general use of FBC and I don't have a
> > > > 5K
> > > > display to test it, so keeping as is for safety.
> > > >
> > > > v2:
> > > > - Added tiling and pixel format rotation checks
> > > > - Changed the GEN version not requiring fences to 11 from 9,
> > > > DDX
> > > > needs some changes but it don't have support for GEN11+
> > > >
> > > > v3:
> > > > - Changed back to GEN9+
> > > > - Moved GEN test to inside of tiling_is_valid()
> > > >
> > > > Cc: Daniel Vetter
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_fbc.c | 45
> > > >
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > 2 files changed, 39 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > index 1d76e3646a25..a0d1d661a006 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > @@ -585,7 +585,7 @@ static bool stride_is_valid(struct
> > > > drm_i915_private *dev_priv,
> > > > }
> > > >
> > > > static bool pixel_format_is_valid(struct drm_i915_private
> > > > *dev_priv,
> > > > - u32 pixel_format)
> > > > + u32 pixel_format, unsigned
> > > > int
> > > > rotation)
> > > > {
> > > > switch (pixel_format) {
> > > > case DRM_FORMAT_XRGB:
> > > > @@ -599,6 +599,9 @@ static bool pixel_format_is_valid(struct
> > > > drm_i915_private *dev_priv,
> > > > /* WaFbcOnly1to1Ratio:ctg */
> > > > if (IS_G4X(dev_priv))
> > > > return false;
> > > > + if ((rotation & (DRM_MODE_ROTATE_90 |
> > > > DRM_MODE_ROTATE_270)) &&
> > > > + INTEL_GEN(dev_priv) >= 9)
> > > > + return false;
> > >
> > > Would still would prefer a rotations_is_valid() or some such
> > > thing.
> >
> > Like this?
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 5e35c894bdf9..692edd45b769 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -600,15 +600,21 @@ static bool pixel_format_is_valid(struct
> > drm_i915_private *dev_priv,
> > /* WaFbcOnly1to1Ratio:ctg */
> > if (IS_G4X(dev_priv))
> > return false;
> > - if ((rotation & (DRM_MODE_ROTATE_90 |
> > DRM_MODE_ROTATE_270)) &&
> > - INTEL_GEN(dev_priv) >= 9)
> > - return false;
> > return true;
> > default:
> > return false;
> > }
> > }
> >
> > +static bool rotations_is_valid(struct drm_i915_private *dev_priv,
> > + u32 pixel_format, unsigned int
> > rotation)
> > +{
> > + if (INTEL_GEN(dev_priv) >= 9 && pixel_format ==
> > DRM_FORMAT_RGB565 &&
> > + rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270))
>
> drm_rotation_90_or_270()
Done
>
> > + return false;
> > + return true;
> > +}
> > +
> > /*
> > * For some reason, the hardware tracking starts looking at
> > whatever
> > we
> > *
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Test over 32k long stride length on icl+ (rev2)
== Series Details == Series: Test over 32k long stride length on icl+ (rev2) URL : https://patchwork.freedesktop.org/series/74884/ State : warning == Summary == $ dim checkpatch origin/drm-tip 62029b8972b3 drm/i915: Allow gen11 to use over 32k long strides -:33: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV) #33: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:399: + max_stride_bytes = 65536-64; ^ total: 0 errors, 0 warnings, 1 checks, 40 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences (rev2)
== Series Details == Series: series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences (rev2) URL : https://patchwork.freedesktop.org/series/74851/ State : success == Summary == CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17027 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/index.html Known issues Here are the changes found in Patchwork_17027 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][1] -> [FAIL][2] ([i915#323]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 Participating hosts (37 -> 35) -- Additional (6): fi-bsw-n3050 fi-byt-j1900 fi-cfl-8109u fi-skl-6600u fi-bsw-nick fi-skl-6700k2 Missing(8): fi-byt-squawks fi-bsw-cyan fi-snb-2520m fi-gdg-551 fi-elk-e7500 fi-bsw-kefka fi-skl-lmem fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8160 -> Patchwork_17027 CI-20190529: 20190529 CI_DRM_8160: 6ba1729e5025761ab74914f6b8aa3288f493e9c7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17027: 4f6235744a939c05913c4cb014945655ea1d82f3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4f6235744a93 drm/i915/dp: Get TC link reference during DP detection 9ac70989f9f6 drm/i915/tc/icl: Implement the TC cold exit sequence 1781e726775b drm/i915/display: Add intel_aux_ch_to_power_domain() a940e1299b38 drm/i915/display: Implement intel_display_power_wait_enable_ack() 80fc6f70f951 drm/i915/display: Add intel_display_power_get_without_ack() 61f30e252243 drm/i915/tc/tgl: Implement TCCOLD sequences == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17027/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Use 64-bit division macro
On Wed, Mar 18, 2020 at 09:08:45PM +0200, Jani Nikula wrote: > On Tue, 17 Mar 2020, Guru Das Srinagesh wrote: > > Since the PWM framework is switching struct pwm_state.duty_cycle's > > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL > > to handle a 64-bit dividend. > > > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Chris Wilson > > Cc: "Ville Syrjälä" > > Cc: intel-gfx@lists.freedesktop.org > > Cc: dri-de...@lists.freedesktop.org > > Cc: Rodrigo Vivi > > Cc: Maarten Lankhorst > > > > Signed-off-by: Guru Das Srinagesh > > Reviewed-by: Jani Nikula Thanks! > Also ack for merging this via whichever tree you prefer; please let me > know if you want me to take this via drm-intel. I'm not sure if this patch can be taken via drm-intel in isolation as it is part of a series... Will let you know if I need to make such a request. Thank you. Guru Das. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/1] Test over 32k long stride length on icl+
Testing part is left with TODO comment for anything older than gen5 Resend because IGT part failed. Test-with: 20200319193644.7417-1-juhapekka.heikk...@gmail.com Juha-Pekka Heikkila (1): drm/i915: Allow gen11 to use over 32k long strides drivers/gpu/drm/i915/display/intel_sprite.c | 30 - 1 file changed, 24 insertions(+), 6 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: Allow gen11 to use over 32k long strides
The stride in bytes must not exceed the size of 8K pixels.
Linear 64 bpp pixel format maximum stride in tiles is 1024
which would mean gen11 support 64k long stride.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_sprite.c | 30 -
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index db80367c0dbc..d829c0be923e 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -383,16 +383,34 @@ skl_plane_max_stride(struct intel_plane *plane,
unsigned int rotation)
{
const struct drm_format_info *info = drm_format_info(pixel_format);
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
int cpp = info->cpp[0];
+ int max_stride_bytes;
+
+ if (INTEL_GEN(dev_priv) >= 11) {
+ /*
+* The stride in bytes must not exceed the
+* size of 8K pixels. Linear 64 bpp pixel format
+* Maximum Stride in tiles = 1024
+* which would mean ICL support 64k long stride.
+* Linear modifier seems to not work with maximum length.
+*/
+ if (modifier == DRM_FORMAT_MOD_LINEAR)
+ max_stride_bytes = 65536-64;
+ else
+ max_stride_bytes = 65536;
+ } else {
+ /*
+* "The stride in bytes must not exceed the
+* of the size of 8K pixels and 32K bytes."
+*/
+ max_stride_bytes = 32768;
+ }
- /*
-* "The stride in bytes must not exceed the
-* of the size of 8K pixels and 32K bytes."
-*/
if (drm_rotation_90_or_270(rotation))
- return min(8192, 32768 / cpp);
+ return min(8192, max_stride_bytes / cpp);
else
- return min(8192 * cpp, 32768);
+ return min(8192 * cpp, max_stride_bytes);
}
static void
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Use explicit flag to mark unreachable intel_context
== Series Details == Series: series starting with [CI,1/2] drm/i915: Use explicit flag to mark unreachable intel_context URL : https://patchwork.freedesktop.org/series/74880/ State : success == Summary == CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17026 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/index.html Known issues Here are the changes found in Patchwork_17026 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-cml-u2: [PASS][1] -> [INCOMPLETE][2] ([i915#283] / [i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-cml-u2/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/fi-cml-u2/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([i915#323]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [i915#283]: https://gitlab.freedesktop.org/drm/intel/issues/283 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (37 -> 41) -- Additional (7): fi-bsw-n3050 fi-byt-j1900 fi-cfl-8109u fi-skl-6700k2 fi-kbl-7560u fi-bsw-nick fi-skl-6600u Missing(3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8160 -> Patchwork_17026 CI-20190529: 20190529 CI_DRM_8160: 6ba1729e5025761ab74914f6b8aa3288f493e9c7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17026: b36c45f467a1434e58b545195c53129413c43e91 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b36c45f467a1 drm/i915/gt: Cancel a hung context if already closed 32d5c83274e0 drm/i915: Use explicit flag to mark unreachable intel_context == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17026/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
== Series Details == Series: series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure URL : https://patchwork.freedesktop.org/series/74879/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8160_full -> Patchwork_17025_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17025_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17025_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_17025_full: ### IGT changes ### Possible regressions * igt@kms_hdr@static-toggle-dpms: - shard-tglb: NOTRUN -> [SKIP][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb5/igt@kms_...@static-toggle-dpms.html Known issues Here are the changes found in Patchwork_17025_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [PASS][2] -> [INCOMPLETE][3] ([i915#1402]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-tglb5/igt@gem_ctx_persiste...@close-replace-race.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-tglb7/igt@gem_ctx_persiste...@close-replace-race.html - shard-kbl: [PASS][4] -> [INCOMPLETE][5] ([i915#1402]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl7/igt@gem_ctx_persiste...@close-replace-race.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl6/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#112080]) +13 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][8] -> [SKIP][9] ([i915#677]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#109276]) +9 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb1/igt@gem_exec_sched...@out-order-bsd2.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb8/igt@gem_exec_sched...@out-order-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#112146]) +4 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#644]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl7/igt@gem_pp...@flink-and-close-vma-leak.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-apl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-256x85-sliding: - shard-hsw: [PASS][18] -> [INCOMPLETE][19] ([i915#61]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-hsw4/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-hsw2/igt@kms_cursor_...@pipe-b-cursor-256x85-sliding.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +4 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render: - shard-skl: [PA
Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
On Wed, 2020-03-18 at 17:00 +0530, Uma Shankar wrote:
> If external monitors are connected during boot up, driver
> uses the same mode programmed by BIOS and avoids a full modeset.
> This results in display audio codec left uninitialized and
> display audio fails to work till user triggers a modeset.
>
> This patch fixes the same by triggering a modeset at boot.
We had the same issue for PSR, take a look to the fix:
commit 33e059a2e4df454359f642f2235af39de9d3e914
drm/i915/psr: Force PSR probe only after full initialization
Maybe make this even more generic.
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Kai Vehmanen
> Signed-off-by: Uma Shankar
> Signed-off-by: SweeAun Khor
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4
> drivers/gpu/drm/i915/display/intel_display.c | 8
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 73d0f4648c06..ba380afa73a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3704,6 +3704,10 @@ static void intel_ddi_update_pipe(struct
> intel_encoder *encoder,
> const struct intel_crtc_state
> *crtc_state,
> const struct drm_connector_state
> *conn_state)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + /* Clear the bootflag */
> + dev_priv->bootflag = false;
>
> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> intel_ddi_update_pipe_dp(encoder, crtc_state,
> conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f23c4d51c33..a1487539495f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14751,6 +14751,10 @@ static int intel_atomic_check(struct
> drm_device *dev,
> if (new_crtc_state->hw.mode.private_flags !=
> old_crtc_state->hw.mode.private_flags)
> new_crtc_state->uapi.mode_changed = true;
> +
> + /* Set mode_change to init audio code once at boot */
> + if (dev_priv->bootflag && new_crtc_state->hw.active)
> + new_crtc_state->uapi.mode_changed = true;
> }
>
> ret = drm_atomic_helper_check_modeset(dev, &state->base);
> @@ -17655,11 +17659,15 @@ static void
> intel_update_fdi_pll_freq(struct drm_i915_private *dev_priv)
>
> static int intel_initial_commit(struct drm_device *dev)
> {
> + struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_atomic_state *state = NULL;
> struct drm_modeset_acquire_ctx ctx;
> struct intel_crtc *crtc;
> int ret = 0;
>
> + /* Set Flag to trigger modeset for audio codec init */
> + dev_priv->bootflag = true;
> +
> state = drm_atomic_state_alloc(dev);
> if (!state)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index a7ea1d855359..207196f9632b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1210,6 +1210,9 @@ struct drm_i915_private {
>* NOTE: This is the dri1/ums dungeon, don't add stuff here.
> Your patch
>* will be rejected. Instead look for a better place.
>*/
> +
> + /* Flag to trigger modeset for Audio codec init once during
> boot */
> + bool bootflag;
> };
>
> static inline struct drm_i915_private *to_i915(const struct
> drm_device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Allow for different modes of interruptible i915_active_wait
== Series Details == Series: series starting with [1/2] drm/i915: Allow for different modes of interruptible i915_active_wait URL : https://patchwork.freedesktop.org/series/74877/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8159_full -> Patchwork_17024_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17024_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17024_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_17024_full: ### IGT changes ### Possible regressions * igt@gem_ctx_param@vm: - shard-skl: [PASS][1] -> [FAIL][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-skl10/igt@gem_ctx_pa...@vm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-skl8/igt@gem_ctx_pa...@vm.html - shard-glk: [PASS][3] -> [FAIL][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-glk3/igt@gem_ctx_pa...@vm.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-glk5/igt@gem_ctx_pa...@vm.html - shard-apl: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-apl3/igt@gem_ctx_pa...@vm.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-apl3/igt@gem_ctx_pa...@vm.html - shard-iclb: [PASS][7] -> [FAIL][8] +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-iclb8/igt@gem_ctx_pa...@vm.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-iclb2/igt@gem_ctx_pa...@vm.html * igt@gem_vm_create@async-destroy: - shard-kbl: [PASS][9] -> [FAIL][10] +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-kbl1/igt@gem_vm_cre...@async-destroy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-kbl6/igt@gem_vm_cre...@async-destroy.html - shard-tglb: [PASS][11] -> [FAIL][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-tglb7/igt@gem_vm_cre...@async-destroy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-tglb6/igt@gem_vm_cre...@async-destroy.html Known issues Here are the changes found in Patchwork_17024_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-kbl6/igt@gem_ctx_isolat...@rcs0-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-apl7/igt@gem_...@in-flight-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-apl4/igt@gem_...@in-flight-suspend.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#110854]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-iclb4/igt@gem_exec_balan...@smoke.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-write-read-bsd2: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109276] / [i915#677]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-iclb4/igt@gem_exec_sched...@implicit-write-read-bsd2.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-iclb8/igt@gem_exec_sched...@implicit-write-read-bsd2.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][21] -> [SKIP][22] ([i915#677]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-iclb8/igt@gem_exec_sched...@pi-userfault-bsd.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-iclb2/igt@gem_exec_sched...@pi-userfault-bsd.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#112146]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@i915_selftest@live@blt: - shard-hsw: [PASS][25] -> [DMESG-FAIL][
[Intel-gfx] [PATCH 1/1] drm/i915: Allow gen11 to use over 32k long strides
The stride in bytes must not exceed the size of 8K pixels.
Linear 64 bpp pixel format maximum stride in tiles is 1024
which would mean gen11 support 64k long stride.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_sprite.c | 30 -
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index db80367c0dbc..d829c0be923e 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -383,16 +383,34 @@ skl_plane_max_stride(struct intel_plane *plane,
unsigned int rotation)
{
const struct drm_format_info *info = drm_format_info(pixel_format);
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
int cpp = info->cpp[0];
+ int max_stride_bytes;
+
+ if (INTEL_GEN(dev_priv) >= 11) {
+ /*
+* The stride in bytes must not exceed the
+* size of 8K pixels. Linear 64 bpp pixel format
+* Maximum Stride in tiles = 1024
+* which would mean ICL support 64k long stride.
+* Linear modifier seems to not work with maximum length.
+*/
+ if (modifier == DRM_FORMAT_MOD_LINEAR)
+ max_stride_bytes = 65536-64;
+ else
+ max_stride_bytes = 65536;
+ } else {
+ /*
+* "The stride in bytes must not exceed the
+* of the size of 8K pixels and 32K bytes."
+*/
+ max_stride_bytes = 32768;
+ }
- /*
-* "The stride in bytes must not exceed the
-* of the size of 8K pixels and 32K bytes."
-*/
if (drm_rotation_90_or_270(rotation))
- return min(8192, 32768 / cpp);
+ return min(8192, max_stride_bytes / cpp);
else
- return min(8192 * cpp, 32768);
+ return min(8192 * cpp, max_stride_bytes);
}
static void
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/1] Test over 32k long stride length on icl+
Testing part is left with TODO comment for anything older than gen5 Test-with: 20200319180322.5451-1-juhapekka.heikk...@gmail.com Juha-Pekka Heikkila (1): drm/i915: Allow gen11 to use over 32k long strides drivers/gpu/drm/i915/display/intel_sprite.c | 30 - 1 file changed, 24 insertions(+), 6 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
== Series Details == Series: series starting with [1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure URL : https://patchwork.freedesktop.org/series/74879/ State : success == Summary == CI Bug Log - changes from CI_DRM_8160 -> Patchwork_17025 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/index.html Known issues Here are the changes found in Patchwork_17025 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2] ([i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-skl-lmem/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/fi-skl-lmem/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [PASS][3] -> [DMESG-FAIL][4] ([i915#877]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/fi-cml-s/igt@i915_selftest@live@gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8160/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (37 -> 40) -- Additional (6): fi-bsw-n3050 fi-byt-j1900 fi-cfl-8109u fi-skl-6600u fi-bsw-nick fi-skl-6700k2 Missing(3): fi-byt-clapper fi-byt-squawks fi-bsw-cyan Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8160 -> Patchwork_17025 CI-20190529: 20190529 CI_DRM_8160: 6ba1729e5025761ab74914f6b8aa3288f493e9c7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17025: 16f1ad9b88c54b0140a587b8953aaeadb5136843 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 16f1ad9b88c5 drm: Constify adjusted_mode a bit 09d9ab0a2195 drm: Refactor intel_dp_compute_link_config_*() 99d00f5603c3 drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17025/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/6] drm/i915/tc/icl: Implement the TC cold exit sequence
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.
Just request PCODE to exit TCCOLD is not enough as it could enter
again be driver makes use of the port, to prevent it BSpec states that
aux powerwell should be held.
So before detecting the mode, aux power is requested without wait for
hardware ack, PCODE is requested to exit TCCOLD and the TC detection
sequences follows as normal.
After detection if mode is not static aux can be powered off otherwise
we need to wait for HW ack as future calls to intel_display_power_get()
over aux will not check for HW ack.
v2:
- fixed typo tc_lock_wakeref to tc_cold_wakeref in icl_tc_cold_request()
BSpec: 21750
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
squash
---
.../drm/i915/display/intel_display_power.c| 30 +-
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_tc.c | 56 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 80 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index a7e531b64e16..71a4c5d790ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -573,8 +573,9 @@ static void icl_tc_port_assert_ref_held(struct
drm_i915_private *dev_priv,
#define TGL_AUX_PW_TO_TC_PORT(pw_idx) ((pw_idx) - TGL_PW_CTL_IDX_AUX_TC1)
static void
-icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
-struct i915_power_well *power_well)
+_icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well,
+ bool wait_ack)
{
enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
u32 val;
@@ -587,7 +588,7 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
val |= DP_AUX_CH_CTL_TBT_IO;
intel_de_write(dev_priv, DP_AUX_CH_CTL(aux_ch), val);
- hsw_power_well_enable(dev_priv, power_well);
+ _hsw_power_well_enable(dev_priv, power_well, wait_ack);
if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc->hsw.is_tc_tbt) {
enum tc_port tc_port;
@@ -603,6 +604,20 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
}
}
+static void
+icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+ _icl_tc_phy_aux_power_well_enable(dev_priv, power_well, true);
+}
+
+static void
+icl_tc_phy_aux_power_well_enable_without_ack(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+ _icl_tc_phy_aux_power_well_enable(dev_priv, power_well, false);
+}
+
static void
icl_tc_phy_aux_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
@@ -642,6 +657,13 @@ static bool hsw_power_well_enabled(struct drm_i915_private
*dev_priv,
return (val & mask) == mask;
}
+static void
+hsw_power_well_wait_ack(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ hsw_wait_for_power_well_enable(dev_priv, power_well);
+}
+
static void assert_can_enable_dc9(struct drm_i915_private *dev_priv)
{
drm_WARN_ONCE(&dev_priv->drm,
@@ -3582,8 +3604,10 @@ static const struct i915_power_well_ops
icl_combo_phy_aux_power_well_ops = {
static const struct i915_power_well_ops icl_tc_phy_aux_power_well_ops = {
.sync_hw = hsw_power_well_sync_hw,
.enable = icl_tc_phy_aux_power_well_enable,
+ .enable_without_ack = icl_tc_phy_aux_power_well_enable_without_ack,
.disable = icl_tc_phy_aux_power_well_disable,
.is_enabled = hsw_power_well_enabled,
+ .wait_enable_ack = hsw_power_well_wait_ack,
};
static const struct i915_power_well_regs icl_aux_power_well_regs = {
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077..9b90be43d67d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1386,6 +1386,7 @@ struct intel_digital_port {
enum tc_port_mode tc_mode;
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ intel_wakeref_t tc_cold_wakeref;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index e4c5de5ce874..ccb5ae370973 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/d
Re: [Intel-gfx] [PATCH] drm/i915/dp/mst : Get clock rate from sink's available PBN
On Mon, 2020-03-16 at 13:56 +, Lee, Shawn C wrote:
> On Wed, 2020-03-11, Lyude Paul wrote:
> > On Tue, 2020-01-07 at 01:41 +0800, Lee Shawn C wrote:
> > > Driver report physcial bandwidth for max dot clock rate.
> > > It would caused compatibility issue sometimes when physical bandwidth
> > > exceed MST hub output ability.
> > >
> > > For example, here is a MST hub with HDMI 1.4 and DP 1.2 output.
> > > And source have DP 1.2 output capability. Connect a HDMI 2.0 display
> > > then source will retrieve EDID from external monitor.
> > > Driver got max resolution was 4k@60fps. DP 1.2 can support this
> > > resolution because it did not surpass max physical bandwidth.
> > > After modeset, source output display data but MST hub can't output
> > > HDMI properly due to it already over HDMI 1.4 spec.
> > >
> > > Apply this calculation, source calcualte max dot clock according to
> > > available PBN. Driver will remove the mode that over current clock
> > > rate. And external display can works normally.
> > >
> > > Cc: Manasi Navare
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Cooper Chiou
> > >
> > > Signed-off-by: Lee Shawn C
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 27
> > > ++---
> > > 1 file changed, 24 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index 3b066c63816d..eaa440165ad2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -550,6 +550,27 @@ static int intel_dp_mst_get_modes(struct
> > > drm_connector
> > > *connector)
> > > return intel_dp_mst_get_ddc_modes(connector);
> > > }
> > >
> > > +static int
> > > +intel_dp_mst_downstream_max_dotclock(struct drm_connector *connector)
> > > +{
> > > + struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > > + struct intel_dp *intel_dp = intel_connector->mst_port;
> > > + struct drm_dp_mst_port *port;
> > > + u64 clock_rate = 0;
> > > +
> > > + if (intel_dp->mst_mgr.mst_primary)
> > > + list_for_each_entry(port, &intel_dp->mst_mgr.mst_primary-
> > > > ports, next)
> > > + if (port->connector == connector) {
> > > + clock_rate = ((u64)port->available_pbn * (54 *
> > > 8 * 1000 * 1000)) / (64 * 1006);
> > > +
> > > + // FIXME: We should used pipe bpp to do this
> > > calculation.
> > > + //But can't retrieve bpp setting from
> > > drm_connector.
> > > + return (int)(clock_rate / 24);
> > > + }
> > > +
> > > + return to_i915(connector->dev)->max_dotclk_freq;
> > > +}
> >
> > Hi! So-there's no need to loop through the ports like this, just use the
> > drm_dp_mst_port struct that's associated with intel_connector->port
> > directly (feel free to change the declaration to `struct drm_dp_mst_port
> > *port` instead of `void *port`, it's not illegal to dereference it anymore
> > I promise!
> >
> > Additionally - you don't want to use pipe_bpp here at all. My advice is to
> > use the hard-coded bpc we currently have for MST. Once you guys have retry
> > logic to dynamically select the bpc depending on the available bandwidth,
> > I'd move this check over to using the smallest possible BPC reported by
> > the connector's display_info. Remember we're checking if -any- variant of
> > each mode is somehow possible, it's ok and expected for modes to
> > potentially fail at higher BPCs.
> >
> > Anyway-this looks fine otherwise, but like Ville mentioned available_pbn
> > isn't the thing that we want to be using here. I've got support for using
> > full_pbn instead and that should be pushed sometime today or tommorrow
> > (dealing with some topic branch weirdness with dim right now). This is the
> > patch series,
> > jfyi:
> >
> > https://patchwork.freedesktop.org/series/74295/
> >
> > Also-feel free to write a drm helper to do these mode_valid checks for
> > mst, if it's feasible and not overkill
> >
>
> Thanks! I will refer the change from patch series you mentioned. Hardcode
> bpc to 24 and use full_pbn instead of available_pbn.
>
> BTW, this patch series still on specific branch (topic/mst-bw-check-fixes-
> for-airlied) and not merge to drm branch yet.
> It would be better to wait the patches merged into drm branch. After that, I
> can commit new patch to fix issue. Any comment?
jfyi the patch should be upstream now. So feel free to send a new patch (also
make sure to cc me so I can review it!)
>
> > > +
> > > static enum drm_mode_status
> > > intel_dp_mst_mode_valid(struct drm_connector *connector,
> > > struct drm_display_mode *mode)
> > > @@ -557,8 +578,7 @@ intel_dp_mst_mode_valid(struct drm_connector
> > > *connector,
> > > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > > struct intel_conn
[Intel-gfx] [CI 2/2] drm/i915/gt: Cancel a hung context if already closed
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_reset.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 9a15bdf31c7f..003f26b42998 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -88,6 +88,11 @@ static bool mark_guilty(struct i915_request *rq)
bool banned;
int i;
+ if (intel_context_is_closed(rq->context)) {
+ intel_context_set_banned(rq->context);
+ return true;
+ }
+
rcu_read_lock();
ctx = rcu_dereference(rq->context->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915: Use explicit flag to mark unreachable intel_context
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.c| 2 ++
drivers/gpu/drm/i915/gt/intel_context.h| 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
5 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c0e476fcd1fa..50e7580f9337 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -574,7 +574,7 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
int err = 0;
/* serialises with execbuf */
- RCU_INIT_POINTER(ce->gem_context, NULL);
+ set_bit(CONTEXT_CLOSED_BIT, &ce->flags);
if (!intel_context_pin_if_active(ce))
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..36d069504836 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2316,7 +2316,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
prev = __i915_request_commit(rq);
/* Check that the context wasn't destroyed before submission */
- if (likely(rcu_access_pointer(eb->context->gem_context))) {
+ if (likely(!intel_context_is_closed(eb->context))) {
attr = eb->gem_context->sched;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 01474d3a558b..aea992e46c42 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -97,6 +97,8 @@ int __intel_context_do_pin(struct intel_context *ce)
{
int err;
+ GEM_BUG_ON(intel_context_is_closed(ce));
+
if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
err = intel_context_alloc_state(ce);
if (err)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 18efad255124..07be021882cc 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -173,6 +173,11 @@ static inline bool intel_context_is_barrier(const struct
intel_context *ce)
return test_bit(CONTEXT_BARRIER_BIT, &ce->flags);
}
+static inline bool intel_context_is_closed(const struct intel_context *ce)
+{
+ return test_bit(CONTEXT_CLOSED_BIT, &ce->flags);
+}
+
static inline bool intel_context_use_semaphores(const struct intel_context *ce)
{
return test_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0f3b68b95c56..07cb83a0d017 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -62,10 +62,11 @@ struct intel_context {
#define CONTEXT_BARRIER_BIT0
#define CONTEXT_ALLOC_BIT 1
#define CONTEXT_VALID_BIT 2
-#define CONTEXT_USE_SEMAPHORES 3
-#define CONTEXT_BANNED 4
-#define CONTEXT_FORCE_SINGLE_SUBMISSION5
-#define CONTEXT_NOPREEMPT 6
+#define CONTEXT_CLOSED_BIT 3
+#define CONTEXT_USE_SEMAPHORES 4
+#define CONTEXT_BANNED 5
+#define CONTEXT_FORCE_SINGLE_SUBMISSION6
+#define CONTEXT_NOPREEMPT 7
u32 *lrc_reg_state;
u64 lrc_desc;
--
2.20.1
___
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: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
On Thu, Mar 19, 2020 at 05:53:08PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/19/20 5:38 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Some new eDP panels don't like to operate at the max parameters, and
> > instead we need to go for an optimal confiugration. That unfortunately
> > doesn't work with older eDP panels which are generally only guaranteed
> > to work at the max parameters.
> >
> > To solve these two conflicting requirements let's start with the optimal
> > setup, and if that fails we start again with the max parameters. The
> > downside is probably an extra modeset when we switch strategies but
> > I don't see a good way to avoid that.
> >
> > For a bit of history we first tried to go for the fast+narrow in
> > commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
> > fast and narrow"). but that had to be reverted due to regression
> > on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
> > to max link rate and lane count on eDP"). So now we try to get
> > the best of both worlds by using both strategies.
> >
> > v2: Deal with output_bpp and uapi vs. hw state split
> > Reword some comments
>
> I'm wondering if, at least for the fastset case, but also
> for later modesets I guess, it would not be better to
> first check if the link is already setup (panel already on)
> and then check if the existing parameters match our min/max
> criteria and if they do continue with those settings?
>
> Doing something like this would likely also fix:
> https://gitlab.freedesktop.org/drm/intel/issues/1476
Yeah, I've thought about doing that. It's a bit ugly though, and
probably requires some actual thought so that we don't end up
doing something stupid.
--
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/6] drm/i915/execlists: Force single submission for sentinels
Quoting Chris Wilson (2020-03-19 15:31:41) > Quoting Chris Wilson (2020-03-19 15:21:41) > > First though, I have to answer the question of how I broke persistence. > > Fwiw, it's the await_active update. Time to double check whether it is > flushing the barrier on demand. And it's because I didn't take the lingering preallocated barriers into account. -Chris ___ 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: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
Hi,
On 3/19/20 5:38 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.
To solve these two conflicting requirements let's start with the optimal
setup, and if that fails we start again with the max parameters. The
downside is probably an extra modeset when we switch strategies but
I don't see a good way to avoid that.
For a bit of history we first tried to go for the fast+narrow in
commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
fast and narrow"). but that had to be reverted due to regression
on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
to max link rate and lane count on eDP"). So now we try to get
the best of both worlds by using both strategies.
v2: Deal with output_bpp and uapi vs. hw state split
Reword some comments
I'm wondering if, at least for the fastset case, but also
for later modesets I guess, it would not be better to
first check if the link is already setup (panel already on)
and then check if the existing parameters match our min/max
criteria and if they do continue with those settings?
Doing something like this would likely also fix:
https://gitlab.freedesktop.org/drm/intel/issues/1476
Regards,
Hans
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Albert Astals Cid # v5.0 backport
Cc: Emanuele Panigati # v5.0 backport
Cc: Matteo Iervasi # v5.0 backport
Cc: Timo Aaltonen
References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
References: https://gitlab.freedesktop.org/drm/intel/issues/272
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 74 ---
2 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077..ffde0d4af23c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1258,6 +1258,7 @@ struct intel_dp {
bool link_trained;
bool has_audio;
bool reset_link_params;
+ bool use_max_params;
u8 dpcd[DP_RECEIVER_CAP_SIZE];
u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ef2e06e292d5..85abcce492ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct
intel_dp *intel_dp,
{
int index;
+ if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
+ DRM_DEBUG_KMS("Retrying Link training for eDP with max
parameters\n");
+ intel_dp->use_max_params = true;
+ return 0;
+ }
+
index = intel_dp_rate_index(intel_dp->common_rates,
intel_dp->num_common_rates,
link_rate);
@@ -2046,6 +2052,44 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
return -EINVAL;
}
+/* Optimize link config in order: max bpp, min lanes, min clock */
+static int
+intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ const struct link_config_limits *limits)
+{
+ const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
+ int bpp, clock, lane_count;
+ int mode_rate, link_clock, link_avail;
+
+ for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+ int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
+
+ mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+ output_bpp);
+
+ for (lane_count = limits->min_lane_count;
+lane_count <= limits->max_lane_count;
+lane_count <<= 1) {
+ for (clock = limits->min_clock; clock <=
limits->max_clock; clock++) {
+ link_clock = intel_dp->common_rates[clock];
+ link_avail = intel_dp_max_data_rate(link_clock,
+ lane_count);
+
+ if (mode_rate <= link_avail) {
+ pipe_config->lane_count = lane_count;
+ pipe_config->pipe_bpp = bpp;
+ pipe_config->port_clock = link_clo
[Intel-gfx] [PATCH 2/3] drm: Refactor intel_dp_compute_link_config_*()
From: Ville Syrjälä
Pull the common parts of intel_dp_compute_link_config_wide()
and intel_dp_compute_link_config_fast() into a shared helper
to avoid duplicated code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 76 ++---
1 file changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 85abcce492ca..8491ce8b8c15 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2014,34 +2014,47 @@ static int intel_dp_output_bpp(const struct
intel_crtc_state *crtc_state, int bp
return bpp;
}
+static bool
+intel_dp_link_config_valid(const struct intel_crtc_state *crtc_state,
+ int bpp, int link_clock, int lane_count)
+{
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->hw.adjusted_mode;
+ int output_bpp = intel_dp_output_bpp(crtc_state, bpp);
+ int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+ output_bpp);
+ int link_avail = intel_dp_max_data_rate(link_clock, lane_count);
+
+ return mode_rate <= link_avail;
+}
+
/* Optimize link config in order: max bpp, min clock, min lanes */
static int
intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
- struct intel_crtc_state *pipe_config,
+ struct intel_crtc_state *crtc_state,
const struct link_config_limits *limits)
{
- struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
- int bpp, clock, lane_count;
- int mode_rate, link_clock, link_avail;
+ int bpp;
for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
- int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
+ int clock;
- mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
- output_bpp);
+ for (clock = limits->min_clock;
+clock <= limits->max_clock;
+clock++) {
+ int lane_count;
- for (clock = limits->min_clock; clock <= limits->max_clock;
clock++) {
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count;
lane_count <<= 1) {
- link_clock = intel_dp->common_rates[clock];
- link_avail = intel_dp_max_data_rate(link_clock,
- lane_count);
+ int link_clock = intel_dp->common_rates[clock];
- if (mode_rate <= link_avail) {
- pipe_config->lane_count = lane_count;
- pipe_config->pipe_bpp = bpp;
- pipe_config->port_clock = link_clock;
+ if (intel_dp_link_config_valid(crtc_state, bpp,
+ link_clock,
+ lane_count)) {
+ crtc_state->pipe_bpp = bpp;
+ crtc_state->port_clock = link_clock;
+ crtc_state->lane_count = lane_count;
return 0;
}
@@ -2055,31 +2068,30 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
/* Optimize link config in order: max bpp, min lanes, min clock */
static int
intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
- struct intel_crtc_state *pipe_config,
+ struct intel_crtc_state *crtc_state,
const struct link_config_limits *limits)
{
- const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
- int bpp, clock, lane_count;
- int mode_rate, link_clock, link_avail;
+ int bpp;
for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
- int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
-
- mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
- output_bpp);
+ int lane_count;
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count;
lane_count <<= 1) {
- for (clock = limits->min_clock; clock <=
limits->max_clock; clock++) {
- link_clock = intel_dp->common_ra
[Intel-gfx] [PATCH 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
From: Ville Syrjälä
Some new eDP panels don't like to operate at the max parameters, and
instead we need to go for an optimal confiugration. That unfortunately
doesn't work with older eDP panels which are generally only guaranteed
to work at the max parameters.
To solve these two conflicting requirements let's start with the optimal
setup, and if that fails we start again with the max parameters. The
downside is probably an extra modeset when we switch strategies but
I don't see a good way to avoid that.
For a bit of history we first tried to go for the fast+narrow in
commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config
fast and narrow"). but that had to be reverted due to regression
on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back
to max link rate and lane count on eDP"). So now we try to get
the best of both worlds by using both strategies.
v2: Deal with output_bpp and uapi vs. hw state split
Reword some comments
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Albert Astals Cid # v5.0 backport
Cc: Emanuele Panigati # v5.0 backport
Cc: Matteo Iervasi # v5.0 backport
Cc: Timo Aaltonen
References: https://bugs.freedesktop.org/show_bug.cgi?id=105267
References: https://bugs.freedesktop.org/show_bug.cgi?id=109959
References: https://gitlab.freedesktop.org/drm/intel/issues/272
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 74 ---
2 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077..ffde0d4af23c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1258,6 +1258,7 @@ struct intel_dp {
bool link_trained;
bool has_audio;
bool reset_link_params;
+ bool use_max_params;
u8 dpcd[DP_RECEIVER_CAP_SIZE];
u8 psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
u8 downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ef2e06e292d5..85abcce492ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -465,6 +465,12 @@ int intel_dp_get_link_train_fallback_values(struct
intel_dp *intel_dp,
{
int index;
+ if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
+ DRM_DEBUG_KMS("Retrying Link training for eDP with max
parameters\n");
+ intel_dp->use_max_params = true;
+ return 0;
+ }
+
index = intel_dp_rate_index(intel_dp->common_rates,
intel_dp->num_common_rates,
link_rate);
@@ -2046,6 +2052,44 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
return -EINVAL;
}
+/* Optimize link config in order: max bpp, min lanes, min clock */
+static int
+intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ const struct link_config_limits *limits)
+{
+ const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
+ int bpp, clock, lane_count;
+ int mode_rate, link_clock, link_avail;
+
+ for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+ int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
+
+ mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+ output_bpp);
+
+ for (lane_count = limits->min_lane_count;
+lane_count <= limits->max_lane_count;
+lane_count <<= 1) {
+ for (clock = limits->min_clock; clock <=
limits->max_clock; clock++) {
+ link_clock = intel_dp->common_rates[clock];
+ link_avail = intel_dp_max_data_rate(link_clock,
+ lane_count);
+
+ if (mode_rate <= link_avail) {
+ pipe_config->lane_count = lane_count;
+ pipe_config->pipe_bpp = bpp;
+ pipe_config->port_clock = link_clock;
+
+ return 0;
+ }
+ }
+ }
+ }
+
+ return -EINVAL;
+}
+
static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc)
{
int i, num_bpc;
@@ -2261,13 +2305,14 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
limits.min_bpp = intel_dp_min_bpp(pipe_config);
limits.max_bpp = intel_dp_comput
[Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit
From: Ville Syrjälä
The DP link computation functions shouldn't modify the
adjusted_mode so make it const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8491ce8b8c15..110d82ee4859 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2181,7 +2181,8 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
- struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
+ const struct drm_display_mode *adjusted_mode =
+ &pipe_config->hw.adjusted_mode;
u8 dsc_max_bpc;
int pipe_bpp;
int ret;
@@ -2296,7 +2297,8 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
- struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
+ const struct drm_display_mode *adjusted_mode =
+ &pipe_config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct link_config_limits limits;
int common_len;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Increase the DDI idle timeout to 500us
On Thu, Mar 19, 2020 at 11:30:03AM +0200, Arkadiusz Hiler wrote: > On Thu, Mar 19, 2020 at 11:20:34AM +0200, Arkadiusz Hiler wrote: > > Bspec says that we should timeout after 500us. Let's match this in the > > code. It may help with few of the timeouts we see here and there. > > Plese disregard. it's 500us when waiting on non-idle and only 8 (16 > for BXT) for back to idle. Could probably convert to intel_de_wait_for...() regardless. 1ms vs. 16us isn't going to kill us in modeset code. The exact bspec value can be kept as a comment. -- 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] drm/i915: Enable non-contiguous pipe fusing
On Thu, Mar 19, 2020 at 01:23:18PM +0530, Anshuman Gupta wrote: > On 2020-03-18 at 18:48:27 +0200, Ville Syrjälä wrote: > > On Fri, Mar 13, 2020 at 12:39:17AM -0700, Lucas De Marchi wrote: > > > On Wed, Mar 11, 2020 at 02:06:32PM +0530, Anshuman Gupta wrote: > > > >Allow 3-display pipes SKU system with any combination > > > >in INTEL_INFO pipe mask. > > > >B.Spec:50075 > > > > > > > >changes since RFC: > > > >- using intel_pipe_mask_is_valid() function to check integrity of > > > > pipe_mask. [Ville] > > > >v2: > > > >- simplify condition in intel_pipe_mask_is_valid(). [Ville] > > > >v3: > > > >- removed non-contiguous pipe fusing check. [Lucas] > > > > > > I'd also say in the commit message that the support for non-contiguous > > > pipe fusing is *already* supported in the driver. So this check here > > > doesn't make sense anymore and since it's an unlike condition we > > > can just stop checking. > > > > BTW I think we still have those crtc index==pipe asserts in the code > > somewhere. Now that all the (known) assumptions have been fixed we can > > remove the WARNs. > yes we still have drm_WARN_ON(&dev_priv->drm, drm_crtc_index(&crtc->base) != > crtc->pipe) > in intel_crtc_init. > AFAIU the idea was to have the WARN_ON to know that we are running a broken > driver > (if there any unknown assumption is still left out). Unknown assumptions are by definition unknown. The WARN will not help with those. -- 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: Allow for different modes of interruptible i915_active_wait
== Series Details == Series: series starting with [1/2] drm/i915: Allow for different modes of interruptible i915_active_wait URL : https://patchwork.freedesktop.org/series/74877/ State : success == Summary == CI Bug Log - changes from CI_DRM_8159 -> Patchwork_17024 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/index.html Known issues Here are the changes found in Patchwork_17024 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-skl-6700k2: [PASS][1] -> [INCOMPLETE][2] ([i915#1430] / [i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/fi-skl-6700k2/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/fi-skl-6700k2/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#106070] / [i915#424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@i915_selftest@live@execlists: - fi-cml-u2: [INCOMPLETE][5] ([i915#283] / [i915#656]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/fi-cml-u2/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/fi-cml-u2/igt@i915_selftest@l...@execlists.html Warnings * igt@i915_pm_rpm@basic-pci-d3-state: - fi-kbl-guc: [FAIL][7] ([i915#665] / [i915#704]) -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][9] ([fdo#111407]) -> [FAIL][10] ([i915#323]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8159/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430 [i915#283]: https://gitlab.freedesktop.org/drm/intel/issues/283 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#665]: https://gitlab.freedesktop.org/drm/intel/issues/665 [i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704 Participating hosts (43 -> 34) -- Additional (1): fi-kbl-7560u Missing(10): fi-bdw-5557u fi-tgl-dsi fi-bsw-n3050 fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-gdg-551 fi-cfl-8109u fi-skl-lmem fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8159 -> Patchwork_17024 CI-20190529: 20190529 CI_DRM_8159: 00b2e0f1e7b3ea36379d68855f46a86400935411 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17024: 3403802550e2ee8def62ef99d583e1dc8b64c2a9 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3403802550e2 drm/i915/gem: Prevent switching of active GEM context VM f48310646e30 drm/i915: Allow for different modes of interruptible i915_active_wait == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17024/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
Quoting Chris Wilson (2020-03-19 14:52:21)
> Quoting Tvrtko Ursulin (2020-03-19 14:20:04)
> >
> > On 19/03/2020 09:19, Chris Wilson wrote:
> > > +static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32
> > > handle)
> > > +{
> > > + do {
> > > + struct drm_i915_gem_object *obj;
> > > struct i915_vma *vma;
> > > + int err;
> > >
> > > - vma = radix_tree_lookup(handles_vma, handle);
> > > + rcu_read_lock();
> > > + vma = radix_tree_lookup(&eb->gem_context->handles_vma,
> > > handle);
> >
> > radix_tree_lookup is documented to be RCU safe okay. How about freeing
> > VMAs - is that done after a RCU grace period?
>
> As we are still stuck with the horrible i915_vma.kref semantics (yes, I
> know I'm supposed to be fixing that), there are 3 paths which may
> destroy i915_vma: the object (RCU safe), the vm (RCU safe) and
> i915_vma_parked, not safe in any way shape or form.
Actually, the nasty fact I keep forgetting is that i915_vma_parked is
serialised with execbuf by virtue of the engine-pm. That has caught me
out many times, but is why this is safe (and takes extra effort to
convert to kref).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 6/7] drm/i915/dp: Register definition for DP compliance register
On Thu, Mar 19, 2020 at 12:09:18PM +0530, Manna, Animesh wrote:
> On 19-03-2020 01:34, Manasi Navare wrote:
> > On Wed, Mar 18, 2020 at 12:05:14PM +0530, Animesh Manna wrote:
> >> DP_COMP_CTL and DP_COMP_PAT register used to program DP
> >> compliance pattern.
> >>
> >> v1: Initial patch.
> >> v2: used pipe instead of port in macro definition. [Manasi]
> >> v3: used trans_offset for offset calculation. [Manasi]
> >>
> >> Reviewed-by: Manasi Navare
> >> Signed-off-by: Animesh Manna
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 16
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 309cb7d96b35..8b6c9fbfe74b 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -9792,6 +9792,22 @@ enum skl_power_gate {
> >> #define DDI_BUF_BALANCE_LEG_ENABLE (1 << 31)
> >> #define DDI_BUF_TRANS_HI(port, i)_MMIO(_PORT(port,
> >> _DDI_BUF_TRANS_A, _DDI_BUF_TRANS_B) + (i) * 8 + 4)
> >>
> >> +/* DDI DP Compliance Control */
> >> +#define _DDI_DP_COMP_CTL_A0x605F0
> >> +#define DDI_DP_COMP_CTL(pipe) _MMIO_TRANS2(pipe,
> >> _DDI_DP_COMP_CTL_A)
> > Any reason why you couldnt use _MMIO_PIPE2 ?
>
> As DP_COMP_CTL is part of transcoder register group, so I choose _MMIO_TRANS2
> for calculation. Yes _MMIO_PIPE2 will also work as the offset difference
> between subsequent pipe is same (0x1000).
The preference is:
1. _MMIO_PIPE()/etc. for evenly spaced things
2. _MMIO_PIPE2()/etc. for regular but not evenly spaced stuff
3. _PICK() where the above two fail
There are probably a few places that do violate that though.
We should probably fix those to not give people the wrong ideas.
--
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/6] drm/i915/execlists: Force single submission for sentinels
Quoting Chris Wilson (2020-03-19 15:21:41) > First though, I have to answer the question of how I broke persistence. Fwiw, it's the await_active update. Time to double check whether it is flushing the barrier on demand. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915/execlists: Force single submission for sentinels
Quoting Tvrtko Ursulin (2020-03-19 15:11:49) > > On 19/03/2020 15:02, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-03-19 14:31:36) > >> > >> On 19/03/2020 09:19, Chris Wilson wrote: > >>> + if (has_sentinel(last, rq)) > >>>goto done; > >> > >> I am only confused by can_merge_rq saying two sentinel requests can be > >> merged together: > >> > >> if (unlikely((i915_request_flags(prev) ^ > >> i915_request_flags(next)) & > >> (BIT(I915_FENCE_FLAG_NOPREEMPT) | > >>BIT(I915_FENCE_FLAG_SENTINEL > >> return false; > >> > >> What am I missing? > > > > I thought it was fine to coalesce consecutive sentinels within the > > context into one. > > > > Except you're thinking about gvt, and not my usage :| > > Sentinel is like "only one context in elsp at a time", right? > This is what GVT wants. GVT wants one request. For my purpose, it was just one context. > And for the active barrier we want single elsp and not > coalesced with non-sentinel from the same context. But sentinels are > kernel context, so should be fine. Although it still may be clearer to > make then not coalesce as well. The frequency should of non-barrier operations along the kernel context should not be high enough that we gain anything by coalescing mixed barrier/non-barrier request streams. I hope. On the other hand we do want to coalesce NOPREEMPT streams. Oh well, my hope for pulling it all in one bitops seems to be fading away. First though, I have to answer the question of how I broke persistence. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915/execlists: Force single submission for sentinels
On 19/03/2020 15:02, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-03-19 14:31:36) On 19/03/2020 09:19, Chris Wilson wrote: + if (has_sentinel(last, rq)) goto done; I am only confused by can_merge_rq saying two sentinel requests can be merged together: if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) & (BIT(I915_FENCE_FLAG_NOPREEMPT) | BIT(I915_FENCE_FLAG_SENTINEL return false; What am I missing? I thought it was fine to coalesce consecutive sentinels within the context into one. Except you're thinking about gvt, and not my usage :| Sentinel is like "only one context in elsp at a time", right? This is what GVT wants. And for the active barrier we want single elsp and not coalesced with non-sentinel from the same context. But sentinels are kernel context, so should be fine. Although it still may be clearer to make then not coalesce as well. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: move files more files into debugfs
On 18/03/2020 13:58, Andi Shyti wrote:
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_gem_drop_caches
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- drop_caches
|
+-- forcewake_user
|
+-- interrupt_info_show
|
+-- wedge
Signed-off-by: Andi Shyti
---
Hi,
this patch is the first of a series that aims to refactor the
debugfs structure in the i915. Some changes will affect the
debugfs framework as well.
Andi
drivers/gpu/drm/i915/gt/debugfs_engines.c | 54 +
drivers/gpu/drm/i915/gt/debugfs_gt.c | 140 +-
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 32 +
3 files changed, 225 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_engines.c
b/drivers/gpu/drm/i915/gt/debugfs_engines.c
index 5e3725e62241..0d0fee1a166d 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_engines.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_engines.c
@@ -11,6 +11,59 @@
#include "i915_drv.h" /* for_each_engine! */
#include "intel_engine.h"
+static int interrupt_info_show(struct seq_file *m, void *data)
+{
+ struct intel_gt *gt = m->private;
+ struct intel_uncore *uncore = gt->uncore;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+
+ wakeref = intel_runtime_pm_get(uncore->rpm);
+
+ if (INTEL_GEN(gt->i915) >= 11) {
+ seq_printf(m, "RCS Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_RCS0_RSVD_INTR_MASK));
+ seq_printf(m, "BCS Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_BCS_RSVD_INTR_MASK));
+ seq_printf(m, "VCS0/VCS1 Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_VCS0_VCS1_INTR_MASK));
+ seq_printf(m, "VCS2/VCS3 Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_VCS2_VCS3_INTR_MASK));
+ seq_printf(m, "VECS0/VECS1 Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_VECS0_VECS1_INTR_MASK));
+ seq_printf(m, "GUC/SG Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_GUC_SG_INTR_MASK));
+ seq_printf(m, "GPM/WGBOXPERF Intr Mask: %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_GPM_WGBOXPERF_INTR_MASK));
+ seq_printf(m, "Crypto Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_CRYPTO_RSVD_INTR_MASK));
+ seq_printf(m, "Gunit/CSME Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_GUNIT_CSME_INTR_MASK));
+
Visually odd blank line.
+ } else if (INTEL_GEN(gt->i915) >= 6) {
+ for_each_engine(engine, gt, id) {
+ seq_printf(m,
+ "Graphics Interrupt mask (%s): %08x\n",
+ engine->name, ENGINE_READ(engine, RING_IMR));
+ }
+ }
I saw that Chris is not overly excited by this one but I think why not.
But two things:
1.
Some platforms are missing and some GT registers are missing from "gen
>= 6". For instance GT_I*R.
What do to with CHV and VLV? Split or leave as is?
For Gen11 I'd have GEN11_GFX_MSTR_IRQ in both GT and display/legacy file
because it is shared. GEN8_MASTER_IRQ as well then I guess.
2.
I'd remove the data which got moved here from the legacy file.
+
+ intel_runtime_pm_put(uncore->rpm, wakeref);
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(interrupt_info);
+
static int engines_show(struct seq_file *m, void *data)
{
struct intel_gt *gt = m->private;
@@ -29,6 +82,7 @@ DEFINE_GT_DEBUGFS_ATTRIBUTE(engines);
void debugfs_engines_register(struct intel_gt *gt, struct dentry *root)
{
static const struct debugfs_gt_file files[] = {
+ { "interrupt_info_show", &interrupt_info_fops, NULL },
{ "engines", &engines_fops },
};
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index fcbc57e226c3..1fc960ebba06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -5,12 +5,148 @@
*/
#include
+#include
#include "debugfs_engines.h"
#include "debugfs_gt.h"
#include "debugfs_gt_pm.h"
-#include "uc/debugfs_uc.h"
#
Re: [Intel-gfx] [PATCH 3/6] drm/i915/execlists: Force single submission for sentinels
Quoting Tvrtko Ursulin (2020-03-19 14:31:36) > > On 19/03/2020 09:19, Chris Wilson wrote: > > + if (has_sentinel(last, rq)) > > goto done; > > I am only confused by can_merge_rq saying two sentinel requests can be > merged together: > > if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) & > (BIT(I915_FENCE_FLAG_NOPREEMPT) | > BIT(I915_FENCE_FLAG_SENTINEL > return false; > > What am I missing? I thought it was fine to coalesce consecutive sentinels within the context into one. Except you're thinking about gvt, and not my usage :| -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
Quoting Tvrtko Ursulin (2020-03-19 14:20:04)
>
> On 19/03/2020 09:19, Chris Wilson wrote:
> > +static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32
> > handle)
> > +{
> > + do {
> > + struct drm_i915_gem_object *obj;
> > struct i915_vma *vma;
> > + int err;
> >
> > - vma = radix_tree_lookup(handles_vma, handle);
> > + rcu_read_lock();
> > + vma = radix_tree_lookup(&eb->gem_context->handles_vma,
> > handle);
>
> radix_tree_lookup is documented to be RCU safe okay. How about freeing
> VMAs - is that done after a RCU grace period?
As we are still stuck with the horrible i915_vma.kref semantics (yes, I
know I'm supposed to be fixing that), there are 3 paths which may
destroy i915_vma: the object (RCU safe), the vm (RCU safe) and
i915_vma_parked, not safe in any way shape or form.
A quick and dirty solution would be to move i915_vma_parked behind an
rcu work.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_vm_create: Update of active VM disallowed
Allow the kernel the rights to reject updating an active VM with -EBUSY.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_param.c | 13 +++--
tests/i915/gem_vm_create.c | 11 ++-
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/tests/i915/gem_ctx_param.c b/tests/i915/gem_ctx_param.c
index 179992875..b2940abc2 100644
--- a/tests/i915/gem_ctx_param.c
+++ b/tests/i915/gem_ctx_param.c
@@ -211,13 +211,14 @@ static void test_vm(int i915)
gem_execbuf(i915, &eb);
igt_assert_eq_u64(batch.offset, nonzero_offset);
+ /* Note: changing an active ctx->vm may be verboten */
arg.ctx_id = child;
- gem_context_set_param(i915, &arg);
-
- eb.rsvd1 = child;
- batch.offset = 0;
- gem_execbuf(i915, &eb);
- igt_assert_eq_u64(batch.offset, nonzero_offset);
+ if (__gem_context_set_param(i915, &arg) != -EBUSY) {
+ eb.rsvd1 = child;
+ batch.offset = 0;
+ gem_execbuf(i915, &eb);
+ igt_assert_eq_u64(batch.offset, nonzero_offset);
+ }
gem_context_destroy(i915, child);
gem_context_destroy(i915, parent);
diff --git a/tests/i915/gem_vm_create.c b/tests/i915/gem_vm_create.c
index e14b07b5f..a6d2dd91b 100644
--- a/tests/i915/gem_vm_create.c
+++ b/tests/i915/gem_vm_create.c
@@ -164,6 +164,7 @@ static void check_same_vm(int i915, uint32_t ctx_a,
uint32_t ctx_b)
eb.rsvd1 = ctx_a;
gem_execbuf(i915, &eb);
igt_assert_eq_u64(batch.offset, 48 << 20);
+ gem_sync(i915, batch.handle); /* be still */
/* An already active VMA will try to keep its offset */
batch.offset = 0;
@@ -224,6 +225,7 @@ static void execbuf(int i915)
batch.offset = 48 << 20;
gem_execbuf(i915, &eb);
igt_assert_eq_u64(batch.offset, 48 << 20);
+ gem_sync(i915, batch.handle);
arg.value = gem_vm_create(i915);
gem_context_set_param(i915, &arg);
@@ -231,6 +233,8 @@ static void execbuf(int i915)
igt_assert_eq_u64(batch.offset, 48 << 20);
gem_vm_destroy(i915, arg.value);
+ gem_sync(i915, batch.handle); /* be idle! */
+
arg.value = gem_vm_create(i915);
gem_context_set_param(i915, &arg);
batch.offset = 0;
@@ -354,13 +358,18 @@ static void async_destroy(int i915)
.param = I915_CONTEXT_PARAM_VM,
};
igt_spin_t *spin[2];
+ int err;
spin[0] = igt_spin_new(i915,
.ctx = arg.ctx_id,
.flags = IGT_SPIN_POLL_RUN);
igt_spin_busywait_until_started(spin[0]);
- gem_context_set_param(i915, &arg);
+ err = __gem_context_set_param(i915, &arg);
+ if (err == -EBUSY) /* update while busy may be verboten, let it ride. */
+ err = 0;
+ igt_assert_eq(err, 0);
+
spin[1] = __igt_spin_new(i915, .ctx = arg.ctx_id);
igt_spin_end(spin[0]);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/gt: Cancel a hung context if already closed
On 19/03/2020 14:40, Tvrtko Ursulin wrote:
On 19/03/2020 09:19, Chris Wilson wrote:
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT
reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_reset.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 9a15bdf31c7f..003f26b42998 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -88,6 +88,11 @@ static bool mark_guilty(struct i915_request *rq)
bool banned;
int i;
+ if (intel_context_is_closed(rq->context)) {
+ intel_context_set_banned(rq->context);
+ return true;
+ }
+
rcu_read_lock();
ctx = rcu_dereference(rq->context->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
Reviewed-by: Tvrtko Ursulin
Although shards are reporting something is not quite right. Is it this
patch? Doesn't look like it..
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Allow for different modes of interruptible i915_active_wait
Allow some users the discretion to not immediately return on a normal
signal. Hopefully, they will opt to use TASK_KILLABLE instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 6 --
drivers/gpu/drm/i915/i915_active.h | 6 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index c4048628188a..2572dab57d8b 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -496,7 +496,7 @@ static int flush_lazy_signals(struct i915_active *ref)
return err;
}
-int i915_active_wait(struct i915_active *ref)
+int __i915_active_wait(struct i915_active *ref, int state)
{
int err;
@@ -511,7 +511,9 @@ int i915_active_wait(struct i915_active *ref)
if (err)
return err;
- if (wait_var_event_interruptible(ref, i915_active_is_idle(ref)))
+ if (!i915_active_is_idle(ref) &&
+ ___wait_var_event(ref, i915_active_is_idle(ref),
+ state, 0, 0, schedule()))
return -EINTR;
flush_work(&ref->work);
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index b3282ae7913c..4f9aa7bab514 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -181,7 +181,11 @@ static inline bool i915_active_has_exclusive(struct
i915_active *ref)
return rcu_access_pointer(ref->excl.fence);
}
-int i915_active_wait(struct i915_active *ref);
+int __i915_active_wait(struct i915_active *ref, int state);
+static inline int i915_active_wait(struct i915_active *ref)
+{
+ return __i915_active_wait(ref, TASK_INTERRUPTIBLE);
+}
int i915_sw_fence_await_active(struct i915_sw_fence *fence,
struct i915_active *ref,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Prevent switching of active GEM context VM
A nasty issue was found with the way we serialise the update of the GTT
(GPU virtual address space) on the GEM context and with execution via
execbuf. On update we serialise with ctx->mutex and attempt to rewrite
the GTT addresses stored within the context from inside a request (along
that context), but from execbuf we were cheerfully using whatever
address was stored inside the intel_context. Thus there was a race where
we might be using a stale vm when the user updated the GEM context
concurrently. To prevent that, deny updating an active context and only
allow switching the VM when the context is unpinned (not in use on the
HW).
Reported-by: Maarten Lankhorst
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 229 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 125 --
drivers/gpu/drm/i915/gt/intel_context.h | 13 +
drivers/gpu/drm/i915/gt/intel_context_param.c | 33 +++
drivers/gpu/drm/i915/gt/intel_context_param.h | 4 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
7 files changed, 64 insertions(+), 343 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c0e476fcd1fa..8cf15fc53982 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -778,20 +778,25 @@ context_apply_all(struct i915_gem_context *ctx,
static int __apply_ppgtt(struct intel_context *ce, void *vm)
{
- i915_vm_put(ce->vm);
- ce->vm = i915_vm_get(vm);
- return 0;
+ return intel_context_set_vm(ce, vm);
}
static struct i915_address_space *
__set_ppgtt(struct i915_gem_context *ctx, struct i915_address_space *vm)
{
struct i915_address_space *old = i915_gem_context_vm(ctx);
+ int err;
GEM_BUG_ON(old && i915_vm_is_4lvl(vm) != i915_vm_is_4lvl(old));
+ err = context_apply_all(ctx, __apply_ppgtt, vm);
+ if (err) {
+ /* Reapplying the old vm should not have to wait... */
+ context_apply_all(ctx, __apply_ppgtt, old);
+ return ERR_PTR(err);
+ }
+
rcu_assign_pointer(ctx->vm, i915_vm_open(vm));
- context_apply_all(ctx, __apply_ppgtt, vm);
return old;
}
@@ -803,6 +808,7 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
return;
vm = __set_ppgtt(ctx, vm);
+ GEM_BUG_ON(IS_ERR(vm));
if (vm)
i915_vm_close(vm);
}
@@ -1051,122 +1057,6 @@ int i915_gem_vm_destroy_ioctl(struct drm_device *dev,
void *data,
return 0;
}
-struct context_barrier_task {
- struct i915_active base;
- void (*task)(void *data);
- void *data;
-};
-
-__i915_active_call
-static void cb_retire(struct i915_active *base)
-{
- struct context_barrier_task *cb = container_of(base, typeof(*cb), base);
-
- if (cb->task)
- cb->task(cb->data);
-
- i915_active_fini(&cb->base);
- kfree(cb);
-}
-
-static inline struct i915_gem_engines *
-__context_engines_await(const struct i915_gem_context *ctx)
-{
- struct i915_gem_engines *engines;
-
- rcu_read_lock();
- do {
- engines = rcu_dereference(ctx->engines);
- if (unlikely(!engines))
- break;
-
- if (unlikely(!i915_sw_fence_await(&engines->fence)))
- continue;
-
- if (likely(engines == rcu_access_pointer(ctx->engines)))
- break;
-
- i915_sw_fence_complete(&engines->fence);
- } while (1);
- rcu_read_unlock();
-
- return engines;
-}
-
-I915_SELFTEST_DECLARE(static intel_engine_mask_t context_barrier_inject_fault);
-static int context_barrier_task(struct i915_gem_context *ctx,
- intel_engine_mask_t engines,
- bool (*skip)(struct intel_context *ce, void
*data),
- int (*emit)(struct i915_request *rq, void
*data),
- void (*task)(void *data),
- void *data)
-{
- struct context_barrier_task *cb;
- struct i915_gem_engines_iter it;
- struct i915_gem_engines *e;
- struct intel_context *ce;
- int err = 0;
-
- GEM_BUG_ON(!task);
-
- cb = kmalloc(sizeof(*cb), GFP_KERNEL);
- if (!cb)
- return -ENOMEM;
-
- i915_active_init(&cb->base, NULL, cb_retire);
- err = i915_active_acquire(&cb->base);
- if (err) {
- kfree(cb);
- return err;
- }
-
- e = __context_engines_await(ctx);
- if (!e) {
- i915_active_release(&cb->base);
- return -ENOENT;
- }
-
- for_each_gem_engine(ce, e, it) {
- struct i915_request *rq;
-
-
Re: [Intel-gfx] [PATCH 6/6] drm/i915/gt: Cancel a hung context if already closed
On 19/03/2020 09:19, Chris Wilson wrote:
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_reset.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 9a15bdf31c7f..003f26b42998 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -88,6 +88,11 @@ static bool mark_guilty(struct i915_request *rq)
bool banned;
int i;
+ if (intel_context_is_closed(rq->context)) {
+ intel_context_set_banned(rq->context);
+ return true;
+ }
+
rcu_read_lock();
ctx = rcu_dereference(rq->context->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915/gem: Wait until the context is finally retired before releasing engines
On 19/03/2020 09:19, Chris Wilson wrote:
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin.
To accommodate this, we need to be able to flush the i915_active's
barriers before awaiting on them. However, this also requires us to
ensure the context is unpinned *before* the barrier request can be
signaled, so mark it as a sentinel.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 17 --
drivers/gpu/drm/i915/i915_active.c | 37 -
drivers/gpu/drm/i915/i915_active.h | 3 +-
3 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c0e476fcd1fa..05fed8797d37 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,23 +570,20 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
engines->ctx = i915_gem_context_get(ctx);
for_each_gem_engine(ce, engines, it) {
- struct dma_fence *fence;
- int err = 0;
+ int err;
/* serialises with execbuf */
RCU_INIT_POINTER(ce->gem_context, NULL);
if (!intel_context_pin_if_active(ce))
continue;
- fence = i915_active_fence_get(&ce->timeline->last_request);
- if (fence) {
- err = i915_sw_fence_await_dma_fence(&engines->fence,
- fence, 0,
- GFP_KERNEL);
- dma_fence_put(fence);
- }
+ /* Wait until context is finally scheduled out and retired */
+ err = i915_sw_fence_await_active(&engines->fence,
+&ce->active,
+I915_ACTIVE_AWAIT_ACTIVE |
+I915_ACTIVE_AWAIT_BARRIER);
intel_context_unpin(ce);
- if (err < 0)
+ if (err)
goto kill;
}
diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
index c4048628188a..da7d35f66dd0 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -518,19 +518,18 @@ int i915_active_wait(struct i915_active *ref)
return 0;
}
-static int __await_active(struct i915_active_fence *active,
- int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+static int __await_fence(struct i915_active_fence *active,
+int (*fn)(void *arg, struct dma_fence *fence),
+void *arg)
{
struct dma_fence *fence;
+ int err;
- if (is_barrier(active)) /* XXX flush the barrier? */
+ if (is_barrier(active))
return 0;
fence = i915_active_fence_get(active);
if (fence) {
- int err;
-
err = fn(arg, fence);
dma_fence_put(fence);
if (err < 0)
@@ -540,6 +539,22 @@ static int __await_active(struct i915_active_fence *active,
return 0;
}
+static int __await_active(struct active_node *it,
+ unsigned int flags,
+ int (*fn)(void *arg, struct dma_fence *fence),
+ void *arg)
+{
+ int err;
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_barrier(it);
+ if (err)
+ return err;
+ }
+
+ return __await_fence(&it->base, fn, arg);
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
@@ -549,16 +564,17 @@ static int await_active(struct i915_active *ref,
/* We must always wait for the exclusive fence! */
if (rcu_access_pointer(ref->excl.fence)) {
- err = __await_active(&ref->excl, fn, arg);
+ err = __await_fence(&ref->excl, fn, arg);
if (err)
return err;
}
- if (flags & I915_ACTIVE_AWAIT_ALL && i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
+ i915_active_acquire_if_busy(ref)) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
- err = __await_active(&it->base, fn, arg);
+ err = __await_active(it, flags, fn, arg);
if (e
Re: [Intel-gfx] [PATCH 3/6] drm/i915/execlists: Force single submission for sentinels
On 19/03/2020 09:19, Chris Wilson wrote:
> Currently, we only combine a sentinel request with a max-priority
> barrier such that a sentinel request is always in ELSP[0] with nothing
> following it. However, we will want to create similar ELSP[] submissions
> providing a full-barrier in the submission queue, but without forcing
> maximum priority. As such I915_FENCE_FLAG_SENTINEL takes on the
> single-submission property and so we can remove the gvt special casing.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_context.h | 24 +++---
> drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +--
> drivers/gpu/drm/i915/gt/intel_lrc.c | 33 +--
> drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++--
> 4 files changed, 26 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index 18efad255124..ee5d47165c12 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -198,18 +198,6 @@ static inline bool intel_context_set_banned(struct
> intel_context *ce)
> return test_and_set_bit(CONTEXT_BANNED, &ce->flags);
> }
>
> -static inline bool
> -intel_context_force_single_submission(const struct intel_context *ce)
> -{
> - return test_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, &ce->flags);
> -}
> -
> -static inline void
> -intel_context_set_single_submission(struct intel_context *ce)
> -{
> - __set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, &ce->flags);
> -}
> -
> static inline bool
> intel_context_nopreempt(const struct intel_context *ce)
> {
> @@ -228,6 +216,18 @@ intel_context_clear_nopreempt(struct intel_context *ce)
> clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
> }
>
> +static inline bool
> +intel_context_is_gvt(const struct intel_context *ce)
> +{
> + return test_bit(CONTEXT_GVT, &ce->flags);
> +}
> +
> +static inline void
> +intel_context_set_gvt(struct intel_context *ce)
> +{
> + set_bit(CONTEXT_GVT, &ce->flags);
> +}
> +
> static inline u64 intel_context_get_total_runtime_ns(struct intel_context
> *ce)
> {
> const u32 period =
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index 0f3b68b95c56..fd2703efc10c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -64,8 +64,8 @@ struct intel_context {
> #define CONTEXT_VALID_BIT 2
> #define CONTEXT_USE_SEMAPHORES 3
> #define CONTEXT_BANNED 4
> -#define CONTEXT_FORCE_SINGLE_SUBMISSION 5
> -#define CONTEXT_NOPREEMPT6
> +#define CONTEXT_NOPREEMPT5
> +#define CONTEXT_GVT 6
>
> u32 *lrc_reg_state;
> u64 lrc_desc;
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 112531b29f59..f0c4084c5b9a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1579,22 +1579,10 @@ static void execlists_submit_ports(struct
> intel_engine_cs *engine)
> writel(EL_CTRL_LOAD, execlists->ctrl_reg);
> }
>
> -static bool ctx_single_port_submission(const struct intel_context *ce)
> -{
> - return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
> - intel_context_force_single_submission(ce));
> -}
> -
> static bool can_merge_ctx(const struct intel_context *prev,
> const struct intel_context *next)
> {
> - if (prev != next)
> - return false;
> -
> - if (ctx_single_port_submission(prev))
> - return false;
> -
> - return true;
> + return prev == next;
> }
>
> static unsigned long i915_request_flags(const struct i915_request *rq)
> @@ -1844,6 +1832,12 @@ static inline void clear_ports(struct i915_request
> **ports, int count)
> memset_p((void **)ports, NULL, count);
> }
>
> +static bool has_sentinel(struct i915_request *prev, struct i915_request
> *next)
> +{
> + return (i915_request_flags(prev) | i915_request_flags(next)) &
> + BIT(I915_FENCE_FLAG_SENTINEL);
> +}
> +
> static void execlists_dequeue(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlists * const execlists = &engine->execlists;
> @@ -2125,18 +2119,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> if (last->context == rq->context)
> goto done;
>
> - if (i915_request_has_sentinel(last))
> - goto done;
> -
> - /*
> - * If GVT overrides us we only ever submit
> - * port[0], leaving port[1] empty. Note that we
> - * also have to be careful that we don't que
Re: [Intel-gfx] [PATCH 2/6] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
On 19/03/2020 09:19, Chris Wilson wrote:
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready prior to actually inserting it
(as soon as it is exposed via the radixtree, it is visible to any other
submission).
v2: For brownie points, remove the goto spaghetti.
v3: Tighten up the closed-handle checks.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 136 +++---
1 file changed, 87 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..042a9ccf348f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -481,7 +481,7 @@ eb_add_vma(struct i915_execbuffer *eb,
GEM_BUG_ON(i915_vma_is_closed(vma));
- ev->vma = i915_vma_get(vma);
+ ev->vma = vma;
ev->exec = entry;
ev->flags = entry->flags;
@@ -728,77 +728,117 @@ static int eb_select_context(struct i915_execbuffer *eb)
return 0;
}
-static int eb_lookup_vmas(struct i915_execbuffer *eb)
+static int __eb_add_lut(struct i915_execbuffer *eb,
+ u32 handle, struct i915_vma *vma)
{
- struct radix_tree_root *handles_vma = &eb->gem_context->handles_vma;
- struct drm_i915_gem_object *obj;
- unsigned int i, batch;
+ struct i915_gem_context *ctx = eb->gem_context;
+ struct i915_lut_handle *lut;
int err;
- if (unlikely(i915_gem_context_is_closed(eb->gem_context)))
- return -ENOENT;
+ lut = i915_lut_handle_alloc();
+ if (unlikely(!lut))
+ return -ENOMEM;
- INIT_LIST_HEAD(&eb->relocs);
- INIT_LIST_HEAD(&eb->unbound);
+ i915_vma_get(vma);
+ if (!atomic_fetch_inc(&vma->open_count))
+ i915_vma_reopen(vma);
+ lut->handle = handle;
+ lut->ctx = ctx;
+
+ /* Check that the context hasn't been closed in the meantime */
+ err = -EINTR;
+ if (!mutex_lock_interruptible(&ctx->mutex)) {
+ err = -ENOENT;
+ if (likely(!i915_gem_context_is_closed(ctx)))
+ err = radix_tree_insert(&ctx->handles_vma, handle, vma);
+ if (err == 0) { /* And nor has this handle */
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ i915_gem_object_lock(obj);
+ if (idr_find(&eb->file->object_idr, handle) == obj) {
+ list_add(&lut->obj_link, &obj->lut_list);
+ } else {
+ radix_tree_delete(&ctx->handles_vma, handle);
+ err = -ENOENT;
+ }
+ i915_gem_object_unlock(obj);
+ }
+ mutex_unlock(&ctx->mutex);
+ }
+ if (unlikely(err))
+ goto err;
- batch = eb_batch_index(eb);
+ return 0;
- for (i = 0; i < eb->buffer_count; i++) {
- u32 handle = eb->exec[i].handle;
- struct i915_lut_handle *lut;
+err:
+ atomic_dec(&vma->open_count);
+ i915_vma_put(vma);
+ i915_lut_handle_free(lut);
+ return err;
+}
+
+static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
+{
+ do {
+ struct drm_i915_gem_object *obj;
struct i915_vma *vma;
+ int err;
- vma = radix_tree_lookup(handles_vma, handle);
+ rcu_read_lock();
+ vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
radix_tree_lookup is documented to be RCU safe okay. How about freeing
VMAs - is that done after a RCU grace period?
Regards,
Tvrtko
+ if (likely(vma))
+ vma = i915_vma_tryget(vma);
+ rcu_read_unlock();
if (likely(vma))
- goto add_vma;
+ return vma;
obj = i915_gem_object_lookup(eb->file, handle);
- if (unlikely(!obj)) {
- err = -ENOENT;
- goto err_vma;
- }
+ if (unlikely(!obj))
+ return ERR_PTR(-ENOENT);
vma = i915_vma_instance(obj, eb->context->vm, NULL);
if (IS_ERR(vma)) {
- err = PTR_ERR(vma);
- goto err_obj;
+ i915_gem_object_put(obj);
+ return vma;
}
- lut = i915_lut_handle_alloc();
- if (unlikely(!lut)) {
- err = -ENOMEM;
- goto err_obj;
- }
+ err = __eb_add_lut(eb, handle, vma);
+
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Prefer '%ps' for printing function symbol names
On 19/03/2020 09:19, Chris Wilson wrote:
%pS includes the offset, which is useful for return addresses but noise
when we are pretty printing a known (and expected) function entry point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index a3d38e089b6e..7daf81f55c90 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -421,7 +421,7 @@ static void timer_i915_sw_fence_wake(struct timer_list *t)
if (!fence)
return;
- pr_notice("Asynchronous wait on fence %s:%s:%llx timed out (hint:%pS)\n",
+ pr_notice("Asynchronous wait on fence %s:%s:%llx timed out
(hint:%ps)\n",
cb->dma->ops->get_driver_name(cb->dma),
cb->dma->ops->get_timeline_name(cb->dma),
cb->dma->seqno,
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 68bbb1580162..54080fb4af4b 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -277,7 +277,7 @@ static struct intel_engine_cs *node_to_barrier(struct
active_node *it)
void i915_active_print(struct i915_active *ref, struct drm_printer *m)
{
- drm_printf(m, "active %pS:%pS\n", ref->active, ref->retire);
+ drm_printf(m, "active %ps:%ps\n", ref->active, ref->retire);
drm_printf(m, "\tcount: %d\n", atomic_read(&ref->count));
drm_printf(m, "\tpreallocated barriers? %s\n",
yesno(!llist_empty(&ref->preallocated_barriers)));
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..7ac9616de9d8 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -1233,7 +1233,7 @@ static int live_parallel_engines(void *arg)
struct igt_live_test t;
unsigned int idx;
- snprintf(name, sizeof(name), "%pS", fn);
+ snprintf(name, sizeof(name), "%ps", fn);
err = igt_live_test_begin(&t, i915, __func__, name);
if (err)
break;
Reviewed-by: Tvrtko ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/13] drm/i915: Drop usless master_transcoder assignments
On Wed, Mar 18, 2020 at 03:37:32PM -0700, Manasi Navare wrote: > On Fri, Mar 13, 2020 at 06:48:21PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > The entire crtc state has been reset before readout so > > master_transcoder is already set to INVALID. > > But wont that mean that the master transcoder would be set to 0 > on reset and what we want is actually setting that to INVALID No. Pls see intel_crtc_state_reset() > > Manasi > > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/display/intel_display.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > b/drivers/gpu/drm/i915/display/intel_display.c > > index c49b4e6eb3d4..12823d8f6afe 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -9364,7 +9364,6 @@ static bool i9xx_get_pipe_config(struct intel_crtc > > *crtc, > > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; > > pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe; > > pipe_config->shared_dpll = NULL; > > - pipe_config->master_transcoder = INVALID_TRANSCODER; > > > > ret = false; > > > > @@ -10588,7 +10587,6 @@ static bool ilk_get_pipe_config(struct intel_crtc > > *crtc, > > > > pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe; > > pipe_config->shared_dpll = NULL; > > - pipe_config->master_transcoder = INVALID_TRANSCODER; > > > > ret = false; > > tmp = intel_de_read(dev_priv, PIPECONF(crtc->pipe)); > > -- > > 2.24.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] [PATCH 02/13] drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it belongs
On Wed, Mar 18, 2020 at 03:34:38PM -0700, Manasi Navare wrote:
> On Fri, Mar 13, 2020 at 06:48:20PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This port sync enable/disable stuff is misplaced. It's just another step
> > of the normal TRANS_DDI_FUNC_CTL enable. Move it to its natural place.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 71 +++-
> > drivers/gpu/drm/i915/display/intel_display.c | 34 --
> > 2 files changed, 39 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 73d0f4648c06..8d486282eea3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1558,12 +1558,34 @@ void intel_ddi_enable_transcoder_func(const struct
> > intel_crtc_state *crtc_state)
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > - u32 temp;
> > + u32 ctl;
> >
> > - temp = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> > + if (INTEL_GEN(dev_priv) >= 11) {
> > + enum transcoder master_transcoder =
> > crtc_state->master_transcoder;
> > + u32 ctl2 = 0;
> > +
> > + if (master_transcoder != INVALID_TRANSCODER) {
> > + u8 master_select;
> > +
> > + if (master_transcoder == TRANSCODER_EDP)
> > + master_select = 0;
> > + else
> > + master_select = master_transcoder + 1;
> > +
> > + ctl2 |= PORT_SYNC_MODE_ENABLE |
> > + (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> > +PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> > + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> > + }
> > +
> > + intel_de_write(dev_priv,
> > + TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> > ctl2);
> > + }
> > +
> > + ctl = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> > - temp |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
> > - intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
> > + ctl |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
> > + intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), ctl);
> > }
> >
> > /*
> > @@ -1576,11 +1598,11 @@ intel_ddi_config_transcoder_func(const struct
> > intel_crtc_state *crtc_state)
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > - u32 temp;
> > + u32 ctl;
> >
> > - temp = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> > - temp &= ~TRANS_DDI_FUNC_ENABLE;
> > - intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
> > + ctl = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> > + ctl &= ~TRANS_DDI_FUNC_ENABLE;
> > + intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), ctl);
> > }
> >
> > void intel_ddi_disable_transcoder_func(const struct intel_crtc_state
> > *crtc_state)
> > @@ -1588,20 +1610,23 @@ void intel_ddi_disable_transcoder_func(const struct
> > intel_crtc_state *crtc_state
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > - u32 val;
> > + u32 ctl;
> >
> > - val = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > - val &= ~TRANS_DDI_FUNC_ENABLE;
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL2(cpu_transcoder),
> > 0);
>
> This should be set to 0 only for the slave where we enable the port sync mode
> so
> set it to 0 only if if (old_crtc_state->master_transcoder !=
> INVALID_TRANSCODER)
>
> This will just ensure that we dont accidently set it to 0 for non slave
> transcoders
No, we should just write the value we want for every transcoder. If
there are bits in there that should be set then we should set them
explicitly. But I didn't think there's anything we want to set.
>
> Manasi
>
> > +
> > + ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > + ctl &= ~TRANS_DDI_FUNC_ENABLE;
> >
> > if (INTEL_GEN(dev_priv) >= 12) {
> > if (!intel_dp_mst_is_master_trans(crtc_state)) {
> > - val &= ~(TGL_TRANS_DDI_PORT_MASK |
> > + ctl &= ~(TGL_TRANS_DDI_PORT_MASK |
> > TRANS_DDI_MODE_SELECT_MASK);
> > }
> > } else {
> > - val &= ~(TRANS_DDI_PORT
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce drm scaling filter property (rev3)
== Series Details == Series: Introduce drm scaling filter property (rev3) URL : https://patchwork.freedesktop.org/series/73883/ State : success == Summary == CI Bug Log - changes from CI_DRM_8158_full -> Patchwork_17023_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17023_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#69]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-skl6/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-skl9/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +14 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-iclb2/igt@gem_exec_sched...@fifo-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-iclb3/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-iclb2/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][11] -> [FAIL][12] ([i915#644]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-apl6/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_selftest@live@execlists: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([i915#58] / [i915#656] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-glk2/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-glk6/igt@i915_selftest@l...@execlists.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#1185] / [i915#221]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-iclb6/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-iclb3/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-skl2/igt@kms_...@bpc-switch.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-skl3/igt@kms_...@bpc-switch.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-apl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#173]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/shard-iclb7/igt@kms_psr@no_drrs.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_primary_mmap_cpu: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +2 similar issues [25]: https://intel-gfx-ci.01.org/tr
Re: [Intel-gfx] [PATCH v19 4/8] drm/i915: Refactor intel_can_enable_sagv
On Wed, Mar 18, 2020 at 02:50:55PM +0200, Ville Syrjälä wrote: > On Wed, Mar 18, 2020 at 11:52:13AM +, Lisovskiy, Stanislav wrote: > > >> @@ -5829,6 +6068,10 @@ skl_compute_wm(struct intel_atomic_state *state) > > >>return ret; > > >>} > > >> > > >> + ret = intel_compute_sagv_mask(state); > > >> + if (ret) > > >> + return ret; > > > > > This seems too early. We haven't even computed the ddb yet. > > > > > > I was thinking about our discussion last week and actually I think there > > are simply two ways how > > > > to do it. > > > > > > 1) What I do here is: calculate minimum amount required to fit SAGV wm > > levels into ddb and > > > > based on that do the ddb allocation accordingly. I.e it is not to early > > because actually we have > > > > already wm levels for sagv and non-sagv calculated - we already can check > > if it can fit into L0 > > > > and then act accordingly. > > > > However one thing to consider here: as you said besides the minimal > > requirements for each plane > > > > (with or without sagv) there is an extra space being allocated in > > proportion to plane data rate, > > > > however here we are actually hitting the prioritization issue - i.e we need > > to decide whether > > > > it is more important to have SAGV or to have more extra space allocated to > > different planes > > > > proportionally to their needs. > > > > So in this first approach we always first determine if we fit into minimum > > SAGV reqs, turn it > > > > on if we do and then rest of extra space is allocated among the planes in > > proportion to data rate. > > > > So that way we would be more often power efficient but but planes get less > > extra ddb space. > > > > > > 2) In your approach we should calculate ddb first, allocate extra space > > proportionally to plane > > > > data rate needs and only then check if all planes got enough space for L0 > > SAGV wm after that. > > > > Then we actually don't even need skl_plane_wm_level accessor, because we > > first would be allocating > > > > using normal wm levels + extra ddb and only then check if all planes fit > > into SAGV requirement - > > > > because that extra space is not actually distributed evenly but in > > proportion to data rate of each > > > > plane, which means that some planes might lack space for SAGV > > theoretically, because some might be > > > > getting more or less depending on the data_rate/total_data_rate ratio. > > > > > > My position is such that I'm really not like "my approach should always > > win" here, but more searching for > > > > solution which is more correct from product point of view. > > > > > > Also could be that it doesn't really matter which approach we do take now,, > > but matter more like > > > > that how fast we deliver. Because the actual outcome difference between two > > > > might be minor, while time overhead for changing the approach could be > > major. > > Pls fix your MUA. Really hard to read this. > > -- > Ville Syrjälä > Intel I was thinking about our discussion last week and actually I think there are simply two ways how to do it. 1) What I do here is: calculate minimum amount required to fit SAGV wm levels into ddb and based on that do the ddb allocation accordingly. I.e it is not to early because actually we have already wm levels for sagv and non-sagv calculated - we already can check if it can fit into L0 and then act accordingly. However one thing to consider here: as you said besides the minimal requirements for each plane (with or without sagv) there is an extra space being allocated in proportion to plane data rate, however here we are actually hitting the prioritization issue - i.e we need to decide whether it is more important to have SAGV or to have more extra space allocated to different planes proportionally to their needs. So in this first approach we always first determine if we fit into minimum SAGV reqs, turn it on if we do and then rest of extra space is allocated among the planes in proportion to data rate. So that way we would be more often power efficient but but planes get less extra ddb space. 2) In your approach we should calculate ddb first, allocate extra space proportionally to plane data rate needs and only then check if all planes got enough space for L0 SAGV wm after that. Then we actually don't even need skl_plane_wm_level accessor, because we first would be allocating using normal wm levels + extra ddb and only then check if all planes fit into SAGV requirement - because that extra space is not actually distributed evenly but in proportion to data rate of each plane, which means that some planes might lack space for SAGV theoretically, because some might be getting more or less depending on the data_rate/total_data_rate ratio. My position is such that I'm really not like "my approach should always win" here, but more searching for solution which is more
Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
Op 18-03-2020 om 15:37 schreef Shankar, Uma:
>
>> -Original Message-
>> From: Maarten Lankhorst
>> Sent: Wednesday, March 18, 2020 5:46 PM
>> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
>> Cc: Ville Syrjälä ; Kai Vehmanen
>> ; Khor, Swee Aun
>> Subject: Re: [PATCH] drm/i915/display: Trigger Modeset at boot for audio
>> codec init
>>
>> Op 18-03-2020 om 12:30 schreef Uma Shankar:
>>> If external monitors are connected during boot up, driver uses the
>>> same mode programmed by BIOS and avoids a full modeset.
>>> This results in display audio codec left uninitialized and display
>>> audio fails to work till user triggers a modeset.
>>>
>>> This patch fixes the same by triggering a modeset at boot.
>>>
>>> Cc: Ville Syrjälä
>>> Cc: Maarten Lankhorst
>>> Cc: Kai Vehmanen
>>> Signed-off-by: Uma Shankar
>>> Signed-off-by: SweeAun Khor
>>> ---
>>> drivers/gpu/drm/i915/display/intel_ddi.c | 4
>>> drivers/gpu/drm/i915/display/intel_display.c | 8
>>> drivers/gpu/drm/i915/i915_drv.h | 3 +++
>>> 3 files changed, 15 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>>> b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> index 73d0f4648c06..ba380afa73a6 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>>> @@ -3704,6 +3704,10 @@ static void intel_ddi_update_pipe(struct
>>> intel_encoder
>> *encoder,
>>> const struct intel_crtc_state *crtc_state,
>>> const struct drm_connector_state *conn_state)
>>> {
>>> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>>> +
>>> + /* Clear the bootflag */
>>> + dev_priv->bootflag = false;
>>>
>>> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
>>> intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state); diff
>>> --git a/drivers/gpu/drm/i915/display/intel_display.c
>>> b/drivers/gpu/drm/i915/display/intel_display.c
>>> index 8f23c4d51c33..a1487539495f 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>>> @@ -14751,6 +14751,10 @@ static int intel_atomic_check(struct drm_device
>> *dev,
>>> if (new_crtc_state->hw.mode.private_flags !=
>>> old_crtc_state->hw.mode.private_flags)
>>> new_crtc_state->uapi.mode_changed = true;
>>> +
>>> + /* Set mode_change to init audio code once at boot */
>>> + if (dev_priv->bootflag && new_crtc_state->hw.active)
>>> + new_crtc_state->uapi.mode_changed = true;
>>> }
>>>
>>> ret = drm_atomic_helper_check_modeset(dev, &state->base); @@
>>> -17655,11 +17659,15 @@ static void intel_update_fdi_pll_freq(struct
>>> drm_i915_private *dev_priv)
>>>
>>> static int intel_initial_commit(struct drm_device *dev) {
>>> + struct drm_i915_private *dev_priv = to_i915(dev);
>>> struct drm_atomic_state *state = NULL;
>>> struct drm_modeset_acquire_ctx ctx;
>>> struct intel_crtc *crtc;
>>> int ret = 0;
>>>
>>> + /* Set Flag to trigger modeset for audio codec init */
>>> + dev_priv->bootflag = true;
>>> +
>>> state = drm_atomic_state_alloc(dev);
>>> if (!state)
>>> return -ENOMEM;
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h index a7ea1d855359..207196f9632b
>>> 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -1210,6 +1210,9 @@ struct drm_i915_private {
>>> * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>>> * will be rejected. Instead look for a better place.
>>> */
>>> +
>>> + /* Flag to trigger modeset for Audio codec init once during boot */
>>> + bool bootflag;
>>> };
>>>
>>> static inline struct drm_i915_private *to_i915(const struct
>>> drm_device *dev)
>> This is not going to help. We read out the has_audio flag now, the only
>> thing we miss
>> is to enable the audio codec. This should be done after the first detect(),
>> in the
>> manner which I described to get the correct eld values.
> Hi Maarten,
> At the time of sanitize, we don't have edid so has_audio flag will not be
> set. Also codec_enable
> needs encoder, crtc_state, conn_state. All these are not there as part of
> detect callbacks.
They can be used. You have connection_mutex, so you can look at
connector->state,
if you then lock conn_state->crtc, you can inspect conn_state->crtc->state as
well.
conn_state->encoder is available as well.
It needs some casting to get the intel_XX_state but you can do it safely.
~Maarten
> With current approach, we force a modeset just during boot and then reset the
> flag so that normal
> operations don't get affected.
>
> Regards,
> Uma Shankar
>
>> ~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedeskto
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915: Prefer '%ps' for printing function symbol names
== Series Details == Series: series starting with [1/6] drm/i915: Prefer '%ps' for printing function symbol names URL : https://patchwork.freedesktop.org/series/74865/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8157_full -> Patchwork_17022_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17022_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17022_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_17022_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@engines-cleanup@vecs0: - shard-tglb: [PASS][1] -> [FAIL][2] +32 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-tglb2/igt@gem_ctx_persistence@engines-clea...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-tglb1/igt@gem_ctx_persistence@engines-clea...@vecs0.html * igt@gem_ctx_persistence@engines-hostile@bcs0: - shard-kbl: [PASS][3] -> [FAIL][4] +28 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-kbl6/igt@gem_ctx_persistence@engines-host...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-kbl3/igt@gem_ctx_persistence@engines-host...@bcs0.html * igt@gem_ctx_persistence@engines-queued@vcs1: - shard-iclb: NOTRUN -> [FAIL][5] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-iclb4/igt@gem_ctx_persistence@engines-que...@vcs1.html * igt@gem_ctx_persistence@legacy-engines-hostile@bsd: - shard-iclb: [PASS][6] -> [FAIL][7] +25 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-iclb6/igt@gem_ctx_persistence@legacy-engines-host...@bsd.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-iclb6/igt@gem_ctx_persistence@legacy-engines-host...@bsd.html * igt@gem_ctx_persistence@legacy-engines-queued@vebox: - shard-skl: [PASS][8] -> [FAIL][9] +20 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-skl3/igt@gem_ctx_persistence@legacy-engines-que...@vebox.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-skl9/igt@gem_ctx_persistence@legacy-engines-que...@vebox.html * igt@gem_ctx_persistence@replace@vcs0: - shard-apl: [PASS][10] -> [FAIL][11] +28 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-apl4/igt@gem_ctx_persistence@repl...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-apl8/igt@gem_ctx_persistence@repl...@vcs0.html * igt@gem_ctx_persistence@saturated-hostile@vecs0: - shard-glk: [PASS][12] -> [FAIL][13] +20 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-glk8/igt@gem_ctx_persistence@saturated-host...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-glk2/igt@gem_ctx_persistence@saturated-host...@vecs0.html * igt@gem_exec_schedule@preempt-hang-vebox: - shard-tglb: [PASS][14] -> [INCOMPLETE][15] +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-tglb1/igt@gem_exec_sched...@preempt-hang-vebox.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-tglb8/igt@gem_exec_sched...@preempt-hang-vebox.html - shard-skl: [PASS][16] -> [INCOMPLETE][17] +8 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-skl3/igt@gem_exec_sched...@preempt-hang-vebox.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-skl9/igt@gem_exec_sched...@preempt-hang-vebox.html * igt@gem_exec_schedule@preemptive-hang-render: - shard-iclb: NOTRUN -> [INCOMPLETE][18] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-iclb7/igt@gem_exec_sched...@preemptive-hang-render.html - shard-kbl: [PASS][19] -> [INCOMPLETE][20] +10 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-kbl4/igt@gem_exec_sched...@preemptive-hang-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-kbl1/igt@gem_exec_sched...@preemptive-hang-render.html * igt@gem_exec_schedule@preemptive-hang-vebox: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-iclb3/igt@gem_exec_sched...@preemptive-hang-vebox.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/shard-iclb2/igt@gem_exec_sched...@preemptive-ha
Re: [Intel-gfx] [PATCH 08/10] cpufreq: intel_pstate: Enable VLP controller based on ACPI FADT profile and CPUID.
On Tuesday, March 10, 2020 10:42:01 PM CET Francisco Jerez wrote:
> For the moment the VLP controller is only enabled on ICL platforms
> other than server FADT profiles in order to reduce the validation
> effort of the initial submission. It should work on any other
> processors that support HWP though (and soon enough on non-HWP too):
> In order to override the default behavior (e.g. to test on other
> platforms) the VLP controller can be forcefully enabled or disabled by
> passing "intel_pstate=vlp" or "intel_pstate=no_vlp" respectively in
> the kernel command line.
>
> v2: Handle HWP VLP controller.
>
> Signed-off-by: Francisco Jerez
> ---
> .../admin-guide/kernel-parameters.txt | 5
> Documentation/admin-guide/pm/intel_pstate.rst | 7 ++
> drivers/cpufreq/intel_pstate.c| 25 +--
> 3 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 0c9894247015..9bc55fc2752e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1828,6 +1828,11 @@
> per_cpu_perf_limits
> Allow per-logical-CPU P-State performance control
> limits using
> cpufreq sysfs interface
> + vlp
> + Force use of VLP P-state controller. Overrides
> selection
> + derived from ACPI FADT profile.
> + no_vlp
> + Prevent use of VLP P-state controller (see "vlp"
> parameter).
>
> intremap= [X86-64, Intel-IOMMU]
> on enable Interrupt Remapping (default)
> diff --git a/Documentation/admin-guide/pm/intel_pstate.rst
> b/Documentation/admin-guide/pm/intel_pstate.rst
> index 67e414e34f37..da6b64812848 100644
> --- a/Documentation/admin-guide/pm/intel_pstate.rst
> +++ b/Documentation/admin-guide/pm/intel_pstate.rst
> @@ -669,6 +669,13 @@ of them have to be prepended with the ``intel_pstate=``
> prefix.
> Use per-logical-CPU P-State limits (see `Coordination of P-state
> Limits`_ for details).
>
> +``vlp``
> + Force use of VLP P-state controller. Overrides selection derived
> + from ACPI FADT profile.
> +
> +``no_vlp``
> + Prevent use of VLP P-state controller (see "vlp" parameter).
> +
>
> Diagnostics and Tuning
> ==
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index a01eed40d897..050cc8f03c26 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -3029,6 +3029,7 @@ static int intel_pstate_update_status(const char *buf,
> size_t size)
>
> static int no_load __initdata;
> static int no_hwp __initdata;
> +static int vlp __initdata = -1;
> static int hwp_only __initdata;
> static unsigned int force_load __initdata;
>
> @@ -3193,6 +3194,7 @@ static inline void
> intel_pstate_request_control_from_smm(void) {}
> #endif /* CONFIG_ACPI */
>
> #define INTEL_PSTATE_HWP_BROADWELL 0x01
> +#define INTEL_PSTATE_HWP_VLP 0x02
>
> #define ICPU_HWP(model, hwp_mode) \
> { X86_VENDOR_INTEL, 6, model, X86_FEATURE_HWP, hwp_mode }
> @@ -3200,12 +3202,15 @@ static inline void
> intel_pstate_request_control_from_smm(void) {}
> static const struct x86_cpu_id hwp_support_ids[] __initconst = {
> ICPU_HWP(INTEL_FAM6_BROADWELL_X, INTEL_PSTATE_HWP_BROADWELL),
> ICPU_HWP(INTEL_FAM6_BROADWELL_D, INTEL_PSTATE_HWP_BROADWELL),
> + ICPU_HWP(INTEL_FAM6_ICELAKE, INTEL_PSTATE_HWP_VLP),
> + ICPU_HWP(INTEL_FAM6_ICELAKE_L, INTEL_PSTATE_HWP_VLP),
> ICPU_HWP(X86_MODEL_ANY, 0),
> {}
> };
>
> static int __init intel_pstate_init(void)
> {
> + bool use_vlp = vlp == 1;
> const struct x86_cpu_id *id;
> int rc;
>
> @@ -3222,8 +3227,19 @@ static int __init intel_pstate_init(void)
> pstate_funcs.update_util = intel_pstate_update_util;
> } else {
> hwp_active++;
> - pstate_funcs.update_util = intel_pstate_update_util_hwp;
> - hwp_mode_bdw = id->driver_data;
> +
> + if (vlp < 0 && !intel_pstate_acpi_pm_profile_server() &&
> + (id->driver_data & INTEL_PSTATE_HWP_VLP)) {
> + /* Enable VLP controller by default. */
> + use_vlp = true;
> + }
> +
> + pstate_funcs.update_util = use_vlp ?
> + intel_pstate_update_util_hwp_vlp :
> + intel_pstate_update_util_hwp;
This basically is only good in a prototype in my view.
There is an interface for selecting scaling algorithms in cpufreq already and
in order to avoid confusion, that one needs to be extended instead of
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce drm scaling filter property (rev3)
== Series Details == Series: Introduce drm scaling filter property (rev3) URL : https://patchwork.freedesktop.org/series/73883/ State : success == Summary == CI Bug Log - changes from CI_DRM_8158 -> Patchwork_17023 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/index.html Known issues Here are the changes found in Patchwork_17023 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gem_contexts: - fi-skl-lmem:[PASS][1] -> [DMESG-FAIL][2] ([i915#933]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@i915_selftest@live@execlists: - fi-skl-lmem:[INCOMPLETE][3] ([i915#656]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/fi-skl-lmem/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/fi-skl-lmem/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [DMESG-FAIL][5] ([i915#877]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8158/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 [i915#933]: https://gitlab.freedesktop.org/drm/intel/issues/933 Participating hosts (40 -> 33) -- Additional (4): fi-icl-dsi fi-elk-e7500 fi-gdg-551 fi-bsw-n3050 Missing(11): fi-kbl-soraka fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-kbl-7500u fi-ivb-3770 fi-cfl-8109u fi-blb-e6850 fi-byt-clapper fi-skl-6600u fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8158 -> Patchwork_17023 CI-20190529: 20190529 CI_DRM_8158: 513c064047e872bab4113465459e67bece56b99d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17023: b7639a6e88a87032d41d66477b5fb79306ec0f54 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b7639a6e88a8 drm/i915: Enable scaling filter for plane and CRTC 2bda386ae840 drm/i915/display: Add Nearest-neighbor based integer scaling support c0c485082dda drm/i915: Introduce scaling filter related registers and bit fields. dbd02a4bbf34 drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation 51d1ea0ac87f drm: Introduce plane and CRTC scaling filter properties == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17023/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/10] cpufreq: intel_pstate: Implement VLP controller target P-state range estimation.
On Tuesday, March 10, 2020 10:41:59 PM CET Francisco Jerez wrote:
> The function introduced here calculates a P-state range derived from
> the statistics computed in the previous patch which will be used to
> drive the HWP P-state range or (if HWP is not available) as basis for
> some additional kernel-side frequency selection mechanism which will
> choose a single P-state from the range. This is meant to provide a
> variably low-pass filtering effect that will damp oscillations below a
> frequency threshold that can be specified by device drivers via PM QoS
> in order to achieve energy-efficient behavior in cases where the
> system has an IO bottleneck.
>
> Signed-off-by: Francisco Jerez
The separation of this patch from the other one appears to be artificial
and it actually makes reviewing them both harder in my perspective.
What would be wrong with merging them together?
> ---
> drivers/cpufreq/intel_pstate.c | 157 +
> 1 file changed, 157 insertions(+)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 12ee350db2a9..cecadfec8bc1 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -207,17 +207,34 @@ struct vlp_status_sample {
> int32_t realtime_avg;
> };
>
> +/**
> + * VLP controller state used for the estimation of the target P-state
> + * range, computed by get_vlp_target_range() from the heuristic status
> + * information defined above in struct vlp_status_sample.
> + */
> +struct vlp_target_range {
> + unsigned int value[2];
> + int32_t p_base;
> +};
> +
> /**
> * struct vlp_data - VLP controller parameters and state.
> * @sample_interval_ns: Update interval in ns.
> * @sample_frequency_hz: Reciprocal of the update interval in Hz.
> + * @gain*:Response factor of the controller relative to each
> + *one of its linear input variables as fixed-point
> + *fraction.
> */
> struct vlp_data {
> s64 sample_interval_ns;
> int32_t sample_frequency_hz;
> + int32_t gain_aggr;
> + int32_t gain_rt;
> + int32_t gain;
>
> struct vlp_input_stats stats;
> struct vlp_status_sample status;
> + struct vlp_target_range target;
> };
>
> /**
> @@ -323,12 +340,18 @@ static struct cpudata **all_cpu_data;
> /**
> * struct vlp_params - VLP controller static configuration
> * @sample_interval_ms: Update interval in ms.
> + * @setpoint_*_pml: Target CPU utilization at which the controller is
> + *expected to leave the current P-state untouched,
> + *as an integer per mille.
> * @avg*_hz: Exponential averaging frequencies of the various
> *low-pass filters as an integer in Hz.
> */
> struct vlp_params {
> int sample_interval_ms;
> + int setpoint_0_pml;
> + int setpoint_aggr_pml;
> int avg_hz;
> + int realtime_gain_pml;
> int debug;
> };
>
> @@ -362,7 +385,10 @@ struct pstate_funcs {
> static struct pstate_funcs pstate_funcs __read_mostly;
> static struct vlp_params vlp_params __read_mostly = {
> .sample_interval_ms = 10,
> + .setpoint_0_pml = 900,
> + .setpoint_aggr_pml = 1500,
> .avg_hz = 2,
> + .realtime_gain_pml = 12000,
> .debug = 0,
> };
>
> @@ -1873,6 +1899,11 @@ static void intel_pstate_reset_vlp(struct cpudata *cpu)
> vlp->sample_interval_ns = vlp_params.sample_interval_ms * NSEC_PER_MSEC;
> vlp->sample_frequency_hz = max(1u, (uint32_t)MSEC_PER_SEC /
> vlp_params.sample_interval_ms);
> + vlp->gain_rt = div_fp(cpu->pstate.max_pstate *
> + vlp_params.realtime_gain_pml, 1000);
> + vlp->gain_aggr = max(1, div_fp(1000, vlp_params.setpoint_aggr_pml));
> + vlp->gain = max(1, div_fp(1000, vlp_params.setpoint_0_pml));
> + vlp->target.p_base = 0;
> vlp->stats.last_response_frequency_hz = vlp_params.avg_hz;
> }
>
> @@ -1996,6 +2027,132 @@ static const struct vlp_status_sample
> *get_vlp_status_sample(
> return last_status;
> }
>
> +/**
> + * Calculate the target P-state range for the next update period.
> + * Uses a variably low-pass-filtering controller intended to improve
> + * energy efficiency when a CPU response frequency target is specified
> + * via PM QoS (e.g. under IO-bound conditions).
> + */
> +static const struct vlp_target_range *get_vlp_target_range(struct cpudata
> *cpu)
> +{
> + struct vlp_data *vlp = &cpu->vlp;
> + struct vlp_target_range *last_target = &vlp->target;
> +
> + /*
> + * P-state limits in fixed-point as allowed by the policy.
> + */
> + const int32_t p0 = int_tofp(max(cpu->pstate.min_pstate,
> + cpu->min_perf_ratio));
> + const int32_t p1 = int_tofp(cpu->max_perf_ratio);
> +
> + /*
> + * Observed
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Prefer '%ps' for printing function symbol names (rev2)
== Series Details == Series: series starting with [1/4] drm/i915: Prefer '%ps' for printing function symbol names (rev2) URL : https://patchwork.freedesktop.org/series/74864/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8157_full -> Patchwork_17021_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17021_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17021_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_17021_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@engines-hostile@bcs0: - shard-kbl: [PASS][1] -> [FAIL][2] +49 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-kbl6/igt@gem_ctx_persistence@engines-host...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-kbl7/igt@gem_ctx_persistence@engines-host...@bcs0.html * igt@gem_ctx_persistence@file: - shard-tglb: [PASS][3] -> [FAIL][4] +44 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-tglb6/igt@gem_ctx_persiste...@file.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-tglb6/igt@gem_ctx_persiste...@file.html - shard-skl: [PASS][5] -> [FAIL][6] +41 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-skl10/igt@gem_ctx_persiste...@file.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-skl9/igt@gem_ctx_persiste...@file.html * igt@gem_ctx_persistence@legacy-engines-cleanup@render: - shard-glk: [PASS][7] -> [FAIL][8] +41 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-glk8/igt@gem_ctx_persistence@legacy-engines-clea...@render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-glk9/igt@gem_ctx_persistence@legacy-engines-clea...@render.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt@bsd1: - shard-iclb: NOTRUN -> [FAIL][9] +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-iclb4/igt@gem_ctx_persistence@legacy-engines-hostile-pree...@bsd1.html * igt@gem_ctx_persistence@legacy-engines-hostile@bsd: - shard-iclb: [PASS][10] -> [FAIL][11] +39 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-iclb6/igt@gem_ctx_persistence@legacy-engines-host...@bsd.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-iclb8/igt@gem_ctx_persistence@legacy-engines-host...@bsd.html * igt@gem_ctx_persistence@replace@vcs0: - shard-apl: [PASS][12] -> [FAIL][13] +41 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-apl4/igt@gem_ctx_persistence@repl...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-apl7/igt@gem_ctx_persistence@repl...@vcs0.html Known issues Here are the changes found in Patchwork_17021_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_exec@basic-nohangcheck: - shard-glk: [PASS][14] -> [FAIL][15] ([i915#1166]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-glk1/igt@gem_ctx_e...@basic-nohangcheck.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-glk8/igt@gem_ctx_e...@basic-nohangcheck.html - shard-snb: [PASS][16] -> [FAIL][17] ([i915#1379]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-snb4/igt@gem_ctx_e...@basic-nohangcheck.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-snb6/igt@gem_ctx_e...@basic-nohangcheck.html - shard-hsw: [PASS][18] -> [FAIL][19] ([i915#1379]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-hsw5/igt@gem_ctx_e...@basic-nohangcheck.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-hsw6/igt@gem_ctx_e...@basic-nohangcheck.html - shard-kbl: [PASS][20] -> [FAIL][21] ([i915#1166]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-kbl2/igt@gem_ctx_e...@basic-nohangcheck.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-kbl3/igt@gem_ctx_e...@basic-nohangcheck.html - shard-apl: [PASS][22] -> [FAIL][23] ([i915#1166]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/shard-apl1/igt@gem_ctx_e...@basic-nohangcheck.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/shard-apl3/igt@gem_ctx_e...@basic-nohangcheck.html - shard-skl: [PASS][24] -> [
Re: [Intel-gfx] [PATCH 05/10] cpufreq: intel_pstate: Implement VLP controller statistics and status calculation.
On Tuesday, March 10, 2020 10:41:58 PM CET Francisco Jerez wrote:
> The goal of the helper code introduced here is to compute two
> informational data structures: struct vlp_input_stats aggregating
> various scheduling and PM statistics gathered in every call of the
> update_util() hook, and struct vlp_status_sample which contains status
> information derived from the former indicating whether the system is
> likely to have an IO or CPU bottleneck. This will be used as main
> heuristic input by the new variably low-pass filtering controller (AKA
> VLP)
I'm not sure how widely used this is.
It would be good to provide a pointer to a definition of it where all of
the maths is described and the foundation of it is explained. Alternatively,
document it in the kernel source.
> that will assist the HWP at finding a reasonably energy-efficient
> P-state given the additional information available to the kernel about
> I/O utilization and scheduling behavior.
>
> Signed-off-by: Francisco Jerez
> ---
> drivers/cpufreq/intel_pstate.c | 230 +
> 1 file changed, 230 insertions(+)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 8cb5bf419b40..12ee350db2a9 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -33,6 +34,8 @@
> #include
> #include
>
> +#include "../../kernel/sched/sched.h"
> +
> #define INTEL_PSTATE_SAMPLING_INTERVAL (10 * NSEC_PER_MSEC)
>
> #define INTEL_CPUFREQ_TRANSITION_LATENCY 2
> @@ -59,6 +62,11 @@ static inline int32_t mul_fp(int32_t x, int32_t y)
> return ((int64_t)x * (int64_t)y) >> FRAC_BITS;
> }
>
> +static inline int rnd_fp(int32_t x)
What does md stand for?
> +{
> + return (x + (1 << (FRAC_BITS - 1))) >> FRAC_BITS;
> +}
> +
> static inline int32_t div_fp(s64 x, s64 y)
> {
> return div64_s64((int64_t)x << FRAC_BITS, y);
> @@ -169,6 +177,49 @@ struct vid_data {
> int32_t ratio;
> };
>
> +/**
> + * Scheduling and PM statistics gathered by update_vlp_sample() at
> + * every call of the VLP update_state() hook, used as heuristic
> + * inputs.
> + */
> +struct vlp_input_stats {
> + int32_t realtime_count;
> + int32_t io_wait_count;
> + uint32_t max_response_frequency_hz;
> + uint32_t last_response_frequency_hz;
> +};
> +
> +enum vlp_status {
> + VLP_BOTTLENECK_IO = 1 << 0,
> + /*
> + * XXX - Add other status bits here indicating a CPU or TDP
> + * bottleneck.
> + */
> +};
> +
> +/**
> + * Heuristic status information calculated by get_vlp_status_sample()
> + * from struct vlp_input_stats above, indicating whether the system
> + * has a potential IO or latency bottleneck.
> + */
> +struct vlp_status_sample {
> + enum vlp_status value;
> + int32_t realtime_avg;
> +};
> +
> +/**
> + * struct vlp_data - VLP controller parameters and state.
> + * @sample_interval_ns: Update interval in ns.
> + * @sample_frequency_hz: Reciprocal of the update interval in Hz.
> + */
> +struct vlp_data {
> + s64 sample_interval_ns;
> + int32_t sample_frequency_hz;
> +
> + struct vlp_input_stats stats;
> + struct vlp_status_sample status;
> +};
> +
> /**
> * struct global_params - Global parameters, mostly tunable via sysfs.
> * @no_turbo:Whether or not to use turbo P-states.
> @@ -239,6 +290,7 @@ struct cpudata {
>
> struct pstate_data pstate;
> struct vid_data vid;
> + struct vlp_data vlp;
>
> u64 last_update;
> u64 last_sample_time;
> @@ -268,6 +320,18 @@ struct cpudata {
>
> static struct cpudata **all_cpu_data;
>
> +/**
> + * struct vlp_params - VLP controller static configuration
> + * @sample_interval_ms: Update interval in ms.
> + * @avg*_hz: Exponential averaging frequencies of the various
> + *low-pass filters as an integer in Hz.
> + */
> +struct vlp_params {
> + int sample_interval_ms;
> + int avg_hz;
> + int debug;
> +};
> +
> /**
> * struct pstate_funcs - Per CPU model specific callbacks
> * @get_max: Callback to get maximum non turbo effective P state
> @@ -296,6 +360,11 @@ struct pstate_funcs {
> };
>
> static struct pstate_funcs pstate_funcs __read_mostly;
> +static struct vlp_params vlp_params __read_mostly = {
> + .sample_interval_ms = 10,
> + .avg_hz = 2,
> + .debug = 0,
> +};
>
> static int hwp_active __read_mostly;
> static int hwp_mode_bdw __read_mostly;
> @@ -1793,6 +1862,167 @@ static inline int32_t get_target_pstate(struct
> cpudata *cpu)
> return target;
> }
>
> +/**
> + * Initialize the struct vlp_data of the specified CPU to the defaults
> + * calculated from @vlp_params.
> + */
Nit: All of the function header comments need to be in the canonical kerneldoc
format, ie. with arguments l
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce drm scaling filter property (rev3)
== Series Details == Series: Introduce drm scaling filter property (rev3) URL : https://patchwork.freedesktop.org/series/73883/ State : warning == Summary == $ dim checkpatch origin/drm-tip 51d1ea0ac87f drm: Introduce plane and CRTC scaling filter properties -:138: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #138: FILE: drivers/gpu/drm/drm_mode_config.c:384: + prop = drm_property_create_enum(dev, 0, + "SCALING_FILTER", -:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #146: FILE: drivers/gpu/drm/drm_mode_config.c:392: + prop = drm_property_create_enum(dev, 0, + "SCALING_FILTER", total: 0 errors, 0 warnings, 2 checks, 218 lines checked dbd02a4bbf34 drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation c0c485082dda drm/i915: Introduce scaling filter related registers and bit fields. -:73: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #73: FILE: drivers/gpu/drm/i915/i915_reg.h:7337: +#define _SKL_PS_COEF_INDEX_SET0(pipe, id) _ID(pipe,\ + _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A), \ + _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B)) -:77: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #77: FILE: drivers/gpu/drm/i915/i915_reg.h:7341: +#define _SKL_PS_COEF_INDEX_SET1(pipe, id) _ID(pipe,\ + _ID(id, _PS_COEF_SET1_INDEX_1A, _PS_COEF_SET1_INDEX_2A), \ + _ID(id, _PS_COEF_SET1_INDEX_1B, _PS_COEF_SET1_INDEX_2B)) -:81: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #81: FILE: drivers/gpu/drm/i915/i915_reg.h:7345: +#define _SKL_PS_COEF_DATA_SET0(pipe, id) _ID(pipe, \ + _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A), \ + _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B)) -:85: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #85: FILE: drivers/gpu/drm/i915/i915_reg.h:7349: +#define _SKL_PS_COEF_DATA_SET1(pipe, id) _ID(pipe, \ + _ID(id, _PS_COEF_SET1_DATA_1A, _PS_COEF_SET1_DATA_2A), \ + _ID(id, _PS_COEF_SET1_DATA_1B, _PS_COEF_SET1_DATA_2B)) -:89: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects? #89: FILE: drivers/gpu/drm/i915/i915_reg.h:7353: +#define SKL_PS_COEF_INDEX_SET(pipe, id, set) \ + _MMIO_PIPE(set, _SKL_PS_COEF_INDEX_SET0(pipe, id), \ + _SKL_PS_COEF_INDEX_SET1(pipe, id)) -:89: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #89: FILE: drivers/gpu/drm/i915/i915_reg.h:7353: +#define SKL_PS_COEF_INDEX_SET(pipe, id, set) \ + _MMIO_PIPE(set, _SKL_PS_COEF_INDEX_SET0(pipe, id), \ + _SKL_PS_COEF_INDEX_SET1(pipe, id)) -:93: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pipe' - possible side-effects? #93: FILE: drivers/gpu/drm/i915/i915_reg.h:7357: +#define SKL_PS_COEF_DATA_SET(pipe, id, set) \ + _MMIO_PIPE(set, _SKL_PS_COEF_DATA_SET0(pipe, id), \ + _SKL_PS_COEF_DATA_SET1(pipe, id)) -:93: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id' - possible side-effects? #93: FILE: drivers/gpu/drm/i915/i915_reg.h:7357: +#define SKL_PS_COEF_DATA_SET(pipe, id, set) \ + _MMIO_PIPE(set, _SKL_PS_COEF_DATA_SET0(pipe, id), \ + _SKL_PS_COEF_DATA_SET1(pipe, id)) total: 0 errors, 0 warnings, 8 checks, 72 lines checked 2bda386ae840 drm/i915/display: Add Nearest-neighbor based integer scaling support -:106: CHECK:SPACING: spaces preferred around that '+' (ctx:VxV) #106: FILE: drivers/gpu/drm/i915/display/intel_display.c:6304: + t = skl_coef_tap(i+1); ^ -:107: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #107: FILE: drivers/gpu/drm/i915/display/intel_display.c:6305: + tmp |= skl_nearest_filter_coef(t)<<16; ^ total: 0 errors, 0 warnings, 2 checks, 86 lines checked b7639a6e88a8 drm/i915: Enable scaling filter for plane and CRTC -:34: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #34: FILE: drivers/gpu/drm/i915/display/intel_display.c:6314: +skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum pipe pipe, + int id, int set, enum drm_crtc_scaling_filter filter) -:47: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #47: FILE: drivers/gpu/drm/i915/display/intel_display.c:6327: + + } -:77: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #77: FILE: drivers/gpu/drm/i915/display/intel_display.c:6366: + skl_scaler_crtc_setup_filter(dev_priv, pipe, id, 0, +
Re: [Intel-gfx] [PATCH 04/10] Revert "cpufreq: intel_pstate: Drop ->update_util from pstate_funcs"
On Tuesday, March 10, 2020 10:41:57 PM CET Francisco Jerez wrote:
> This reverts commit c4f3f70cacba2fa19545389a12d09b606d2ad1cf. A
> future commit will introduce a new update_util implementation, so the
> pstate_funcs table entry is going to be useful.
This basically means that you want to introduce a new scaling algorithm.
In my view that needs to be exposed via scaling_governor so users can
switch over between this and the existing ones (powersave and performance).
That would require the cpufreq core to be updated somewhat to recognize
an additional CPUFREQ_POLICY_ value, but that should be perfectly doable.
And ->
> Signed-off-by: Francisco Jerez
> ---
> drivers/cpufreq/intel_pstate.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 7fa869004cf0..8cb5bf419b40 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -277,6 +277,7 @@ static struct cpudata **all_cpu_data;
> * @get_scaling: Callback to get frequency scaling factor
> * @get_val: Callback to convert P state to actual MSR write value
> * @get_vid: Callback to get VID data for Atom platforms
> + * @update_util: Active mode utilization update callback.
> *
> * Core and Atom CPU models have different way to get P State limits. This
> * structure is used to store those callbacks.
> @@ -290,6 +291,8 @@ struct pstate_funcs {
> int (*get_aperf_mperf_shift)(void);
> u64 (*get_val)(struct cpudata*, int pstate);
> void (*get_vid)(struct cpudata *);
> + void (*update_util)(struct update_util_data *data, u64 time,
> + unsigned int flags);
> };
>
> static struct pstate_funcs pstate_funcs __read_mostly;
> @@ -1877,6 +1880,7 @@ static struct pstate_funcs core_funcs = {
> .get_turbo = core_get_turbo_pstate,
> .get_scaling = core_get_scaling,
> .get_val = core_get_val,
> + .update_util = intel_pstate_update_util,
> };
>
> static const struct pstate_funcs silvermont_funcs = {
> @@ -1887,6 +1891,7 @@ static const struct pstate_funcs silvermont_funcs = {
> .get_val = atom_get_val,
> .get_scaling = silvermont_get_scaling,
> .get_vid = atom_get_vid,
> + .update_util = intel_pstate_update_util,
> };
>
> static const struct pstate_funcs airmont_funcs = {
> @@ -1897,6 +1902,7 @@ static const struct pstate_funcs airmont_funcs = {
> .get_val = atom_get_val,
> .get_scaling = airmont_get_scaling,
> .get_vid = atom_get_vid,
> + .update_util = intel_pstate_update_util,
> };
>
> static const struct pstate_funcs knl_funcs = {
> @@ -1907,6 +1913,7 @@ static const struct pstate_funcs knl_funcs = {
> .get_aperf_mperf_shift = knl_get_aperf_mperf_shift,
> .get_scaling = core_get_scaling,
> .get_val = core_get_val,
> + .update_util = intel_pstate_update_util,
> };
>
> #define ICPU(model, policy) \
> @@ -2013,9 +2020,7 @@ static void intel_pstate_set_update_util_hook(unsigned
> int cpu_num)
> /* Prevent intel_pstate_update_util() from using stale data. */
> cpu->sample.time = 0;
> cpufreq_add_update_util_hook(cpu_num, &cpu->update_util,
> - (hwp_active ?
> - intel_pstate_update_util_hwp :
> - intel_pstate_update_util));
-> it should be possible to extend this code to install an update_util matching
the scaling algo chosen by the user.
> + pstate_funcs.update_util);
> cpu->update_util_set = true;
> }
>
> @@ -2584,6 +2589,7 @@ static void __init copy_cpu_funcs(struct pstate_funcs
> *funcs)
> pstate_funcs.get_scaling = funcs->get_scaling;
> pstate_funcs.get_val = funcs->get_val;
> pstate_funcs.get_vid = funcs->get_vid;
> + pstate_funcs.update_util = funcs->update_util;
> pstate_funcs.get_aperf_mperf_shift = funcs->get_aperf_mperf_shift;
> }
>
> @@ -2750,8 +2756,11 @@ static int __init intel_pstate_init(void)
> id = x86_match_cpu(hwp_support_ids);
> if (id) {
> copy_cpu_funcs(&core_funcs);
> - if (!no_hwp) {
> + if (no_hwp) {
> + pstate_funcs.update_util = intel_pstate_update_util;
> + } else {
> hwp_active++;
> + pstate_funcs.update_util = intel_pstate_update_util_hwp;
> hwp_mode_bdw = id->driver_data;
> intel_pstate.attr = hwp_cpufreq_attrs;
> goto hwp_cpu_matched;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv2 01/10] PM: QoS: Add CPU_RESPONSE_FREQUENCY global PM QoS limit.
On Wednesday, March 11, 2020 8:23:19 PM CET Francisco Jerez wrote:
> The purpose of this PM QoS limit is to give device drivers additional
> control over the latency/energy efficiency trade-off made by the PM
> subsystem (particularly the CPUFREQ governor). It allows device
> drivers to set a lower bound on the response latency of PM (defined as
> the time it takes from wake-up to the CPU reaching a certain
> steady-state level of performance [e.g. the nominal frequency] in
> response to a step-function load). It reports to PM the minimum
> ramp-up latency considered of use to the application, and explicitly
> requests PM to filter out oscillations faster than the specified
> frequency. It is somewhat complementary to the current
> CPU_DMA_LATENCY PM QoS class which can be understood as specifying an
> upper latency bound on the CPU wake-up time, instead of a lower bound
> on the CPU frequency ramp-up time.
>
> Note that even though this provides a latency constraint it's
> represented as its reciprocal in Hz units for computational efficiency
> (since it would take a 64-bit division to compute the number of cycles
> elapsed from a time increment in nanoseconds and a time bound, while a
> frequency can simply be multiplied with the time increment).
>
> This implements a MAX constraint so that the strictest (highest
> response frequency) request is honored. This means that PM won't
> provide any guarantee that frequencies greater than the specified
> bound will be filtered, since that might be incompatible with the
> constraints specified by another more latency-sensitive application (A
> more fine-grained result could be achieved with a scheduling-based
> interface). The default value needs to be equal to zero (best effort)
> for it to behave as identity of the MAX operation.
>
> v2: Drop wake_up_all_idle_cpus() call from
> cpu_response_frequency_qos_apply() (Peter).
>
> Signed-off-by: Francisco Jerez
> ---
> include/linux/pm_qos.h | 9 +++
> include/trace/events/power.h | 33 +
> kernel/power/qos.c | 138 ++-
First, the documentation (Documentation/power/pm_qos_interface.rst) needs to be
updated too to cover the new QoS category.
> 3 files changed, 162 insertions(+), 18 deletions(-)
>
> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> index 4a69d4af3ff8..b522e2194c05 100644
> --- a/include/linux/pm_qos.h
> +++ b/include/linux/pm_qos.h
> @@ -28,6 +28,7 @@ enum pm_qos_flags_status {
> #define PM_QOS_LATENCY_ANY_NS((s64)PM_QOS_LATENCY_ANY *
> NSEC_PER_USEC)
>
> #define PM_QOS_CPU_LATENCY_DEFAULT_VALUE (2000 * USEC_PER_SEC)
> +#define PM_QOS_CPU_RESPONSE_FREQUENCY_DEFAULT_VALUE 0
I would call this PM_QOS_CPU_SCALING_RESPONSE_DEFAULT_VALUE and all of the
API pieces accordingly.
> #define PM_QOS_RESUME_LATENCY_DEFAULT_VALUE PM_QOS_LATENCY_ANY
> #define PM_QOS_RESUME_LATENCY_NO_CONSTRAINT PM_QOS_LATENCY_ANY
> #define PM_QOS_RESUME_LATENCY_NO_CONSTRAINT_NS PM_QOS_LATENCY_ANY_NS
> @@ -162,6 +163,14 @@ static inline void cpu_latency_qos_update_request(struct
> pm_qos_request *req,
> static inline void cpu_latency_qos_remove_request(struct pm_qos_request
> *req) {}
> #endif
>
> +s32 cpu_response_frequency_qos_limit(void);
For example
cpu_scaling_response_qos_limit()
> +bool cpu_response_frequency_qos_request_active(struct pm_qos_request *req);
cpu_scaling_response_qos_request_active()
and so on.
> +void cpu_response_frequency_qos_add_request(struct pm_qos_request *req,
> + s32 value);
> +void cpu_response_frequency_qos_update_request(struct pm_qos_request *req,
> +s32 new_value);
> +void cpu_response_frequency_qos_remove_request(struct pm_qos_request *req);
> +
> #ifdef CONFIG_PM
> enum pm_qos_flags_status __dev_pm_qos_flags(struct device *dev, s32 mask);
> enum pm_qos_flags_status dev_pm_qos_flags(struct device *dev, s32 mask);
> diff --git a/include/trace/events/power.h b/include/trace/events/power.h
> index af5018aa9517..7e4b52e8ca3a 100644
> --- a/include/trace/events/power.h
> +++ b/include/trace/events/power.h
> @@ -359,45 +359,48 @@ DEFINE_EVENT(power_domain, power_domain_target,
> );
>
> /*
> - * CPU latency QoS events used for global CPU latency QoS list updates
> + * CPU latency/response frequency QoS events used for global CPU PM
> + * QoS list updates.
> */
> -DECLARE_EVENT_CLASS(cpu_latency_qos_request,
> +DECLARE_EVENT_CLASS(pm_qos_request,
>
> - TP_PROTO(s32 value),
> + TP_PROTO(const char *name, s32 value),
>
> - TP_ARGS(value),
> + TP_ARGS(name, value),
>
> TP_STRUCT__entry(
> + __string(name, name )
> __field( s32,value )
> ),
>
> TP_fast_assign(
> + __assign_str(name, name);
> __entry->value = value;
> ),
>
> - TP_p
[Intel-gfx] [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v1:
* None
Changes since RFC:
* Enable properties for GEN >= 10 platforms (Ville)
* Do not round off the crtc co-ordinate (Danial Stone, Ville)
* Add new functions to handle scaling filter setup (Ville)
* Remove coefficient set 0 hardcoding.
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display.c | 32 ++--
drivers/gpu/drm/i915/display/intel_sprite.c | 31 ++-
2 files changed, 60 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 791dd908aa89..4b3387ee332e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6309,6 +6309,25 @@ void skl_scaler_setup_nearest_neighbor_filter(struct
drm_i915_private *dev_priv,
}
}
+static u32
+skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum pipe pipe,
+ int id, int set, enum drm_crtc_scaling_filter filter)
+{
+ u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
+
+ if (filter == DRM_CRTC_SCALING_FILTER_NEAREST_NEIGHBOR) {
+ skl_scaler_setup_nearest_neighbor_filter(dev_priv, pipe, id,
+set);
+ scaler_filter_ctl = PS_FILTER_PROGRAMMED |
+ PS_UV_VERT_FILTER_SELECT(set) |
+ PS_UV_HORZ_FILTER_SELECT(set) |
+ PS_Y_VERT_FILTER_SELECT(set) |
+ PS_Y_HORZ_FILTER_SELECT(set);
+
+ }
+ return scaler_filter_ctl;
+}
+
static void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -6316,12 +6335,14 @@ static void skl_pfit_enable(const struct
intel_crtc_state *crtc_state)
enum pipe pipe = crtc->pipe;
const struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
+ const struct drm_crtc_state *state = &crtc_state->uapi;
if (crtc_state->pch_pfit.enabled) {
u16 uv_rgb_hphase, uv_rgb_vphase;
int pfit_w, pfit_h, hscale, vscale;
unsigned long irqflags;
int id;
+ int scaler_filter_ctl;
if (drm_WARN_ON(&dev_priv->drm,
crtc_state->scaler_state.scaler_id < 0))
@@ -6340,8 +6361,12 @@ static void skl_pfit_enable(const struct
intel_crtc_state *crtc_state)
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
- intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN
|
- PS_FILTER_MEDIUM |
scaler_state->scalers[id].mode);
+ scaler_filter_ctl =
+ skl_scaler_crtc_setup_filter(dev_priv, pipe, id, 0,
+ state->scaling_filter);
+ intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id),
+ PS_SCALER_EN | scaler_filter_ctl |
+ scaler_state->scalers[id].mode);
intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
PS_Y_PHASE(0) |
PS_UV_RGB_PHASE(uv_rgb_vphase));
intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
@@ -16777,6 +16802,9 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
dev_priv->plane_to_crtc_mapping[i9xx_plane] = crtc;
}
+ if (INTEL_GEN(dev_priv) >= 10)
+ drm_crtc_enable_scaling_filter(&crtc->base);
+
intel_color_init(crtc);
intel_crtc_crc_init(crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index deda351719db..ac3fd9843ace 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -395,6 +395,26 @@ skl_plane_max_stride(struct intel_plane *plane,
return min(8192 * cpp, 32768);
}
+static u32
+skl_scaler_plane_setup_filter(struct drm_i915_private *dev_priv, enum pipe
pipe,
+ int id, int set,
+ enum drm_plane_scaling_filter filter)
+{
+ u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
+
+ if (filter == DRM_PLANE_SCALING_FILTER_NEAREST_NEIGHBOR) {
+ skl_scaler_setup_nearest_neighbor_filter(dev_priv, pipe, id,
+set);
+ scaler_filter_ctl = PS_FILTER_PROGRAMMED |
+ PS_UV_VERT_FILTER_SELECT(set) |
+
[Intel-gfx] [PATCH v2 3/5] drm/i915: Introduce scaling filter related registers and bit fields.
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v1:
* None
changes since RFC:
* Parametrize scaler coeffient macros by 'set' (Ville)
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_reg.h | 48 +
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c53fe918be6..d40f12d2a6b5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7205,6 +7205,7 @@ enum {
#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
#define PS_FILTER_MEDIUM (0 << 23)
+#define PS_FILTER_PROGRAMMED (1 << 23)
#define PS_FILTER_EDGE_ENHANCE (2 << 23)
#define PS_FILTER_BILINEAR (3 << 23)
#define PS_VERT3TAP(1 << 21)
@@ -7219,6 +7220,10 @@ enum {
#define PS_VADAPT_MODE_MOST_ADAPT (3 << 5)
#define PS_PLANE_Y_SEL_MASK (7 << 5)
#define PS_PLANE_Y_SEL(plane) (((plane) + 1) << 5)
+#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
+#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
+#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2)
+#define PS_UV_HORZ_FILTER_SELECT(set) ((set) << 1)
#define _PS_PWR_GATE_1A 0x68160
#define _PS_PWR_GATE_2A 0x68260
@@ -7281,6 +7286,25 @@ enum {
#define _PS_ECC_STAT_2B 0x68AD0
#define _PS_ECC_STAT_1C 0x691D0
+#define _PS_COEF_SET0_INDEX_1A0x68198
+#define _PS_COEF_SET0_INDEX_2A0x68298
+#define _PS_COEF_SET0_INDEX_1B0x68998
+#define _PS_COEF_SET0_INDEX_2B0x68A98
+#define _PS_COEF_SET1_INDEX_1A0x681A0
+#define _PS_COEF_SET1_INDEX_2A0x682A0
+#define _PS_COEF_SET1_INDEX_1B0x689A0
+#define _PS_COEF_SET1_INDEX_2B0x68AA0
+#define PS_COEE_INDEX_AUTO_INC(1 << 10)
+
+#define _PS_COEF_SET0_DATA_1A 0x6819C
+#define _PS_COEF_SET0_DATA_2A 0x6829C
+#define _PS_COEF_SET0_DATA_1B 0x6899C
+#define _PS_COEF_SET0_DATA_2B 0x68A9C
+#define _PS_COEF_SET1_DATA_1A 0x681A4
+#define _PS_COEF_SET1_DATA_2A 0x682A4
+#define _PS_COEF_SET1_DATA_1B 0x689A4
+#define _PS_COEF_SET1_DATA_2B 0x68AA4
+
#define _ID(id, a, b) _PICK_EVEN(id, a, b)
#define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
_ID(id, _PS_1A_CTRL, _PS_2A_CTRL), \
@@ -7310,6 +7334,30 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
+#define _SKL_PS_COEF_INDEX_SET0(pipe, id) _ID(pipe,\
+ _ID(id, _PS_COEF_SET0_INDEX_1A,
_PS_COEF_SET0_INDEX_2A), \
+ _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B))
+
+#define _SKL_PS_COEF_INDEX_SET1(pipe, id) _ID(pipe,\
+ _ID(id, _PS_COEF_SET1_INDEX_1A,
_PS_COEF_SET1_INDEX_2A), \
+ _ID(id, _PS_COEF_SET1_INDEX_1B, _PS_COEF_SET1_INDEX_2B))
+
+#define _SKL_PS_COEF_DATA_SET0(pipe, id) _ID(pipe, \
+ _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A), \
+ _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B))
+
+#define _SKL_PS_COEF_DATA_SET1(pipe, id) _ID(pipe, \
+ _ID(id, _PS_COEF_SET1_DATA_1A, _PS_COEF_SET1_DATA_2A), \
+ _ID(id, _PS_COEF_SET1_DATA_1B, _PS_COEF_SET1_DATA_2B))
+
+#define SKL_PS_COEF_INDEX_SET(pipe, id, set) \
+ _MMIO_PIPE(set, _SKL_PS_COEF_INDEX_SET0(pipe, id), \
+ _SKL_PS_COEF_INDEX_SET1(pipe, id))
+
+#define SKL_PS_COEF_DATA_SET(pipe, id, set) \
+ _MMIO_PIPE(set, _SKL_PS_COEF_DATA_SET0(pipe, id), \
+ _SKL_PS_COEF_DATA_SET1(pipe, id))
+
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] Introduce drm scaling filter property
This series is the continuation for the RFC that I posted earlier [1] [1] RFC: https://patchwork.freedesktop.org/series/73884/ Integer scaling (IS) is a nearest-neighbor upscaling technique that simply scales up the existing pixels by an integer (i.e., whole number) multiplier. Nearest-neighbor (NN) interpolation works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Both IS and NN preserve the clarity of the original image. In contrast, traditional upscaling algorithms, such as bilinear or bicubic interpolation, result in blurry upscaled images because they employ interpolation techniques that smooth out the transition from one pixel to another. Therefore, integer scaling is particularly useful for pixel art games that rely on sharp, blocky images to deliver their distinctive look. Many gaming communities have been asking for integer-mode scaling support, some links and background: https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics http://tanalin.com/en/articles/lossless-scaling/ https://community.amd.com/thread/209107 https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ This patch series - - Introduces new scaling filter properties to allow userspace to select the driver's default scaling filter or Nearest-neighbor(NN) filter for scaling operations on crtc and plane. - Implements and enable integer scaling for i915 Userspace patch series link: https://github.com/lrusak/xbmc/pull/24 Thanks to Shashank for initiating this work. His initial work can be found here [2] [2] https://patchwork.freedesktop.org/patch/337082/ changes since v1: * Add userspace patch link to this cover letter. * 4/5 - Rearrange skl_scaler_setup_nearest_neighbor_filter() to iterate the registers directly instead of the phases and taps (Ville) Pankaj Bharadiya (5): drm: Introduce plane and CRTC scaling filter properties drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation drm/i915: Introduce scaling filter related registers and bit fields. drm/i915/display: Add Nearest-neighbor based integer scaling support drm/i915: Enable scaling filter for plane and CRTC Documentation/gpu/drm-kms.rst| 12 +++ drivers/gpu/drm/drm_atomic_uapi.c| 8 ++ drivers/gpu/drm/drm_crtc.c | 33 ++ drivers/gpu/drm/drm_mode_config.c| 26 + drivers/gpu/drm/drm_plane.c | 33 ++ drivers/gpu/drm/i915/display/intel_display.c | 104 ++- drivers/gpu/drm/i915/display/intel_display.h | 2 + drivers/gpu/drm/i915/display/intel_sprite.c | 31 +- drivers/gpu/drm/i915/i915_reg.h | 48 + include/drm/drm_crtc.h | 13 +++ include/drm/drm_mode_config.h| 12 +++ include/drm/drm_plane.h | 13 +++ 12 files changed, 332 insertions(+), 3 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation
Add documentation for newly introduced KMS plane and CRTC scaling filter properties. changes since v1: * None changes since RFC: * Add separate documentation for plane and CRTC. Signed-off-by: Pankaj Bharadiya --- Documentation/gpu/drm-kms.rst | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 906771e03103..b0335e9d887c 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -509,6 +509,18 @@ Variable Refresh Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: Variable refresh properties +Plane Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: Plane scaling filter property + +CRTC Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :doc: CRTC scaling filter property + Existing KMS Properties --- -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] drm/i915/display: Add Nearest-neighbor based integer scaling support
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest source pixel value.
Both IS and NN preserve the clarity of the original image. Integer
scaling is particularly useful for pixel art games that rely on
sharp, blocky images to deliver their distinctive look.
Introduce skl_scaler_setup_nearest_neighbor_filter() function which
configures the scaler filter coefficients to enable nearest-neighbor
filtering.
Bspec: 49247
changes since v1:
* Rearrange skl_scaler_setup_nearest_neighbor_filter() to iterate the
registers directly instead of the phases and taps (Ville)
changes since RFC:
* Refine the skl_scaler_setup_nearest_neighbor_filter() logic (Ville)
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display.c | 72
drivers/gpu/drm/i915/display/intel_display.h | 2 +
2 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f23c4d51c33..791dd908aa89 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6237,6 +6237,78 @@ void skl_scaler_disable(const struct intel_crtc_state
*old_crtc_state)
skl_detach_scaler(crtc, i);
}
+static int skl_coef_tap(int i)
+{
+ return i % 7;
+}
+
+static u16 skl_nearest_filter_coef(int t)
+{
+ return t == 3 ? 0x0800 : 0x3000;
+}
+
+/**
+ * Theory behind setting nearest-neighbor integer scaling:
+ *
+ * 17 phase of 7 taps requires 119 coefficients in 60 dwords per set.
+ * The letter represents the filter tap (D is the center tap) and the number
+ * represents the coefficient set for a phase (0-16).
+ *
+ * ++++
+ * |Index value | Data value coeffient 1 | Data value coeffient 2 |
+ * ++++
+ * | 00h | B0| A0|
+ * ++++
+ * | 01h | D0| C0|
+ * ++++
+ * | 02h | F0| E0|
+ * ++++
+ * | 03h | A1| G0|
+ * ++++
+ * | 04h | C1| B1|
+ * ++++
+ * | ... | ... | ... |
+ * ++++
+ * | 38h | B16 | A16 |
+ * ++++
+ * | 39h | D16 | C16 |
+ * ++++
+ * | 3Ah | F16 | C16 |
+ * ++++
+ * | 3Bh |Reserved| G16 |
+ * ++++
+ *
+ * To enable nearest-neighbor scaling: program scaler coefficents with
+ * the center tap (Dxx) values set to 1 and all other values set to 0 as per
+ * SCALER_COEFFICIENT_FORMAT
+ *
+ */
+
+void skl_scaler_setup_nearest_neighbor_filter(struct drm_i915_private
*dev_priv,
+ enum pipe pipe, int id, int set)
+{
+ int i;
+
+ /*enable the index auto increment.*/
+ intel_de_write_fw(dev_priv,
+ SKL_PS_COEF_INDEX_SET(pipe, id, set),
+ PS_COEE_INDEX_AUTO_INC);
+
+ for (i = 0; i < 17 * 7; i += 2) {
+ u32 tmp;
+ int t;
+
+ t = skl_coef_tap(i);
+ tmp = skl_nearest_filter_coef(t);
+
+ t = skl_coef_tap(i+1);
+ tmp |= skl_nearest_filter_coef(t)<<16;
+
+ intel_de_write_fw(dev_priv, SKL_PS_COEF_DATA_SET(pipe, id, set),
+ tmp);
+ }
+}
+
static void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/int
[Intel-gfx] [PATCH v2 1/5] drm: Introduce plane and CRTC scaling filter properties
Introduce new plane and CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_enable_scaling_filter() and for a CRTC by calling
drm_crtc_enable_scaling_filter().
NN filter works by filling in the missing color values in the upscaled
image with that of the coordinate-mapped nearest source pixel value.
NN filter for integer multiple scaling can be particularly useful for
for pixel art games that rely on sharp, blocky images to deliver their
distinctive look.
changes since v1:
* None
changes since RFC:
* Add separate properties for plane and CRTC (Ville)
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/drm_atomic_uapi.c | 8
drivers/gpu/drm/drm_crtc.c| 33 +++
drivers/gpu/drm/drm_mode_config.c | 26
drivers/gpu/drm/drm_plane.c | 33 +++
include/drm/drm_crtc.h| 13
include/drm/drm_mode_config.h | 12 +++
include/drm/drm_plane.h | 13
7 files changed, 138 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index a1e5e262bae2..3c72ab52ff62 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->crtc_scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->crtc_scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
@@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
sizeof(struct drm_rect),
&replaced);
return ret;
+ } else if (property == config->plane_scaling_filter_property) {
+ state->scaling_filter = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
+ } else if (property == config->plane_scaling_filter_property) {
+ *val = state->scaling_filter;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4936e1080e41..c8d387891dd5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -748,3 +748,36 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
return ret;
}
+
+/**
+ * DOC: CRTC scaling filter property
+ *
+ * SCALING_FILTER:
+ *
+ * Indicates scaling filter to be used for CRTC scaler
+ *
+ * The value of this property can be one of the following:
+ * Default:
+ * Driver's default scaling filter
+ * Nearest Neighbor:
+ * Nearest Neighbor scaling filter
+ *
+ * Drivers can set up this property for a CRTC by calling
+ * drm_crtc_enable_scaling_filter()
+ */
+
+/**
+ * drm_crtc_enable_scaling_filter - Enables CRTC scaling filter property.
+ * @crtc: CRTC on which to enable scaling filter property.
+ *
+ * This function lets driver to enable the scaling filter property on a CRTC.
+ */
+void drm_crtc_enable_scaling_filter(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+
+ drm_object_attach_property(&crtc->base,
+
dev->mode_config.crtc_scaling_filter_property,
+ 0);
+}
+EXPORT_SYMBOL(drm_crtc_enable_scaling_filter);
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index e1ec1bb7068d..483705581930 100644
--- a/drivers/gpu/dr
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Prefer '%ps' for printing function symbol names
== Series Details == Series: series starting with [1/6] drm/i915: Prefer '%ps' for printing function symbol names URL : https://patchwork.freedesktop.org/series/74865/ State : success == Summary == CI Bug Log - changes from CI_DRM_8157 -> Patchwork_17022 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/index.html Known issues Here are the changes found in Patchwork_17022 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-icl-y: [PASS][1] -> [DMESG-FAIL][2] ([fdo#108569]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-icl-y/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/fi-icl-y/igt@i915_selftest@l...@execlists.html - fi-bxt-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] / [i915#1430] / [i915#656]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-icl-dsi: [INCOMPLETE][5] ([i915#189]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-icl-dsi/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/fi-icl-dsi/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-kbl-soraka: [FAIL][7] ([IGT#5]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-kbl-soraka/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/fi-kbl-soraka/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][9] ([i915#323]) -> [FAIL][10] ([fdo#111407]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [IGT#5]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/5 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (41 -> 36) -- Additional (2): fi-skl-lmem fi-bwr-2160 Missing(7): fi-byt-j1900 fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ilk-650 fi-gdg-551 fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8157 -> Patchwork_17022 CI-20190529: 20190529 CI_DRM_8157: 4f297a639d15ec6c293b74ff0904de6146b18e4f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17022: 5ac96f1320c04c2e34bbc577ba9c130c2f5aabd3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5ac96f1320c0 drm/i915/gt: Cancel a hung context if already closed 24264f0110bf drm/i915: Use explicit flag to mark unreachable intel_context 0d627b859e10 drm/i915/gem: Wait until the context is finally retired before releasing engines 41e5d3f53cb8 drm/i915/execlists: Force single submission for sentinels bfbf43d0da6a drm/i915/gem: Avoid gem_context->mutex for simple vma lookup a8c2d338a0df drm/i915: Prefer '%ps' for printing function symbol names == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17022/index.html ___ 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/dp: intel_dp connector hook for VRR support
On Tue, 17 Mar 2020, Manasi Navare wrote:
> This defines the get_vrr_support hook for intel DP connector
> VRR support is set to true based on the DPCD ignore MSA and
> EDID monitor range
Yeah... but what do you use it for?
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Cc: Aditya Swarup
> Signed-off-by: Manasi Navare
> ---
> .../drm/i915/display/intel_display_types.h| 3 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 19 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 5e00e611f077..cd37ee6db1ff 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1353,6 +1353,9 @@ struct intel_dp {
>
> /* Display stream compression testing */
> bool force_dsc_en;
> +
> + /* DP Variable refresh rate/ Adaptive sync support */
> + bool vrr_capable;
Only set, never read.
> };
>
> enum lspcon_vendor {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a417cd2af2b..ccf5d868b5c1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5860,6 +5860,24 @@ static int intel_dp_get_modes(struct drm_connector
> *connector)
> return 0;
> }
>
> +static void intel_dp_get_vrr_support(struct drm_connector *connector)
> +{
> + struct intel_dp *intel_dp =
> intel_attached_dp(to_intel_connector(connector));
> + const struct drm_display_info *info = &connector->display_info;
> + struct drm_i915_private *dev_priv = to_i915(connector->dev);
> +
> + /*
> + * DP Sink is capable of Variable refresh video timings if
> + * Ignore MSA bit is set in DPCD.
> + * EDID monitor range also should be atleast 10 for reasonable
> + * Adaptive sync/ VRR end user experience.
> + */
> + if (INTEL_GEN(dev_priv) >= 12 &&
> + drm_dp_sink_is_capable_without_timing_msa(intel_dp->dpcd) &&
> + info->monitor_range.max_vfreq - info->monitor_range.min_vfreq > 10)
> + intel_dp->vrr_capable = true;
So for now this is just a cached value for i915 use. I don't know what
you'll need it for, but you also don't explain why it needs to be
*cached* instead of having a helper to tell you based on the above
data. You only ever set ->vrr_capable to true, but you never reset it
back to false e.g. when the display is changed on the connector.
Furthermore, because of the placing of the hook call in the previous
patch, this will only use whatever details ->get_modes gives you, not
the fallback data.
BR,
Jani.
> +}
> +
> static int
> intel_dp_connector_register(struct drm_connector *connector)
> {
> @@ -6756,6 +6774,7 @@ static const struct drm_connector_helper_funcs
> intel_dp_connector_helper_funcs =
> .get_modes = intel_dp_get_modes,
> .mode_valid = intel_dp_mode_valid,
> .atomic_check = intel_dp_connector_atomic_check,
> + .get_adaptive_sync_support = intel_dp_get_vrr_support,
> };
>
> static const struct drm_encoder_funcs intel_dp_enc_funcs = {
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm: Create a drm_connector_helper_funcs hook for Adaptive Sync support
On Tue, 17 Mar 2020, Manasi Navare wrote:
> This patch adds a hook in drm_connector_helper_funcs to get the
> support of the driver for adaptive sync functionality.
>
> This can be called in the connector probe helper function after
> the connector detect() and get_modes() hooks to also
> query the adaptive sync support of the driver.
I can obviously see that from the patch. But this does not explain at
all *why* we need another hook to begin with, and why it neeeds to be
called from ->fill_modes that is set to
drm_helper_probe_single_connector_modes().
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_probe_helper.c | 4
> include/drm/drm_modeset_helper_vtables.h | 16
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 576b4b7dcd89..4403817bfb02 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -482,6 +482,10 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
>
> count = (*connector_funcs->get_modes)(connector);
>
> + /* Get the Adaptive Sync Support if helper exists */
> + if (*connector_funcs->get_adaptive_sync_support)
> + (**connector_funcs->get_adaptive_sync_support)(connector);
> +
This is in the middle of a sequence figuring out the modes. First
->get_modes, then fallback to other mechanisms. Certainly we don't want
to do something else in the middle.
> /*
>* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
>* override/firmware EDID.
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index 7c20b1c8b6a7..0b203fdd25df 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1079,6 +1079,22 @@ struct drm_connector_helper_funcs {
>struct drm_writeback_job *job);
> void (*cleanup_writeback_job)(struct drm_writeback_connector *connector,
> struct drm_writeback_job *job);
> +
> + /**
> + * @get_adaptive_sync_support:
> + *
> + * This hook is used by the probe helper to get the driver's support
> + * for adaptive sync or variable refresh rate.
> + * This is called from drm_helper_probe_single_connector_modes()
> + * This is called after the @get_modes hook so that the connector modes
> + * are already obtained and EDID is parsed to obtain the monitor
> + * range descriptor information.
> + *
> + * This hook is optional and defined only for the drivers and on
> + * connectors that advertise adaptive sync support.
> + *
> + */
> + void (*get_adaptive_sync_support)(struct drm_connector *connector);
> };
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/dp: DRM DP helper for reading Ignore MSA from DPCD
On Tue, 17 Mar 2020, Manasi Navare wrote:
> DP sink device sets the Ignore MSA bit in its
> DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
> ignore the MSA video timing paramaters and its ability to support
> seamless video timing change over a range of timing exposed by
> DisplayID and EDID.
> This is required for the sink to indicate that it is Adaptive sync
> capable.
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Signed-off-by: Manasi Navare
> ---
> include/drm/drm_dp_helper.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c6119e4c169a..ccd6e2e988b9 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1315,6 +1315,14 @@ drm_dp_alternate_scrambler_reset_cap(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> DP_ALTERNATE_SCRAMBLER_RESET_CAP;
> }
>
> +/* Ignore MSA timing for Adaptive Sync support on DP 1.4 */
> +static inline bool
> +drm_dp_sink_is_capable_without_timing_msa(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
From the department of nitpicks, if you read the name of the function
aloud, what does it actually mean?
Is sink capable of *what*?
BR,
Jani.
> +{
> + return dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> + DP_MSA_TIMING_PAR_IGNORED;
> +}
> +
> /*
> * DisplayPort AUX channel
> */
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915/gt: convert to struct drm_device based logging macros.
On Sat, 14 Mar 2020, Wambui Karuga wrote: > This patchset continues the conversion of printk based macros to use > the struct drm_device based drm logging macros focused on the i915/gt > folder. > These patches were achieved using both coccinelle and manually. Pushed the lot, thanks for the patches. BR, Jani. > > Wambui Karuga (7): > drm/i915/ggtt: convert to drm_device based logging macros. > drm/i915/lrc: convert to struct drm_device based logging macros. > drm/i915/rc6: convert to struct drm_device based logging macros. > drm/i915/renderstate: use struct drm_device based logging macros. > drm/i915/ring_submission: use drm_device based logging macros. > drm/i915/rps: use struct drm_device based logging macros. > drm/i915/workarounds: convert to drm_device based logging macros. > > drivers/gpu/drm/i915/gt/intel_ggtt.c | 38 ++ > drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ++-- > drivers/gpu/drm/i915/gt/intel_rc6.c | 35 + > drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- > .../gpu/drm/i915/gt/intel_ring_submission.c | 33 > drivers/gpu/drm/i915/gt/intel_rps.c | 75 +-- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +- > 7 files changed, 110 insertions(+), 94 deletions(-) -- 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 [1/4] drm/i915: Prefer '%ps' for printing function symbol names (rev2)
== Series Details == Series: series starting with [1/4] drm/i915: Prefer '%ps' for printing function symbol names (rev2) URL : https://patchwork.freedesktop.org/series/74864/ State : success == Summary == CI Bug Log - changes from CI_DRM_8157 -> Patchwork_17021 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/index.html Known issues Here are the changes found in Patchwork_17021 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_pm_rpm@module-reload: - fi-icl-dsi: [INCOMPLETE][1] ([i915#189]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-icl-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/fi-icl-dsi/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][3] ([i915#323]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-kbl-soraka: [FAIL][5] ([IGT#5]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8157/fi-kbl-soraka/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/fi-kbl-soraka/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [IGT#5]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/5 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 Participating hosts (41 -> 40) -- Additional (2): fi-skl-lmem fi-bwr-2160 Missing(3): fi-byt-squawks fi-ehl-1 fi-bsw-cyan Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8157 -> Patchwork_17021 CI-20190529: 20190529 CI_DRM_8157: 4f297a639d15ec6c293b74ff0904de6146b18e4f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17021: a8127f1ca9e3175868fa53da440c5bd88261f3a0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a8127f1ca9e3 drm/i915/gem: Wait until the context is finally retired before releasing engines e5dfe0a1b939 drm/i915/execlists: Force single submission for sentinels 8c607ce297db drm/i915/gem: Avoid gem_context->mutex for simple vma lookup 46267b8160d6 drm/i915: Prefer '%ps' for printing function symbol names == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17021/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Increase the DDI idle timeout to 500us
On Thu, Mar 19, 2020 at 11:20:34AM +0200, Arkadiusz Hiler wrote: > Bspec says that we should timeout after 500us. Let's match this in the > code. It may help with few of the timeouts we see here and there. Plese disregard. it's 500us when waiting on non-idle and only 8 (16 for BXT) for back to idle. -- Cheers, Arek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915/gt: Cancel a hung context if already closed
Use the restored ability to check if a context is closed to decide
whether or not to immediately ban the context from further execution
after a hang.
Fixes: be90e344836a ("drm/i915/gt: Cancel banned contexts after GT reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_reset.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 9a15bdf31c7f..003f26b42998 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -88,6 +88,11 @@ static bool mark_guilty(struct i915_request *rq)
bool banned;
int i;
+ if (intel_context_is_closed(rq->context)) {
+ intel_context_set_banned(rq->context);
+ return true;
+ }
+
rcu_read_lock();
ctx = rcu_dereference(rq->context->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915/gem: Wait until the context is finally retired before releasing engines
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin.
To accommodate this, we need to be able to flush the i915_active's
barriers before awaiting on them. However, this also requires us to
ensure the context is unpinned *before* the barrier request can be
signaled, so mark it as a sentinel.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 17 --
drivers/gpu/drm/i915/i915_active.c | 37 -
drivers/gpu/drm/i915/i915_active.h | 3 +-
3 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c0e476fcd1fa..05fed8797d37 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,23 +570,20 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
engines->ctx = i915_gem_context_get(ctx);
for_each_gem_engine(ce, engines, it) {
- struct dma_fence *fence;
- int err = 0;
+ int err;
/* serialises with execbuf */
RCU_INIT_POINTER(ce->gem_context, NULL);
if (!intel_context_pin_if_active(ce))
continue;
- fence = i915_active_fence_get(&ce->timeline->last_request);
- if (fence) {
- err = i915_sw_fence_await_dma_fence(&engines->fence,
- fence, 0,
- GFP_KERNEL);
- dma_fence_put(fence);
- }
+ /* Wait until context is finally scheduled out and retired */
+ err = i915_sw_fence_await_active(&engines->fence,
+&ce->active,
+I915_ACTIVE_AWAIT_ACTIVE |
+I915_ACTIVE_AWAIT_BARRIER);
intel_context_unpin(ce);
- if (err < 0)
+ if (err)
goto kill;
}
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index c4048628188a..da7d35f66dd0 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -518,19 +518,18 @@ int i915_active_wait(struct i915_active *ref)
return 0;
}
-static int __await_active(struct i915_active_fence *active,
- int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+static int __await_fence(struct i915_active_fence *active,
+int (*fn)(void *arg, struct dma_fence *fence),
+void *arg)
{
struct dma_fence *fence;
+ int err;
- if (is_barrier(active)) /* XXX flush the barrier? */
+ if (is_barrier(active))
return 0;
fence = i915_active_fence_get(active);
if (fence) {
- int err;
-
err = fn(arg, fence);
dma_fence_put(fence);
if (err < 0)
@@ -540,6 +539,22 @@ static int __await_active(struct i915_active_fence *active,
return 0;
}
+static int __await_active(struct active_node *it,
+ unsigned int flags,
+ int (*fn)(void *arg, struct dma_fence *fence),
+ void *arg)
+{
+ int err;
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_barrier(it);
+ if (err)
+ return err;
+ }
+
+ return __await_fence(&it->base, fn, arg);
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
@@ -549,16 +564,17 @@ static int await_active(struct i915_active *ref,
/* We must always wait for the exclusive fence! */
if (rcu_access_pointer(ref->excl.fence)) {
- err = __await_active(&ref->excl, fn, arg);
+ err = __await_fence(&ref->excl, fn, arg);
if (err)
return err;
}
- if (flags & I915_ACTIVE_AWAIT_ALL && i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
+ i915_active_acquire_if_busy(ref)) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, &ref->tree, node) {
- err = __await_active(&it->base, fn, arg);
+ err = __await_active(it, flags, fn, arg);
if (err)
[Intel-gfx] [PATCH] drm/i915/display: Increase the DDI idle timeout to 500us
Bspec says that we should timeout after 500us. Let's match this in the
code. It may help with few of the timeouts we see here and there.
Bspec: 22243, 49190
Issue: https://gitlab.freedesktop.org/drm/intel/issues/1069
Suggested-by: Uma Shankar
Cc: Imre Deak
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 73d0f4648c06..28650797fc2f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1097,7 +1097,7 @@ static void intel_wait_ddi_buf_idle(struct
drm_i915_private *dev_priv,
i915_reg_t reg = DDI_BUF_CTL(port);
int i;
- for (i = 0; i < 16; i++) {
+ for (i = 0; i < 500; i++) {
udelay(1);
if (intel_de_read(dev_priv, reg) & DDI_BUF_IS_IDLE)
return;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
As we store the handle lookup inside a radix tree, we do not need the
gem_context->mutex except until we need to insert our lookup into the
common radix tree. This takes a small bit of rearranging to ensure that
the lut we insert into the tree is ready prior to actually inserting it
(as soon as it is exposed via the radixtree, it is visible to any other
submission).
v2: For brownie points, remove the goto spaghetti.
v3: Tighten up the closed-handle checks.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 136 +++---
1 file changed, 87 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..042a9ccf348f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -481,7 +481,7 @@ eb_add_vma(struct i915_execbuffer *eb,
GEM_BUG_ON(i915_vma_is_closed(vma));
- ev->vma = i915_vma_get(vma);
+ ev->vma = vma;
ev->exec = entry;
ev->flags = entry->flags;
@@ -728,77 +728,117 @@ static int eb_select_context(struct i915_execbuffer *eb)
return 0;
}
-static int eb_lookup_vmas(struct i915_execbuffer *eb)
+static int __eb_add_lut(struct i915_execbuffer *eb,
+ u32 handle, struct i915_vma *vma)
{
- struct radix_tree_root *handles_vma = &eb->gem_context->handles_vma;
- struct drm_i915_gem_object *obj;
- unsigned int i, batch;
+ struct i915_gem_context *ctx = eb->gem_context;
+ struct i915_lut_handle *lut;
int err;
- if (unlikely(i915_gem_context_is_closed(eb->gem_context)))
- return -ENOENT;
+ lut = i915_lut_handle_alloc();
+ if (unlikely(!lut))
+ return -ENOMEM;
- INIT_LIST_HEAD(&eb->relocs);
- INIT_LIST_HEAD(&eb->unbound);
+ i915_vma_get(vma);
+ if (!atomic_fetch_inc(&vma->open_count))
+ i915_vma_reopen(vma);
+ lut->handle = handle;
+ lut->ctx = ctx;
+
+ /* Check that the context hasn't been closed in the meantime */
+ err = -EINTR;
+ if (!mutex_lock_interruptible(&ctx->mutex)) {
+ err = -ENOENT;
+ if (likely(!i915_gem_context_is_closed(ctx)))
+ err = radix_tree_insert(&ctx->handles_vma, handle, vma);
+ if (err == 0) { /* And nor has this handle */
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ i915_gem_object_lock(obj);
+ if (idr_find(&eb->file->object_idr, handle) == obj) {
+ list_add(&lut->obj_link, &obj->lut_list);
+ } else {
+ radix_tree_delete(&ctx->handles_vma, handle);
+ err = -ENOENT;
+ }
+ i915_gem_object_unlock(obj);
+ }
+ mutex_unlock(&ctx->mutex);
+ }
+ if (unlikely(err))
+ goto err;
- batch = eb_batch_index(eb);
+ return 0;
- for (i = 0; i < eb->buffer_count; i++) {
- u32 handle = eb->exec[i].handle;
- struct i915_lut_handle *lut;
+err:
+ atomic_dec(&vma->open_count);
+ i915_vma_put(vma);
+ i915_lut_handle_free(lut);
+ return err;
+}
+
+static struct i915_vma *eb_lookup_vma(struct i915_execbuffer *eb, u32 handle)
+{
+ do {
+ struct drm_i915_gem_object *obj;
struct i915_vma *vma;
+ int err;
- vma = radix_tree_lookup(handles_vma, handle);
+ rcu_read_lock();
+ vma = radix_tree_lookup(&eb->gem_context->handles_vma, handle);
+ if (likely(vma))
+ vma = i915_vma_tryget(vma);
+ rcu_read_unlock();
if (likely(vma))
- goto add_vma;
+ return vma;
obj = i915_gem_object_lookup(eb->file, handle);
- if (unlikely(!obj)) {
- err = -ENOENT;
- goto err_vma;
- }
+ if (unlikely(!obj))
+ return ERR_PTR(-ENOENT);
vma = i915_vma_instance(obj, eb->context->vm, NULL);
if (IS_ERR(vma)) {
- err = PTR_ERR(vma);
- goto err_obj;
+ i915_gem_object_put(obj);
+ return vma;
}
- lut = i915_lut_handle_alloc();
- if (unlikely(!lut)) {
- err = -ENOMEM;
- goto err_obj;
- }
+ err = __eb_add_lut(eb, handle, vma);
+ if (likely(!err))
+ return vma;
- err = radix_tree_insert(handles_vma, handle, vma);
-
[Intel-gfx] [PATCH 3/6] drm/i915/execlists: Force single submission for sentinels
Currently, we only combine a sentinel request with a max-priority
barrier such that a sentinel request is always in ELSP[0] with nothing
following it. However, we will want to create similar ELSP[] submissions
providing a full-barrier in the submission queue, but without forcing
maximum priority. As such I915_FENCE_FLAG_SENTINEL takes on the
single-submission property and so we can remove the gvt special casing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.h | 24 +++---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 33 +--
drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++--
4 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 18efad255124..ee5d47165c12 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -198,18 +198,6 @@ static inline bool intel_context_set_banned(struct
intel_context *ce)
return test_and_set_bit(CONTEXT_BANNED, &ce->flags);
}
-static inline bool
-intel_context_force_single_submission(const struct intel_context *ce)
-{
- return test_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, &ce->flags);
-}
-
-static inline void
-intel_context_set_single_submission(struct intel_context *ce)
-{
- __set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, &ce->flags);
-}
-
static inline bool
intel_context_nopreempt(const struct intel_context *ce)
{
@@ -228,6 +216,18 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
}
+static inline bool
+intel_context_is_gvt(const struct intel_context *ce)
+{
+ return test_bit(CONTEXT_GVT, &ce->flags);
+}
+
+static inline void
+intel_context_set_gvt(struct intel_context *ce)
+{
+ set_bit(CONTEXT_GVT, &ce->flags);
+}
+
static inline u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
const u32 period =
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0f3b68b95c56..fd2703efc10c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -64,8 +64,8 @@ struct intel_context {
#define CONTEXT_VALID_BIT 2
#define CONTEXT_USE_SEMAPHORES 3
#define CONTEXT_BANNED 4
-#define CONTEXT_FORCE_SINGLE_SUBMISSION5
-#define CONTEXT_NOPREEMPT 6
+#define CONTEXT_NOPREEMPT 5
+#define CONTEXT_GVT6
u32 *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 112531b29f59..f0c4084c5b9a 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1579,22 +1579,10 @@ static void execlists_submit_ports(struct
intel_engine_cs *engine)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
}
-static bool ctx_single_port_submission(const struct intel_context *ce)
-{
- return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
- intel_context_force_single_submission(ce));
-}
-
static bool can_merge_ctx(const struct intel_context *prev,
const struct intel_context *next)
{
- if (prev != next)
- return false;
-
- if (ctx_single_port_submission(prev))
- return false;
-
- return true;
+ return prev == next;
}
static unsigned long i915_request_flags(const struct i915_request *rq)
@@ -1844,6 +1832,12 @@ static inline void clear_ports(struct i915_request
**ports, int count)
memset_p((void **)ports, NULL, count);
}
+static bool has_sentinel(struct i915_request *prev, struct i915_request *next)
+{
+ return (i915_request_flags(prev) | i915_request_flags(next)) &
+ BIT(I915_FENCE_FLAG_SENTINEL);
+}
+
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -2125,18 +2119,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (last->context == rq->context)
goto done;
- if (i915_request_has_sentinel(last))
- goto done;
-
- /*
-* If GVT overrides us we only ever submit
-* port[0], leaving port[1] empty. Note that we
-* also have to be careful that we don't queue
-* the same context (even though a different
-* request) to the second port.
-*/
- if (ctx_single_port_submission(last->context) ||
-
[Intel-gfx] [PATCH 5/6] drm/i915: Use explicit flag to mark unreachable intel_context
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.h| 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
4 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 05fed8797d37..1280b627adcf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -573,7 +573,7 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
int err;
/* serialises with execbuf */
- RCU_INIT_POINTER(ce->gem_context, NULL);
+ set_bit(CONTEXT_CLOSED_BIT, &ce->flags);
if (!intel_context_pin_if_active(ce))
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 042a9ccf348f..5c6bcf2b4488 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2354,7 +2354,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
prev = __i915_request_commit(rq);
/* Check that the context wasn't destroyed before submission */
- if (likely(rcu_access_pointer(eb->context->gem_context))) {
+ if (likely(!intel_context_is_closed(eb->context))) {
attr = eb->gem_context->sched;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index ee5d47165c12..02df04f76547 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -173,6 +173,11 @@ static inline bool intel_context_is_barrier(const struct
intel_context *ce)
return test_bit(CONTEXT_BARRIER_BIT, &ce->flags);
}
+static inline bool intel_context_is_closed(const struct intel_context *ce)
+{
+ return test_bit(CONTEXT_CLOSED_BIT, &ce->flags);
+}
+
static inline bool intel_context_use_semaphores(const struct intel_context *ce)
{
return test_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index fd2703efc10c..418516fd9b9e 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -62,10 +62,11 @@ struct intel_context {
#define CONTEXT_BARRIER_BIT0
#define CONTEXT_ALLOC_BIT 1
#define CONTEXT_VALID_BIT 2
-#define CONTEXT_USE_SEMAPHORES 3
-#define CONTEXT_BANNED 4
-#define CONTEXT_NOPREEMPT 5
-#define CONTEXT_GVT6
+#define CONTEXT_CLOSED_BIT 3
+#define CONTEXT_USE_SEMAPHORES 4
+#define CONTEXT_BANNED 5
+#define CONTEXT_NOPREEMPT 6
+#define CONTEXT_GVT7
u32 *lrc_reg_state;
u64 lrc_desc;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915: Prefer '%ps' for printing function symbol names
%pS includes the offset, which is useful for return addresses but noise
when we are pretty printing a known (and expected) function entry point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index a3d38e089b6e..7daf81f55c90 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -421,7 +421,7 @@ static void timer_i915_sw_fence_wake(struct timer_list *t)
if (!fence)
return;
- pr_notice("Asynchronous wait on fence %s:%s:%llx timed out
(hint:%pS)\n",
+ pr_notice("Asynchronous wait on fence %s:%s:%llx timed out
(hint:%ps)\n",
cb->dma->ops->get_driver_name(cb->dma),
cb->dma->ops->get_timeline_name(cb->dma),
cb->dma->seqno,
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 68bbb1580162..54080fb4af4b 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -277,7 +277,7 @@ static struct intel_engine_cs *node_to_barrier(struct
active_node *it)
void i915_active_print(struct i915_active *ref, struct drm_printer *m)
{
- drm_printf(m, "active %pS:%pS\n", ref->active, ref->retire);
+ drm_printf(m, "active %ps:%ps\n", ref->active, ref->retire);
drm_printf(m, "\tcount: %d\n", atomic_read(&ref->count));
drm_printf(m, "\tpreallocated barriers? %s\n",
yesno(!llist_empty(&ref->preallocated_barriers)));
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..7ac9616de9d8 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -1233,7 +1233,7 @@ static int live_parallel_engines(void *arg)
struct igt_live_test t;
unsigned int idx;
- snprintf(name, sizeof(name), "%pS", fn);
+ snprintf(name, sizeof(name), "%ps", fn);
err = igt_live_test_begin(&t, i915, __func__, name);
if (err)
break;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
