Re: [Intel-gfx] [PATCH 3/8] iommu/vt-d: Remove IOVA handling code from non-dma_ops path
On 2020/3/20 14:30, Tom Murphy wrote: Could we merge patch 1-3 from this series? it just cleans up weird code and merging these patches will cover some of the work needed to move the intel iommu driver to the dma-iommu api in the future. Can you please take a look at this patch series? https://lkml.org/lkml/2020/3/13/1162 It probably makes this series easier. Best regards, baolu On Sat, 21 Dec 2019 at 07:04, Tom Murphy wrote: Remove all IOVA handling code from the non-dma_ops path in the intel iommu driver. There's no need for the non-dma_ops path to keep track of IOVAs. The whole point of the non-dma_ops path is that it allows the IOVAs to be handled separately. The IOVA handling code removed in this patch is pointless. Signed-off-by: Tom Murphy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: move files more files into debugfs
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- interrupt_info_show
|
+-- sseu_status
|
+-- 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.
It is based on Daniele's series and it applies only on top of
that.
Thanks Tvrtko for the review,
Andi
Changelog
=
v2:
- dropped changes on "drop_caches", they were indeed irrelevant
- improved interrupt info function
drivers/gpu/drm/i915/gt/debugfs_gt.c| 464 +++-
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 32 ++
drivers/gpu/drm/i915/i915_debugfs.c | 441 +-
3 files changed, 499 insertions(+), 438 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index fcbc57e226c3..ab731350daea 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -5,12 +5,472 @@
*/
#include
+#include
#include "debugfs_engines.h"
#include "debugfs_gt.h"
#include "debugfs_gt_pm.h"
-#include "uc/debugfs_uc.h"
#include "i915_drv.h"
+#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
+#include "uc/debugfs_uc.h"
+
+static void
+intel_sseu_copy_subslices(const struct sseu_dev_info *sseu, int slice,
+ u8 *to_mask)
+{
+ int offset = slice * sseu->ss_stride;
+
+ memcpy(_mask[offset], >subslice_mask[offset], sseu->ss_stride);
+}
+
+static void cherryview_sseu_device_status(struct intel_gt *gt,
+ struct sseu_dev_info *sseu)
+{
+#define SS_MAX 2
+ const int ss_max = SS_MAX;
+ u32 sig1[SS_MAX], sig2[SS_MAX];
+ int ss;
+
+ sig1[0] = intel_uncore_read(gt->uncore, CHV_POWER_SS0_SIG1);
+ sig1[1] = intel_uncore_read(gt->uncore, CHV_POWER_SS1_SIG1);
+ sig2[0] = intel_uncore_read(gt->uncore, CHV_POWER_SS0_SIG2);
+ sig2[1] = intel_uncore_read(gt->uncore, CHV_POWER_SS1_SIG2);
+
+ for (ss = 0; ss < ss_max; ss++) {
+ unsigned int eu_cnt;
+
+ if (sig1[ss] & CHV_SS_PG_ENABLE)
+ /* skip disabled subslice */
+ continue;
+
+ sseu->slice_mask = BIT(0);
+ sseu->subslice_mask[0] |= BIT(ss);
+ eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
+((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
+ sseu->eu_total += eu_cnt;
+ sseu->eu_per_subslice = max_t(unsigned int,
+ sseu->eu_per_subslice, eu_cnt);
+ }
+#undef SS_MAX
+}
+
+static void gen10_sseu_device_status(struct intel_gt *gt,
+struct sseu_dev_info *sseu)
+{
+#define SS_MAX 6
+ const struct intel_runtime_info *info = RUNTIME_INFO(gt->i915);
+ u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
+ int s, ss;
+
+ for (s = 0; s < info->sseu.max_slices; s++) {
+ /*
+* FIXME: Valid SS Mask respects the spec and read
+* only valid bits for those registers, excluding reserved
+* although this seems wrong because it would leave many
+* subslices without ACK.
+*/
+ s_reg[s] = intel_uncore_read(gt->uncore,
+GEN10_SLICE_PGCTL_ACK(s)) &
+ GEN10_PGCTL_VALID_SS_MASK(s);
+ eu_reg[2 * s] = intel_uncore_read(gt->uncore,
+ GEN10_SS01_EU_PGCTL_ACK(s));
+ eu_reg[2 * s + 1] = intel_uncore_read(gt->uncore,
+ GEN10_SS23_EU_PGCTL_ACK(s));
+ }
+
+ eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
+GEN9_PGCTL_SSA_EU19_ACK |
+GEN9_PGCTL_SSA_EU210_ACK |
+GEN9_PGCTL_SSA_EU311_ACK;
+ eu_mask[1] = GEN9_PGCTL_SSB_EU08_ACK |
+GEN9_PGCTL_SSB_EU19_ACK |
+GEN9_PGCTL_SSB_EU210_ACK |
+GEN9_PGCTL_SSB_EU311_ACK;
+
+ for (s = 0; s < info->sseu.max_slices; s++) {
+ if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
+ /* skip disabled slice */
+ continue;
+
+ sseu->slice_mask |= BIT(s);
+ intel_sseu_copy_subslices(>sseu, s, sseu->subslice_mask);
+
+ for (ss = 0; ss < info->sseu.max_subslices; ss++) {
+ unsigned int
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: move files more files into debugfs (rev2)
== Series Details == Series: drm/i915/gt: move files more files into debugfs (rev2) URL : https://patchwork.freedesktop.org/series/74834/ State : failure == Summary == Applying: drm/i915/gt: move files more files into debugfs error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_debugfs.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/gt: move files more files into debugfs When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] 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, >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.
Quoting Francisco Jerez (2020-03-20 02:46:19)
> 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(>overload, 1))
> + intel_gt_pm_active_begin(>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(>overload, 0)) {
> + struct intel_engine_cs *engine =
> + container_of(execlists, typeof(*engine),
> execlists);
> + intel_gt_pm_active_end(>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(>overload, 0))
> +
> intel_gt_pm_active_end(>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(>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(>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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Report context-is-closed prior to pinning
== Series Details == Series: drm/i915/gt: Report context-is-closed prior to pinning URL : https://patchwork.freedesktop.org/series/74916/ State : success == Summary == CI Bug Log - changes from CI_DRM_8163 -> Patchwork_17034 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/index.html Known issues Here are the changes found in Patchwork_17034 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1430] / [i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-cfl-guc/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/fi-cfl-guc/igt@i915_selftest@l...@execlists.html - fi-icl-y: [PASS][3] -> [DMESG-FAIL][4] ([fdo#108569]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-icl-y/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([i915#323]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-cfl-8109u: [FAIL][7] ([fdo#103375]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-cfl-8109u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/fi-cfl-8109u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (41 -> 40) -- Additional (3): fi-skl-6770hq fi-skl-6600u fi-elk-e7500 Missing(4): fi-byt-squawks fi-kbl-7560u fi-ehl-1 fi-bsw-cyan Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8163 -> Patchwork_17034 CI-20190529: 20190529 CI_DRM_8163: 710b3af22d17146897a55f01868d8e2d867895d3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17034: f69264ac723e239058f1019f14540fa472e9896c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f69264ac723e drm/i915/gt: Report context-is-closed prior to pinning == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915/tc/icl: Implement the TC cold exit sequence
Hi "José,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Jos-Roberto-de-Souza/drm-i915-tc-tgl-Implement-TCCOLD-sequences/20200319-080253
base: git://anongit.freedesktop.org/drm-intel for-linux-next
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/gpu/drm/i915/display/intel_tc.c:554 icl_tc_cold_request() error:
uninitialized symbol 'ret'.
#
https://github.com/0day-ci/linux/commit/29f27e6df6ad82b09a3c9ddaf5f51b2fc1647178
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 29f27e6df6ad82b09a3c9ddaf5f51b2fc1647178
vim +/ret +554 drivers/gpu/drm/i915/display/intel_tc.c
29f27e6df6ad82 José Roberto de Souza 2020-03-18 528 static inline int
icl_tc_cold_request(struct intel_digital_port *dig_port,
29f27e6df6ad82 José Roberto de Souza 2020-03-18 529
bool block)
29f27e6df6ad82 José Roberto de Souza 2020-03-18 530 {
29f27e6df6ad82 José Roberto de Souza 2020-03-18 531struct drm_i915_private
*i915 = to_i915(dig_port->base.base.dev);
29f27e6df6ad82 José Roberto de Souza 2020-03-18 532enum
intel_display_power_domain aux_domain;
29f27e6df6ad82 José Roberto de Souza 2020-03-18 533int ret;
29f27e6df6ad82 José Roberto de Souza 2020-03-18 534
29f27e6df6ad82 José Roberto de Souza 2020-03-18 535aux_domain =
intel_aux_ch_to_power_domain(dig_port->aux_ch);
29f27e6df6ad82 José Roberto de Souza 2020-03-18 536
29f27e6df6ad82 José Roberto de Souza 2020-03-18 537if (block) {
29f27e6df6ad82 José Roberto de Souza 2020-03-18 538
dig_port->tc_cold_wakeref =
29f27e6df6ad82 José Roberto de Souza 2020-03-18 539
intel_display_power_get_without_ack(i915, aux_domain);
29f27e6df6ad82 José Roberto de Souza 2020-03-18 540
29f27e6df6ad82 José Roberto de Souza 2020-03-18 541do {
29f27e6df6ad82 José Roberto de Souza 2020-03-18 542ret =
sandybridge_pcode_write_timeout(i915,
29f27e6df6ad82 José Roberto de Souza 2020-03-18 543
ICL_PCODE_EXIT_TCCOLD,
29f27e6df6ad82 José Roberto de Souza 2020-03-18 544
0, 250, 1);
29f27e6df6ad82 José Roberto de Souza 2020-03-18 545
29f27e6df6ad82 José Roberto de Souza 2020-03-18 546} while (ret ==
-EAGAIN);
ret is only initialized on this path
29f27e6df6ad82 José Roberto de Souza 2020-03-18 547} else if
(dig_port->tc_mode == TC_PORT_LEGACY) {
29f27e6df6ad82 José Roberto de Souza 2020-03-18 548
drm_WARN_ON(>drm, !dig_port->tc_lock_wakeref);
29f27e6df6ad82 José Roberto de Souza 2020-03-18 549
intel_display_power_put(i915, aux_domain,
29f27e6df6ad82 José Roberto de Souza 2020-03-18 550
dig_port->tc_cold_wakeref);
29f27e6df6ad82 José Roberto de Souza 2020-03-18 551
dig_port->tc_cold_wakeref = 0;
29f27e6df6ad82 José Roberto de Souza 2020-03-18 552}
29f27e6df6ad82 José Roberto de Souza 2020-03-18 553
29f27e6df6ad82 José Roberto de Souza 2020-03-18 @554return ret;
29f27e6df6ad82 José Roberto de Souza 2020-03-18 555 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: move files more files into debugfs
Quoting Tvrtko Ursulin (2020-03-20 12:01:14) > > > On 20/03/2020 11:45, Andi Shyti wrote: > > Hi Chris, > > > > On Fri, Mar 20, 2020 at 11:11:46AM +, Chris Wilson wrote: > >> Quoting Andi Shyti (2020-03-20 03:49:01) > >>> From: Andi Shyti > >>> > >>> The following interfaces: > >>> > >>> i915_wedged > >>> i915_forcewake_user > >>> i915_gem_interrupt > >>> i915_sseu_status > >>> > >>> are dependent on gt values. Put them inside gt/ and drop the > >>> "i915_" prefix name. This would be the new structure: > >>> > >>>gt > >>>| > >>>+-- forcewake_user > >>>| > >>>+-- interrupt_info_show > >> > >> Please tell me you didn't actually include _show :) > > > > You know me, everything can happen! > > I did overlook indeed, but I had to check if I actually did > > include _show. Thanks for spotting it. > > > >>>| > >>>+-- sseu_status > >>>| > >>>+-- wedge > >> > >> The world will rejoice when it's stopped being called wedged. > >> Well Mika will at any rate. > > > > well, I did keep the original name. > > > >> 'echo rcs0 > reset' maybe? Yeah. Wait, but rcs0 is uabi name, so top > >> level. > >> > >> Oh well, I definitely do not think copying a mistake is a good idea. > > > > OK, I'll call it reset > > Wedge is wedge and reset is reset, or is it not? i915_wedged is reset :) Hysterical raisons. But my main question is what do you feed into a gt/reset? Currently we have a random bitmask to reset a group of engines. Should we just go and put reset into sysfs/engine/ ? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.
v2: Tweak the balance to avoid over submitting lite-restores
Signed-off-by: Chris Wilson
Cc: Francisco Jerez
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 40 +
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f09dd87324b9..0d9c6ea4adaa 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2884,29 +2884,47 @@ static void queue_request(struct intel_engine_cs
*engine,
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
-static void __submit_queue_imm(struct intel_engine_cs *engine)
+static bool pending_csb(const struct intel_engine_execlists *el)
{
- struct intel_engine_execlists * const execlists = >execlists;
-
- if (reset_in_progress(execlists))
- return; /* defer until we restart the engine following reset */
-
- if (execlists->tasklet.func == execlists_submission_tasklet)
- __execlists_submission_tasklet(engine);
- else
- tasklet_hi_schedule(>tasklet);
+ return READ_ONCE(*el->csb_write) != READ_ONCE(el->csb_head);
}
static void submit_queue(struct intel_engine_cs *engine,
const struct i915_request *rq)
{
struct intel_engine_execlists *execlists = >execlists;
+ struct i915_request *inflight;
if (rq_prio(rq) <= execlists->queue_priority_hint)
return;
+ if (reset_in_progress(execlists))
+ return; /* defer until we restart the engine following reset */
+
+ /* Hopefully we clear execlists->pending[] to let us through */
+ if (execlists->pending[0] && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ }
+
+ /*
+* Suppress immediate lite-restores, leave that to the tasklet.
+*
+* However, we leave the queue_priority_hint unset so that if we do
+* submit a second context, we push that into ELSP[1] immediately.
+*/
+ inflight = execlists_active(>execlists);
+ if (inflight && inflight->context == rq->context)
+ return;
+
execlists->queue_priority_hint = rq_prio(rq);
- __submit_queue_imm(engine);
+ __execlists_submission_tasklet(engine);
+
+ /* Try and pull an interrupt-bh queued on another CPU to here */
+ if (pending_csb(execlists) && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ }
}
static bool ancestor_on_hold(const struct intel_engine_cs *engine,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v19 4/8] drm/i915: Refactor intel_can_enable_sagv
On Wed, Mar 11, 2020 at 06:31:30PM +0200, Ville Syrjälä wrote: > On Mon, Mar 09, 2020 at 06:12:00PM +0200, Stanislav Lisovskiy wrote: > > Currently intel_can_enable_sagv function contains > > a mix of workarounds for different platforms > > some of them are not valid for gens >= 11 already, > > so lets split it into separate functions. > > > > v2: > > - Rework watermark calculation algorithm to > > attempt to calculate Level 0 watermark > > with added sagv block time latency and > > check if it fits in DBuf in order to > > determine if SAGV can be enabled already > > at this stage, just as BSpec 49325 states. > > if that fails rollback to usual Level 0 > > latency and disable SAGV. > > - Remove unneeded tabs(James Ausmus) > > > > v3: Rebased the patch > > > > v4: - Added back interlaced check for Gen12 and > > added separate function for TGL SAGV check > > (thanks to James Ausmus for spotting) > > - Removed unneeded gen check > > - Extracted Gen12 SAGV decision making code > > to a separate function from skl_compute_wm > > > > v5: - Added SAGV global state to dev_priv, because > > we need to track all pipes, not only those > > in atomic state. Each pipe has now correspondent > > bit mask reflecting, whether it can tolerate > > SAGV or not(thanks to Ville Syrjala for suggestions). > > - Now using active flag instead of enable in crc > > usage check. > > > > v6: - Fixed rebase conflicts > > > > v7: - kms_cursor_legacy seems to get broken because of multiple memcpy > > calls when copying level 0 water marks for enabled SAGV, to > > fix this now simply using that field right away, without copying, > > for that introduced a new wm_level accessor which decides which > > wm_level to return based on SAGV state. > > > > v8: - Protect crtc_sagv_mask same way as we do for other global state > > changes: i.e check if changes are needed, then grab all crtc locks > > to serialize the changes(Ville Syrjälä) > > - Add crtc_sagv_mask caching in order to avoid needless recalculations > > (Matthew Roper) > > - Put back Gen12 SAGV switch in order to get it enabled in separate > > patch(Matthew Roper) > > - Rename *_set_sagv_mask to *_compute_sagv_mask(Matthew Roper) > > - Check if there are no active pipes in intel_can_enable_sagv > > instead of platform specific functions(Matthew Roper), same > > for intel_has_sagv check. > > > > v9 - Switched to u8 for crtc_sagv_mask(Ville Syrjälä) > > - crtc_sagv_mask now is pipe_sagv_mask(Ville Syrjälä) > > - Extracted sagv checking logic from skl/icl/tgl_compute_sagv_mask > > - Extracted skl_plane_wm_level function and passing latency to > > separate patches(Ville Syrjälä) > > - Removed part of unneeded copy-paste from tgl_check_pipe_fits_sagv_wm > > (Ville Syrjälä) > > - Now using simple assignment for sagv_wm0 as it contains only > > pod types and no pointers(Ville Syrjälä) > > - Fixed intel_can_enable_sagv not to do double duty, now it only > > check SAGV bits by ANDing those between local and global state. > > The SAGV masks are now computed after watermarks are available, > > in order to be able to figure out if ddb ranges are fitting nicely. > > (Ville Syrjälä) > > - Now having uv_sagv_wm0 and sagv_wm0, otherwise we have wrong logic > > when using skl_plane_wm_level accessor, as we had previously for > > Gen11+ color plane and regular wm levels, so probably both > > has to be recalculated with additional SAGV block time for Level 0. > > > > v10: - Starting to use new global state for storing pipe_sagv_mask > > > > v11: - Fixed rebase conflict with recent drm-tip > > - Check if we really need to recalculate SAGV mask, otherwise > >bail out without making any changes. > > - Use cached SAGV result, instead of recalculating it everytime, > >if bw_state hasn't changed. > > > > v12: - Removed WARN from intel_can_enable_sagv, in some of the commits > >if we don't recalculated watermarks, bw_state is not recalculated, > >thus leading to SAGV state not recalculated by the commit state, > >which is still calling intel_can_enable_sagv function. Fix that > >by just analyzing the current global bw_state object - because > >we simply have no other objects related to that. > > > > v13: - Rebased, fixed warnings regarding long lines > > - Changed function call sites from intel_atomic_bw* to > >intel_wb_* as was suggested.(Jani Nikula) > > - Taken ddb_state_changed and bw_state_changed into use. > > > > v14: - total_affected_planes is no longer needed to check for ddb changes, > >just as active_pipe_changes. > > > > v15: - Fixed stupid mistake with uninitialized crtc in > >skl_compute_sagv_mask. > > > > v16: -
Re: [Intel-gfx] [CI 2/2] drm/i915/gt: Cancel a hung context if already closed
Chris Wilson writes:
> 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
Reviewed-by: Mika Kuoppala
> ---
> 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(>ref))
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: move files more files into debugfs
Hi Chris, On Fri, Mar 20, 2020 at 11:11:46AM +, Chris Wilson wrote: > Quoting Andi Shyti (2020-03-20 03:49:01) > > From: Andi Shyti > > > > The following interfaces: > > > > i915_wedged > > i915_forcewake_user > > i915_gem_interrupt > > i915_sseu_status > > > > are dependent on gt values. Put them inside gt/ and drop the > > "i915_" prefix name. This would be the new structure: > > > > gt > > | > > +-- forcewake_user > > | > > +-- interrupt_info_show > > Please tell me you didn't actually include _show :) You know me, everything can happen! I did overlook indeed, but I had to check if I actually did include _show. Thanks for spotting it. > > | > > +-- sseu_status > > | > > +-- wedge > > The world will rejoice when it's stopped being called wedged. > Well Mika will at any rate. well, I did keep the original name. > 'echo rcs0 > reset' maybe? Yeah. Wait, but rcs0 is uabi name, so top > level. > > Oh well, I definitely do not think copying a mistake is a good idea. OK, I'll call it reset Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: move files more files into debugfs
On 20/03/2020 11:45, Andi Shyti wrote: Hi Chris, On Fri, Mar 20, 2020 at 11:11:46AM +, Chris Wilson wrote: Quoting Andi Shyti (2020-03-20 03:49:01) From: Andi Shyti The following interfaces: i915_wedged i915_forcewake_user i915_gem_interrupt i915_sseu_status are dependent on gt values. Put them inside gt/ and drop the "i915_" prefix name. This would be the new structure: gt | +-- forcewake_user | +-- interrupt_info_show Please tell me you didn't actually include _show :) You know me, everything can happen! I did overlook indeed, but I had to check if I actually did include _show. Thanks for spotting it. | +-- sseu_status | +-- wedge The world will rejoice when it's stopped being called wedged. Well Mika will at any rate. well, I did keep the original name. 'echo rcs0 > reset' maybe? Yeah. Wait, but rcs0 is uabi name, so top level. Oh well, I definitely do not think copying a mistake is a good idea. OK, I'll call it reset Wedge is wedge and reset is reset, or is it not? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Immediately execute the fenced work
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we still prefer to offload the task to another cpu,
especially if we plan on executing many such tasks in parallel for this
client.)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 -
drivers/gpu/drm/i915/i915_sw_fence_work.h | 12
drivers/gpu/drm/i915/i915_vma.c| 2 +-
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 36d069504836..c1179c00bc61 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1784,7 +1784,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
dma_resv_add_excl_fence(shadow->resv, >base.dma);
dma_resv_unlock(shadow->resv);
- dma_fence_work_commit(>base);
+ dma_fence_work_commit_imm(>base);
return 0;
err_batch_unlock:
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 997b2998f1f2..a3a81bb8f2c3 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -38,7 +38,10 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
if (!f->dma.error) {
dma_fence_get(>dma);
- queue_work(system_unbound_wq, >work);
+ if (test_bit(DMA_FENCE_WORK_IMM, >dma.flags))
+ fence_work(>work);
+ else
+ queue_work(system_unbound_wq, >work);
} else {
fence_complete(f);
}
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index 3a22b287e201..90a371e0d183 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -32,6 +32,10 @@ struct dma_fence_work {
const struct dma_fence_work_ops *ops;
};
+enum {
+ DMA_FENCE_WORK_IMM = DMA_FENCE_FLAG_USER_BITS,
+};
+
void dma_fence_work_init(struct dma_fence_work *f,
const struct dma_fence_work_ops *ops);
int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence *signal);
@@ -41,4 +45,12 @@ static inline void dma_fence_work_commit(struct
dma_fence_work *f)
i915_sw_fence_commit(>chain);
}
+static inline void dma_fence_work_commit_imm(struct dma_fence_work *f)
+{
+ if (atomic_read(>chain.pending) <= 1)
+ set_bit(DMA_FENCE_WORK_IMM, >dma.flags);
+
+ dma_fence_work_commit(f);
+}
+
#endif /* I915_SW_FENCE_WORK_H */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 5b3efb43a8ef..6dd242c09daf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -980,7 +980,7 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
mutex_unlock(>vm->mutex);
err_fence:
if (work)
- dma_fence_work_commit(>base);
+ dma_fence_work_commit_imm(>base);
if (wakeref)
intel_runtime_pm_put(>vm->i915->runtime_pm, wakeref);
err_pages:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
== Series Details == Series: drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission URL : https://patchwork.freedesktop.org/series/74914/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8163_full -> Patchwork_17032_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17032_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17032_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_17032_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-tglb7/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-tglb1/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_17032_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb2/igt@gem_b...@busy-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-iclb7/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@close-replace-race: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927] / [i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-apl6/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-apl8/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_persistence@engines-mixed-process@vecs0: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#679]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-skl5/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110841]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_parallel@vcs1-contexts: - shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#529]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-tglb5/igt@gem_exec_paral...@vcs1-contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-tglb8/igt@gem_exec_paral...@vcs1-contexts.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276] / [i915#677]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb4/igt@gem_exec_sched...@implicit-read-write-bsd1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([i915#677]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb5/igt@gem_exec_sched...@pi-shared-iova-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-iclb1/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@pi-shared-iova-vebox: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#859]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-glk9/igt@gem_exec_sched...@pi-shared-iova-vebox.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-glk3/igt@gem_exec_sched...@pi-shared-iova-vebox.html * igt@gem_exec_schedule@preempt-hang-bsd: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#112146]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb5/igt@gem_exec_sched...@preempt-hang-bsd.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-iclb1/igt@gem_exec_sched...@preempt-hang-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-apl8/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/shard-apl1/igt@gem_pp...@flink-and-close-vma-leak.html *
[Intel-gfx] [PATCH 4/4] 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 c1179c00bc61..876fc2e124b9 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 = >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(>relocs);
- INIT_LIST_HEAD(>unbound);
+ i915_vma_get(vma);
+ if (!atomic_fetch_inc(>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(>mutex)) {
+ err = -ENOENT;
+ if (likely(!i915_gem_context_is_closed(ctx)))
+ err = radix_tree_insert(>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(>file->object_idr, handle) == obj) {
+ list_add(>obj_link, >lut_list);
+ } else {
+ radix_tree_delete(>handles_vma, handle);
+ err = -ENOENT;
+ }
+ i915_gem_object_unlock(obj);
+ }
+ mutex_unlock(>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(>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(>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);
- if (unlikely(err)) {
-
[Intel-gfx] [PATCH 1/4] drm/i915/gt: Report context-is-closed prior to pinning
Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index aea992e46c42..7132bf616cc4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -97,8 +97,6 @@ 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, >flags))) {
err = intel_context_alloc_state(ce);
if (err)
@@ -114,6 +112,11 @@ int __intel_context_do_pin(struct intel_context *ce)
goto out_release;
}
+ if (unlikely(intel_context_is_closed(ce))) {
+ err = -ENOENT;
+ goto out_release;
+ }
+
if (likely(!atomic_add_unless(>pin_count, 1, 0))) {
err = intel_context_active_acquire(ce);
if (unlikely(err))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.
v2: Tweak the balance to avoid over submitting lite-restores
Signed-off-by: Chris Wilson
Cc: Francisco Jerez
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 40 +
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f09dd87324b9..0d9c6ea4adaa 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2884,29 +2884,47 @@ static void queue_request(struct intel_engine_cs
*engine,
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
-static void __submit_queue_imm(struct intel_engine_cs *engine)
+static bool pending_csb(const struct intel_engine_execlists *el)
{
- struct intel_engine_execlists * const execlists = >execlists;
-
- if (reset_in_progress(execlists))
- return; /* defer until we restart the engine following reset */
-
- if (execlists->tasklet.func == execlists_submission_tasklet)
- __execlists_submission_tasklet(engine);
- else
- tasklet_hi_schedule(>tasklet);
+ return READ_ONCE(*el->csb_write) != READ_ONCE(el->csb_head);
}
static void submit_queue(struct intel_engine_cs *engine,
const struct i915_request *rq)
{
struct intel_engine_execlists *execlists = >execlists;
+ struct i915_request *inflight;
if (rq_prio(rq) <= execlists->queue_priority_hint)
return;
+ if (reset_in_progress(execlists))
+ return; /* defer until we restart the engine following reset */
+
+ /* Hopefully we clear execlists->pending[] to let us through */
+ if (execlists->pending[0] && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ }
+
+ /*
+* Suppress immediate lite-restores, leave that to the tasklet.
+*
+* However, we leave the queue_priority_hint unset so that if we do
+* submit a second context, we push that into ELSP[1] immediately.
+*/
+ inflight = execlists_active(>execlists);
+ if (inflight && inflight->context == rq->context)
+ return;
+
execlists->queue_priority_hint = rq_prio(rq);
- __submit_queue_imm(engine);
+ __execlists_submission_tasklet(engine);
+
+ /* Try and pull an interrupt-bh queued on another CPU to here */
+ if (pending_csb(execlists) && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ }
}
static bool ancestor_on_hold(const struct intel_engine_cs *engine,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Immediately execute the fenced work
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we still prefer to offload the task to another cpu,
especially if we plan on executing many such tasks in parallel for this
client.)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 -
drivers/gpu/drm/i915/i915_sw_fence_work.h | 12
drivers/gpu/drm/i915/i915_vma.c| 2 +-
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 36d069504836..c1179c00bc61 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1784,7 +1784,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
dma_resv_add_excl_fence(shadow->resv, >base.dma);
dma_resv_unlock(shadow->resv);
- dma_fence_work_commit(>base);
+ dma_fence_work_commit_imm(>base);
return 0;
err_batch_unlock:
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 997b2998f1f2..a3a81bb8f2c3 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -38,7 +38,10 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
if (!f->dma.error) {
dma_fence_get(>dma);
- queue_work(system_unbound_wq, >work);
+ if (test_bit(DMA_FENCE_WORK_IMM, >dma.flags))
+ fence_work(>work);
+ else
+ queue_work(system_unbound_wq, >work);
} else {
fence_complete(f);
}
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index 3a22b287e201..0719d661dc9c 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -32,6 +32,10 @@ struct dma_fence_work {
const struct dma_fence_work_ops *ops;
};
+enum {
+ DMA_FENCE_WORK_IMM = DMA_FENCE_FLAG_USER_BITS,
+};
+
void dma_fence_work_init(struct dma_fence_work *f,
const struct dma_fence_work_ops *ops);
int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence *signal);
@@ -41,4 +45,12 @@ static inline void dma_fence_work_commit(struct
dma_fence_work *f)
i915_sw_fence_commit(>chain);
}
+static inline void dma_fence_work_commit_imm(struct dma_fence_work *f)
+{
+ if (atomic_read(>chain.pending) <= 1)
+ __set_bit(DMA_FENCE_WORK_IMM, >dma.flags);
+
+ dma_fence_work_commit(f);
+}
+
#endif /* I915_SW_FENCE_WORK_H */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 5b3efb43a8ef..6dd242c09daf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -980,7 +980,7 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
mutex_unlock(>vm->mutex);
err_fence:
if (work)
- dma_fence_work_commit(>base);
+ dma_fence_work_commit_imm(>base);
if (wakeref)
intel_runtime_pm_put(>vm->i915->runtime_pm, wakeref);
err_pages:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
Quoting Tvrtko Ursulin (2020-03-20 13:47:39)
>
> On 20/03/2020 13:01, 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 c1179c00bc61..876fc2e124b9 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 = >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(>relocs);
> > - INIT_LIST_HEAD(>unbound);
> > + i915_vma_get(vma);
> > + if (!atomic_fetch_inc(>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(>mutex)) {
> > + err = -ENOENT;
> > + if (likely(!i915_gem_context_is_closed(ctx)))
> > + err = radix_tree_insert(>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);
>
> Does this fit into Maarten's rework - nesting of object_lock under
> ctx->mutex I mean?
This is the current lock nesting, and should generally remain so. One
context will peek at multiple objects and we should be holding an object
lock to peek at a context.
As for the rework, it holds a bunch of exclusive locks far beyond their
scope causing an even worse BKL, and that will have to be reworked.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: move files more files into debugfs
Quoting Andi Shyti (2020-03-20 03:49:01) > From: Andi Shyti > > The following interfaces: > > i915_wedged > i915_forcewake_user > i915_gem_interrupt > i915_sseu_status > > are dependent on gt values. Put them inside gt/ and drop the > "i915_" prefix name. This would be the new structure: > > gt > | > +-- forcewake_user > | > +-- interrupt_info_show Please tell me you didn't actually include _show :) > | > +-- sseu_status > | > +-- wedge The world will rejoice when it's stopped being called wedged. Well Mika will at any rate. 'echo rcs0 > reset' maybe? Yeah. Wait, but rcs0 is uabi name, so top level. Oh well, I definitely do not think copying a mistake is a good idea. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
== Series Details == Series: drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission URL : https://patchwork.freedesktop.org/series/74914/ State : success == Summary == CI Bug Log - changes from CI_DRM_8163 -> Patchwork_17032 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/index.html Known issues Here are the changes found in Patchwork_17032 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-icl-y: [PASS][1] -> [INCOMPLETE][2] ([i915#140]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-icl-y/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-skl-lmem:[PASS][3] -> [INCOMPLETE][4] ([i915#424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-cfl-8109u: [FAIL][5] ([fdo#103375]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-cfl-8109u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/fi-cfl-8109u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#140]: https://gitlab.freedesktop.org/drm/intel/issues/140 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 Participating hosts (41 -> 37) -- Additional (3): fi-skl-6770hq fi-skl-6600u fi-elk-e7500 Missing(7): fi-kbl-7560u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ilk-650 fi-blb-e6850 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8163 -> Patchwork_17032 CI-20190529: 20190529 CI_DRM_8163: 710b3af22d17146897a55f01868d8e2d867895d3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17032: d22b57277d7c1f4887fed185e7ce1054fcec9f23 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d22b57277d7c drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17032/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 05/18] video/hdmi: Add Unpack only function for DRM infoframe
On Fri, 20 Mar 2020, Jani Nikula wrote:
> On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
>> It adds an unpack only function for DRM infoframe for dynamic range and
>> mastering infoframe readout.
>> It unpacks the information data block contained in the binary buffer into
>> a structured frame of the HDMI Dynamic Range and Mastering (DRM)
>> information frame.
>>
>> In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
>> a checksum.
>>
>> It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
>> DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
>> (DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
>> But DP SDP header and payload structure are different from HDMI DRM
>> Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
>> a verifying checksum.
>>
>> Signed-off-by: Gwan-gyeong Mun
>> Reviewed-by: Uma Shankar
>
> Bartlomiej, can I have your ack for merging this via drm-intel along
> with the rest of the series, please?
Or Hans or Laurent, from v4l/video point of view.
Thanks,
Jani.
>
> BR,
> Jani.
>
>
>> ---
>> drivers/video/hdmi.c | 58 +++-
>> include/linux/hdmi.h | 2 ++
>> 2 files changed, 43 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>> index 9c82e2a0a411..9818836d82b7 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1775,20 +1775,18 @@ hdmi_vendor_any_infoframe_unpack(union
>> hdmi_vendor_any_infoframe *frame,
>> }
>>
>> /**
>> - * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
>> infoframe
>> + * hdmi_drm_infoframe_unpack_only() - unpack binary buffer to a HDMI DRM
>> infoframe
>> * @frame: HDMI DRM infoframe
>> * @buffer: source buffer
>> * @size: size of buffer
>> *
>> - * Unpacks the information contained in binary @buffer into a structured
>> + * Unpacks the information data block contained in binary @buffer into a
>> structured
>> * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
>> - * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
>> - * specification.
>> *
>> * Returns 0 on success or a negative error code on failure.
>> */
>> -static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
>> - const void *buffer, size_t size)
>> +int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
>> + const void *buffer, size_t size)
>> {
>> const u8 *ptr = buffer;
>> const u8 *temp;
>> @@ -1797,23 +1795,13 @@ static int hdmi_drm_infoframe_unpack(struct
>> hdmi_drm_infoframe *frame,
>> int ret;
>> int i;
>>
>> -if (size < HDMI_INFOFRAME_SIZE(DRM))
>> -return -EINVAL;
>> -
>> -if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
>> -ptr[1] != 1 ||
>> -ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
>> -return -EINVAL;
>> -
>> -if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
>> +if (size < HDMI_DRM_INFOFRAME_SIZE)
>> return -EINVAL;
>>
>> ret = hdmi_drm_infoframe_init(frame);
>> if (ret)
>> return ret;
>>
>> -ptr += HDMI_INFOFRAME_HEADER_SIZE;
>> -
>> frame->eotf = ptr[0] & 0x7;
>> frame->metadata_type = ptr[1] & 0x7;
>>
>> @@ -1837,6 +1825,42 @@ static int hdmi_drm_infoframe_unpack(struct
>> hdmi_drm_infoframe *frame,
>>
>> return 0;
>> }
>> +EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
>> +
>> +/**
>> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
>> infoframe
>> + * @frame: HDMI DRM infoframe
>> + * @buffer: source buffer
>> + * @size: size of buffer
>> + *
>> + * Unpacks the information contained in binary @buffer into a structured
>> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
>> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
>> + * specification.
>> + *
>> + * Returns 0 on success or a negative error code on failure.
>> + */
>> +static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
>> + const void *buffer, size_t size)
>> +{
>> +const u8 *ptr = buffer;
>> +int ret;
>> +
>> +if (size < HDMI_INFOFRAME_SIZE(DRM))
>> +return -EINVAL;
>> +
>> +if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
>> +ptr[1] != 1 ||
>> +ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
>> +return -EINVAL;
>> +
>> +if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
>> +return -EINVAL;
>> +
>> +ret = hdmi_drm_infoframe_unpack_only(frame, ptr +
>> HDMI_INFOFRAME_HEADER_SIZE,
>> + size - HDMI_INFOFRAME_HEADER_SIZE);
>> +return ret;
>> +}
>>
>> /**
>> * hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
>> diff --git a/include/linux/hdmi.h
Re: [Intel-gfx] [PATCH v7 05/18] video/hdmi: Add Unpack only function for DRM infoframe
Hi Jani,
On Fri, Mar 20, 2020 at 01:32:17PM +0200, Jani Nikula wrote:
> On Fri, 20 Mar 2020, Jani Nikula wrote:
> > On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
> >> It adds an unpack only function for DRM infoframe for dynamic range and
> >> mastering infoframe readout.
> >> It unpacks the information data block contained in the binary buffer into
> >> a structured frame of the HDMI Dynamic Range and Mastering (DRM)
> >> information frame.
> >>
> >> In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
> >> a checksum.
> >>
> >> It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
> >> DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
> >> (DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
> >> But DP SDP header and payload structure are different from HDMI DRM
> >> Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
> >> a verifying checksum.
> >>
> >> Signed-off-by: Gwan-gyeong Mun
> >> Reviewed-by: Uma Shankar
> >
> > Bartlomiej, can I have your ack for merging this via drm-intel along
> > with the rest of the series, please?
>
> Or Hans or Laurent, from v4l/video point of view.
I'm no expert on InfoFrame, I'll only comment on the API below.
> >> ---
> >> drivers/video/hdmi.c | 58 +++-
> >> include/linux/hdmi.h | 2 ++
> >> 2 files changed, 43 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> >> index 9c82e2a0a411..9818836d82b7 100644
> >> --- a/drivers/video/hdmi.c
> >> +++ b/drivers/video/hdmi.c
> >> @@ -1775,20 +1775,18 @@ hdmi_vendor_any_infoframe_unpack(union
> >> hdmi_vendor_any_infoframe *frame,
> >> }
> >>
> >> /**
> >> - * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
> >> infoframe
> >> + * hdmi_drm_infoframe_unpack_only() - unpack binary buffer to a HDMI DRM
> >> infoframe
> >> * @frame: HDMI DRM infoframe
> >> * @buffer: source buffer
> >> * @size: size of buffer
> >> *
> >> - * Unpacks the information contained in binary @buffer into a structured
> >> + * Unpacks the information data block contained in binary @buffer into a
> >> structured
Line wrap please.
This needs to be clarified to explain exactly what the buffer points to.
Also, as this is applicable to DP too, shouldn't we drop the hdmi_
prefix ? Is there another prefix that could be used for functions that
are application to infoframe handling shared by different display
interfaces ? A bit of refactoring would help making all this clear.
> >> * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> >> - * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> >> - * specification.
> >> *
> >> * Returns 0 on success or a negative error code on failure.
> >> */
> >> -static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
> >> - const void *buffer, size_t size)
> >> +int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
> >> + const void *buffer, size_t size)
> >> {
> >>const u8 *ptr = buffer;
> >>const u8 *temp;
> >> @@ -1797,23 +1795,13 @@ static int hdmi_drm_infoframe_unpack(struct
> >> hdmi_drm_infoframe *frame,
> >>int ret;
> >>int i;
> >>
> >> - if (size < HDMI_INFOFRAME_SIZE(DRM))
> >> - return -EINVAL;
> >> -
> >> - if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> >> - ptr[1] != 1 ||
> >> - ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> >> - return -EINVAL;
> >> -
> >> - if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
> >> + if (size < HDMI_DRM_INFOFRAME_SIZE)
> >>return -EINVAL;
> >>
> >>ret = hdmi_drm_infoframe_init(frame);
> >>if (ret)
> >>return ret;
> >>
> >> - ptr += HDMI_INFOFRAME_HEADER_SIZE;
> >> -
> >>frame->eotf = ptr[0] & 0x7;
> >>frame->metadata_type = ptr[1] & 0x7;
> >>
> >> @@ -1837,6 +1825,42 @@ static int hdmi_drm_infoframe_unpack(struct
> >> hdmi_drm_infoframe *frame,
> >>
> >>return 0;
> >> }
> >> +EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
> >> +
> >> +/**
> >> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM
> >> infoframe
> >> + * @frame: HDMI DRM infoframe
> >> + * @buffer: source buffer
> >> + * @size: size of buffer
> >> + *
> >> + * Unpacks the information contained in binary @buffer into a structured
Same here. The difference between the two functions is "information data
block" vs. "information", it's very unclear to the reader without
looking at either the commit message or the implementation.
> >> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> >> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> >> + * specification.
> >> + *
> >> + * Returns 0 on success or a negative error code on failure.
> >> + */
> >> +static int
[Intel-gfx] [PATCH] drm/i915: Immediately execute the fenced work
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we still prefer to offload the task to another cpu,
especially if we plan on executing many such tasks in parallel for this
client.)
Signed-off-by: Chris Wilson
---
We know we have exclusive access to the fence (if pending <= 1) so we
can just use __set_bit.
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence_work.c | 5 -
drivers/gpu/drm/i915/i915_sw_fence_work.h | 12
drivers/gpu/drm/i915/i915_vma.c| 2 +-
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 36d069504836..c1179c00bc61 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1784,7 +1784,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
dma_resv_add_excl_fence(shadow->resv, >base.dma);
dma_resv_unlock(shadow->resv);
- dma_fence_work_commit(>base);
+ dma_fence_work_commit_imm(>base);
return 0;
err_batch_unlock:
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 997b2998f1f2..a3a81bb8f2c3 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -38,7 +38,10 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
if (!f->dma.error) {
dma_fence_get(>dma);
- queue_work(system_unbound_wq, >work);
+ if (test_bit(DMA_FENCE_WORK_IMM, >dma.flags))
+ fence_work(>work);
+ else
+ queue_work(system_unbound_wq, >work);
} else {
fence_complete(f);
}
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index 3a22b287e201..0719d661dc9c 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -32,6 +32,10 @@ struct dma_fence_work {
const struct dma_fence_work_ops *ops;
};
+enum {
+ DMA_FENCE_WORK_IMM = DMA_FENCE_FLAG_USER_BITS,
+};
+
void dma_fence_work_init(struct dma_fence_work *f,
const struct dma_fence_work_ops *ops);
int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence *signal);
@@ -41,4 +45,12 @@ static inline void dma_fence_work_commit(struct
dma_fence_work *f)
i915_sw_fence_commit(>chain);
}
+static inline void dma_fence_work_commit_imm(struct dma_fence_work *f)
+{
+ if (atomic_read(>chain.pending) <= 1)
+ __set_bit(DMA_FENCE_WORK_IMM, >dma.flags);
+
+ dma_fence_work_commit(f);
+}
+
#endif /* I915_SW_FENCE_WORK_H */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 5b3efb43a8ef..6dd242c09daf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -980,7 +980,7 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
mutex_unlock(>vm->mutex);
err_fence:
if (work)
- dma_fence_work_commit(>base);
+ dma_fence_work_commit_imm(>base);
if (wakeref)
intel_runtime_pm_put(>vm->i915->runtime_pm, wakeref);
err_pages:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] iommu/vt-d: Remove IOVA handling code from non-dma_ops path
Could we merge patch 1-3 from this series? it just cleans up weird
code and merging these patches will cover some of the work needed to
move the intel iommu driver to the dma-iommu api in the future.
On Sat, 21 Dec 2019 at 07:04, Tom Murphy wrote:
>
> Remove all IOVA handling code from the non-dma_ops path in the intel
> iommu driver.
>
> There's no need for the non-dma_ops path to keep track of IOVAs. The
> whole point of the non-dma_ops path is that it allows the IOVAs to be
> handled separately. The IOVA handling code removed in this patch is
> pointless.
>
> Signed-off-by: Tom Murphy
> ---
> drivers/iommu/intel-iommu.c | 89 ++---
> 1 file changed, 33 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 64b1a9793daa..8d72ea0fb843 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1908,7 +1908,8 @@ static void domain_exit(struct dmar_domain *domain)
> domain_remove_dev_info(domain);
>
> /* destroy iovas */
> - put_iova_domain(>iovad);
> + if (domain->domain.type == IOMMU_DOMAIN_DMA)
> + put_iova_domain(>iovad);
>
> if (domain->pgd) {
> struct page *freelist;
> @@ -2671,19 +2672,9 @@ static struct dmar_domain *set_domain_for_dev(struct
> device *dev,
> }
>
> static int iommu_domain_identity_map(struct dmar_domain *domain,
> -unsigned long long start,
> -unsigned long long end)
> +unsigned long first_vpfn,
> +unsigned long last_vpfn)
> {
> - unsigned long first_vpfn = start >> VTD_PAGE_SHIFT;
> - unsigned long last_vpfn = end >> VTD_PAGE_SHIFT;
> -
> - if (!reserve_iova(>iovad, dma_to_mm_pfn(first_vpfn),
> - dma_to_mm_pfn(last_vpfn))) {
> - pr_err("Reserving iova failed\n");
> - return -ENOMEM;
> - }
> -
> - pr_debug("Mapping reserved region %llx-%llx\n", start, end);
> /*
> * RMRR range might have overlap with physical memory range,
> * clear it first
> @@ -2760,7 +2751,8 @@ static int __init si_domain_init(int hw)
>
> for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
> ret = iommu_domain_identity_map(si_domain,
> - PFN_PHYS(start_pfn),
> PFN_PHYS(end_pfn));
> + mm_to_dma_pfn(start_pfn),
> + mm_to_dma_pfn(end_pfn));
> if (ret)
> return ret;
> }
> @@ -4593,58 +4585,37 @@ static int intel_iommu_memory_notifier(struct
> notifier_block *nb,
>unsigned long val, void *v)
> {
> struct memory_notify *mhp = v;
> - unsigned long long start, end;
> - unsigned long start_vpfn, last_vpfn;
> + unsigned long start_vpfn = mm_to_dma_pfn(mhp->start_pfn);
> + unsigned long last_vpfn = mm_to_dma_pfn(mhp->start_pfn +
> + mhp->nr_pages - 1);
>
> switch (val) {
> case MEM_GOING_ONLINE:
> - start = mhp->start_pfn << PAGE_SHIFT;
> - end = ((mhp->start_pfn + mhp->nr_pages) << PAGE_SHIFT) - 1;
> - if (iommu_domain_identity_map(si_domain, start, end)) {
> - pr_warn("Failed to build identity map for
> [%llx-%llx]\n",
> - start, end);
> + if (iommu_domain_identity_map(si_domain, start_vpfn,
> + last_vpfn)) {
> + pr_warn("Failed to build identity map for
> [%lx-%lx]\n",
> + start_vpfn, last_vpfn);
> return NOTIFY_BAD;
> }
> break;
>
> case MEM_OFFLINE:
> case MEM_CANCEL_ONLINE:
> - start_vpfn = mm_to_dma_pfn(mhp->start_pfn);
> - last_vpfn = mm_to_dma_pfn(mhp->start_pfn + mhp->nr_pages - 1);
> - while (start_vpfn <= last_vpfn) {
> - struct iova *iova;
> + {
> struct dmar_drhd_unit *drhd;
> struct intel_iommu *iommu;
> struct page *freelist;
>
> - iova = find_iova(_domain->iovad, start_vpfn);
> - if (iova == NULL) {
> - pr_debug("Failed get IOVA for PFN %lx\n",
> -start_vpfn);
> - break;
> - }
> -
> - iova = split_and_remove_iova(_domain->iovad, iova,
> -start_vpfn, last_vpfn);
> - if
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
Any news on this? Is there anyone who wants to try and fix this possible bug? On Mon, 23 Dec 2019 at 03:41, Jani Nikula wrote: > > On Mon, 23 Dec 2019, Robin Murphy wrote: > > On 2019-12-23 10:37 am, Jani Nikula wrote: > >> On Sat, 21 Dec 2019, Tom Murphy wrote: > >>> This patchset converts the intel iommu driver to the dma-iommu api. > >>> > >>> While converting the driver I exposed a bug in the intel i915 driver > >>> which causes a huge amount of artifacts on the screen of my > >>> laptop. You can see a picture of it here: > >>> https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg > >>> > >>> This issue is most likely in the i915 driver and is most likely caused > >>> by the driver not respecting the return value of the > >>> dma_map_ops::map_sg function. You can see the driver ignoring the > >>> return value here: > >>> https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > >>> > >>> Previously this didn’t cause issues because the intel map_sg always > >>> returned the same number of elements as the input scatter gather list > >>> but with the change to this dma-iommu api this is no longer the > >>> case. I wasn’t able to track the bug down to a specific line of code > >>> unfortunately. > >>> > >>> Could someone from the intel team look at this? > >> > >> Let me get this straight. There is current API that on success always > >> returns the same number of elements as the input scatter gather > >> list. You propose to change the API so that this is no longer the case? > > > > No, the API for dma_map_sg() has always been that it may return fewer > > DMA segments than nents - see Documentation/DMA-API.txt (and otherwise, > > the return value would surely be a simple success/fail condition). > > Relying on a particular implementation behaviour has never been strictly > > correct, even if it does happen to be a very common behaviour. > > > >> A quick check of various dma_map_sg() calls in the kernel seems to > >> indicate checking for 0 for errors and then ignoring the non-zero return > >> is a common pattern. Are you sure it's okay to make the change you're > >> proposing? > > > > Various code uses tricks like just iterating the mapped list until the > > first segment with zero sg_dma_len(). Others may well simply have bugs. > > Thanks for the clarification. > > BR, > Jani. > > > > > Robin. > > > >> Anyway, due to the time of year and all, I'd like to ask you to file a > >> bug against i915 at [1] so this is not forgotten, and please let's not > >> merge the changes before this is resolved. > >> > >> > >> Thanks, > >> Jani. > >> > >> > >> [1] https://gitlab.freedesktop.org/drm/intel/issues/new > >> > >> > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 00/12] Convert PWM period and duty cycle to u64
Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds. Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors. This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors. Changes from v9: - Gathered the received "Reviewed-by: " tag - Added back the clk-pwm.c patch because kbuild test robot complained [3] and addressed received review comments. - clps711x: Addressed review comments. Changes from v8: - Gathered all received "Acked-by: " and "Reviewed-by: " tags - Dropped patch to clk-pwm.c for reasons mentiond in [2] - Expanded audience of unreviewed patches Changes from v7: - Changed commit messages of all patches to be brief and to the point. - Added explanation of change in cover letter. - Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core. Changes from v6: - Split out the driver changes out into separate patches, one patch per file for ease of reviewing. Changes from v5: - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned in https://www.spinics.net/lists/linux-pwm/msg11541.html Changes from v4: - Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise. - Re-examined the patch and made the following corrections: * intel_panel.c: DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case). * pwm-sti.c: do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible). Changes from v3: - Rebased to current tip of for-next. Changes from v2: - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c Changes from v1: - Fixed compilation errors seen when compiling for different archs. v1: - Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual. [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/ [2] https://lore.kernel.org/lkml/20200312190859.ga19...@codeaurora.org/ [3] https://www.spinics.net/lists/linux-pwm/msg11906.html Guru Das Srinagesh (12): drm/i915: Use 64-bit division macro hwmon: pwm-fan: Use 64-bit division macro ir-rx51: Use 64-bit division macro pwm: clps711x: Cast period to u32 before use as divisor pwm: pwm-imx-tpm: Use 64-bit division macro pwm: imx27: Use 64-bit division macro and function pwm: sifive: Use 64-bit division macro pwm: stm32-lp: Use %llu format specifier for period pwm: sun4i: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function clk: pwm: Assign u64 divisor to unsigned int before use pwm: core: Convert period and duty cycle to u64 drivers/clk/clk-pwm.c | 4 +++- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- drivers/hwmon/pwm-fan.c| 2 +- drivers/media/rc/ir-rx51.c | 3 ++- drivers/pwm/core.c | 4 ++-- drivers/pwm/pwm-clps711x.c | 5 - drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c| 5 ++--- drivers/pwm/pwm-sifive.c | 2 +- drivers/pwm/pwm-stm32-lp.c | 2 +- drivers/pwm/pwm-sun4i.c| 2 +- drivers/pwm/sysfs.c| 8 drivers/video/backlight/pwm_bl.c | 3 ++- include/linux/pwm.h| 12 ++-- 14 files changed, 31 insertions(+), 25 deletions(-) Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-fb...@vger.kernel.org Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Philipp Zabel Cc: Fabrice Gasnier Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: linux-ri...@lists.infradead.org Cc: Yash Shah Cc: Atish Patra Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: Sascha Hauer
[Intel-gfx] [PATCH v11 00/12] Convert PWM period and duty cycle to u64
Because period and duty cycle are defined in the PWM framework structs as ints with units of nanoseconds, the maximum time duration that can be set is limited to ~2.147 seconds. Consequently, applications desiring to set greater time periods via the PWM framework are not be able to do so - like, for instance, causing an LED to blink at an interval of 5 seconds. Redefining the period and duty cycle struct members in the core PWM framework structs as u64 values will enable larger time durations to be set and solve this problem. Such a change to the framework mandates that drivers using these struct members (and corresponding helper functions) also be modified correctly in order to prevent compilation errors. This patch series introduces the changes to all the drivers first, followed by the framework change at the very end so that when the latter is applied, all the drivers are in good shape and there are no compilation errors. Changes from v10: - Carefully added back all the "Reviewed-by: " and "Acked-by: " tags received so far that had gotten missed in v9. No other changes. Changes from v9: - Gathered the received "Reviewed-by: " tag - Added back the clk-pwm.c patch because kbuild test robot complained [3] and addressed received review comments. - clps711x: Addressed review comments. Changes from v8: - Gathered all received "Acked-by: " and "Reviewed-by: " tags - Dropped patch to clk-pwm.c for reasons mentiond in [2] - Expanded audience of unreviewed patches Changes from v7: - Changed commit messages of all patches to be brief and to the point. - Added explanation of change in cover letter. - Dropped change to pwm-sti.c as upon review it was unnecessary as struct pwm_capture is not being modified in the PWM core. Changes from v6: - Split out the driver changes out into separate patches, one patch per file for ease of reviewing. Changes from v5: - Dropped the conversion of struct pwm_capture to u64 for reasons mentioned in https://www.spinics.net/lists/linux-pwm/msg11541.html Changes from v4: - Split the patch into two: one for changes to the drivers, and the actual switch to u64 for ease of reverting should the need arise. - Re-examined the patch and made the following corrections: * intel_panel.c: DIV64_U64_ROUND_UP -> DIV_ROUND_UP_ULL (as only the numerator would be 64-bit in this case). * pwm-sti.c: do_div -> div_u64 (do_div is optimized only for x86 architectures, and div_u64's comment block suggests to use this as much as possible). Changes from v3: - Rebased to current tip of for-next. Changes from v2: - Fixed %u -> %llu in a dev_dbg in pwm-stm32-lp.c, thanks to kbuild test robot - Added a couple of fixes to pwm-imx-tpm.c and pwm-sifive.c Changes from v1: - Fixed compilation errors seen when compiling for different archs. v1: - Reworked the change pushed upstream earlier [1] so as to not add an extension to an obsolete API. With this change, pwm_ops->apply() can be used to set pwm_state parameters as usual. [1] https://lore.kernel.org/lkml/20190916140048.GB7488@ulmo/ [2] https://lore.kernel.org/lkml/20200312190859.ga19...@codeaurora.org/ [3] https://www.spinics.net/lists/linux-pwm/msg11906.html Guru Das Srinagesh (12): drm/i915: Use 64-bit division macro hwmon: pwm-fan: Use 64-bit division macro ir-rx51: Use 64-bit division macro pwm: clps711x: Cast period to u32 before use as divisor pwm: pwm-imx-tpm: Use 64-bit division macro pwm: imx27: Use 64-bit division macro and function pwm: sifive: Use 64-bit division macro pwm: stm32-lp: Use %llu format specifier for period pwm: sun4i: Use 64-bit division function backlight: pwm_bl: Use 64-bit division function clk: pwm: Assign u64 divisor to unsigned int before use pwm: core: Convert period and duty cycle to u64 drivers/clk/clk-pwm.c | 4 +++- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- drivers/hwmon/pwm-fan.c| 2 +- drivers/media/rc/ir-rx51.c | 3 ++- drivers/pwm/core.c | 4 ++-- drivers/pwm/pwm-clps711x.c | 5 - drivers/pwm/pwm-imx-tpm.c | 2 +- drivers/pwm/pwm-imx27.c| 5 ++--- drivers/pwm/pwm-sifive.c | 2 +- drivers/pwm/pwm-stm32-lp.c | 2 +- drivers/pwm/pwm-sun4i.c| 2 +- drivers/pwm/sysfs.c| 8 drivers/video/backlight/pwm_bl.c | 3 ++- include/linux/pwm.h| 12 ++-- 14 files changed, 31 insertions(+), 25 deletions(-) Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: linux-fb...@vger.kernel.org Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Philipp Zabel Cc: Fabrice Gasnier Cc: Maxime Coquelin Cc: Alexandre Torgue Cc: Palmer Dabbelt Cc: Paul Walmsley Cc:
[Intel-gfx] [PATCH v10 01/12] drm/i915: Use 64-bit division macro
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 Reviewed-by: Jani Nikula Signed-off-by: Guru Das Srinagesh --- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c index bc14e9c..843cac1 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, panel->backlight.min = 0; /* 0% */ panel->backlight.max = 100; /* 100% */ - panel->backlight.level = DIV_ROUND_UP( + panel->backlight.level = DIV_ROUND_UP_ULL( pwm_get_duty_cycle(panel->backlight.pwm) * 100, CRC_PMIC_PWM_PERIOD_NS); panel->backlight.enabled = panel->backlight.level != 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 01/12] drm/i915: Use 64-bit division macro
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 Reviewed-by: Jani Nikula Signed-off-by: Guru Das Srinagesh --- drivers/gpu/drm/i915/display/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c index bc14e9c..843cac1 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, panel->backlight.min = 0; /* 0% */ panel->backlight.max = 100; /* 100% */ - panel->backlight.level = DIV_ROUND_UP( + panel->backlight.level = DIV_ROUND_UP_ULL( pwm_get_duty_cycle(panel->backlight.pwm) * 100, CRC_PMIC_PWM_PERIOD_NS); panel->backlight.enabled = panel->backlight.level != 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 05/18] video/hdmi: Add Unpack only function for DRM infoframe
On Tue, 11 Feb 2020, Gwan-gyeong Mun wrote:
> It adds an unpack only function for DRM infoframe for dynamic range and
> mastering infoframe readout.
> It unpacks the information data block contained in the binary buffer into
> a structured frame of the HDMI Dynamic Range and Mastering (DRM)
> information frame.
>
> In contrast to hdmi_drm_infoframe_unpack() function, it does not verify
> a checksum.
>
> It can be used for unpacking a DP HDR Metadata Infoframe SDP case.
> DP HDR Metadata Infoframe SDP uses the same Dynamic Range and Mastering
> (DRM) information (CTA-861-G spec.) such as HDMI DRM infoframe.
> But DP SDP header and payload structure are different from HDMI DRM
> Infoframe. Therefore unpacking DRM infoframe for DP requires skipping of
> a verifying checksum.
>
> Signed-off-by: Gwan-gyeong Mun
> Reviewed-by: Uma Shankar
Bartlomiej, can I have your ack for merging this via drm-intel along
with the rest of the series, please?
BR,
Jani.
> ---
> drivers/video/hdmi.c | 58 +++-
> include/linux/hdmi.h | 2 ++
> 2 files changed, 43 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 9c82e2a0a411..9818836d82b7 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1775,20 +1775,18 @@ hdmi_vendor_any_infoframe_unpack(union
> hdmi_vendor_any_infoframe *frame,
> }
>
> /**
> - * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
> + * hdmi_drm_infoframe_unpack_only() - unpack binary buffer to a HDMI DRM
> infoframe
> * @frame: HDMI DRM infoframe
> * @buffer: source buffer
> * @size: size of buffer
> *
> - * Unpacks the information contained in binary @buffer into a structured
> + * Unpacks the information data block contained in binary @buffer into a
> structured
> * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> - * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> - * specification.
> *
> * Returns 0 on success or a negative error code on failure.
> */
> -static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
> - const void *buffer, size_t size)
> +int hdmi_drm_infoframe_unpack_only(struct hdmi_drm_infoframe *frame,
> +const void *buffer, size_t size)
> {
> const u8 *ptr = buffer;
> const u8 *temp;
> @@ -1797,23 +1795,13 @@ static int hdmi_drm_infoframe_unpack(struct
> hdmi_drm_infoframe *frame,
> int ret;
> int i;
>
> - if (size < HDMI_INFOFRAME_SIZE(DRM))
> - return -EINVAL;
> -
> - if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> - ptr[1] != 1 ||
> - ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> - return -EINVAL;
> -
> - if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
> + if (size < HDMI_DRM_INFOFRAME_SIZE)
> return -EINVAL;
>
> ret = hdmi_drm_infoframe_init(frame);
> if (ret)
> return ret;
>
> - ptr += HDMI_INFOFRAME_HEADER_SIZE;
> -
> frame->eotf = ptr[0] & 0x7;
> frame->metadata_type = ptr[1] & 0x7;
>
> @@ -1837,6 +1825,42 @@ static int hdmi_drm_infoframe_unpack(struct
> hdmi_drm_infoframe *frame,
>
> return 0;
> }
> +EXPORT_SYMBOL(hdmi_drm_infoframe_unpack_only);
> +
> +/**
> + * hdmi_drm_infoframe_unpack() - unpack binary buffer to a HDMI DRM infoframe
> + * @frame: HDMI DRM infoframe
> + * @buffer: source buffer
> + * @size: size of buffer
> + *
> + * Unpacks the information contained in binary @buffer into a structured
> + * @frame of the HDMI Dynamic Range and Mastering (DRM) information frame.
> + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4
> + * specification.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +static int hdmi_drm_infoframe_unpack(struct hdmi_drm_infoframe *frame,
> + const void *buffer, size_t size)
> +{
> + const u8 *ptr = buffer;
> + int ret;
> +
> + if (size < HDMI_INFOFRAME_SIZE(DRM))
> + return -EINVAL;
> +
> + if (ptr[0] != HDMI_INFOFRAME_TYPE_DRM ||
> + ptr[1] != 1 ||
> + ptr[2] != HDMI_DRM_INFOFRAME_SIZE)
> + return -EINVAL;
> +
> + if (hdmi_infoframe_checksum(buffer, HDMI_INFOFRAME_SIZE(DRM)) != 0)
> + return -EINVAL;
> +
> + ret = hdmi_drm_infoframe_unpack_only(frame, ptr +
> HDMI_INFOFRAME_HEADER_SIZE,
> + size - HDMI_INFOFRAME_HEADER_SIZE);
> + return ret;
> +}
>
> /**
> * hdmi_infoframe_unpack() - unpack binary buffer to a HDMI infoframe
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 9918a6c910c5..afb43efc03e0 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -219,6 +219,8 @@ ssize_t hdmi_drm_infoframe_pack(struct hdmi_drm_infoframe
> *frame, void *buffer,
>
Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Report context-is-closed prior to pinning
On 20/03/2020 13:01, Chris Wilson wrote:
Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index aea992e46c42..7132bf616cc4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -97,8 +97,6 @@ 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, >flags))) {
err = intel_context_alloc_state(ce);
if (err)
@@ -114,6 +112,11 @@ int __intel_context_do_pin(struct intel_context *ce)
goto out_release;
}
+ if (unlikely(intel_context_is_closed(ce))) {
+ err = -ENOENT;
+ goto out_release;
+ }
+
if (likely(!atomic_add_unless(>pin_count, 1, 0))) {
err = intel_context_active_acquire(ce);
if (unlikely(err))
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Check for has-reset before testing hostile contexts
== Series Details == Series: drm/i915/selftests: Check for has-reset before testing hostile contexts URL : https://patchwork.freedesktop.org/series/74915/ State : success == Summary == CI Bug Log - changes from CI_DRM_8163_full -> Patchwork_17033_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17033_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb2/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-iclb5/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@close-replace-race: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([i915#1402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927] / [i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-apl6/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-apl8/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_schedule@implicit-write-read-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb1/igt@gem_exec_sched...@implicit-write-read-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-iclb3/igt@gem_exec_sched...@implicit-write-read-bsd2.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb6/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@promotion-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb6/igt@gem_exec_sched...@promotion-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-iclb4/igt@gem_exec_sched...@promotion-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#644]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-tglb6/igt@gem_pp...@flink-and-close-vma-leak.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-tglb1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#413]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb2/igt@i915_pm_...@waitboost.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-iclb5/igt@i915_pm_...@waitboost.html * igt@kms_flip@2x-plain-flip-ts-check: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#34]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-glk6/igt@kms_f...@2x-plain-flip-ts-check.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-glk8/igt@kms_f...@2x-plain-flip-ts-check.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-kbl3/igt@kms_frontbuffer_track...@fbc-suspend.html - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-apl2/igt@kms_frontbuffer_track...@fbc-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/shard-apl1/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#49]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-skl10/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-render.html [26]:
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gem: Avoid gem_context->mutex for simple vma lookup
On 20/03/2020 13:01, 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 c1179c00bc61..876fc2e124b9 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 = >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(>relocs);
- INIT_LIST_HEAD(>unbound);
+ i915_vma_get(vma);
+ if (!atomic_fetch_inc(>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(>mutex)) {
+ err = -ENOENT;
+ if (likely(!i915_gem_context_is_closed(ctx)))
+ err = radix_tree_insert(>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);
Does this fit into Maarten's rework - nesting of object_lock under
ctx->mutex I mean?
Other than this question it looks clean.
Regards,
Tvrtko
+ if (idr_find(>file->object_idr, handle) == obj) {
+ list_add(>obj_link, >lut_list);
+ } else {
+ radix_tree_delete(>handles_vma, handle);
+ err = -ENOENT;
+ }
+ i915_gem_object_unlock(obj);
+ }
+ mutex_unlock(>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(>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(>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))
+
[Intel-gfx] [PATCH] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.
Signed-off-by: Chris Wilson
Cc: Francisco Jerez
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f09dd87324b9..996554766aa5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2884,6 +2884,11 @@ static void queue_request(struct intel_engine_cs *engine,
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
+static bool pending_csb(const struct intel_engine_execlists *execlists)
+{
+ return READ_ONCE(*execlists->csb_write) != execlists->csb_head;
+}
+
static void __submit_queue_imm(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
@@ -2891,10 +2896,19 @@ static void __submit_queue_imm(struct intel_engine_cs
*engine)
if (reset_in_progress(execlists))
return; /* defer until we restart the engine following reset */
- if (execlists->tasklet.func == execlists_submission_tasklet)
- __execlists_submission_tasklet(engine);
- else
- tasklet_hi_schedule(>tasklet);
+ /* Hopefully we clear execlists->pending[] to let us through */
+ if (execlists->pending[0] && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ }
+
+ __execlists_submission_tasklet(engine);
+
+ /* Try and pull an interrupt-bh queued on another CPU to here */
+ if (pending_csb(execlists) && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ }
}
static void submit_queue(struct intel_engine_cs *engine,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Check for has-reset before testing hostile contexts
In order to kill off a hostile context, we need to be able to reset the
GPU. So check that is supported prior to beginning the test.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 6f06ba750a0a..7e3a92faf392 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -2030,6 +2030,9 @@ static int __cancel_hostile(struct live_preempt_cancel
*arg)
if (!IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
return 0;
+ if (!intel_has_reset_engine(arg->engine->gt))
+ return 0;
+
GEM_TRACE("%s(%s)\n", __func__, arg->engine->name);
rq = spinner_create_request(>a.spin,
arg->a.ctx, arg->engine,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Report context-is-closed prior to pinning
Our assertion caught that we do try to pin a closed context if userspace
is viciously racing context-closure with execbuf, so make it fail
gracefully.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1492
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index aea992e46c42..7132bf616cc4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -97,8 +97,6 @@ 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, >flags))) {
err = intel_context_alloc_state(ce);
if (err)
@@ -114,6 +112,11 @@ int __intel_context_do_pin(struct intel_context *ce)
goto out_release;
}
+ if (unlikely(intel_context_is_closed(ce))) {
+ err = -ENOENT;
+ goto out_release;
+ }
+
if (likely(!atomic_add_unless(>pin_count, 1, 0))) {
err = intel_context_active_acquire(ce);
if (unlikely(err))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Check for has-reset before testing hostile contexts
== Series Details == Series: drm/i915/selftests: Check for has-reset before testing hostile contexts URL : https://patchwork.freedesktop.org/series/74915/ State : success == Summary == CI Bug Log - changes from CI_DRM_8163 -> Patchwork_17033 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/index.html Known issues Here are the changes found in Patchwork_17033 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2] ([fdo#112259] / [i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/fi-kbl-soraka/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_8163/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-cfl-8109u: [FAIL][5] ([fdo#103375]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/fi-cfl-8109u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/fi-cfl-8109u/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#112259]: https://bugs.freedesktop.org/show_bug.cgi?id=112259 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (41 -> 39) -- Additional (2): fi-skl-6600u fi-elk-e7500 Missing(4): fi-bsw-kefka fi-kbl-7560u fi-byt-squawks fi-bsw-cyan Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8163 -> Patchwork_17033 CI-20190529: 20190529 CI_DRM_8163: 710b3af22d17146897a55f01868d8e2d867895d3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5523: cf6d524007ac51a7d5a48503ea3dd5f01fd4ebab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17033: dd08db2eba929e3546b814186865a741e019694c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == dd08db2eba92 drm/i915/selftests: Check for has-reset before testing hostile contexts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17033/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 04/18] drm/i915/dp: Add writing of DP SDPs
On Mon, 16 Mar 2020, "Shankar, Uma" wrote:
>> -Original Message-
>> From: dri-devel On Behalf Of Gwan-
>> gyeong Mun
>> Sent: Tuesday, February 11, 2020 1:17 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: linux-fb...@vger.kernel.org; dri-de...@lists.freedesktop.org
>> Subject: [PATCH v7 04/18] drm/i915/dp: Add writing of DP SDPs
>>
>> It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP.
>> In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function.
>> It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table
>> 2-117: VSC
>> SDP Payload for DB16 through DB18]
>>
>> In order to pack DP HDR Metadata Infoframe SDP, it adds
>> intel_dp_hdr_metadata_infoframe_sdp_pack() function.
>> And it follows DP 1.4a spec.
>> ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME
>> SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec.
>> [Table-42
>> Dynamic Range and Mastering InfoFrame].
>>
>> A mechanism and a naming rule of intel_dp_set_infoframes() function
>> references
>> intel_encoder->set_infoframes() of intel_hdmi.c .
>> VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases.
>> Because PSR routine has its own routine of writing a VSC SDP, when the PSR is
>> enabled, intel_dp_set_infoframes() does not write a VSC SDP.
>>
>> v3:
>> - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be
>> used for HDMI), when intel_dp_set_infoframes() function will be called.
>> - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp.
>> v4: Use struct drm_device logging macros
>> v5:
>> - use intel_de_*() functions for register access
>> - Addressed review comments from Uma
>> Polish commit message and comments
>> Add 6bpc to packing of VSC SDP
>
> Looks good to me.
> Reviewed-by: Uma Shankar
Pushed up to and including this patch, thanks for the patches and
review.
BR,
Jani.
>
>> Signed-off-by: Gwan-gyeong Mun
>> ---
>> drivers/gpu/drm/i915/display/intel_dp.c | 199
>> drivers/gpu/drm/i915/display/intel_dp.h | 3 +
>> 2 files changed, 202 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index fb008168ca83..5bbc55113325 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -4741,6 +4741,205 @@ intel_dp_needs_vsc_sdp(const struct intel_crtc_state
>> *crtc_state,
>> return false;
>> }
>>
>> +static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
>> + struct dp_sdp *sdp, size_t size) {
>> +size_t length = sizeof(struct dp_sdp);
>> +
>> +if (size < length)
>> +return -ENOSPC;
>> +
>> +memset(sdp, 0, size);
>> +
>> +/*
>> + * Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
>> + * VSC SDP Header Bytes
>> + */
>> +sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
>> +sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
>> +sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
>> +sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
>> +
>> +/* VSC SDP Payload for DB16 through DB18 */
>> +/* Pixel Encoding and Colorimetry Formats */
>> +sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
>> +sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
>> +
>> +switch (vsc->bpc) {
>> +case 6:
>> +/* 6bpc: 0x0 */
>> +break;
>> +case 8:
>> +sdp->db[17] = 0x1; /* DB17[3:0] */
>> +break;
>> +case 10:
>> +sdp->db[17] = 0x2;
>> +break;
>> +case 12:
>> +sdp->db[17] = 0x3;
>> +break;
>> +case 16:
>> +sdp->db[17] = 0x4;
>> +break;
>> +default:
>> +MISSING_CASE(vsc->bpc);
>> +break;
>> +}
>> +/* Dynamic Range and Component Bit Depth */
>> +if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
>> +sdp->db[17] |= 0x80; /* DB17[7] */
>> +
>> +/* Content Type */
>> +sdp->db[18] = vsc->content_type & 0x7;
>> +
>> +return length;
>> +}
>> +
>> +static ssize_t
>> +intel_dp_hdr_metadata_infoframe_sdp_pack(const struct hdmi_drm_infoframe
>> *drm_infoframe,
>> + struct dp_sdp *sdp,
>> + size_t size)
>> +{
>> +size_t length = sizeof(struct dp_sdp);
>> +const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
>> HDMI_DRM_INFOFRAME_SIZE;
>> +unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
>> HDMI_DRM_INFOFRAME_SIZE];
>> +ssize_t len;
>> +
>> +if (size < length)
>> +return -ENOSPC;
>> +
>> +memset(sdp, 0, size);
>> +
>> +len = hdmi_drm_infoframe_pack_only(drm_infoframe, buf, sizeof(buf));
>> +if (len < 0) {
>> +
[Intel-gfx] [PATCH 13/13] drm/i915/wopcm: convert to drm device based logging
Prefer drm_dbg() over DRM_DEV_DEBUG_DRIVER() and drm_err() over
dev_err().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_wopcm.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2bb9f9f9a50a..2186386a45c8 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -86,7 +86,7 @@ void intel_wopcm_init_early(struct intel_wopcm *wopcm)
else
wopcm->size = GEN9_WOPCM_SIZE;
- DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "WOPCM: %uK\n", wopcm->size / 1024);
+ drm_dbg(>drm, "WOPCM: %uK\n", wopcm->size / 1024);
}
static inline u32 context_reserved_size(struct drm_i915_private *i915)
@@ -112,7 +112,7 @@ static inline bool gen9_check_dword_gap(struct
drm_i915_private *i915,
offset = guc_wopcm_base + GEN9_GUC_WOPCM_OFFSET;
if (offset > guc_wopcm_size ||
(guc_wopcm_size - offset) < sizeof(u32)) {
- dev_err(i915->drm.dev,
+ drm_err(>drm,
"WOPCM: invalid GuC region size: %uK < %uK\n",
guc_wopcm_size / SZ_1K,
(u32)(offset + sizeof(u32)) / SZ_1K);
@@ -131,7 +131,7 @@ static inline bool gen9_check_huc_fw_fits(struct
drm_i915_private *i915,
* firmware uploading would fail.
*/
if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
- dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+ drm_err(>drm, "WOPCM: no space for %s: %uK < %uK\n",
intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
(guc_wopcm_size - GUC_WOPCM_RESERVED) / SZ_1K,
huc_fw_size / 1024);
@@ -166,7 +166,7 @@ static inline bool __check_layout(struct drm_i915_private
*i915, u32 wopcm_size,
size = wopcm_size - ctx_rsvd;
if (unlikely(range_overflows(guc_wopcm_base, guc_wopcm_size, size))) {
- dev_err(i915->drm.dev,
+ drm_err(>drm,
"WOPCM: invalid GuC region layout: %uK + %uK > %uK\n",
guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K,
size / SZ_1K);
@@ -175,7 +175,7 @@ static inline bool __check_layout(struct drm_i915_private
*i915, u32 wopcm_size,
size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
if (unlikely(guc_wopcm_size < size)) {
- dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+ drm_err(>drm, "WOPCM: no space for %s: %uK < %uK\n",
intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
guc_wopcm_size / SZ_1K, size / SZ_1K);
return false;
@@ -183,7 +183,7 @@ static inline bool __check_layout(struct drm_i915_private
*i915, u32 wopcm_size,
size = huc_fw_size + WOPCM_RESERVED_SIZE;
if (unlikely(guc_wopcm_base < size)) {
- dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+ drm_err(>drm, "WOPCM: no space for %s: %uK < %uK\n",
intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
guc_wopcm_base / SZ_1K, size / SZ_1K);
return false;
@@ -242,10 +242,8 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
return;
if (__wopcm_regs_locked(gt->uncore, _wopcm_base, _wopcm_size)) {
- DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
-"GuC WOPCM is already locked [%uK, %uK)\n",
-guc_wopcm_base / SZ_1K,
-guc_wopcm_size / SZ_1K);
+ drm_dbg(>drm, "GuC WOPCM is already locked [%uK, %uK)\n",
+ guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K);
goto check;
}
@@ -266,8 +264,8 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
guc_wopcm_size = wopcm->size - ctx_rsvd - guc_wopcm_base;
guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
- DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "Calculated GuC WOPCM [%uK, %uK)\n",
-guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K);
+ drm_dbg(>drm, "Calculated GuC WOPCM [%uK, %uK)\n",
+ guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K);
check:
if (__check_layout(i915, wopcm->size, guc_wopcm_base, guc_wopcm_size,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/13] drm/i915/ddi: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_ddi.c | 118 ++-
1 file changed, 72 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 73d0f4648c06..3df7fb5b3d02 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1102,7 +1102,8 @@ static void intel_wait_ddi_buf_idle(struct
drm_i915_private *dev_priv,
if (intel_de_read(dev_priv, reg) & DDI_BUF_IS_IDLE)
return;
}
- DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n", port_name(port));
+ drm_err(_priv->drm, "Timeout waiting for DDI BUF %c idle bit\n",
+ port_name(port));
}
static u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
@@ -1249,7 +1250,8 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
temp = intel_de_read(dev_priv, DP_TP_STATUS(PORT_E));
if (temp & DP_TP_STATUS_AUTOTRAIN_DONE) {
- DRM_DEBUG_KMS("FDI link training done on step %d\n", i);
+ drm_dbg_kms(_priv->drm,
+ "FDI link training done on step %d\n", i);
break;
}
@@ -1258,7 +1260,7 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
* Results in less fireworks from the state checker.
*/
if (i == ARRAY_SIZE(hsw_ddi_translations_fdi) * 2 - 1) {
- DRM_ERROR("FDI link training failed!\n");
+ drm_err(_priv->drm, "FDI link training failed!\n");
break;
}
@@ -1605,7 +1607,8 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
- DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
+ drm_dbg_kms(_priv->drm,
+ "Quirk Increase DDI disabled time\n");
/* Quirk time at 100ms for reliable operation */
msleep(100);
}
@@ -1786,20 +1789,23 @@ static void intel_ddi_get_encoder_pipes(struct
intel_encoder *encoder,
}
if (!*pipe_mask)
- DRM_DEBUG_KMS("No pipe for [ENCODER:%d:%s] found\n",
- encoder->base.base.id, encoder->base.name);
+ drm_dbg_kms(_priv->drm,
+ "No pipe for [ENCODER:%d:%s] found\n",
+ encoder->base.base.id, encoder->base.name);
if (!mst_pipe_mask && hweight8(*pipe_mask) > 1) {
- DRM_DEBUG_KMS("Multiple pipes for [ENCODER:%d:%s] (pipe_mask
%02x)\n",
- encoder->base.base.id, encoder->base.name,
- *pipe_mask);
+ drm_dbg_kms(_priv->drm,
+ "Multiple pipes for [ENCODER:%d:%s] (pipe_mask
%02x)\n",
+ encoder->base.base.id, encoder->base.name,
+ *pipe_mask);
*pipe_mask = BIT(ffs(*pipe_mask) - 1);
}
if (mst_pipe_mask && mst_pipe_mask != *pipe_mask)
- DRM_DEBUG_KMS("Conflicting MST and non-MST state for
[ENCODER:%d:%s] (pipe_mask %02x mst_pipe_mask %02x)\n",
- encoder->base.base.id, encoder->base.name,
- *pipe_mask, mst_pipe_mask);
+ drm_dbg_kms(_priv->drm,
+ "Conflicting MST and non-MST state for
[ENCODER:%d:%s] (pipe_mask %02x mst_pipe_mask %02x)\n",
+ encoder->base.base.id, encoder->base.name,
+ *pipe_mask, mst_pipe_mask);
else
*is_dp_mst = mst_pipe_mask;
@@ -1809,9 +1815,9 @@ static void
[Intel-gfx] [PATCH 06/13] drm/i915/hdmi: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 189 ++
1 file changed, 121 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 39930232b253..395dc192baa0 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -691,6 +691,7 @@ void intel_read_infoframe(struct intel_encoder *encoder,
union hdmi_infoframe *frame)
{
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+ struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
u8 buffer[VIDEO_DIP_DATA_SIZE];
int ret;
@@ -707,13 +708,15 @@ void intel_read_infoframe(struct intel_encoder *encoder,
/* see comment above for the reason for this offset */
ret = hdmi_infoframe_unpack(frame, buffer + 1, sizeof(buffer) - 1);
if (ret) {
- DRM_DEBUG_KMS("Failed to unpack infoframe type 0x%02x\n", type);
+ drm_dbg_kms(>drm,
+ "Failed to unpack infoframe type 0x%02x\n", type);
return;
}
if (frame->any.type != type)
- DRM_DEBUG_KMS("Found the wrong infoframe type 0x%x (expected
0x%02x)\n",
- frame->any.type, type);
+ drm_dbg_kms(>drm,
+ "Found the wrong infoframe type 0x%x (expected
0x%02x)\n",
+ frame->any.type, type);
}
static bool
@@ -853,7 +856,8 @@ intel_hdmi_compute_drm_infoframe(struct intel_encoder
*encoder,
ret = drm_hdmi_infoframe_set_hdr_metadata(frame, conn_state);
if (ret < 0) {
- DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+ drm_dbg_kms(_priv->drm,
+ "couldn't set HDR metadata in infoframe\n");
return false;
}
@@ -893,8 +897,9 @@ static void g4x_set_infoframes(struct intel_encoder
*encoder,
if (!(val & VIDEO_DIP_ENABLE))
return;
if (port != (val & VIDEO_DIP_PORT_MASK)) {
- DRM_DEBUG_KMS("video DIP still enabled on port %c\n",
- (val & VIDEO_DIP_PORT_MASK) >> 29);
+ drm_dbg_kms(_priv->drm,
+ "video DIP still enabled on port %c\n",
+ (val & VIDEO_DIP_PORT_MASK) >> 29);
return;
}
val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI |
@@ -906,8 +911,9 @@ static void g4x_set_infoframes(struct intel_encoder
*encoder,
if (port != (val & VIDEO_DIP_PORT_MASK)) {
if (val & VIDEO_DIP_ENABLE) {
- DRM_DEBUG_KMS("video DIP already enabled on port %c\n",
- (val & VIDEO_DIP_PORT_MASK) >> 29);
+ drm_dbg_kms(_priv->drm,
+ "video DIP already enabled on port %c\n",
+ (val & VIDEO_DIP_PORT_MASK) >> 29);
return;
}
val &= ~VIDEO_DIP_PORT_MASK;
@@ -1264,8 +1270,8 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi
*hdmi, bool enable)
if (hdmi->dp_dual_mode.type < DRM_DP_DUAL_MODE_TYPE2_DVI)
return;
- DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS output\n",
- enable ? "Enabling" : "Disabling");
+ drm_dbg_kms(_priv->drm, "%s DP dual mode adaptor TMDS output\n",
+ enable ? "Enabling" : "Disabling");
drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
adapter, enable);
@@ -1346,13 +1352,14 @@ int intel_hdmi_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
ret =
[Intel-gfx] [PATCH 05/13] drm/i915/dsi: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dsi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.c
b/drivers/gpu/drm/i915/display/intel_dsi.c
index a2a937109a5a..afa4e6817e8c 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi.c
@@ -31,20 +31,21 @@ int intel_dsi_tlpx_ns(const struct intel_dsi *intel_dsi)
int intel_dsi_get_modes(struct drm_connector *connector)
{
+ struct drm_i915_private *i915 = to_i915(connector->dev);
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_display_mode *mode;
- DRM_DEBUG_KMS("\n");
+ drm_dbg_kms(>drm, "\n");
if (!intel_connector->panel.fixed_mode) {
- DRM_DEBUG_KMS("no fixed mode\n");
+ drm_dbg_kms(>drm, "no fixed mode\n");
return 0;
}
mode = drm_mode_duplicate(connector->dev,
intel_connector->panel.fixed_mode);
if (!mode) {
- DRM_DEBUG_KMS("drm_mode_duplicate failed\n");
+ drm_dbg_kms(>drm, "drm_mode_duplicate failed\n");
return 0;
}
@@ -60,7 +61,7 @@ enum drm_mode_status intel_dsi_mode_valid(struct
drm_connector *connector,
const struct drm_display_mode *fixed_mode =
intel_connector->panel.fixed_mode;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
- DRM_DEBUG_KMS("\n");
+ drm_dbg_kms(_priv->drm, "\n");
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/13] drm/i915/dp_mst: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 26 ++---
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 44f3fd251ca1..b978ddd96578 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -47,6 +47,7 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
struct intel_dp *intel_dp = _mst->primary->dp;
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
void *port = connector->port;
@@ -73,7 +74,8 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
}
if (slots < 0) {
- DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
+ drm_dbg_kms(>drm, "failed finding vcpi slots:%d\n",
+ slots);
return slots;
}
@@ -322,15 +324,17 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder,
struct intel_dp *intel_dp = _dig_port->dp;
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
int ret;
- DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
+ drm_dbg_kms(>drm, "active links %d\n",
+ intel_dp->active_mst_links);
drm_dp_mst_reset_vcpi_slots(_dp->mst_mgr, connector->port);
ret = drm_dp_update_payload_part1(_dp->mst_mgr);
if (ret) {
- DRM_DEBUG_KMS("failed to update payload %d\n", ret);
+ drm_dbg_kms(>drm, "failed to update payload %d\n", ret);
}
if (old_crtc_state->has_audio)
intel_audio_codec_disable(encoder,
@@ -371,7 +375,8 @@ static void intel_mst_post_disable_dp(struct intel_encoder
*encoder,
if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
DP_TP_STATUS_ACT_SENT, 1))
- DRM_ERROR("Timed out waiting for ACT sent when disabling\n");
+ drm_err(_priv->drm,
+ "Timed out waiting for ACT sent when disabling\n");
drm_dp_check_act_status(_dp->mst_mgr);
drm_dp_mst_deallocate_vcpi(_dp->mst_mgr, connector->port);
@@ -405,7 +410,8 @@ static void intel_mst_post_disable_dp(struct intel_encoder
*encoder,
intel_dig_port->base.post_disable(_dig_port->base,
old_crtc_state, NULL);
- DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
+ drm_dbg_kms(_priv->drm, "active links %d\n",
+ intel_dp->active_mst_links);
}
static void intel_mst_pre_pll_enable_dp(struct intel_encoder *encoder,
@@ -445,7 +451,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder,
INTEL_GEN(dev_priv) >= 12 && first_mst_stream &&
!intel_dp_mst_is_master_trans(pipe_config));
- DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
+ drm_dbg_kms(_priv->drm, "active links %d\n",
+ intel_dp->active_mst_links);
if (first_mst_stream)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
@@ -461,7 +468,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder,
pipe_config->pbn,
pipe_config->dp_m_n.tu);
if (!ret)
- DRM_ERROR("failed to allocate vcpi\n");
+ drm_err(_priv->drm, "failed to allocate vcpi\n");
intel_dp->active_mst_links++;
temp =
[Intel-gfx] [PATCH 02/13] drm/i915/display_power: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_power.c| 22 +--
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 246e406bb385..433e5a81dd4d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -1873,20 +1873,27 @@ __async_put_domains_state_ok(struct i915_power_domains
*power_domains)
static void print_power_domains(struct i915_power_domains *power_domains,
const char *prefix, u64 mask)
{
+ struct drm_i915_private *i915 = container_of(power_domains,
+struct drm_i915_private,
+power_domains);
enum intel_display_power_domain domain;
- DRM_DEBUG_DRIVER("%s (%lu):\n", prefix, hweight64(mask));
+ drm_dbg(>drm, "%s (%lu):\n", prefix, hweight64(mask));
for_each_power_domain(domain, mask)
- DRM_DEBUG_DRIVER("%s use_count %d\n",
-intel_display_power_domain_str(domain),
-power_domains->domain_use_count[domain]);
+ drm_dbg(>drm, "%s use_count %d\n",
+ intel_display_power_domain_str(domain),
+ power_domains->domain_use_count[domain]);
}
static void
print_async_put_domains_state(struct i915_power_domains *power_domains)
{
- DRM_DEBUG_DRIVER("async_put_wakeref %u\n",
-power_domains->async_put_wakeref);
+ struct drm_i915_private *i915 = container_of(power_domains,
+struct drm_i915_private,
+power_domains);
+
+ drm_dbg(>drm, "async_put_wakeref %u\n",
+ power_domains->async_put_wakeref);
print_power_domains(power_domains, "async_put_domains[0]",
power_domains->async_put_domains[0]);
@@ -4480,7 +4487,8 @@ void icl_dbuf_slices_update(struct drm_i915_private
*dev_priv,
drm_WARN(_priv->drm, hweight8(req_slices) > max_slices,
"Invalid number of dbuf slices requested\n");
- DRM_DEBUG_KMS("Updating dbuf slices to 0x%x\n", req_slices);
+ drm_dbg_kms(_priv->drm, "Updating dbuf slices to 0x%x\n",
+ req_slices);
/*
* Might be running this in parallel to gen9_dc_off_power_well_enable
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/13] drm/i915/dp_aux_backlight: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_dp_aux_backlight.c | 84 +++
1 file changed, 50 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 3e706bb850a8..4b916468540f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -27,6 +27,7 @@
static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 reg_val = 0;
/* Early return when display use other mechanism to enable backlight. */
@@ -35,8 +36,8 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
_val) < 0) {
- DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
- DP_EDP_DISPLAY_CONTROL_REGISTER);
+ drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
+ DP_EDP_DISPLAY_CONTROL_REGISTER);
return;
}
if (enable)
@@ -46,8 +47,8 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
if (drm_dp_dpcd_writeb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
reg_val) != 1) {
- DRM_DEBUG_KMS("Failed to %s aux backlight\n",
- enable ? "enable" : "disable");
+ drm_dbg_kms(>drm, "Failed to %s aux backlight\n",
+ enable ? "enable" : "disable");
}
}
@@ -58,6 +59,7 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 read_val[2] = { 0x0 };
u8 mode_reg;
u16 level = 0;
@@ -65,8 +67,9 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector
*connector)
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
_reg) != 1) {
- DRM_DEBUG_KMS("Failed to read the DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+ drm_dbg_kms(>drm,
+ "Failed to read the DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
return 0;
}
@@ -80,8 +83,8 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector
*connector)
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val, sizeof(read_val)) < 0) {
- DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
- DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
+ drm_dbg_kms(>drm, "Failed to read DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
return 0;
}
level = read_val[0];
@@ -100,6 +103,7 @@ intel_dp_aux_set_backlight(const struct drm_connector_state
*conn_state, u32 lev
{
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
vals[0] = level;
@@ -111,7 +115,8 @@ intel_dp_aux_set_backlight(const struct drm_connector_state
*conn_state, u32 lev
}
if (drm_dp_dpcd_write(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
vals, sizeof(vals)) < 0) {
- DRM_DEBUG_KMS("Failed to write aux backlight level\n");
+ drm_dbg_kms(>drm,
+ "Failed
[Intel-gfx] [PATCH 00/13] drm/i915: drm device based logging changes
Here's a batch of logging conversion. BR, Jani. Jani Nikula (13): drm/i915/ddi: use struct drm_device based logging drm/i915/display_power: use struct drm_device based logging drm/i915/dp_aux_backlight: use struct drm_device based logging drm/i915/dp_mst: use struct drm_device based logging drm/i915/dsi: use struct drm_device based logging drm/i915/hdmi: use struct drm_device based logging drm/i915/dsi: use struct drm_device based logging drm/i915/connector: use MISSING_CASE instead of logging drm/i915/tv: use struct drm_device based logging drm/i915/display: clean up intel_PLL_is_valid() drm/i915/display: use struct drm_device based logging drm/i915/psr: use struct drm_device based logging drm/i915/wopcm: convert to drm device based logging drivers/gpu/drm/i915/display/icl_dsi.c| 10 +- .../gpu/drm/i915/display/intel_connector.c| 2 +- drivers/gpu/drm/i915/display/intel_ddi.c | 118 ++- drivers/gpu/drm/i915/display/intel_display.c | 65 +++--- .../drm/i915/display/intel_display_power.c| 22 +- .../drm/i915/display/intel_dp_aux_backlight.c | 84 drivers/gpu/drm/i915/display/intel_dp_mst.c | 26 ++- drivers/gpu/drm/i915/display/intel_dsi.c | 9 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 11 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 189 +++--- drivers/gpu/drm/i915/display/intel_psr.c | 47 +++-- drivers/gpu/drm/i915/display/intel_tv.c | 6 +- drivers/gpu/drm/i915/display/vlv_dsi.c| 3 +- drivers/gpu/drm/i915/intel_wopcm.c| 22 +- 14 files changed, 367 insertions(+), 247 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: move files more files into debugfs
On 20/03/2020 03:49, Andi Shyti wrote:
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_sseu_status
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- forcewake_user
|
+-- interrupt_info_show
|
+-- sseu_status
|
+-- 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.
It is based on Daniele's series and it applies only on top of
that.
Thanks Tvrtko for the review,
Andi
Changelog
=
v2:
- dropped changes on "drop_caches", they were indeed irrelevant
- improved interrupt info function
drivers/gpu/drm/i915/gt/debugfs_gt.c| 464 +++-
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 32 ++
drivers/gpu/drm/i915/i915_debugfs.c | 441 +-
3 files changed, 499 insertions(+), 438 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index fcbc57e226c3..ab731350daea 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -5,12 +5,472 @@
*/
#include
+#include
#include "debugfs_engines.h"
#include "debugfs_gt.h"
#include "debugfs_gt_pm.h"
-#include "uc/debugfs_uc.h"
#include "i915_drv.h"
+#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
+#include "uc/debugfs_uc.h"
+
+static void
+intel_sseu_copy_subslices(const struct sseu_dev_info *sseu, int slice,
+ u8 *to_mask)
+{
+ int offset = slice * sseu->ss_stride;
+
+ memcpy(_mask[offset], >subslice_mask[offset], sseu->ss_stride);
+}
+
+static void cherryview_sseu_device_status(struct intel_gt *gt,
+ struct sseu_dev_info *sseu)
+{
+#define SS_MAX 2
+ const int ss_max = SS_MAX;
+ u32 sig1[SS_MAX], sig2[SS_MAX];
+ int ss;
+
+ sig1[0] = intel_uncore_read(gt->uncore, CHV_POWER_SS0_SIG1);
+ sig1[1] = intel_uncore_read(gt->uncore, CHV_POWER_SS1_SIG1);
+ sig2[0] = intel_uncore_read(gt->uncore, CHV_POWER_SS0_SIG2);
+ sig2[1] = intel_uncore_read(gt->uncore, CHV_POWER_SS1_SIG2);
+
+ for (ss = 0; ss < ss_max; ss++) {
+ unsigned int eu_cnt;
+
+ if (sig1[ss] & CHV_SS_PG_ENABLE)
+ /* skip disabled subslice */
+ continue;
+
+ sseu->slice_mask = BIT(0);
+ sseu->subslice_mask[0] |= BIT(ss);
+ eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) +
+((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) +
+((sig2[ss] & CHV_EU311_PG_ENABLE) ? 0 : 2);
+ sseu->eu_total += eu_cnt;
+ sseu->eu_per_subslice = max_t(unsigned int,
+ sseu->eu_per_subslice, eu_cnt);
+ }
+#undef SS_MAX
+}
+
+static void gen10_sseu_device_status(struct intel_gt *gt,
+struct sseu_dev_info *sseu)
+{
+#define SS_MAX 6
+ const struct intel_runtime_info *info = RUNTIME_INFO(gt->i915);
+ u32 s_reg[SS_MAX], eu_reg[2 * SS_MAX], eu_mask[2];
+ int s, ss;
+
+ for (s = 0; s < info->sseu.max_slices; s++) {
+ /*
+* FIXME: Valid SS Mask respects the spec and read
+* only valid bits for those registers, excluding reserved
+* although this seems wrong because it would leave many
+* subslices without ACK.
+*/
+ s_reg[s] = intel_uncore_read(gt->uncore,
+GEN10_SLICE_PGCTL_ACK(s)) &
+ GEN10_PGCTL_VALID_SS_MASK(s);
+ eu_reg[2 * s] = intel_uncore_read(gt->uncore,
+ GEN10_SS01_EU_PGCTL_ACK(s));
+ eu_reg[2 * s + 1] = intel_uncore_read(gt->uncore,
+ GEN10_SS23_EU_PGCTL_ACK(s));
+ }
+
+ eu_mask[0] = GEN9_PGCTL_SSA_EU08_ACK |
+GEN9_PGCTL_SSA_EU19_ACK |
+GEN9_PGCTL_SSA_EU210_ACK |
+GEN9_PGCTL_SSA_EU311_ACK;
+ eu_mask[1] = GEN9_PGCTL_SSB_EU08_ACK |
+GEN9_PGCTL_SSB_EU19_ACK |
+GEN9_PGCTL_SSB_EU210_ACK |
+GEN9_PGCTL_SSB_EU311_ACK;
+
+ for (s = 0; s < info->sseu.max_slices; s++) {
+ if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0)
+ /* skip disabled slice */
+ continue;
+
+ sseu->slice_mask |= BIT(s);
+ intel_sseu_copy_subslices(>sseu, s, sseu->subslice_mask);
+
+ for (ss = 0; ss <
[Intel-gfx] [PATCH 09/13] drm/i915/tv: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_tv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
b/drivers/gpu/drm/i915/display/intel_tv.c
index d2e3a3a323e9..5de39cfce054 100644
--- a/drivers/gpu/drm/i915/display/intel_tv.c
+++ b/drivers/gpu/drm/i915/display/intel_tv.c
@@ -1698,13 +1698,13 @@ intel_tv_detect(struct drm_connector *connector,
struct drm_modeset_acquire_ctx *ctx,
bool force)
{
+ struct drm_i915_private *i915 = to_i915(connector->dev);
struct intel_tv *intel_tv =
intel_attached_tv(to_intel_connector(connector));
enum drm_connector_status status;
int type;
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force=%d\n",
- connector->base.id, connector->name,
- force);
+ drm_dbg_kms(>drm, "[CONNECTOR:%d:%s] force=%d\n",
+ connector->base.id, connector->name, force);
if (force) {
struct intel_load_detect_pipe tmp;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/13] drm/i915/display: clean up intel_PLL_is_valid()
Drop useless macro hiding the return. Fix superfluous whitespace. Rename
function to all lowercase.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 40 ++--
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 37bd7ce88ecd..6af8d43ceb0c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -620,45 +620,43 @@ int chv_calc_dpll_params(int refclk, struct dpll *clock)
return clock->dot / 5;
}
-#define INTELPllInvalid(s) do { /* DRM_DEBUG(s); */ return false; } while (0)
-
/*
* Returns whether the given set of divisors are valid for a given refclk with
* the given connectors.
*/
-static bool intel_PLL_is_valid(struct drm_i915_private *dev_priv,
+static bool intel_pll_is_valid(struct drm_i915_private *dev_priv,
const struct intel_limit *limit,
const struct dpll *clock)
{
- if (clock->n < limit->n.min || limit->n.max < clock->n)
- INTELPllInvalid("n out of range\n");
- if (clock->p1 < limit->p1.min || limit->p1.max < clock->p1)
- INTELPllInvalid("p1 out of range\n");
- if (clock->m2 < limit->m2.min || limit->m2.max < clock->m2)
- INTELPllInvalid("m2 out of range\n");
- if (clock->m1 < limit->m1.min || limit->m1.max < clock->m1)
- INTELPllInvalid("m1 out of range\n");
+ if (clock->n < limit->n.min || limit->n.max < clock->n)
+ return false;
+ if (clock->p1 < limit->p1.min || limit->p1.max < clock->p1)
+ return false;
+ if (clock->m2 < limit->m2.min || limit->m2.max < clock->m2)
+ return false;
+ if (clock->m1 < limit->m1.min || limit->m1.max < clock->m1)
+ return false;
if (!IS_PINEVIEW(dev_priv) && !IS_VALLEYVIEW(dev_priv) &&
!IS_CHERRYVIEW(dev_priv) && !IS_GEN9_LP(dev_priv))
if (clock->m1 <= clock->m2)
- INTELPllInvalid("m1 <= m2\n");
+ return false;
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
!IS_GEN9_LP(dev_priv)) {
if (clock->p < limit->p.min || limit->p.max < clock->p)
- INTELPllInvalid("p out of range\n");
+ return false;
if (clock->m < limit->m.min || limit->m.max < clock->m)
- INTELPllInvalid("m out of range\n");
+ return false;
}
if (clock->vco < limit->vco.min || limit->vco.max < clock->vco)
- INTELPllInvalid("vco out of range\n");
+ return false;
/* XXX: We may need to be checking "Dot clock" depending on the
multiplier,
* connector, etc., rather than just a single range.
*/
if (clock->dot < limit->dot.min || limit->dot.max < clock->dot)
- INTELPllInvalid("dot out of range\n");
+ return false;
return true;
}
@@ -725,7 +723,7 @@ i9xx_find_best_dpll(const struct intel_limit *limit,
int this_err;
i9xx_calc_dpll_params(refclk, );
- if (!intel_PLL_is_valid(to_i915(dev),
+ if (!intel_pll_is_valid(to_i915(dev),
limit,
))
continue;
@@ -781,7 +779,7 @@ pnv_find_best_dpll(const struct intel_limit *limit,
int this_err;
pnv_calc_dpll_params(refclk, );
- if (!intel_PLL_is_valid(to_i915(dev),
+ if (!intel_pll_is_valid(to_i915(dev),
limit,
))
continue;
@@ -842,7 +840,7 @@ g4x_find_best_dpll(const struct intel_limit *limit,
int this_err;
i9xx_calc_dpll_params(refclk, );
- if (!intel_PLL_is_valid(to_i915(dev),
+ if (!intel_pll_is_valid(to_i915(dev),
limit,
))
continue;
@@ -939,7 +937,7 @@ vlv_find_best_dpll(const struct intel_limit *limit,
vlv_calc_dpll_params(refclk, );
-
[Intel-gfx] [PATCH 11/13] drm/i915/display: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 25 +++-
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6af8d43ceb0c..fe55c7c713f1 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2908,6 +2908,7 @@ intel_fb_plane_get_subsampling(int *hsub, int *vsub,
static int
intel_fb_check_ccs_xy(struct drm_framebuffer *fb, int ccs_plane, int x, int y)
{
+ struct drm_i915_private *i915 = to_i915(fb->dev);
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
int main_plane;
int hsub, vsub;
@@ -2936,7 +2937,8 @@ intel_fb_check_ccs_xy(struct drm_framebuffer *fb, int
ccs_plane, int x, int y)
* x/y offsets must match between CCS and the main surface.
*/
if (main_x != ccs_x || main_y != ccs_y) {
- DRM_DEBUG_KMS("Bad CCS x/y (main %d,%d ccs %d,%d) full (main
%d,%d ccs %d,%d)\n",
+ drm_dbg_kms(>drm,
+ "Bad CCS x/y (main %d,%d ccs %d,%d) full (main
%d,%d ccs %d,%d)\n",
main_x, main_y,
ccs_x, ccs_y,
intel_fb->normal[main_plane].x,
@@ -12882,16 +12884,17 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
return 0;
}
-static void intel_dump_crtc_timings(const struct drm_display_mode *mode)
+static void intel_dump_crtc_timings(struct drm_i915_private *i915,
+ const struct drm_display_mode *mode)
{
- DRM_DEBUG_KMS("crtc timings: %d %d %d %d %d %d %d %d %d, "
- "type: 0x%x flags: 0x%x\n",
- mode->crtc_clock,
- mode->crtc_hdisplay, mode->crtc_hsync_start,
- mode->crtc_hsync_end, mode->crtc_htotal,
- mode->crtc_vdisplay, mode->crtc_vsync_start,
- mode->crtc_vsync_end, mode->crtc_vtotal,
- mode->type, mode->flags);
+ drm_dbg_kms(>drm, "crtc timings: %d %d %d %d %d %d %d %d %d, "
+ "type: 0x%x flags: 0x%x\n",
+ mode->crtc_clock,
+ mode->crtc_hdisplay, mode->crtc_hsync_start,
+ mode->crtc_hsync_end, mode->crtc_htotal,
+ mode->crtc_vdisplay, mode->crtc_vsync_start,
+ mode->crtc_vsync_end, mode->crtc_vtotal,
+ mode->type, mode->flags);
}
static inline void
@@ -13075,7 +13078,7 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
drm_mode_debug_printmodeline(_config->hw.mode);
drm_dbg_kms(_priv->drm, "adjusted mode:\n");
drm_mode_debug_printmodeline(_config->hw.adjusted_mode);
- intel_dump_crtc_timings(_config->hw.adjusted_mode);
+ intel_dump_crtc_timings(dev_priv, _config->hw.adjusted_mode);
drm_dbg_kms(_priv->drm,
"port clock: %d, pipe src size: %dx%d, pixel rate %d\n",
pipe_config->port_clock,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/13] drm/i915/psr: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Generated using the following semantic patch, originally written by
Wambui Karuga , with manual fixups on top:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_NOTE(
+drm_notice(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
Cc: Wambui Karuga
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_psr.c | 47 +---
1 file changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index fd9b146e3aba..a0569fdfeb16 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -137,41 +137,42 @@ static void psr_irq_control(struct drm_i915_private
*dev_priv)
intel_de_write(dev_priv, imr_reg, val);
}
-static void psr_event_print(u32 val, bool psr2_enabled)
+static void psr_event_print(struct drm_i915_private *i915,
+ u32 val, bool psr2_enabled)
{
- DRM_DEBUG_KMS("PSR exit events: 0x%x\n", val);
+ drm_dbg_kms(>drm, "PSR exit events: 0x%x\n", val);
if (val & PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
- DRM_DEBUG_KMS("\tPSR2 watchdog timer expired\n");
+ drm_dbg_kms(>drm, "\tPSR2 watchdog timer expired\n");
if ((val & PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
- DRM_DEBUG_KMS("\tPSR2 disabled\n");
+ drm_dbg_kms(>drm, "\tPSR2 disabled\n");
if (val & PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
- DRM_DEBUG_KMS("\tSU dirty FIFO underrun\n");
+ drm_dbg_kms(>drm, "\tSU dirty FIFO underrun\n");
if (val & PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
- DRM_DEBUG_KMS("\tSU CRC FIFO underrun\n");
+ drm_dbg_kms(>drm, "\tSU CRC FIFO underrun\n");
if (val & PSR_EVENT_GRAPHICS_RESET)
- DRM_DEBUG_KMS("\tGraphics reset\n");
+ drm_dbg_kms(>drm, "\tGraphics reset\n");
if (val & PSR_EVENT_PCH_INTERRUPT)
- DRM_DEBUG_KMS("\tPCH interrupt\n");
+ drm_dbg_kms(>drm, "\tPCH interrupt\n");
if (val & PSR_EVENT_MEMORY_UP)
- DRM_DEBUG_KMS("\tMemory up\n");
+ drm_dbg_kms(>drm, "\tMemory up\n");
if (val & PSR_EVENT_FRONT_BUFFER_MODIFY)
- DRM_DEBUG_KMS("\tFront buffer modification\n");
+ drm_dbg_kms(>drm, "\tFront buffer modification\n");
if (val & PSR_EVENT_WD_TIMER_EXPIRE)
- DRM_DEBUG_KMS("\tPSR watchdog timer expired\n");
+ drm_dbg_kms(>drm, "\tPSR watchdog timer expired\n");
if (val & PSR_EVENT_PIPE_REGISTERS_UPDATE)
- DRM_DEBUG_KMS("\tPIPE registers updated\n");
+ drm_dbg_kms(>drm, "\tPIPE registers updated\n");
if (val & PSR_EVENT_REGISTER_UPDATE)
- DRM_DEBUG_KMS("\tRegister updated\n");
+ drm_dbg_kms(>drm, "\tRegister updated\n");
if (val & PSR_EVENT_HDCP_ENABLE)
- DRM_DEBUG_KMS("\tHDCP enabled\n");
+ drm_dbg_kms(>drm, "\tHDCP enabled\n");
if (val & PSR_EVENT_KVMR_SESSION_ENABLE)
- DRM_DEBUG_KMS("\tKVMR session enabled\n");
+ drm_dbg_kms(>drm, "\tKVMR session enabled\n");
if (val & PSR_EVENT_VBI_ENABLE)
- DRM_DEBUG_KMS("\tVBI enabled\n");
+ drm_dbg_kms(>drm, "\tVBI enabled\n");
if (val & PSR_EVENT_LPSP_MODE_EXIT)
- DRM_DEBUG_KMS("\tLPSP mode exited\n");
+ drm_dbg_kms(>drm, "\tLPSP mode exited\n");
if ((val & PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
- DRM_DEBUG_KMS("\tPSR disabled\n");
+ drm_dbg_kms(>drm, "\tPSR disabled\n");
}
void intel_psr_irq_handler(struct drm_i915_private *dev_priv, u32 psr_iir)
@@ -209,7 +210,7 @@ void intel_psr_irq_handler(struct drm_i915_private
*dev_priv, u32 psr_iir)
intel_de_write(dev_priv, PSR_EVENT(cpu_transcoder),
val);
- psr_event_print(val, psr2_enabled);
+ psr_event_print(dev_priv, val, psr2_enabled);
}
}
@@ -249,18 +250,21 @@ static bool intel_dp_get_alpm_status(struct intel_dp
*intel_dp)
static u8
[Intel-gfx] [PATCH 07/13] drm/i915/dsi: use struct drm_device based logging
Convert all the DRM_* logging macros to the struct drm_device based
macros to provide device specific logging.
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 10 +++---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 11 +--
drivers/gpu/drm/i915/display/vlv_dsi.c | 3 ++-
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 17cee6f80d8b..1ca1f377419c 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -186,16 +186,19 @@ static int dsi_send_pkt_hdr(struct intel_dsi_host *host,
static int dsi_send_pkt_payld(struct intel_dsi_host *host,
struct mipi_dsi_packet pkt)
{
+ struct intel_dsi *intel_dsi = host->intel_dsi;
+ struct drm_i915_private *i915 = to_i915(intel_dsi->base.base.dev);
+
/* payload queue can accept *256 bytes*, check limit */
if (pkt.payload_length > MAX_PLOAD_CREDIT * 4) {
- DRM_ERROR("payload size exceeds max queue limit\n");
+ drm_err(>drm, "payload size exceeds max queue limit\n");
return -1;
}
/* load data into command payload queue */
if (!add_payld_to_queue(host, pkt.payload,
pkt.payload_length)) {
- DRM_ERROR("adding payload to queue failed\n");
+ drm_err(>drm, "adding payload to queue failed\n");
return -1;
}
@@ -1417,6 +1420,7 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
base);
struct intel_connector *intel_connector = intel_dsi->attached_connector;
@@ -1446,7 +1450,7 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
pipe_config->clock_set = true;
if (gen11_dsi_dsc_compute_config(encoder, pipe_config))
- DRM_DEBUG_KMS("Attempting to use DSC failed\n");
+ drm_dbg_kms(>drm, "Attempting to use DSC failed\n");
pipe_config->port_clock = afe_clk(encoder, pipe_config) / 5;
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 574dcfec9577..3c9c05478a03 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -453,8 +453,7 @@ static inline void i2c_acpi_find_adapter(struct intel_dsi
*intel_dsi,
static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
{
- struct drm_device *drm_dev = intel_dsi->base.base.dev;
- struct device *dev = _dev->pdev->dev;
+ struct drm_i915_private *i915 = to_i915(intel_dsi->base.base.dev);
struct i2c_adapter *adapter;
struct i2c_msg msg;
int ret;
@@ -471,7 +470,7 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi,
const u8 *data)
adapter = i2c_get_adapter(intel_dsi->i2c_bus_num);
if (!adapter) {
- DRM_DEV_ERROR(dev, "Cannot find a valid i2c bus for xfer\n");
+ drm_err(>drm, "Cannot find a valid i2c bus for xfer\n");
goto err_bus;
}
@@ -489,9 +488,9 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi,
const u8 *data)
ret = i2c_transfer(adapter, , 1);
if (ret < 0)
- DRM_DEV_ERROR(dev,
- "Failed to xfer payload of size (%u) to reg
(%u)\n",
- payload_size, reg_offset);
+ drm_err(>drm,
+ "Failed to xfer payload of size (%u) to reg (%u)\n",
+ payload_size, reg_offset);
kfree(payload_data);
err_alloc:
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index f4c362dc6e15..456909ee37a7 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -875,10 +875,11 @@ static void intel_dsi_disable(struct intel_encoder
*encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
enum port port;
- DRM_DEBUG_KMS("\n");
+ drm_dbg_kms(>drm, "\n");
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_panel_disable_backlight(old_conn_state);
--
2.20.1
___
[Intel-gfx] [PATCH 08/13] drm/i915/connector: use MISSING_CASE instead of logging
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 903e49659f56..98ec2ea86c7c 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -290,7 +290,7 @@ intel_attach_colorspace_property(struct drm_connector
*connector)
return;
break;
default:
- DRM_DEBUG_KMS("Colorspace property not supported\n");
+ MISSING_CASE(connector->connector_type);
return;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Report context-is-closed prior to pinning
== Series Details == Series: drm/i915/gt: Report context-is-closed prior to pinning URL : https://patchwork.freedesktop.org/series/74916/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8163_full -> Patchwork_17034_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17034_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17034_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_17034_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@close-replace-race: - shard-apl: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-apl6/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-apl8/igt@gem_ctx_persiste...@close-replace-race.html Warnings * igt@gem_ctx_persistence@close-replace-race: - shard-skl: [INCOMPLETE][3] ([i915#1402]) -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-skl9/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-skl6/igt@gem_ctx_persiste...@close-replace-race.html Known issues Here are the changes found in Patchwork_17034_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#1340]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-iclb8/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +10 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276] / [i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +13 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb4/igt@gem_exec_sched...@out-order-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-iclb8/igt@gem_exec_sched...@out-order-bsd2.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb3/igt@gem_exec_sched...@pi-userfault-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-iclb1/igt@gem_exec_sched...@pi-userfault-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112146]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-kbl7/igt@gem_exec_susp...@basic-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-kbl2/igt@gem_exec_susp...@basic-s3.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#69]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-skl8/igt@gem_exec_susp...@basic-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-skl4/igt@gem_exec_susp...@basic-s3.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8163/shard-apl8/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17034/shard-apl1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_selftest@live@execlists:
Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
On Fri, Mar 20, 2020 at 06:19:37AM +, Shankar, Uma wrote: > > > > -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. How about just fixing the uapi vs. hw fail I showed instead of adding even more hacks? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915/gt: Report context-is-closed prior to pinning
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Report context-is-closed prior
to pinning
URL : https://patchwork.freedesktop.org/series/74918/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17037
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17037 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17037, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17037:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@execlists:
- fi-kbl-r: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-r/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-kbl-r/igt@i915_selftest@l...@execlists.html
- fi-cfl-8109u: [PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-apl-guc: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-apl-guc/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-apl-guc/igt@i915_selftest@l...@execlists.html
- fi-kbl-x1275: [PASS][7] -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-x1275/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-kbl-x1275/igt@i915_selftest@l...@execlists.html
- fi-skl-6600u: [PASS][9] -> [DMESG-FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-skl-6600u/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-skl-6600u/igt@i915_selftest@l...@execlists.html
- fi-bsw-kefka: [PASS][11] -> [DMESG-FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050: [PASS][13] -> [DMESG-FAIL][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
- fi-skl-guc: [PASS][15] -> [DMESG-FAIL][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-skl-guc/igt@i915_selftest@l...@execlists.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-skl-guc/igt@i915_selftest@l...@execlists.html
- fi-bxt-dsi: [PASS][17] -> [DMESG-FAIL][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
- fi-bdw-5557u: [PASS][19] -> [DMESG-FAIL][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html
- fi-kbl-7500u: [PASS][21] -> [DMESG-FAIL][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-7500u/igt@i915_selftest@l...@execlists.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-kbl-7500u/igt@i915_selftest@l...@execlists.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@execlists:
- {fi-ehl-1}: [PASS][23] -> [DMESG-FAIL][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-ehl-1/igt@i915_selftest@l...@execlists.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17037/fi-ehl-1/igt@i915_selftest@l...@execlists.html
Known issues
Here are the changes found in Patchwork_17037 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-cfl-guc: [PASS][25] -> [INCOMPLETE][26] ([i915#656])
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-cfl-guc/igt@i915_selftest@l...@execlists.html
[26]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission (rev2)
== Series Details == Series: drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission (rev2) URL : https://patchwork.freedesktop.org/series/74914/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17035 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17035 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17035, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17035: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@basic-rte: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-bsw-kefka/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-bsw-kefka/igt@i915_pm_...@basic-rte.html * igt@i915_selftest@live@execlists: - fi-kbl-r: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-r/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-kbl-r/igt@i915_selftest@l...@execlists.html - fi-cfl-8109u: [PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html - fi-skl-lmem:[PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-skl-lmem/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-skl-lmem/igt@i915_selftest@l...@execlists.html - fi-kbl-x1275: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-x1275/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-kbl-x1275/igt@i915_selftest@l...@execlists.html - fi-icl-u2: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-icl-u2/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-icl-u2/igt@i915_selftest@l...@execlists.html - fi-skl-6600u: [PASS][13] -> [DMESG-FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-skl-6600u/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-skl-6600u/igt@i915_selftest@l...@execlists.html - fi-skl-guc: [PASS][15] -> [DMESG-FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-skl-guc/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-skl-guc/igt@i915_selftest@l...@execlists.html - fi-cfl-guc: [PASS][17] -> [DMESG-FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-cfl-guc/igt@i915_selftest@l...@execlists.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-cfl-guc/igt@i915_selftest@l...@execlists.html - fi-cml-u2: [PASS][19] -> [DMESG-FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-cml-u2/igt@i915_selftest@l...@execlists.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-cml-u2/igt@i915_selftest@l...@execlists.html - fi-kbl-guc: [PASS][21] -> [DMESG-FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-guc/igt@i915_selftest@l...@execlists.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-kbl-guc/igt@i915_selftest@l...@execlists.html - fi-bdw-5557u: [PASS][23] -> [DMESG-FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html - fi-kbl-7500u: [PASS][25] -> [DMESG-FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-7500u/igt@i915_selftest@l...@execlists.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-kbl-7500u/igt@i915_selftest@l...@execlists.html - fi-kbl-8809g: [PASS][27] -> [DMESG-FAIL][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-8809g/igt@i915_selftest@l...@execlists.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-kbl-8809g/igt@i915_selftest@l...@execlists.html -
Re: ✗ Fi.CI.BAT: failure for drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission (rev2)
Quoting Patchwork (2020-03-20 17:02:49) > * igt@i915_selftest@live@execlists: > - fi-kbl-r: [PASS][3] -> [DMESG-FAIL][4] >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-r/igt@i915_selftest@l...@execlists.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17035/fi-kbl-r/igt@i915_selftest@l...@execlists.html No worries, the test was expecting lite-restore direct submission which we suppressed instead. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Immediately execute the fenced work (rev2)
== Series Details == Series: drm/i915: Immediately execute the fenced work (rev2) URL : https://patchwork.freedesktop.org/series/74917/ State : success == Summary == CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17036 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/index.html Known issues Here are the changes found in Patchwork_17036 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] / [i915#1430] / [i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-apl-guc/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/fi-apl-guc/igt@i915_selftest@l...@execlists.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][3] ([CI#94]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-crc-fast: - fi-icl-u2: [FAIL][5] ([fdo#109635] / [i915#217]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][7] ([fdo#111407]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (49 -> 42) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8167 -> Patchwork_17036 CI-20190529: 20190529 CI_DRM_8167: b51a7e7f4f72cf780661a1e4b479e2b27ddbafc8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5526: f49ebeee9f54d6f23c60a842f75f65561d452ab0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17036: 4568cf81d30bf68ad8124e6b8d8b6322e8fc9113 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4568cf81d30b drm/i915: Immediately execute the fenced work == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/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: Trigger Modeset at boot for audio codec init
Hi Ville,
You means this change right? Sure. Will try your suggestion as well.
By the way, what is different between hw.mode and uapi.mode and how we know
which to be used? It used to only base.mode before hw/uapi split patches.
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14671,8 +14671,8 @@ static int intel_atomic_check(struct drm_device *dev,
> /* Catch I915_MODE_FLAG_INHERITED */
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> - if (new_crtc_state->hw.mode.private_flags !=
> - old_crtc_state->hw.mode.private_flags)
> + if (new_crtc_state->uapi.mode.private_flags !=
> + old_crtc_state->uapi.mode.private_flags)
> new_crtc_state->uapi.mode_changed = true;
> }
>
> ?
Regards,
SweeAun
-Original Message-
From: Ville Syrjälä
Sent: Friday, March 20, 2020 11:24 PM
To: Shankar, Uma
Cc: Souza, Jose ; intel-gfx@lists.freedesktop.org; Khor,
Swee Aun
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for
audio codec init
On Fri, Mar 20, 2020 at 06:19:37AM +, Shankar, Uma wrote:
>
>
> > -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.
How about just fixing the uapi vs. hw fail I showed instead of adding even more
hacks?
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct submission if we can acquire the tasklet's lock.
v2: Tweak the balance to avoid over submitting lite-restores
Signed-off-by: Chris Wilson
Cc: Francisco Jerez
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 44 --
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
2 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f09dd87324b9..dceb65a0088f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2884,17 +2884,17 @@ static void queue_request(struct intel_engine_cs
*engine,
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
-static void __submit_queue_imm(struct intel_engine_cs *engine)
+static bool pending_csb(const struct intel_engine_execlists *el)
{
- struct intel_engine_execlists * const execlists = >execlists;
+ return READ_ONCE(*el->csb_write) != READ_ONCE(el->csb_head);
+}
- if (reset_in_progress(execlists))
- return; /* defer until we restart the engine following reset */
+static bool skip_lite_restore(struct intel_engine_execlists *el,
+ const struct i915_request *rq)
+{
+ struct i915_request *inflight = execlists_active(el);
- if (execlists->tasklet.func == execlists_submission_tasklet)
- __execlists_submission_tasklet(engine);
- else
- tasklet_hi_schedule(>tasklet);
+ return inflight && inflight->context == rq->context;
}
static void submit_queue(struct intel_engine_cs *engine,
@@ -2905,8 +2905,34 @@ static void submit_queue(struct intel_engine_cs *engine,
if (rq_prio(rq) <= execlists->queue_priority_hint)
return;
+ if (reset_in_progress(execlists))
+ return; /* defer until we restart the engine following reset */
+
+ /*
+* Suppress immediate lite-restores, leave that to the tasklet.
+*
+* However, we leave the queue_priority_hint unset so that if we do
+* submit a second context, we push that into ELSP[1] immediately.
+*/
+ if (skip_lite_restore(execlists, rq))
+ return;
+
+ /* Hopefully we clear execlists->pending[] to let us through */
+ if (execlists->pending[0] && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ if (skip_lite_restore(execlists, rq))
+ return;
+ }
+
execlists->queue_priority_hint = rq_prio(rq);
- __submit_queue_imm(engine);
+ __execlists_submission_tasklet(engine);
+
+ /* Try and pull an interrupt-bh queued on another CPU to here */
+ if (pending_csb(execlists) && tasklet_trylock(>tasklet)) {
+ process_csb(engine);
+ tasklet_unlock(>tasklet);
+ }
}
static bool ancestor_on_hold(const struct intel_engine_cs *engine,
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 6f06ba750a0a..c5c4b07a7d5f 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1028,7 +1028,7 @@ static int live_timeslice_rewind(void *arg)
if (IS_ERR(rq[1]))
goto err;
- err = wait_for_submit(engine, rq[1], HZ / 2);
+ err = wait_for_submit(engine, rq[0], HZ / 2);
if (err) {
pr_err("%s: failed to submit first context\n",
engine->name);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Get rid of silly void* from MST code (rev2)
== Series Details == Series: drm/i915: Get rid of silly void* from MST code (rev2) URL : https://patchwork.freedesktop.org/series/74539/ State : success == Summary == CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17039 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/index.html Known issues Here are the changes found in Patchwork_17039 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#189]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-icl-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/fi-icl-dsi/igt@i915_pm_...@module-reload.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_8167/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/fi-cml-s/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][5] ([CI#94]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-crc-fast: - fi-icl-u2: [FAIL][7] ([fdo#109635] / [i915#217]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html Warnings * 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_8167/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (49 -> 39) -- Additional (1): fi-skl-6770hq Missing(11): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-bdw-samus fi-byt-clapper fi-skl-6600u fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8167 -> Patchwork_17039 CI-20190529: 20190529 CI_DRM_8167: b51a7e7f4f72cf780661a1e4b479e2b27ddbafc8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5526: f49ebeee9f54d6f23c60a842f75f65561d452ab0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17039: d91996e50770660c5d42c30a8d6c8b746717cb75 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d91996e50770 drm/i915: Get rid of silly void* from MST code == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/index.html ___ 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 03:20:50PM -0700, Manasi Navare wrote:
> 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?
No. Why do you think it needs to be removed?
--
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 5/6] drm/i915/tc/icl: Implement the TC cold exit sequence
On Fri, 2020-03-20 at 16:11 +0300, Dan Carpenter wrote:
> Hi "José,
>
> Thank you for the patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Jos-Roberto-de-Souza/drm-i915-tc-tgl-Implement-TCCOLD-sequences/20200319-080253
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
> Reported-by: Dan Carpenter
>
> smatch warnings:
> drivers/gpu/drm/i915/display/intel_tc.c:554 icl_tc_cold_request()
> error: uninitialized symbol 'ret'.
>
> #
> https://github.com/0day-ci/linux/commit/29f27e6df6ad82b09a3c9ddaf5f51b2fc1647178
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 29f27e6df6ad82b09a3c9ddaf5f51b2fc1647178
> vim +/ret +554 drivers/gpu/drm/i915/display/intel_tc.c
>
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 528 static inline
> int icl_tc_cold_request(struct intel_digital_port *dig_port,
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 529
> bool block)
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 530 {
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 531 struct
> drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 532 enum
> intel_display_power_domain aux_domain;
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 533 int
> ret;
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 534
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 535 aux_dom
> ain = intel_aux_ch_to_power_domain(dig_port->aux_ch);
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 536
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 537 if
> (block) {
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 538
> dig_port->tc_cold_wakeref =
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 539
> intel_display_power_get_without_ack(i915, aux_domain);
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 540
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 541
> do {
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 542
> ret = sandybridge_pcode_write_timeout(i915,
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 543
> ICL_PCODE_EXIT_TCCOLD,
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 544
> 0, 250, 1);
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 545
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 546
> } while (ret == -EAGAIN);
>
> ret is only initialized on this path
Thanks
>
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 547 } else
> if (dig_port->tc_mode == TC_PORT_LEGACY) {
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 548
> drm_WARN_ON(>drm, !dig_port->tc_lock_wakeref);
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 549
> intel_display_power_put(i915, aux_domain,
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 550
> dig_port->tc_cold_wakeref);
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 551
> dig_port->tc_cold_wakeref = 0;
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 552 }
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 553
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 @554 return
> ret;
> 29f27e6df6ad82 José Roberto de Souza 2020-03-18 555 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
___
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/gt: Report context-is-closed prior to pinning (rev2)
== Series Details == Series: series starting with [1/4] drm/i915/gt: Report context-is-closed prior to pinning (rev2) URL : https://patchwork.freedesktop.org/series/74918/ State : success == Summary == CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17041 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/index.html Known issues Here are the changes found in Patchwork_17041 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][1] ([CI#94]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-crc-fast: - fi-icl-u2: [FAIL][3] ([fdo#109635] / [i915#217]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 Participating hosts (49 -> 38) -- Additional (1): fi-skl-6770hq Missing(12): fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-kbl-7500u fi-ctg-p8600 fi-ivb-3770 fi-skl-lmem fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8167 -> Patchwork_17041 CI-20190529: 20190529 CI_DRM_8167: b51a7e7f4f72cf780661a1e4b479e2b27ddbafc8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5526: f49ebeee9f54d6f23c60a842f75f65561d452ab0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17041: e1571c1ed506ad288f8064f5bc432aaceb66ad95 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e1571c1ed506 drm/i915/gem: Avoid gem_context->mutex for simple vma lookup 1492bcdd449a drm/i915: Immediately execute the fenced work bee757d6cbda drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
On Fri, 2020-03-20 at 00:20 +, Patchwork wrote: > == 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 Will update this test to handle the FBC changes. > > * 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 This two are handled by: https://patchwork.freedesktop.org/series/74606/ > > > 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]: >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hotplug cleanups (rev6)
== Series Details == Series: drm/i915: Hotplug cleanups (rev6) URL : https://patchwork.freedesktop.org/series/72348/ State : success == Summary == CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17038 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/index.html Known issues Here are the changes found in Patchwork_17038 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-glk-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#58] / [i915#656] / [k.org#198133]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-glk-dsi/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/fi-glk-dsi/igt@i915_selftest@l...@execlists.html Possible fixes * igt@kms_chamelium@hdmi-crc-fast: - fi-icl-u2: [FAIL][3] ([fdo#109635] / [i915#217]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][5] ([fdo#111407]) -> [FAIL][6] ([i915#323]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@runner@aborted: - fi-kbl-8809g: [FAIL][7] ([i915#1209]) -> [FAIL][8] ([i915#1485] / [i915#192] / [i915#193] / [i915#194]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-8809g/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/fi-kbl-8809g/igt@run...@aborted.html [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#1209]: https://gitlab.freedesktop.org/drm/intel/issues/1209 [i915#1485]: https://gitlab.freedesktop.org/drm/intel/issues/1485 [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192 [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193 [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (49 -> 37) -- Additional (2): fi-skl-6770hq fi-kbl-7560u Missing(14): fi-cml-u2 fi-ilk-m540 fi-bdw-5557u fi-cml-s fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-cfl-8109u fi-bsw-kefka fi-blb-e6850 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8167 -> Patchwork_17038 CI-20190529: 20190529 CI_DRM_8167: b51a7e7f4f72cf780661a1e4b479e2b27ddbafc8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5526: f49ebeee9f54d6f23c60a842f75f65561d452ab0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17038: 5ea9c1e2721b47853a773f52d426920ac5c4c633 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5ea9c1e2721b drm/i915: Use stashed away hpd isr bits in intel_digital_port_connected() 9bdedc5134f0 drm/i915: Stash hpd status bits under dev_priv 7a2933ed6c37 drm/i915: Turn intel_digital_port_connected() in a vfunc == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/index.html ___ 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: drm device based logging changes
== Series Details == Series: drm/i915: drm device based logging changes URL : https://patchwork.freedesktop.org/series/74927/ State : warning == Summary == $ dim checkpatch origin/drm-tip ddb4a444dd75 drm/i915/ddi: use struct drm_device based logging 07dd9ea10f43 drm/i915/display_power: use struct drm_device based logging df9678067397 drm/i915/dp_aux_backlight: use struct drm_device based logging 70006dcff1cf drm/i915/dp_mst: use struct drm_device based logging 96a362dca265 drm/i915/dsi: use struct drm_device based logging 6d311eabae6b drm/i915/hdmi: use struct drm_device based logging 2c83198c9de1 drm/i915/dsi: use struct drm_device based logging 0eea474ebae3 drm/i915/connector: use MISSING_CASE instead of logging -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one total: 0 errors, 1 warnings, 0 checks, 8 lines checked b1419778ed0f drm/i915/tv: use struct drm_device based logging 87560bf44a17 drm/i915/display: clean up intel_PLL_is_valid() c057e5d545d4 drm/i915/display: use struct drm_device based logging -:113: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #113: FILE: drivers/gpu/drm/i915/display/intel_display.c:2941: + drm_dbg_kms(>drm, + "Bad CCS x/y (main %d,%d ccs %d,%d) full (main %d,%d ccs %d,%d)\n", total: 0 errors, 0 warnings, 1 checks, 50 lines checked f022c9422f91 drm/i915/psr: use struct drm_device based logging 5196c0d8ee07 drm/i915/wopcm: convert to drm device based logging ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: drm device based logging changes
== Series Details == Series: drm/i915: drm device based logging changes URL : https://patchwork.freedesktop.org/series/74927/ State : success == Summary == CI Bug Log - changes from CI_DRM_8167 -> Patchwork_17040 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/index.html Known issues Here are the changes found in Patchwork_17040 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#656]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-cfl-guc/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/fi-cfl-guc/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_8167/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/fi-cml-s/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@kms_chamelium@hdmi-crc-fast: - fi-icl-u2: [FAIL][5] ([fdo#109635] / [i915#217]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][7] ([fdo#111407]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][9] ([CI#94]) -> [INCOMPLETE][10] ([CI#94] / [i915#460]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#460]: https://gitlab.freedesktop.org/drm/intel/issues/460 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (49 -> 42) -- Additional (2): fi-skl-6770hq fi-kbl-7560u Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-hsw-4770 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8167 -> Patchwork_17040 CI-20190529: 20190529 CI_DRM_8167: b51a7e7f4f72cf780661a1e4b479e2b27ddbafc8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5526: f49ebeee9f54d6f23c60a842f75f65561d452ab0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17040: 5196c0d8ee072e997c79eb7a258c2f9d25ab07d6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5196c0d8ee07 drm/i915/wopcm: convert to drm device based logging f022c9422f91 drm/i915/psr: use struct drm_device based logging c057e5d545d4 drm/i915/display: use struct drm_device based logging 87560bf44a17 drm/i915/display: clean up intel_PLL_is_valid() b1419778ed0f drm/i915/tv: use struct drm_device based logging 0eea474ebae3 drm/i915/connector: use MISSING_CASE instead of logging 2c83198c9de1 drm/i915/dsi: use struct drm_device based logging 6d311eabae6b drm/i915/hdmi: use struct drm_device based logging 96a362dca265 drm/i915/dsi: use struct drm_device based logging 70006dcff1cf drm/i915/dp_mst: use struct drm_device based logging df9678067397 drm/i915/dp_aux_backlight: use struct drm_device based logging 07dd9ea10f43 drm/i915/display_power: use struct drm_device based logging ddb4a444dd75 drm/i915/ddi: use struct drm_device based logging == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/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/execlists: Pull tasklet interrupt-bh local to direct submission
Chris Wilson writes:
> We dropped calling process_csb prior to handling direct submission in
> order to avoid the nesting of spinlocks and lift process_csb() and the
> majority of the tasklet out of irq-off. However, we do want to avoid
> ksoftirqd latency in the fast path, so try and pull the interrupt-bh
> local to direct submission if we can acquire the tasklet's lock.
>
> v2: Tweak the balance to avoid over submitting lite-restores
>
> Signed-off-by: Chris Wilson
> Cc: Francisco Jerez
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c| 44 --
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
> 2 files changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index f09dd87324b9..dceb65a0088f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2884,17 +2884,17 @@ static void queue_request(struct intel_engine_cs
> *engine,
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> }
>
> -static void __submit_queue_imm(struct intel_engine_cs *engine)
> +static bool pending_csb(const struct intel_engine_execlists *el)
> {
> - struct intel_engine_execlists * const execlists = >execlists;
> + return READ_ONCE(*el->csb_write) != READ_ONCE(el->csb_head);
> +}
>
> - if (reset_in_progress(execlists))
> - return; /* defer until we restart the engine following reset */
> +static bool skip_lite_restore(struct intel_engine_execlists *el,
> + const struct i915_request *rq)
> +{
> + struct i915_request *inflight = execlists_active(el);
>
> - if (execlists->tasklet.func == execlists_submission_tasklet)
> - __execlists_submission_tasklet(engine);
> - else
> - tasklet_hi_schedule(>tasklet);
> + return inflight && inflight->context == rq->context;
> }
>
> static void submit_queue(struct intel_engine_cs *engine,
> @@ -2905,8 +2905,34 @@ static void submit_queue(struct intel_engine_cs
> *engine,
> if (rq_prio(rq) <= execlists->queue_priority_hint)
> return;
>
> + if (reset_in_progress(execlists))
> + return; /* defer until we restart the engine following reset */
> +
> + /*
> + * Suppress immediate lite-restores, leave that to the tasklet.
> + *
> + * However, we leave the queue_priority_hint unset so that if we do
> + * submit a second context, we push that into ELSP[1] immediately.
> + */
> + if (skip_lite_restore(execlists, rq))
> + return;
> +
Why do you need to treat lite-restore specially here?
Anyway, trying this out now in combination with my patches now.
> + /* Hopefully we clear execlists->pending[] to let us through */
> + if (execlists->pending[0] && tasklet_trylock(>tasklet)) {
> + process_csb(engine);
> + tasklet_unlock(>tasklet);
> + if (skip_lite_restore(execlists, rq))
> + return;
> + }
> +
> execlists->queue_priority_hint = rq_prio(rq);
> - __submit_queue_imm(engine);
> + __execlists_submission_tasklet(engine);
> +
> + /* Try and pull an interrupt-bh queued on another CPU to here */
> + if (pending_csb(execlists) && tasklet_trylock(>tasklet)) {
> + process_csb(engine);
> + tasklet_unlock(>tasklet);
> + }
> }
>
> static bool ancestor_on_hold(const struct intel_engine_cs *engine,
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index 6f06ba750a0a..c5c4b07a7d5f 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -1028,7 +1028,7 @@ static int live_timeslice_rewind(void *arg)
> if (IS_ERR(rq[1]))
> goto err;
>
> - err = wait_for_submit(engine, rq[1], HZ / 2);
> + err = wait_for_submit(engine, rq[0], HZ / 2);
> if (err) {
> pr_err("%s: failed to submit first context\n",
> engine->name);
> --
> 2.20.1
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm: Constify adjusted_mode a bit
On Thu, Mar 19, 2020 at 06:38:44PM +0200, Ville Syrjala wrote:
> 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ä
Reviewed-by: Manasi Navare
Manasi
> ---
> 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 = _config->hw.adjusted_mode;
> + const struct drm_display_mode *adjusted_mode =
> + _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 = _config->hw.adjusted_mode;
> + const struct drm_display_mode *adjusted_mode =
> + _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
___
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 Thu, Mar 19, 2020 at 03:20:56PM +0200, Ville Syrjälä wrote:
> 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.
>
Yes for now there is nothing that we need to set.
So for now,
Reviewed-by: Manasi Navare
Manasi
> >
> > 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
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Pull tasklet interrupt-bh local to direct submission
Francisco Jerez writes:
> Chris Wilson writes:
>
>> We dropped calling process_csb prior to handling direct submission in
>> order to avoid the nesting of spinlocks and lift process_csb() and the
>> majority of the tasklet out of irq-off. However, we do want to avoid
>> ksoftirqd latency in the fast path, so try and pull the interrupt-bh
>> local to direct submission if we can acquire the tasklet's lock.
>>
>> v2: Tweak the balance to avoid over submitting lite-restores
>>
>> Signed-off-by: Chris Wilson
>> Cc: Francisco Jerez
>> Cc: Tvrtko Ursulin
>> ---
>> drivers/gpu/drm/i915/gt/intel_lrc.c| 44 --
>> drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
>> 2 files changed, 36 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> index f09dd87324b9..dceb65a0088f 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> @@ -2884,17 +2884,17 @@ static void queue_request(struct intel_engine_cs
>> *engine,
>> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
>> }
>>
>> -static void __submit_queue_imm(struct intel_engine_cs *engine)
>> +static bool pending_csb(const struct intel_engine_execlists *el)
>> {
>> -struct intel_engine_execlists * const execlists = >execlists;
>> +return READ_ONCE(*el->csb_write) != READ_ONCE(el->csb_head);
>> +}
>>
>> -if (reset_in_progress(execlists))
>> -return; /* defer until we restart the engine following reset */
>> +static bool skip_lite_restore(struct intel_engine_execlists *el,
>> + const struct i915_request *rq)
>> +{
>> +struct i915_request *inflight = execlists_active(el);
>>
>> -if (execlists->tasklet.func == execlists_submission_tasklet)
>> -__execlists_submission_tasklet(engine);
>> -else
>> -tasklet_hi_schedule(>tasklet);
>> +return inflight && inflight->context == rq->context;
>> }
>>
>> static void submit_queue(struct intel_engine_cs *engine,
>> @@ -2905,8 +2905,34 @@ static void submit_queue(struct intel_engine_cs
>> *engine,
>> if (rq_prio(rq) <= execlists->queue_priority_hint)
>> return;
>>
>> +if (reset_in_progress(execlists))
>> +return; /* defer until we restart the engine following reset */
>> +
>> +/*
>> + * Suppress immediate lite-restores, leave that to the tasklet.
>> + *
>> + * However, we leave the queue_priority_hint unset so that if we do
>> + * submit a second context, we push that into ELSP[1] immediately.
>> + */
>> +if (skip_lite_restore(execlists, rq))
>> +return;
>> +
> Why do you need to treat lite-restore specially here?
>
> Anyway, trying this out now in combination with my patches now.
>
This didn't seem to help (together with your other suggestion to move
the overload accounting to __execlists_schedule_in/out). And it makes
the current -5% SynMark OglMultithread regression with my series go down
to -10%. My previous suggestion of moving the
intel_gt_pm_active_begin() call to process_csb() when the submission is
ACK'ed by the hardware does seem to help (and it roughly halves the
OglMultithread regression), possibly because that way we're able to
determine whether the first context was actually overlapping at the
point that the second was received by the hardware -- I haven't tested
it extensively yet though.
>> +/* Hopefully we clear execlists->pending[] to let us through */
>> +if (execlists->pending[0] && tasklet_trylock(>tasklet)) {
>> +process_csb(engine);
>> +tasklet_unlock(>tasklet);
>> +if (skip_lite_restore(execlists, rq))
>> +return;
>> +}
>> +
>> execlists->queue_priority_hint = rq_prio(rq);
>> -__submit_queue_imm(engine);
>> +__execlists_submission_tasklet(engine);
>> +
>> +/* Try and pull an interrupt-bh queued on another CPU to here */
>> +if (pending_csb(execlists) && tasklet_trylock(>tasklet)) {
>> +process_csb(engine);
>> +tasklet_unlock(>tasklet);
>> +}
>> }
>>
>> static bool ancestor_on_hold(const struct intel_engine_cs *engine,
>> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> index 6f06ba750a0a..c5c4b07a7d5f 100644
>> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
>> @@ -1028,7 +1028,7 @@ static int live_timeslice_rewind(void *arg)
>> if (IS_ERR(rq[1]))
>> goto err;
>>
>> -err = wait_for_submit(engine, rq[1], HZ / 2);
>> +err = wait_for_submit(engine, rq[0], HZ / 2);
>> if (err) {
>> pr_err("%s: failed to submit first context\n",
>> engine->name);
>> --
>> 2.20.1
> ___
> Intel-gfx mailing list
>
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
On Fri, 2020-03-20 at 20:07 +, Souza, Jose wrote: > On Fri, 2020-03-20 at 00:20 +, Patchwork wrote: > > == 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 > > Will update this test to handle the FBC changes. Patches handling this case here: https://patchwork.freedesktop.org/series/74934/ Will merge this series monday unless someone is against it. > > > * 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 > > This two are handled by: > https://patchwork.freedesktop.org/series/74606/ > > > > > 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]: > >
Re: [Intel-gfx] [PATCH 03/13] drm/i915: Drop usless master_transcoder assignments
On Thu, Mar 19, 2020 at 03:22:06PM +0200, Ville Syrjälä wrote: > 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() > Okay got it with that Reviewed-by: Manasi Navare Manasi > > > > > 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 1/3] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure
On Fri, Mar 20, 2020 at 09:08:31PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 19, 2020 at 03:20:50PM -0700, Manasi Navare wrote:
> > 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?
>
> No. Why do you think it needs to be removed?
>
Okay so if trying max params link training again fails on eDP, then it
fallsback from max to lower values
and fallback link training continues until it can handle the fixed mode with
the params or
the lowest params?
So if I understand it correctly we first try to use the optimum approach, if
that fails then
we try with max params so in this iteration if it fails again then max params
is still true
then it will fallback and call intel_dp_can_link_train_fallback_for_edp() and
then
again keep retrying?
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 drm/i915: Immediately execute the fenced work (rev2)
== Series Details == Series: drm/i915: Immediately execute the fenced work (rev2) URL : https://patchwork.freedesktop.org/series/74917/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17036_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17036_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17036_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_17036_full: ### IGT changes ### Possible regressions * igt@gem_exec_parallel@vcs0-contexts: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl10/igt@gem_exec_paral...@vcs0-contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-skl1/igt@gem_exec_paral...@vcs0-contexts.html Known issues Here are the changes found in Patchwork_17036_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@gem_b...@busy-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-iclb8/igt@gem_b...@busy-vcs1.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb5/igt@gem_exec_as...@concurrent-writes-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#644]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-tglb1/igt@gem_pp...@flink-and-close-vma-leak.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-tglb1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#716]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl3/igt@gen9_exec_pa...@allowed-single.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-skl6/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc5-dpms: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#447]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb4/igt@i915_pm...@dc5-dpms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-iclb3/igt@i915_pm...@dc5-dpms.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#454]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb1/igt@i915_pm...@dc6-dpms.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#454]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl6/igt@i915_pm...@dc6-psr.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-skl7/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@i915_suspend@sysfs-reader: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl2/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17036/shard-kbl3/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-random: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#54]) +1 similar issue [23]:
Re: [Intel-gfx] [PATCH 01/13] drm/i915/mst: Use .compute_config_late() to compute master transcoder
This will not work for MST, here a example
Previous state:
MST master pipe A
MST slave pipe B
New state:
Pipe A being disabled
On drm_atomic_helper_check_modeset() both intel_crtc_states will be
added to the state with crtc_state->uapi.mode_changed=true.
Then on the regular for_each_oldnew_intel_crtc_in_state() loop config
of CRTC B will have mst_master_transcoder=INVALID_TRANSCODER that
differs from TRANSCODER_A and will keep mode_changed set.
Then on the config_late loop it will skip the interation on the
needs_modeset() check keeping CRTC B with
mst_master_transcoder=INVALID_TRANSCODER.
That would be caugh by CI if this tests were merged and the TGL machine
with MST is still on: https://patchwork.freedesktop.org/series/72211/
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the recently introduced encoder .compute_config_late() hook to
> do the MST master transcoder assignment. Avoids having to do it
> in a funny way before we know the CPU transcoder of each pipe.
>
> And now we can also properly use hw.active instead of uapi.active
> since it too has been calculated earlier for everyone.
>
> Cc: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 98 +++--
>
> 1 file changed, 51 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 44f3fd251ca1..b9afc1135b9b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -88,56 +88,10 @@ static int
> intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
> return 0;
> }
>
> -/*
> - * Iterate over all connectors and return the smallest transcoder in
> the MST
> - * stream
> - */
> -static enum transcoder
> -intel_dp_mst_master_trans_compute(struct intel_atomic_state *state,
> - struct intel_dp *mst_port)
> -{
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct intel_digital_connector_state *conn_state;
> - struct intel_connector *connector;
> - enum pipe ret = I915_MAX_PIPES;
> - int i;
> -
> - if (INTEL_GEN(dev_priv) < 12)
> - return INVALID_TRANSCODER;
> -
> - for_each_new_intel_connector_in_state(state, connector,
> conn_state, i) {
> - struct intel_crtc_state *crtc_state;
> - struct intel_crtc *crtc;
> -
> - if (connector->mst_port != mst_port || !conn_state-
> >base.crtc)
> - continue;
> -
> - crtc = to_intel_crtc(conn_state->base.crtc);
> - crtc_state = intel_atomic_get_new_crtc_state(state,
> crtc);
> - if (!crtc_state->uapi.active)
> - continue;
> -
> - /*
> - * Using crtc->pipe because crtc_state->cpu_transcoder
> is
> - * computed, so others CRTCs could have non-computed
> - * cpu_transcoder
> - */
> - if (crtc->pipe < ret)
> - ret = crtc->pipe;
> - }
> -
> - if (ret == I915_MAX_PIPES)
> - return INVALID_TRANSCODER;
> -
> - /* Simple cast works because TGL don't have a eDP transcoder */
> - return (enum transcoder)ret;
> -}
> -
> static int intel_dp_mst_compute_config(struct intel_encoder
> *encoder,
> struct intel_crtc_state
> *pipe_config,
> struct drm_connector_state
> *conn_state)
> {
> - struct intel_atomic_state *state =
> to_intel_atomic_state(conn_state->state);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> struct intel_dp *intel_dp = _mst->primary->dp;
> @@ -201,7 +155,56 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>
> intel_ddi_compute_min_voltage_level(dev_priv, pipe_config);
>
> - pipe_config->mst_master_transcoder =
> intel_dp_mst_master_trans_compute(state, intel_dp);
> + return 0;
> +}
> +
> +/*
> + * Iterate over all connectors and return a mask of
> + * all CPU transcoders streaming over the same DP link.
> + */
> +static unsigned int
> +intel_dp_mst_transcoder_mask(struct intel_atomic_state *state,
> + struct intel_dp *mst_port)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_digital_connector_state *conn_state;
> + struct intel_connector *connector;
> + u8 transcoders = 0;
> + int i;
> +
> + if (INTEL_GEN(dev_priv) < 12)
> + return 0;
> +
> + for_each_new_intel_connector_in_state(state, connector,
> conn_state, i) {
> + const struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> +
> + if (connector->mst_port != mst_port ||
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Get rid of silly void* from MST code (rev2)
== Series Details == Series: drm/i915: Get rid of silly void* from MST code (rev2) URL : https://patchwork.freedesktop.org/series/74539/ State : success == Summary == CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17039_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17039_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +15 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-iclb7/igt@gem_b...@busy-vcs1.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-iclb7/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb5/igt@gem_exec_sched...@in-order-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl6/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-skl10/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#413]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@i915_pm_...@waitboost.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-iclb7/igt@i915_pm_...@waitboost.html * igt@i915_selftest@live@execlists: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#656]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl9/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-skl3/igt@i915_selftest@l...@execlists.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([i915#155]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-kbl3/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#69]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-skl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@kms_psr@psr2_primary_mmap_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-iclb3/igt@kms_psr@psr2_primary_mmap_gtt.html * igt@kms_setmode@basic: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#31]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl4/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17039/shard-skl5/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][25] -> [DMESG-WARN][26] ([i915#180]) +1 similar issue [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-apl2/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [26]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/gt: Report context-is-closed prior to pinning (rev2)
== Series Details == Series: series starting with [1/4] drm/i915/gt: Report context-is-closed prior to pinning (rev2) URL : https://patchwork.freedesktop.org/series/74918/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17041_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17041_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17041_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_17041_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@replace@rcs0: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl6/igt@gem_ctx_persistence@repl...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-skl6/igt@gem_ctx_persistence@repl...@rcs0.html * igt@gem_ctx_persistence@smoketest: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-tglb1/igt@gem_ctx_persiste...@smoketest.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-tglb7/igt@gem_ctx_persiste...@smoketest.html - shard-kbl: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl3/igt@gem_ctx_persiste...@smoketest.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-kbl7/igt@gem_ctx_persiste...@smoketest.html - shard-iclb: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb8/igt@gem_ctx_persiste...@smoketest.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-iclb4/igt@gem_ctx_persiste...@smoketest.html * igt@gem_exec_async@concurrent-writes-bsd1: - shard-tglb: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-tglb7/igt@gem_exec_as...@concurrent-writes-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-tglb6/igt@gem_exec_as...@concurrent-writes-bsd1.html Warnings * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [TIMEOUT][11] ([i915#1340]) -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-tglb1/igt@gem_ctx_persiste...@close-replace-race.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-tglb7/igt@gem_ctx_persiste...@close-replace-race.html - shard-kbl: [DMESG-WARN][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl1/igt@gem_ctx_persiste...@close-replace-race.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-kbl7/igt@gem_ctx_persiste...@close-replace-race.html Known issues Here are the changes found in Patchwork_17041_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-apl1/igt@gem_ctx_isolat...@vecs0-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-apl1/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_ctx_persistence@smoketest: - shard-apl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103927]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-apl6/igt@gem_ctx_persiste...@smoketest.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-apl1/igt@gem_ctx_persiste...@smoketest.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109276]) +11 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#112146]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb6/igt@gem_exec_sched...@pi-ringfull-bsd.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17041/shard-iclb1/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][23] -> [SKIP][24] ([i915#677]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb7/igt@gem_exec_sched...@pi-shared-iova-bsd.html [24]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Hotplug cleanups (rev6)
== Series Details == Series: drm/i915: Hotplug cleanups (rev6) URL : https://patchwork.freedesktop.org/series/72348/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17038_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17038_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17038_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_17038_full: ### IGT changes ### Possible regressions * igt@kms_flip@plain-flip-fb-recreate: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl10/igt@kms_f...@plain-flip-fb-recreate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-skl5/igt@kms_f...@plain-flip-fb-recreate.html Warnings * igt@gem_ctx_persistence@close-replace-race: - shard-apl: [INCOMPLETE][3] ([fdo#103927] / [i915#1402]) -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-apl6/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-apl8/igt@gem_ctx_persiste...@close-replace-race.html - shard-skl: [TIMEOUT][5] ([i915#1340]) -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl10/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-skl8/igt@gem_ctx_persiste...@close-replace-race.html Known issues Here are the changes found in Patchwork_17038_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +12 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@gem_b...@busy-vcs1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-iclb3/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-kbl6/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#1277]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-tglb6/igt@gem_exec_balan...@hang.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-tglb6/igt@gem_exec_balan...@hang.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276] / [i915#677]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#454]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl6/igt@i915_pm...@dc6-psr.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-skl1/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-apl2/igt@i915_susp...@debugfs-reader.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-apl6/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_crc@pipe-c-cursor-256x256-onscreen: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#54]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-256x256-onscreen.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-256x256-onscreen.html * igt@kms_flip@busy-flip: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#275]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl10/igt@kms_f...@busy-flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17038/shard-skl5/igt@kms_f...@busy-flip.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl8/igt@kms_...@bpc-switch-dpms.html [24]:
Re: [Intel-gfx] [PATCH 01/13] drm/i915/mst: Use .compute_config_late() to compute master transcoder
Never mind, read the code again it will work.
Reviewed-by: José Roberto de Souza
On Fri, 2020-03-20 at 23:37 +, Souza, Jose wrote:
> This will not work for MST, here a example
>
> Previous state:
> MST master pipe A
> MST slave pipe B
>
> New state:
> Pipe A being disabled
>
> On drm_atomic_helper_check_modeset() both intel_crtc_states will be
> added to the state with crtc_state->uapi.mode_changed=true.
> Then on the regular for_each_oldnew_intel_crtc_in_state() loop config
> of CRTC B will have mst_master_transcoder=INVALID_TRANSCODER that
> differs from TRANSCODER_A and will keep mode_changed set.
> Then on the config_late loop it will skip the interation on the
> needs_modeset() check keeping CRTC B with
> mst_master_transcoder=INVALID_TRANSCODER.
>
> That would be caugh by CI if this tests were merged and the TGL
> machine
> with MST is still on: https://patchwork.freedesktop.org/series/72211/
>
> On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use the recently introduced encoder .compute_config_late() hook to
> > do the MST master transcoder assignment. Avoids having to do it
> > in a funny way before we know the CPU transcoder of each pipe.
> >
> > And now we can also properly use hw.active instead of uapi.active
> > since it too has been calculated earlier for everyone.
> >
> > Cc: José Roberto de Souza
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 98 +++--
> >
> > 1 file changed, 51 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 44f3fd251ca1..b9afc1135b9b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -88,56 +88,10 @@ static int
> > intel_dp_mst_compute_link_config(struct intel_encoder *encoder,
> > return 0;
> > }
> >
> > -/*
> > - * Iterate over all connectors and return the smallest transcoder
> > in
> > the MST
> > - * stream
> > - */
> > -static enum transcoder
> > -intel_dp_mst_master_trans_compute(struct intel_atomic_state
> > *state,
> > - struct intel_dp *mst_port)
> > -{
> > - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > - struct intel_digital_connector_state *conn_state;
> > - struct intel_connector *connector;
> > - enum pipe ret = I915_MAX_PIPES;
> > - int i;
> > -
> > - if (INTEL_GEN(dev_priv) < 12)
> > - return INVALID_TRANSCODER;
> > -
> > - for_each_new_intel_connector_in_state(state, connector,
> > conn_state, i) {
> > - struct intel_crtc_state *crtc_state;
> > - struct intel_crtc *crtc;
> > -
> > - if (connector->mst_port != mst_port || !conn_state-
> > > base.crtc)
> > - continue;
> > -
> > - crtc = to_intel_crtc(conn_state->base.crtc);
> > - crtc_state = intel_atomic_get_new_crtc_state(state,
> > crtc);
> > - if (!crtc_state->uapi.active)
> > - continue;
> > -
> > - /*
> > -* Using crtc->pipe because crtc_state->cpu_transcoder
> > is
> > -* computed, so others CRTCs could have non-computed
> > -* cpu_transcoder
> > -*/
> > - if (crtc->pipe < ret)
> > - ret = crtc->pipe;
> > - }
> > -
> > - if (ret == I915_MAX_PIPES)
> > - return INVALID_TRANSCODER;
> > -
> > - /* Simple cast works because TGL don't have a eDP transcoder */
> > - return (enum transcoder)ret;
> > -}
> > -
> > static int intel_dp_mst_compute_config(struct intel_encoder
> > *encoder,
> >struct intel_crtc_state
> > *pipe_config,
> >struct drm_connector_state
> > *conn_state)
> > {
> > - struct intel_atomic_state *state =
> > to_intel_atomic_state(conn_state->state);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> > struct intel_dp *intel_dp = _mst->primary->dp;
> > @@ -201,7 +155,56 @@ static int intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> >
> > intel_ddi_compute_min_voltage_level(dev_priv, pipe_config);
> >
> > - pipe_config->mst_master_transcoder =
> > intel_dp_mst_master_trans_compute(state, intel_dp);
> > + return 0;
> > +}
> > +
> > +/*
> > + * Iterate over all connectors and return a mask of
> > + * all CPU transcoders streaming over the same DP link.
> > + */
> > +static unsigned int
> > +intel_dp_mst_transcoder_mask(struct intel_atomic_state *state,
> > +struct intel_dp *mst_port)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + const struct intel_digital_connector_state *conn_state;
> > + struct intel_connector *connector;
> > + u8 transcoders = 0;
> > + int
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: drm device based logging changes
== Series Details == Series: drm/i915: drm device based logging changes URL : https://patchwork.freedesktop.org/series/74927/ State : success == Summary == CI Bug Log - changes from CI_DRM_8167_full -> Patchwork_17040_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17040_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@deep-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112146]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb7/igt@gem_exec_sched...@deep-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-iclb1/igt@gem_exec_sched...@deep-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +14 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_store@pages-vcs1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +14 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb1/igt@gem_exec_st...@pages-vcs1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-iclb5/igt@gem_exec_st...@pages-vcs1.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#454]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb4/igt@i915_pm...@dc6-psr.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-iclb4/igt@i915_pm...@dc6-psr.html - shard-skl: [PASS][11] -> [FAIL][12] ([i915#454]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl6/igt@i915_pm...@dc6-psr.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-skl6/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-256x256-onscreen: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#54]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-256x256-onscreen.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-256x256-onscreen.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][19] -> [INCOMPLETE][20] ([i915#155]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#53]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl9/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-c.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-skl2/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-c.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17040/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8167/shard-iclb2/igt@kms_psr@psr2_primary_mmap_gtt.html [26]:
