[Intel-gfx] ✗ Fi.CI.IGT: failure for CRTC background color (rev8)
== Series Details == Series: CRTC background color (rev8) URL : https://patchwork.freedesktop.org/series/50834/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6979_full -> Patchwork_14594_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14594_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14594_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_14594_full: ### IGT changes ### Possible regressions * igt@gem_softpin@softpin: - shard-skl: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-skl1/igt@gem_soft...@softpin.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-skl9/igt@gem_soft...@softpin.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-hsw: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-hsw7/igt@gem_userptr_bl...@dmabuf-unsync.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-hsw7/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@map-fixed-invalidate-busy: - shard-glk: [PASS][5] -> [DMESG-WARN][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-glk5/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-glk4/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup: - shard-snb: [PASS][7] -> [DMESG-WARN][8] +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-kbl1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-kbl2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html Known issues Here are the changes found in Patchwork_14594_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#110854]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-iclb2/igt@gem_exec_balan...@smoke.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#111325]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_mmap_gtt@hang: - shard-snb: [PASS][15] -> [INCOMPLETE][16] ([fdo#105411]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-snb1/igt@gem_mmap_...@hang.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-snb5/igt@gem_mmap_...@hang.html * igt@gem_pwrite@big-cpu-fbr: - shard-apl: [PASS][17] -> [TIMEOUT][18] ([fdo#111861]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-apl3/igt@gem_pwr...@big-cpu-fbr.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-apl8/igt@gem_pwr...@big-cpu-fbr.html * igt@gem_softpin@noreloc-s3: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713] / [fdo#109100]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-iclb1/igt@gem_soft...@noreloc-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-iclb7/igt@gem_soft...@noreloc-s3.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([fdo#109385]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-apl3/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/shard-apl4/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) [23]: https://intel-gfx-ci.01.org/tree/drm
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/color: fix broken display in icl+
== Series Details == Series: drm/i915/color: fix broken display in icl+ URL : https://patchwork.freedesktop.org/series/67429/ State : success == Summary == CI Bug Log - changes from CI_DRM_6979 -> Patchwork_14597 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/index.html Changes --- No changes found Participating hosts (15 -> 44) -- Additional (29): fi-kbl-soraka fi-bdw-gvtdvm fi-icl-u2 fi-apl-guc fi-snb-2520m fi-icl-u3 fi-skl-lmem fi-blb-e6850 fi-byt-n2820 fi-icl-guc fi-skl-6600u fi-hsw-4770r fi-bxt-dsi fi-cml-s fi-byt-j1900 fi-glk-dsi fi-bwr-2160 fi-ilk-650 fi-kbl-7500u fi-gdg-551 fi-elk-e7500 fi-skl-6700k2 fi-hsw-peppy fi-cfl-guc fi-whl-u fi-kbl-x1275 fi-cfl-8109u fi-skl-iommu fi-kbl-8809g Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6979 -> Patchwork_14597 CI-20190529: 20190529 CI_DRM_6979: 46637a3b58ef5e2c0fb6e53b7c50bba8f5de3455 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14597: 5d9d27e6eccf677042c217f7a1add0b2bb2935fe @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5d9d27e6eccf drm/i915/color: fix broken display in icl+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] TGL HAX drm/i915/tgl: Defer direct submission from interrupt context
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ef9eb3330a37..8906d86c76de 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2167,10 +2167,14 @@ static void __submit_queue_imm(struct intel_engine_cs
*engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
+ if (READ_ONCE(engine->execlists.pending[0]))
+ return;
+
if (reset_in_progress(execlists))
return; /* defer until we restart the engine following reset */
- if (execlists->tasklet.func == execlists_submission_tasklet)
+ if (execlists->tasklet.func == execlists_submission_tasklet &&
+ !in_irq())
__execlists_submission_tasklet(engine);
else
tasklet_hi_schedule(&execlists->tasklet);
--
2.23.0
___
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/tc: Implement the TC cold exit sequence (rev2)
== Series Details ==
Series: drm/i915/tc: Implement the TC cold exit sequence (rev2)
URL : https://patchwork.freedesktop.org/series/67426/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6979 -> Patchwork_14598
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14598:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_sync@basic-all:
- {fi-tgl-u2}:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/fi-tgl-u2/igt@gem_s...@basic-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/fi-tgl-u2/igt@gem_s...@basic-all.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
Participating hosts (15 -> 43)
--
Additional (28): fi-kbl-soraka fi-bdw-gvtdvm fi-icl-u2 fi-apl-guc
fi-snb-2520m fi-icl-u3 fi-skl-lmem fi-blb-e6850 fi-byt-n2820 fi-icl-guc
fi-skl-6600u fi-hsw-4770r fi-bxt-dsi fi-cml-s fi-byt-j1900 fi-glk-dsi
fi-ilk-650 fi-kbl-7500u fi-gdg-551 fi-elk-e7500 fi-skl-6700k2 fi-hsw-peppy
fi-cfl-guc fi-whl-u fi-kbl-x1275 fi-cfl-8109u fi-skl-iommu fi-kbl-8809g
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6979 -> Patchwork_14598
CI-20190529: 20190529
CI_DRM_6979: 46637a3b58ef5e2c0fb6e53b7c50bba8f5de3455 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14598: 811c4fd9bfd814ea3f9be9f0f8f4cf7c5e6b03d0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
811c4fd9bfd8 drm/i915/tc: Implement the TC cold exit sequence
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/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/color: fix broken display in icl+
On Tue, 01 Oct 2019, Swati Sharma wrote:
> Premature gamma lut prepration and loading which was getting
> reflected in first modeset causing different colors on
> screen during boot.
>
> Issue: In BIOS, gamma is disabled by default. However,
> legacy_read_luts() was getting called even before the legacy_load_luts()
> which was setting crtc_state->base.gamma_lut and gamma_lut was
> programmed with junk values which led to visual artifacts (different
> colored screens instead of usual black during boot).
>
> Fix: Calling read_luts() only when gamma is enabled which will happen
> after first modeset.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809
I'm confused. Is there a current problem upstream after the revert
1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"")?
Or does this fix a problem that only occurs in conjunction with the
reverted commit? Then say so.
Note inline.
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f1328c08f4ad..f89aa4bb9f42 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10528,7 +10528,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> i9xx_get_pipe_color_config(pipe_config);
> }
>
> - intel_color_get_config(pipe_config);
> + if ((INTEL_GEN(dev_priv) >= 11 && (pipe_config->gamma_mode &
> POST_CSC_GAMMA_ENABLE)) ||
> +(INTEL_GEN(dev_priv) >= 9 && (pipe_config->gamma_enable)))
> + intel_color_get_config(pipe_config);
Put all of the conditions inside intel_color_get_config().
BR,
Jani.
>
> power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> WARN_ON(power_domain_mask & BIT_ULL(power_domain));
--
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 v3] string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
The kernel has plenty of ternary operators to choose between constant
strings, such as condition ? "yes" : "no", as well as value == 1 ? "" :
"s":
$ git grep '? "yes" : "no"' | wc -l
258
$ git grep '? "on" : "off"' | wc -l
204
$ git grep '? "enabled" : "disabled"' | wc -l
196
$ git grep '? "" : "s"' | wc -l
25
Additionally, there are some occurences of the same in reverse order,
split to multiple lines, or otherwise not caught by the simple grep.
Add helpers to return the constant strings. Remove existing equivalent
and conflicting functions in i915, cxgb4, and USB core. Further
conversion can be done incrementally.
While the main goal here is to abstract recurring patterns, and slightly
clean up the code base by not open coding the ternary operators, there
are also some space savings to be had via better string constant
pooling.
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: Vishal Kulkarni
Cc: net...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: Andrew Morton
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall
Cc: Rasmus Villemoes
Reviewed-by: Greg Kroah-Hartman # v1
Signed-off-by: Jani Nikula
---
v2: add string-choice.[ch] to not clutter kernel.h and to actually save
space on string constants.
v3: back to static inlines based on Rasmus' feedback
Example of further cleanup possibilities are at [1], to be done
incrementally afterwards.
[1] http://lore.kernel.org/r/20190903133731.2094-2-jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_utils.h | 16 +-
.../ethernet/chelsio/cxgb4/cxgb4_debugfs.c| 12 +--
drivers/usb/core/config.c | 6 +---
drivers/usb/core/generic.c| 6 +---
include/linux/string-choice.h | 31 +++
5 files changed, 35 insertions(+), 36 deletions(-)
create mode 100644 include/linux/string-choice.h
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 562f756da421..794f02a90efe 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -395,21 +396,6 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
#define MBps(x) KBps(1000 * (x))
#define GBps(x) ((u64)1000 * MBps((x)))
-static inline const char *yesno(bool v)
-{
- return v ? "yes" : "no";
-}
-
-static inline const char *onoff(bool v)
-{
- return v ? "on" : "off";
-}
-
-static inline const char *enableddisabled(bool v)
-{
- return v ? "enabled" : "disabled";
-}
-
static inline void add_taint_for_CI(unsigned int taint)
{
/*
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index ae6a47dd7dc9..d9123dae1d00 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2023,17 +2024,6 @@ static const struct file_operations rss_debugfs_fops = {
/* RSS Configuration.
*/
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
- static const char *yes = "yes";
- static const char *no = "no";
-
- return x ? yes : no;
-}
-
static int rss_config_show(struct seq_file *seq, void *v)
{
struct adapter *adapter = seq->private;
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 151a74a54386..52cee9067eb4 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include "usb.h"
@@ -19,11 +20,6 @@
#define USB_MAXCONFIG 8 /* Arbitrary limit */
-static inline const char *plural(int n)
-{
- return (n == 1 ? "" : "s");
-}
-
static int find_next_descriptor(unsigned char *buffer, int size,
int dt1, int dt2, int *num_skipped)
{
diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
index 38f8b3e31762..a784a09794d6 100644
--- a/drivers/usb/core/generic.c
+++ b/drivers/usb/core/generic.c
@@ -21,14 +21,10 @@
#include
#include
+#include
#include
#include "usb.h"
-static inline const char *plural(int n)
-{
- return (n == 1 ? "" : "s");
-}
-
static int is_rndis(struct usb_interface_descriptor *desc)
{
return desc->bInterfaceClass == USB_CLASS_COMM
diff --git a/include/linux/string-choice.h b/include/linux/string-choice.h
new file mode 100644
index ..320b598bd8f0
--- /dev/null
+++ b/include/linux/string-choice.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef __STRING_CHOICE_H__
+#define __STRING_CHOICE_H__
+
+#include
+
+static inline const char *yesno(bool v)
+{
+ return v ?
Re: [Intel-gfx] [PATCH] drm/i915/gt: Only unwedge if we can reset first
Hi Chris, On Friday, September 27, 2019 6:03:35 PM CEST Chris Wilson wrote: > Unwedging the GPU requires a successful GPU reset before we restore the > default submission, or else we may see residual context switch events > that we were not expecting. > > v2: Pull in the special-case reset_clobbers_display, and explain why it > should be safe in the context of unwedging. > > v3: Just forget all about resets before unwedging if it will clobber the > display; risk it all. AFAICU, the risk we take is, when running on hardware with support for execlists, if reset clobbers the display we never unwedge, even if maybe we could. On the other hand, when running on hardware which doesn't support execlists, we optimistically unwedge unless we can try the reset and it fails. Assuming the issue we are trying to fix here is specific to execlists mode, that seems to be a safe choice. Thanks, Janusz > Reported-by: Janusz Krzysztofik > Signed-off-by: Chris Wilson > Cc: Janusz Krzysztofik > Cc: Daniele Ceraolo Spurio > Cc: Ville Syrjälä > Reviewed-by: Daniele Ceraolo Spurio #v1 > --- > drivers/gpu/drm/i915/gt/intel_reset.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/ gt/intel_reset.c > index d08226f5bea5..11781a626f75 100644 > --- a/drivers/gpu/drm/i915/gt/intel_reset.c > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > @@ -807,6 +807,7 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt) > struct intel_gt_timelines *timelines = >->timelines; > struct intel_timeline *tl; > unsigned long flags; > + bool ok; > > if (!test_bit(I915_WEDGED, >->reset.flags)) > return true; > @@ -853,7 +854,12 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt) > } > spin_unlock_irqrestore(&timelines->lock, flags); > > - intel_gt_sanitize(gt, false); > + /* We must reset pending GPU events before restoring our submission */ > + ok = !HAS_EXECLISTS(gt->i915); > + if (!INTEL_INFO(gt->i915)->gpu_reset_clobbers_display) > + ok = __intel_gt_reset(gt, ALL_ENGINES) == 0; > + if (!ok) > + return false; > > /* >* Undo nop_submit_request. We prevent all new i915 requests from > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFT drm/i915/tgl: Re-enable rps (rev2)
== Series Details == Series: RFT drm/i915/tgl: Re-enable rps (rev2) URL : https://patchwork.freedesktop.org/series/67398/ State : warning == Summary == $ dim checkpatch origin/drm-tip c071a17cd8f9 RFT drm/i915/tgl: Re-enable rps -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:18: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 7 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] HAX: Force kmemleak off
--- mm/kmemleak.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index f6e602918dac..cf392615ad40 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -2015,6 +2015,9 @@ void __init kmemleak_init(void) } #endif + kmemleak_disable(); + return; + jiffies_min_age = msecs_to_jiffies(MSECS_MIN_AGE); jiffies_scan_wait = msecs_to_jiffies(SECS_SCAN_WAIT * 1000); -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for RFT drm/i915/tgl: Re-enable rps (rev2)
== Series Details ==
Series: RFT drm/i915/tgl: Re-enable rps (rev2)
URL : https://patchwork.freedesktop.org/series/67398/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6980 -> Patchwork_14599
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/index.html
Known issues
Here are the changes found in Patchwork_14599 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] /
[fdo#111381])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][5] -> [FAIL][6] ([fdo#103167])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_prop_blob@basic:
- fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@kms_prop_b...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-icl-u3/igt@kms_prop_b...@basic.html
Possible fixes
* igt@gem_exec_fence@nb-await-default:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@gem_exec_fe...@nb-await-default.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-icl-u3/igt@gem_exec_fe...@nb-await-default.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: [DMESG-WARN][11] ([fdo#102505] / [fdo#110390]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][13] ([fdo#102614]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][15] ([fdo#106107] / [fdo#107724] /
[fdo#111214]) -> [DMESG-WARN][16] ([fdo#107724] / [fdo#111214])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@i915_module_l...@reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/fi-icl-u3/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111871]: https://bugs.freedesktop.org/show_bug.cgi?id=111871
Participating hosts (50 -> 43)
--
Additional (1): fi-byt-j1900
Missing(8): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6980 -> Patchwork_14599
CI-20190529: 20190529
CI_DRM_6980: 46637a3b58ef5e2c0fb6e53b7c50bba8f5de3455 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c013
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for TGL HAX drm/i915/tgl: Defer direct submission from interrupt context
== Series Details == Series: TGL HAX drm/i915/tgl: Defer direct submission from interrupt context URL : https://patchwork.freedesktop.org/series/67431/ State : warning == Summary == $ dim checkpatch origin/drm-tip c5799b216ffc TGL HAX drm/i915/tgl: Defer direct submission from interrupt context -:9: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:27: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 15 lines checked ___ 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/color: fix broken display in icl+
== Series Details ==
Series: drm/i915/color: fix broken display in icl+
URL : https://patchwork.freedesktop.org/series/67429/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6979_full -> Patchwork_14597_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14597_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14597_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_14597_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock_vma:
- shard-skl: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-skl9/igt@i915_selftest@mock_vma.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-skl5/igt@i915_selftest@mock_vma.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_eio@kms}:
- shard-glk: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-glk1/igt@gem_...@kms.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-glk2/igt@gem_...@kms.html
Known issues
Here are the changes found in Patchwork_14597_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@bcs0-s3:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-skl9/igt@gem_ctx_isolat...@bcs0-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-skl10/igt@gem_ctx_isolat...@bcs0-s3.html
* igt@gem_ctx_isolation@rcs0-s3:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html
* igt@gem_eio@in-flight-contexts-1us:
- shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#105957])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-hsw5/igt@gem_...@in-flight-contexts-1us.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-hsw7/igt@gem_...@in-flight-contexts-1us.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#110854])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-iclb2/igt@gem_exec_balan...@smoke.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-iclb3/igt@gem_exec_balan...@smoke.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#111325]) +8 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html
* igt@gem_tiled_swapping@non-threaded:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108686])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-kbl2/igt@gem_tiled_swapp...@non-threaded.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-kbl2/igt@gem_tiled_swapp...@non-threaded.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy:
- shard-glk: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-glk5/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-glk8/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-snb: [PASS][19] -> [DMESG-WARN][20] ([fdo#111870]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-snb4/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy:
- shard-apl: [PASS][21] -> [DMESG-WARN][22] ([fdo#109385] /
[fdo#111870])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-apl3/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14597/shard-apl1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html
Re: [Intel-gfx] [PATCH v10 4/6] drm/i915/tgl: Do modeset to enable and configure DC3CO exitline
On Mon, Sep 30, 2019 at 11:11:35PM +0530, Anshuman Gupta wrote:
> DC3CO enabling B.Specs sequence requires to enable end configure
> exit scanlines to TRANS_EXITLINE register, programming this register
> has to be part of modeset sequence as this can't be change when
> transcoder or port is enabled.
> When system boots with only eDP panel there may not be real
> modeset as BIOS has already programmed the necessary registers,
> therefore it needs to force a modeset to enable and configure
> DC3CO exitline.
>
> v1: Computing dc3co_exitline crtc state from a DP encoder
> compute config. [Imre]
> Enabling and disabling DC3CO PSR2 transcoder exitline from
> encoder pre_enable and post_disable hooks. [Imre]
> Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre]
> v2: Code refactoring for symmetry and to avoid exported function. [Imre]
> Removing IS_TIGERLAKE check from compute_config, adding PIPE_A
> restriction and clearing dc3co_exitline state if crtc is not active
> or it is not PSR2 capable in dc3co exitline compute_config. [Imre]
> Using IS_TGL check and dc3co exitline get_config
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 104 +-
> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 4 files changed, 105 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index aa470c70a198..d779a33c70db 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -45,6 +45,7 @@
> #include "intel_lspcon.h"
> #include "intel_panel.h"
> #include "intel_psr.h"
> +#include "intel_sprite.h"
> #include "intel_tc.h"
> #include "intel_vdsc.h"
>
> @@ -3200,6 +3201,97 @@ static void intel_ddi_disable_fec_state(struct
> intel_encoder *encoder,
> POSTING_READ(intel_dp->regs.dp_tp_ctl);
> }
>
> +static u32 intel_get_frame_time_us(const struct intel_crtc_state *cstate)
> +{
> + if (!cstate || !cstate->base.active)
> + return 0;
> +
> + return DIV_ROUND_UP(1000 * 1000,
> + drm_mode_vrefresh(&cstate->base.adjusted_mode));
> +}
> +
> +static void
> +tgl_clear_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
> +{
> + struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
> + u32 val;
> +
> + if (!cstate->dc3co_exitline)
> + return;
> +
> + val = I915_READ(EXITLINE(cstate->cpu_transcoder));
> + val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
> + I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
> +}
> +
> +static void
> +tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
> +{
> + u32 val, exit_scanlines;
> + struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
> +
> + if (!cstate->dc3co_exitline)
> + return;
> +
> + exit_scanlines = cstate->dc3co_exitline;
> + exit_scanlines <<= EXITLINE_SHIFT;
> + val = I915_READ(EXITLINE(cstate->cpu_transcoder));
> + val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
> + val |= exit_scanlines;
> + val |= EXITLINE_ENABLE;
> + I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
> +}
> +
> +static void tgl_dc3co_exitline_compute_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *cstate)
> +{
> + u32 exit_scanlines;
> + struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
> + u32 crtc_vdisplay = cstate->base.adjusted_mode.crtc_vdisplay;
> +
> + dev_priv->psr.dc3co_frame_time_us = 0;
dev_priv->psr may be unrelated to this commit, so we can't update it
here; let's compute/set it in intel_psr_enable_locked().
> + cstate->dc3co_exitline = 0;
> +
> + if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC3CO))
> + return;
> +
> + /* B.Specs:49196 DC3CO only works with pipeA and DDIA.*/
> + if (to_intel_crtc(cstate->base.crtc)->pipe != PIPE_A ||
> + encoder->port != PORT_A)
> + return;
> +
> + if (!cstate->has_psr2 || !cstate->base.active)
> + return;
> +
> + /*
> + * DC3CO Exit time 200us B.Spec 49196
> + * PSR2 transcoder Early Exit scanlines = ROUNDUP(200 / line time) + 1
> + */
> + exit_scanlines =
> + intel_usecs_to_scanlines(&cstate->base.adjusted_mode, 200) + 1;
> +
> + if (WARN_ON(exit_scanlines > crtc_vdisplay))
> + return;
> +
> + cstate->dc3co_exitline = crtc_vdisplay - exit_scanlines;
> + DRM_DEBUG_KMS("DC3CO exit scanlines %d\n", cstate->dc3co_exitline);
> + dev_priv->psr.dc3co_frame_time_us = intel_get_frame_time_us(cstate);
> +}
> +
> +static void tgl_dc3co_exitline_get_confi
Re: [Intel-gfx] [PATCH 1/4] drm/rect: Add drm_rect_translate_to()
On Mon, 30 Sep 2019, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a helper to translate a rectangle to an absolute position.
>
> Signed-off-by: Ville Syrjälä
The series is
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_rect.h | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index 6195820aa5c5..fc7c14627ee2 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -106,6 +106,20 @@ static inline void drm_rect_translate(struct drm_rect
> *r, int dx, int dy)
> r->y2 += dy;
> }
>
> +/**
> + * drm_rect_translate_to - translate the rectangle to an absolute position
> + * @r: rectangle to be tranlated
> + * @x: horizontal position
> + * @y: vertical position
> + *
> + * Move rectangle @r to @x in the horizontal direction,
> + * and to @y in the vertical direction.
> + */
> +static inline void drm_rect_translate_to(struct drm_rect *r, int x, int y)
> +{
> + drm_rect_translate(r, x - r->x1, y - r->y1);
> +}
> +
> /**
> * drm_rect_downscale - downscale a rectangle
> * @r: rectangle to be downscaled
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 5/6] drm/i915/tgl: Switch between dc3co and dc5 based on display idleness
On Mon, Sep 30, 2019 at 11:11:36PM +0530, Anshuman Gupta wrote:
> DC3CO is useful power state, when DMC detects PSR2 idle frame
> while an active video playback, playing 30fps video on 60hz panel
> is the classic example of this use case.
>
> B.Specs:49196 has a restriction to enable DC3CO only for Video Playback.
> It will be worthy to enable DC3CO after completion of each pageflip
> and switch back to DC5 when display is idle because driver doesn't
> differentiate between video playback and a normal pageflip.
> We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO
> state only for ORIGIN_FLIP flush call, because DC3CO state has primarily
> targeted for VPB use case. We are not interested here for frontbuffer
> invalidates calls because that triggers PSR2 exit, which will
> explicitly disable DC3CO.
>
> DC5 and DC6 saves more power, but can't be entered during video
> playback because there are not enough idle frames in a row to meet
> most PSR2 panel deep sleep entry requirement typically 4 frames.
> As PSR2 existing implementation is using minimum 6 idle frames for
> deep sleep, it is safer to enable DC5/6 after 6 idle frames
> (By scheduling a delayed work of 6 idle frames, once DC3CO has been
> enabled after a pageflip).
>
> After manually waiting for 6 idle frames DC5/6 will be enabled and
> PSR2 deep sleep idle frames will be restored to 6 idle frames, at this
> point DMC will triggers DC5/6 once PSR2 enters to deep sleep after
> 6 idle frames.
> In future when we will enable S/W PSR2 tracking, we can change the
> PSR2 required deep sleep idle frames to 1 so DMC can trigger the
> DC5/6 immediately after S/W manual waiting of 6 idle frames get
> complete.
>
> v2: calculated s/w state to switch over dc3co when there is an
> update. [Imre]
> Used cancel_delayed_work_sync() in order to avoid any race
> with already scheduled delayed work. [Imre]
> v3: Cancel_delayed_work_sync() may blocked the commit work.
> hence dropping it, dc5_idle_thread() checks the valid wakeref before
> putting the reference count, which avoids any chances of dropping
> a zero wakeref. [Imre (IRC)]
> v4: Used frontbuffer flush mechanism. [Imre]
> v5: Used psr.pipe to extract frontbuffer busy bits. [Imre]
> Used cancel_delayed_work_sync() in encoder disable path. [Imre]
> Used mod_delayed_work() instead of cancelling and scheduling a
> delayed work. [Imre]
> Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep
> sleep. [Imre]
> Removed DC5_REQ_IDLE_FRAMES macro. [Imre]
> v6: Used dc3co_exitline check instead of TGL and dc3co allowed_dc_mask
> checks, used delayed_work_pending with the psr lock and removed the
> psr2_deep_slp_disabled flag. [Imre]
> v7: Code refactoring moved the most of functional code to inte_psr.c [Imre]
> Using frontbuffer_bits on psr.pipe check instead of
> busy_frontbuffer_bits. [Imre]
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
> ---
> .../drm/i915/display/intel_display_power.c| 45
> .../drm/i915/display/intel_display_power.h| 2 +
> drivers/gpu/drm/i915/display/intel_psr.c | 109 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> 4 files changed, 157 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 67ba92dd8366..9fddebfda169 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -886,6 +886,51 @@ lookup_power_well(struct drm_i915_private *dev_priv,
> return &dev_priv->power_domains.power_wells[0];
> }
>
> +/**
> + * intel_display_power_set_target_dc_state - Set target dc state.
> + * @dev_priv: i915 device
> + * @state: state which needs to be set as target_dc_state.
> + *
> + * This function set the "DC off" power well target_dc_state,
> + * based upon this target_dc_stste, "DC off" power well will
> + * enable desired DC state.
> + */
> +void intel_display_power_set_target_dc_state(struct drm_i915_private
> *dev_priv,
> + u32 state)
> +{
> + struct i915_power_well *power_well;
> + bool dc_off_enabled;
> + struct i915_power_domains *power_domains = &dev_priv->power_domains;
> +
> + mutex_lock(&power_domains->lock);
> + power_well = lookup_power_well(dev_priv, SKL_DISP_DC_OFF);
> +
> + if (WARN_ON(!power_well))
> + goto unlock;
> +
> + state = sanitize_target_dc_state(dev_priv, state);
> +
> + if (state == dev_priv->csr.target_dc_state)
> + goto unlock;
> +
> + dc_off_enabled = power_well->desc->ops->is_enabled(dev_priv,
> +power_well);
> + /*
> + * If DC off power well is disabled, need to enable and disable the
> + * DC off power well to effect target DC
[Intel-gfx] ✓ Fi.CI.BAT: success for TGL HAX drm/i915/tgl: Defer direct submission from interrupt context
== Series Details ==
Series: TGL HAX drm/i915/tgl: Defer direct submission from interrupt context
URL : https://patchwork.freedesktop.org/series/67431/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6980 -> Patchwork_14600
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/index.html
Known issues
Here are the changes found in Patchwork_14600 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload-with-fault-injection:
- fi-hsw-4770r: [PASS][1] -> [DMESG-WARN][2] ([fdo#107732])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-hsw-4770r/igt@i915_module_l...@reload-with-fault-injection.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-hsw-4770r/igt@i915_module_l...@reload-with-fault-injection.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][3] -> [FAIL][4] ([fdo#103167])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
* igt@prime_self_import@basic-with_fd_dup:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-icl-u3/igt@prime_self_import@basic-with_fd_dup.html
Possible fixes
* igt@gem_exec_fence@nb-await-default:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@gem_exec_fe...@nb-await-default.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-icl-u3/igt@gem_exec_fe...@nb-await-default.html
* igt@gem_sync@basic-each:
- {fi-tgl-u2}:[INCOMPLETE][9] ([fdo#111647]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-tgl-u2/igt@gem_s...@basic-each.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-tgl-u2/igt@gem_s...@basic-each.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#106107] / [fdo#107724] /
[fdo#111214]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u4}:[FAIL][13] ([fdo#103167]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
- fi-hsw-peppy: [DMESG-WARN][15] ([fdo#102614]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
Participating hosts (50 -> 44)
--
Additional (3): fi-byt-j1900 fi-cml-h fi-snb-2600
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-icl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6980 -> Patchwork_14600
CI-20190529: 20190529
CI_DRM_6980: 46637a3b58ef5e2c0fb6e53b7c50bba8f5de3455 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14600: c5799b216ffc81004761263a060fe348255b9177 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c5799b216ffc TGL HAX drm/i915/tgl: Defer direct submission from inter
Re: [PATCH v3] string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
On Tue, Oct 01, 2019 at 11:07:39AM +0300, Jani Nikula wrote: > The kernel has plenty of ternary operators to choose between constant > strings, such as condition ? "yes" : "no", as well as value == 1 ? "" : > "s": > > $ git grep '? "yes" : "no"' | wc -l > 258 > $ git grep '? "on" : "off"' | wc -l > 204 > $ git grep '? "enabled" : "disabled"' | wc -l > 196 > $ git grep '? "" : "s"' | wc -l > 25 > > Additionally, there are some occurences of the same in reverse order, > split to multiple lines, or otherwise not caught by the simple grep. > > Add helpers to return the constant strings. Remove existing equivalent > and conflicting functions in i915, cxgb4, and USB core. Further > conversion can be done incrementally. > > While the main goal here is to abstract recurring patterns, and slightly > clean up the code base by not open coding the ternary operators, there > are also some space savings to be had via better string constant > pooling. > > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: intel-gfx@lists.freedesktop.org > Cc: Vishal Kulkarni > Cc: net...@vger.kernel.org > Cc: Greg Kroah-Hartman > Cc: linux-...@vger.kernel.org > Cc: Andrew Morton > Cc: linux-ker...@vger.kernel.org > Cc: Julia Lawall > Cc: Rasmus Villemoes > Reviewed-by: Greg Kroah-Hartman # v1 As this is a totally different version, please drop my reviewed-by as that's really not true here :(
Re: DDC on Thinkpad x220
On Mon, 30 Sep 2019, Pavel Machek wrote: > Hi! > > Thinkpad X220 should be new enough machine to talk DDC to the > monitors, right? And my monitor has DDC enable/disable in the menu, so > it should support it, too... > > But I don't have /dev/i2c* and did not figure out how to talk to the > monitor. Is the support there in the kernel? What do I need to enable > it? # modprobe i2c-dev BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/userptr: Never allow userptr into the mappable GGTT (rev3)
== Series Details ==
Series: drm/i915/userptr: Never allow userptr into the mappable GGTT (rev3)
URL : https://patchwork.freedesktop.org/series/67349/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d0541b40d6ed drm/i915/userptr: Never allow userptr into the mappable GGTT
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#25:
<4>[ 246.794030] 3f565be6 (&dev->struct_mutex/1){+.+.}, at:
userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
total: 0 errors, 1 warnings, 0 checks, 60 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH v3] string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
On Tue, 01 Oct 2019, Greg Kroah-Hartman wrote: > On Tue, Oct 01, 2019 at 11:07:39AM +0300, Jani Nikula wrote: >> The kernel has plenty of ternary operators to choose between constant >> strings, such as condition ? "yes" : "no", as well as value == 1 ? "" : >> "s": >> >> $ git grep '? "yes" : "no"' | wc -l >> 258 >> $ git grep '? "on" : "off"' | wc -l >> 204 >> $ git grep '? "enabled" : "disabled"' | wc -l >> 196 >> $ git grep '? "" : "s"' | wc -l >> 25 >> >> Additionally, there are some occurences of the same in reverse order, >> split to multiple lines, or otherwise not caught by the simple grep. >> >> Add helpers to return the constant strings. Remove existing equivalent >> and conflicting functions in i915, cxgb4, and USB core. Further >> conversion can be done incrementally. >> >> While the main goal here is to abstract recurring patterns, and slightly >> clean up the code base by not open coding the ternary operators, there >> are also some space savings to be had via better string constant >> pooling. >> >> Cc: Joonas Lahtinen >> Cc: Rodrigo Vivi >> Cc: intel-gfx@lists.freedesktop.org >> Cc: Vishal Kulkarni >> Cc: net...@vger.kernel.org >> Cc: Greg Kroah-Hartman >> Cc: linux-...@vger.kernel.org >> Cc: Andrew Morton >> Cc: linux-ker...@vger.kernel.org >> Cc: Julia Lawall >> Cc: Rasmus Villemoes >> Reviewed-by: Greg Kroah-Hartman # v1 > > As this is a totally different version, please drop my reviewed-by as > that's really not true here :( I did indicate it was for v1. Indeed v2 was different, but care to elaborate what's wrong with v3? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH] drm/i915/selftests: Exercise potential false lite-restore
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poisoning the ringbuffer of the first context and trying
to trick a simple RING_TAIL update (i.e. lite-restore)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 117 +
1 file changed, 117 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 93f2fcdc49bf..464b2e325970 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -79,6 +79,122 @@ static int live_sanitycheck(void *arg)
return err;
}
+static int live_unlite_restore(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct igt_spinner spin;
+ int err = -ENOMEM;
+
+ /*
+* Check that we can correctly context switch between 2 instances
+* on the same engine from the same parent context.
+*/
+
+ mutex_lock(&i915->drm.struct_mutex);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ if (igt_spinner_init(&spin, &i915->gt))
+ goto err_unlock;
+
+ ctx = kernel_context(i915);
+ if (!ctx)
+ goto err_spin;
+
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq[2];
+ struct igt_live_test t;
+ int n;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(&t, i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ ce[n] = intel_context_create(ctx, engine);
+ if (IS_ERR(ce[n])) {
+ err = PTR_ERR(ce[n]);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(ce[n]);
+ if (err)
+ goto err_ce;
+
+ /*
+* Setup the pair of contexts such that if we
+* lite-restore using the RING_TAIL from ce[1] it
+* will execute garbage from ce[0]->ring.
+*/
+ memset(ce[n]->ring->vaddr,
+ POISON_INUSE,
+ ce[n]->ring->vma->size);
+ }
+ intel_ring_reset(ce[1]->ring, ce[1]->ring->vma->size / 2);
+ __execlists_update_reg_state(ce[1], engine);
+
+ rq[0] = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq[0])) {
+ err = PTR_ERR(rq[0]);
+ goto err_ce;
+ }
+
+ GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
+ i915_request_get(rq[0]);
+ i915_request_add(rq[0]);
+
+ if (!igt_wait_for_spinner(&spin, rq[0])) {
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ rq[1] = i915_request_create(ce[1]);
+ if (IS_ERR(rq[1])) {
+ err = PTR_ERR(rq[1]);
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+ GEM_BUG_ON(rq[1]->tail <= rq[0]->tail);
+
+ /* Ensure we do a completion switch from ce[0] to ce[1] */
+ i915_request_await_dma_fence(rq[1], &rq[0]->fence);
+ i915_request_put(rq[0]);
+
+ i915_request_add(rq[1]);
+
+err_ce:
+ igt_spinner_end(&spin);
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ if (IS_ERR_OR_NULL(ce[n]))
+ break;
+
+ intel_context_unpin(ce[n]);
+ intel_context_put(ce[n]);
+ }
+
+ if (igt_live_test_end(&t))
+ err = -EIO;
+ if (err)
+ break;
+ }
+
+ kernel_context_close(ctx);
+err_spin:
+ igt_spinner_fini(&spin);
+err_unlock:
+ intel_runtime_pm_put(&i915->runtime_pm, wakeref);
+ mutex_unlock(&i915->drm.struct_mutex);
+ return err;
+}
+
static int
emit_semaphore_chain(struct i915_request *rq, struct i915_vma *vma, int idx)
{
@@ -2178,6 +2294,7 @@ int intel_execlists_live_selftests(struct
drm_i915_private *i915)
[Intel-gfx] [PATCH] drm/i915/selftests: Exercise potential false lite-restore
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poisoning the ringbuffer of the first context and trying
to trick a simple RING_TAIL update (i.e. lite-restore)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Then switch back to ce[0] for fun.
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 132 +
1 file changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 93f2fcdc49bf..b90b970a44b9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -79,6 +79,137 @@ static int live_sanitycheck(void *arg)
return err;
}
+static int live_unlite_restore(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct igt_spinner spin;
+ int err = -ENOMEM;
+
+ /*
+* Check that we can correctly context switch between 2 instances
+* on the same engine from the same parent context.
+*/
+
+ mutex_lock(&i915->drm.struct_mutex);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ if (igt_spinner_init(&spin, &i915->gt))
+ goto err_unlock;
+
+ ctx = kernel_context(i915);
+ if (!ctx)
+ goto err_spin;
+
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq[3];
+ struct igt_live_test t;
+ int n;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(&t, i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ ce[n] = intel_context_create(ctx, engine);
+ if (IS_ERR(ce[n])) {
+ err = PTR_ERR(ce[n]);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(ce[n]);
+ if (err)
+ goto err_ce;
+
+ /*
+* Setup the pair of contexts such that if we
+* lite-restore using the RING_TAIL from ce[1] it
+* will execute garbage from ce[0]->ring.
+*/
+ memset(ce[n]->ring->vaddr,
+ POISON_INUSE,
+ ce[n]->ring->vma->size);
+ }
+ intel_ring_reset(ce[1]->ring, ce[1]->ring->vma->size / 2);
+ __execlists_update_reg_state(ce[1], engine);
+
+ rq[0] = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq[0])) {
+ err = PTR_ERR(rq[0]);
+ goto err_ce;
+ }
+
+ GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
+ i915_request_get(rq[0]);
+ i915_request_add(rq[0]);
+
+ if (!igt_wait_for_spinner(&spin, rq[0])) {
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ rq[1] = i915_request_create(ce[1]);
+ if (IS_ERR(rq[1])) {
+ err = PTR_ERR(rq[1]);
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+ GEM_BUG_ON(rq[1]->tail <= rq[0]->tail);
+
+ /* Ensure we do a completion switch from ce[0] to ce[1] */
+ i915_request_await_dma_fence(rq[1], &rq[0]->fence);
+ i915_request_put(rq[0]);
+
+ i915_request_get(rq[1]);
+ i915_request_add(rq[1]);
+
+ /* And switch back to ce[0] for good measure */
+ rq[2] = i915_request_create(ce[0]);
+ if (IS_ERR(rq[2])) {
+ err = PTR_ERR(rq[2]);
+ i915_request_put(rq[1]);
+ goto err_ce;
+ }
+ GEM_BUG_ON(rq[2]->tail > rq[1]->tail);
+
+ i915_request_await_dma_fence(rq[2], &rq[1]->fence);
+ i915_request_put(rq[1]);
+
+ i915_request_add(rq[2]);
+
+err_ce:
+ igt_spinner_end(&spin);
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ if (IS_ERR_OR_NULL(ce[n]))
+ break;
+
+ intel_context_unpin(ce[n]);
+ inte
Re: [Intel-gfx] [PATCH v10 5/6] drm/i915/tgl: Switch between dc3co and dc5 based on display idleness
On Mon, Sep 30, 2019 at 11:11:36PM +0530, Anshuman Gupta wrote:
> DC3CO is useful power state, when DMC detects PSR2 idle frame
> while an active video playback, playing 30fps video on 60hz panel
> is the classic example of this use case.
>
> B.Specs:49196 has a restriction to enable DC3CO only for Video Playback.
> It will be worthy to enable DC3CO after completion of each pageflip
> and switch back to DC5 when display is idle because driver doesn't
> differentiate between video playback and a normal pageflip.
> We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO
> state only for ORIGIN_FLIP flush call, because DC3CO state has primarily
> targeted for VPB use case. We are not interested here for frontbuffer
> invalidates calls because that triggers PSR2 exit, which will
> explicitly disable DC3CO.
>
> DC5 and DC6 saves more power, but can't be entered during video
> playback because there are not enough idle frames in a row to meet
> most PSR2 panel deep sleep entry requirement typically 4 frames.
> As PSR2 existing implementation is using minimum 6 idle frames for
> deep sleep, it is safer to enable DC5/6 after 6 idle frames
> (By scheduling a delayed work of 6 idle frames, once DC3CO has been
> enabled after a pageflip).
>
> After manually waiting for 6 idle frames DC5/6 will be enabled and
> PSR2 deep sleep idle frames will be restored to 6 idle frames, at this
> point DMC will triggers DC5/6 once PSR2 enters to deep sleep after
> 6 idle frames.
> In future when we will enable S/W PSR2 tracking, we can change the
> PSR2 required deep sleep idle frames to 1 so DMC can trigger the
> DC5/6 immediately after S/W manual waiting of 6 idle frames get
> complete.
>
> v2: calculated s/w state to switch over dc3co when there is an
> update. [Imre]
> Used cancel_delayed_work_sync() in order to avoid any race
> with already scheduled delayed work. [Imre]
> v3: Cancel_delayed_work_sync() may blocked the commit work.
> hence dropping it, dc5_idle_thread() checks the valid wakeref before
> putting the reference count, which avoids any chances of dropping
> a zero wakeref. [Imre (IRC)]
> v4: Used frontbuffer flush mechanism. [Imre]
> v5: Used psr.pipe to extract frontbuffer busy bits. [Imre]
> Used cancel_delayed_work_sync() in encoder disable path. [Imre]
> Used mod_delayed_work() instead of cancelling and scheduling a
> delayed work. [Imre]
> Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep
> sleep. [Imre]
> Removed DC5_REQ_IDLE_FRAMES macro. [Imre]
> v6: Used dc3co_exitline check instead of TGL and dc3co allowed_dc_mask
> checks, used delayed_work_pending with the psr lock and removed the
> psr2_deep_slp_disabled flag. [Imre]
> v7: Code refactoring moved the most of functional code to inte_psr.c [Imre]
> Using frontbuffer_bits on psr.pipe check instead of
> busy_frontbuffer_bits. [Imre]
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Cc: Animesh Manna
> Signed-off-by: Anshuman Gupta
> ---
> .../drm/i915/display/intel_display_power.c| 45
> .../drm/i915/display/intel_display_power.h| 2 +
> drivers/gpu/drm/i915/display/intel_psr.c | 109 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> 4 files changed, 157 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 67ba92dd8366..9fddebfda169 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -886,6 +886,51 @@ lookup_power_well(struct drm_i915_private *dev_priv,
> return &dev_priv->power_domains.power_wells[0];
> }
>
> +/**
> + * intel_display_power_set_target_dc_state - Set target dc state.
> + * @dev_priv: i915 device
> + * @state: state which needs to be set as target_dc_state.
> + *
> + * This function set the "DC off" power well target_dc_state,
> + * based upon this target_dc_stste, "DC off" power well will
> + * enable desired DC state.
> + */
> +void intel_display_power_set_target_dc_state(struct drm_i915_private
> *dev_priv,
> + u32 state)
> +{
> + struct i915_power_well *power_well;
> + bool dc_off_enabled;
> + struct i915_power_domains *power_domains = &dev_priv->power_domains;
> +
> + mutex_lock(&power_domains->lock);
> + power_well = lookup_power_well(dev_priv, SKL_DISP_DC_OFF);
> +
> + if (WARN_ON(!power_well))
> + goto unlock;
> +
> + state = sanitize_target_dc_state(dev_priv, state);
> +
> + if (state == dev_priv->csr.target_dc_state)
> + goto unlock;
> +
> + dc_off_enabled = power_well->desc->ops->is_enabled(dev_priv,
> +power_well);
> + /*
> + * If DC off power well is disabled, need to enable and disable the
> + * DC off power well to effect target DC
Re: [PATCH v3] string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
On Tue, Oct 01, 2019 at 12:42:34PM +0300, Jani Nikula wrote: > On Tue, 01 Oct 2019, Greg Kroah-Hartman wrote: > > On Tue, Oct 01, 2019 at 11:07:39AM +0300, Jani Nikula wrote: > >> The kernel has plenty of ternary operators to choose between constant > >> strings, such as condition ? "yes" : "no", as well as value == 1 ? "" : > >> "s": > >> > >> $ git grep '? "yes" : "no"' | wc -l > >> 258 > >> $ git grep '? "on" : "off"' | wc -l > >> 204 > >> $ git grep '? "enabled" : "disabled"' | wc -l > >> 196 > >> $ git grep '? "" : "s"' | wc -l > >> 25 > >> > >> Additionally, there are some occurences of the same in reverse order, > >> split to multiple lines, or otherwise not caught by the simple grep. > >> > >> Add helpers to return the constant strings. Remove existing equivalent > >> and conflicting functions in i915, cxgb4, and USB core. Further > >> conversion can be done incrementally. > >> > >> While the main goal here is to abstract recurring patterns, and slightly > >> clean up the code base by not open coding the ternary operators, there > >> are also some space savings to be had via better string constant > >> pooling. > >> > >> Cc: Joonas Lahtinen > >> Cc: Rodrigo Vivi > >> Cc: intel-gfx@lists.freedesktop.org > >> Cc: Vishal Kulkarni > >> Cc: net...@vger.kernel.org > >> Cc: Greg Kroah-Hartman > >> Cc: linux-...@vger.kernel.org > >> Cc: Andrew Morton > >> Cc: linux-ker...@vger.kernel.org > >> Cc: Julia Lawall > >> Cc: Rasmus Villemoes > >> Reviewed-by: Greg Kroah-Hartman # v1 > > > > As this is a totally different version, please drop my reviewed-by as > > that's really not true here :( > > I did indicate it was for v1. Indeed v2 was different, but care to > elaborate what's wrong with v3? No idea, but I haven't reviewed it yet, so to put my tag on there isn't the nicest... greg k-h
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tc: Implement the TC cold exit sequence (rev2)
== Series Details == Series: drm/i915/tc: Implement the TC cold exit sequence (rev2) URL : https://patchwork.freedesktop.org/series/67426/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6979_full -> Patchwork_14598_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14598_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14598_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_14598_full: ### IGT changes ### Possible regressions * igt@gem_pipe_control_store_loop@reused-buffer: - shard-skl: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-skl5/igt@gem_pipe_control_store_l...@reused-buffer.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-skl8/igt@gem_pipe_control_store_l...@reused-buffer.html Known issues Here are the changes found in Patchwork_14598_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-apl4/igt@gem_ctx_isolat...@bcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_ctx_isolation@vcs0-s3: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-kbl1/igt@gem_ctx_isolat...@vcs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-kbl7/igt@gem_ctx_isolat...@vcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_eio@in-flight-contexts-1us: - shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#105957]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-hsw5/igt@gem_...@in-flight-contexts-1us.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-hsw7/igt@gem_...@in-flight-contexts-1us.html * igt@gem_eio@in-flight-suspend: - shard-glk: [PASS][11] -> [CRASH][12] ([fdo#111559]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-glk6/igt@gem_...@in-flight-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-glk8/igt@gem_...@in-flight-suspend.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#111325]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-iclb6/igt@gem_exec_as...@concurrent-writes-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108686]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-kbl2/igt@gem_tiled_swapp...@non-threaded.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-kbl6/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@map-fixed-invalidate-busy: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-glk5/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-glk3/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup: - shard-snb: [PASS][19] -> [DMESG-WARN][20] ([fdo#111870]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([fdo#109385] / [fdo#111870]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/shard-apl3/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14598/shard-apl1/igt@gem_userptr_bl...@map-fixed-inva
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: Never allow userptr into the mappable GGTT (rev3)
== Series Details ==
Series: drm/i915/userptr: Never allow userptr into the mappable GGTT (rev3)
URL : https://patchwork.freedesktop.org/series/67349/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6980 -> Patchwork_14601
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14601:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_sync@basic-many-each:
- {fi-cml-h}: NOTRUN -> [TIMEOUT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-cml-h/igt@gem_s...@basic-many-each.html
* igt@runner@aborted:
- {fi-cml-h}: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-cml-h/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_14601 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] /
[fdo#111381])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-icl-u2/igt@gem_ctx_swi...@legacy-render.html
* igt@kms_addfb_basic@addfb25-yf-tiled:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@kms_addfb_ba...@addfb25-yf-tiled.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-icl-u3/igt@kms_addfb_ba...@addfb25-yf-tiled.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-hsw-4770r: [PASS][7] -> [DMESG-WARN][8] ([fdo#105602])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-hsw-4770r/igt@kms_f...@basic-flip-vs-modeset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-hsw-4770r/igt@kms_f...@basic-flip-vs-modeset.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][9] -> [FAIL][10] ([fdo#103167])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_exec_fence@nb-await-default:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +3
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@gem_exec_fe...@nb-await-default.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-icl-u3/igt@gem_exec_fe...@nb-await-default.html
* igt@gem_sync@basic-each:
- {fi-tgl-u2}:[INCOMPLETE][13] ([fdo#111647]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-tgl-u2/igt@gem_s...@basic-each.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-tgl-u2/igt@gem_s...@basic-each.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u4}:[FAIL][15] ([fdo#103167]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
- fi-hsw-peppy: [DMESG-WARN][17] ([fdo#102614]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][19] ([fdo#106107] / [fdo#107724] /
[fdo#111214]) -> [DMESG-WARN][20] ([fdo#107724] / [fdo#111214])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/fi-icl-u3/igt@i915_module_l...@reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/fi-icl-u3/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
Re: [Intel-gfx] [PATCH v3] string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
On Tue, 01 Oct 2019, Greg Kroah-Hartman wrote: > On Tue, Oct 01, 2019 at 12:42:34PM +0300, Jani Nikula wrote: >> On Tue, 01 Oct 2019, Greg Kroah-Hartman wrote: >> > On Tue, Oct 01, 2019 at 11:07:39AM +0300, Jani Nikula wrote: >> >> The kernel has plenty of ternary operators to choose between constant >> >> strings, such as condition ? "yes" : "no", as well as value == 1 ? "" : >> >> "s": >> >> >> >> $ git grep '? "yes" : "no"' | wc -l >> >> 258 >> >> $ git grep '? "on" : "off"' | wc -l >> >> 204 >> >> $ git grep '? "enabled" : "disabled"' | wc -l >> >> 196 >> >> $ git grep '? "" : "s"' | wc -l >> >> 25 >> >> >> >> Additionally, there are some occurences of the same in reverse order, >> >> split to multiple lines, or otherwise not caught by the simple grep. >> >> >> >> Add helpers to return the constant strings. Remove existing equivalent >> >> and conflicting functions in i915, cxgb4, and USB core. Further >> >> conversion can be done incrementally. >> >> >> >> While the main goal here is to abstract recurring patterns, and slightly >> >> clean up the code base by not open coding the ternary operators, there >> >> are also some space savings to be had via better string constant >> >> pooling. >> >> >> >> Cc: Joonas Lahtinen >> >> Cc: Rodrigo Vivi >> >> Cc: intel-gfx@lists.freedesktop.org >> >> Cc: Vishal Kulkarni >> >> Cc: net...@vger.kernel.org >> >> Cc: Greg Kroah-Hartman >> >> Cc: linux-...@vger.kernel.org >> >> Cc: Andrew Morton >> >> Cc: linux-ker...@vger.kernel.org >> >> Cc: Julia Lawall >> >> Cc: Rasmus Villemoes >> >> Reviewed-by: Greg Kroah-Hartman # v1 >> > >> > As this is a totally different version, please drop my reviewed-by as >> > that's really not true here :( >> >> I did indicate it was for v1. Indeed v2 was different, but care to >> elaborate what's wrong with v3? > > No idea, but I haven't reviewed it yet, so to put my tag on there isn't > the nicest... Apologies, no harm intended. At times, I've seen the "# vN" notation used, I suppose both to indicate that the *ideas* presented in the earlier version warranted Reviewed-by from so-and-so, though this particular version still needs detailed review, and that the approval of the reviewer of the earlier version should be sought out before merging a subsequent version. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH] drm/i915: Initialise breadcrumb lists on the virtual engine
With deferring the breadcrumb signalling to the virtual engine (thanks
preempt-to-busy) we need to make sure the lists and irq-worker are ready
to send a signal.
[41958.710544] BUG: kernel NULL pointer dereference, address:
[41958.710553] #PF: supervisor write access in kernel mode
[41958.710556] #PF: error_code(0x0002) - not-present page
[41958.710558] PGD 0 P4D 0
[41958.710562] Oops: 0002 [#1] SMP
[41958.710565] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U5.3.0+
#207
[41958.710568] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS
BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[41958.710602] RIP: 0010:i915_request_enable_breadcrumb+0xe1/0x130 [i915]
[41958.710605] Code: 8b 44 24 30 48 89 41 08 48 89 08 48 8b 85 98 01 00 00 48
8d 8d 90 01 00 00 48 89 95 98 01 00 00 49 89 4c 24 28 49 89 44 24 30 <48> 89 10
f0 80 4b 30 10 c6 85 88 01 00 00 00 e9 1a ff ff ff 48 83
[41958.710609] RSP: 0018:c9003de0 EFLAGS: 00010046
[41958.710612] RAX: RBX: 888735424480 RCX: 8887cddb2190
[41958.710614] RDX: 8887cddb3570 RSI: 50362190 RDI: 8887cddb2188
[41958.710617] RBP: 8887cddb2000 R08: 503624a8 R09: 0100
[41958.710619] R10: 0001 R11: R12: 8887cddb3548
[41958.710622] R13: R14: 0046 R15: 50362070
[41958.710625] FS: () GS:5ea0()
knlGS:
[41958.710628] CS: 0010 DS: ES: CR0: 80050033
[41958.710630] CR2: CR3: 02c09002 CR4: 001606f0
[41958.710633] Call Trace:
[41958.710636]
[41958.710668] __i915_request_submit+0x12b/0x160 [i915]
[41958.710693] virtual_submit_request+0x67/0x120 [i915]
[41958.710720] __unwind_incomplete_requests+0x131/0x170 [i915]
[41958.710744] execlists_dequeue+0xb40/0xe00 [i915]
[41958.710771] execlists_submission_tasklet+0x10f/0x150 [i915]
[41958.710776] tasklet_action_common.isra.17+0x41/0xa0
[41958.710781] __do_softirq+0xc8/0x221
[41958.710785] irq_exit+0xa6/0xb0
[41958.710788] smp_apic_timer_interrupt+0x4d/0x80
[41958.710791] apic_timer_interrupt+0xf/0x20
[41958.710794]
Fixes: cb2377a919bb ("drm/i915: Fixup preempt-to-busy vs reset of a virtual
request")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
Include the GPF trace from using the NULL lists
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3566ec8ad33a..48a1ef4c3572 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4195,6 +4195,7 @@ intel_execlists_create_virtual(struct i915_gem_context
*ctx,
snprintf(ve->base.name, sizeof(ve->base.name), "virtual");
intel_engine_init_active(&ve->base, ENGINE_VIRTUAL);
+ intel_engine_init_breadcrumbs(&ve->base);
intel_engine_init_execlists(&ve->base);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Initialise breadcrumb lists on the virtual engine
On 01/10/2019 11:35, Chris Wilson wrote:
With deferring the breadcrumb signalling to the virtual engine (thanks
preempt-to-busy) we need to make sure the lists and irq-worker are ready
to send a signal.
[41958.710544] BUG: kernel NULL pointer dereference, address:
[41958.710553] #PF: supervisor write access in kernel mode
[41958.710556] #PF: error_code(0x0002) - not-present page
[41958.710558] PGD 0 P4D 0
[41958.710562] Oops: 0002 [#1] SMP
[41958.710565] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U5.3.0+
#207
[41958.710568] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS
BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[41958.710602] RIP: 0010:i915_request_enable_breadcrumb+0xe1/0x130 [i915]
[41958.710605] Code: 8b 44 24 30 48 89 41 08 48 89 08 48 8b 85 98 01 00 00 48 8d 8d
90 01 00 00 48 89 95 98 01 00 00 49 89 4c 24 28 49 89 44 24 30 <48> 89 10 f0 80
4b 30 10 c6 85 88 01 00 00 00 e9 1a ff ff ff 48 83
[41958.710609] RSP: 0018:c9003de0 EFLAGS: 00010046
[41958.710612] RAX: RBX: 888735424480 RCX: 8887cddb2190
[41958.710614] RDX: 8887cddb3570 RSI: 50362190 RDI: 8887cddb2188
[41958.710617] RBP: 8887cddb2000 R08: 503624a8 R09: 0100
[41958.710619] R10: 0001 R11: R12: 8887cddb3548
[41958.710622] R13: R14: 0046 R15: 50362070
[41958.710625] FS: () GS:5ea0()
knlGS:
[41958.710628] CS: 0010 DS: ES: CR0: 80050033
[41958.710630] CR2: CR3: 02c09002 CR4: 001606f0
[41958.710633] Call Trace:
[41958.710636]
[41958.710668] __i915_request_submit+0x12b/0x160 [i915]
[41958.710693] virtual_submit_request+0x67/0x120 [i915]
[41958.710720] __unwind_incomplete_requests+0x131/0x170 [i915]
[41958.710744] execlists_dequeue+0xb40/0xe00 [i915]
[41958.710771] execlists_submission_tasklet+0x10f/0x150 [i915]
[41958.710776] tasklet_action_common.isra.17+0x41/0xa0
[41958.710781] __do_softirq+0xc8/0x221
[41958.710785] irq_exit+0xa6/0xb0
[41958.710788] smp_apic_timer_interrupt+0x4d/0x80
[41958.710791] apic_timer_interrupt+0xf/0x20
[41958.710794]
Fixes: cb2377a919bb ("drm/i915: Fixup preempt-to-busy vs reset of a virtual
request")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
Include the GPF trace from using the NULL lists
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3566ec8ad33a..48a1ef4c3572 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4195,6 +4195,7 @@ intel_execlists_create_virtual(struct i915_gem_context
*ctx,
snprintf(ve->base.name, sizeof(ve->base.name), "virtual");
intel_engine_init_active(&ve->base, ENGINE_VIRTUAL);
+ intel_engine_init_breadcrumbs(&ve->base);
intel_engine_init_execlists(&ve->base);
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.CHECKPATCH: warning for lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers (rev2)
== Series Details == Series: lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers (rev2) URL : https://patchwork.freedesktop.org/series/67405/ State : warning == Summary == $ dim checkpatch origin/drm-tip ff289b0aa561 string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers -:155: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #155: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 116 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
5.4-rc1 on Thinkpad x220: graphics regression, it "snows" on digital output
Hi! When 5.4-rc1 is booted on thinkpad X220 I get "snow" and other artefacts on digital output. 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) It already snows when kernel is booting, snow continues in X. HDMI1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 478mm x 268mm 1920x1080 60.00*+ Snow continues in other video modes: pavel@duo:~$ xrandr --output HDMI1 --mode 1024x768 pavel@duo:~$ VGA output appears normal. Any ideas? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: 5.4-rc1 on Thinkpad x220: graphics regression, it "snows" on digital output
Hi! > When 5.4-rc1 is booted on thinkpad X220 I get "snow" and other > artefacts on digital output. > > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation > Core Processor Family Integrated Graphics Controller (rev 09) > > It already snows when kernel is booting, snow continues in X. Sorry, false alarm. I seem to have a hardware problem, it persisted reboot to older kernel, and went away after I wiggled cables. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [Intel-gfx] [PATCH v2 0/9] drm/print: add and use drm_debug_enabled()
On Thu, 26 Sep 2019, Eric Engestrom wrote: > On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote: >> Hi all, v2 of [1], a little refactoring around drm_debug access to >> abstract it better. There shouldn't be any functional changes. >> >> I'd appreciate acks for merging the lot via drm-misc. If there are any >> objections to that, we'll need to postpone the last patch until >> everything has been merged and converted in drm-next. >> >> BR, >> Jani. >> >> Cc: Eric Engestrom >> Cc: Alex Deucher >> Cc: Christian König >> Cc: David (ChunMing) Zhou >> Cc: amd-...@lists.freedesktop.org >> Cc: Ben Skeggs >> Cc: nouv...@lists.freedesktop.org >> Cc: Rob Clark >> Cc: Sean Paul >> Cc: linux-arm-...@vger.kernel.org >> Cc: freedr...@lists.freedesktop.org >> Cc: Francisco Jerez >> Cc: Lucas Stach >> Cc: Russell King >> Cc: Christian Gmeiner >> Cc: etna...@lists.freedesktop.org >> >> >> [1] cover.1568375189.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1568375189.git.jani.nikula@intel.com >> >> Jani Nikula (9): >> drm/print: move drm_debug variable to drm_print.[ch] >> drm/print: add drm_debug_enabled() >> drm/i915: use drm_debug_enabled() to check for debug categories >> drm/print: rename drm_debug to __drm_debug to discourage use > > The above four patches are: > Reviewed-by: Eric Engestrom > > Did you check to make sure the `unlikely()` is propagated correctly > outside the `drm_debug_enabled()` call? I did now. Having drm_debug_enabled() as a macro vs. as an inline function does not seem to make a difference, so I think the inline is clearly preferrable. However, for example unlikely(foo && drm_debug & DRM_UT_DP) does produce code different from (foo && drm_debug_enabled(DRM_UT_DP)) indicating that the unlikely() within drm_debug_enabled() does not propagate to the whole condition. It's possible to retain the same assembly output with (unlikely(foo) && drm_debug_enabled(DRM_UT_DP)) but it's unclear to me whether this is really worth it, either readability or performance wise. Thoughts? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers (rev2)
== Series Details ==
Series: lib/string-choice: add yesno(), onoff(), enableddisabled(), plural()
helpers (rev2)
URL : https://patchwork.freedesktop.org/series/67405/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6981 -> Patchwork_14602
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/index.html
Known issues
Here are the changes found in Patchwork_14602 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_busy@basic-wait-after-default:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-cml-u2: [INCOMPLETE][3] ([fdo#110566]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
* igt@gem_mmap_gtt@basic-read-no-prefault:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html
* igt@gem_sync@basic-all:
- {fi-tgl-u}: [FAIL][9] ([fdo#111871]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/fi-tgl-u/igt@gem_s...@basic-all.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/fi-tgl-u/igt@gem_s...@basic-all.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724] / [fdo#111214]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/fi-icl-u3/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111871]: https://bugs.freedesktop.org/show_bug.cgi?id=111871
Participating hosts (48 -> 46)
--
Additional (2): fi-cml-h fi-bwr-2160
Missing(4): fi-ctg-p8600 fi-byt-clapper fi-ilk-m540 fi-bsw-cyan
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6981 -> Patchwork_14602
CI-20190529: 20190529
CI_DRM_6981: 3b9046f56a0924158484a0aaddd1aa3a1960ac65 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14602: ff289b0aa561a579575fcf3eb0827593e5e84f56 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ff289b0aa561 string-choice: add yesno(), onoff(), enableddisabled(), plural()
helpers
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: DDC on Thinkpad x220
On Tue 2019-10-01 12:39:34, Jani Nikula wrote: > On Mon, 30 Sep 2019, Pavel Machek wrote: > > Hi! > > > > Thinkpad X220 should be new enough machine to talk DDC to the > > monitors, right? And my monitor has DDC enable/disable in the menu, so > > it should support it, too... > > > > But I don't have /dev/i2c* and did not figure out how to talk to the > > monitor. Is the support there in the kernel? What do I need to enable > > it? > > # modprobe i2c-dev Thanks! I enabled I2C_CHARDEV, and installed ddccontrol: c ddccontrol - program to control monitor I can read parameters of Dell monitor on VGA: sudo ddccontrol dev:/dev/i2c-1 -c -d /usr/share/ddccontrol-db/monitor/DELA013.xml Control 0x10: +/79/100 [???] -- brightness Control 0x12: +/63/100 [???] -- contrast Unfortunately the Fujitsu monitor does not seem to communicate. Fujitsu is my main monitor :-(. pavel@duo:~$ sudo ddccontrol dev:/dev/i2c-4 -c -d ddccontrol version 0.4.2 Copyright 2004-2005 Oleg I. Vdovikin (o...@cs.msu.su) Copyright 2004-2006 Nicolas Boichat (nico...@boichat.ch) This program comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of this program under the terms of the GNU General Public License. Reading EDID and initializing DDC/CI at bus dev:/dev/i2c-4... ioctl(): No such device or address ioctl returned -1 ioctl(): No such device or address ioctl returned -1 ioctl(): No such device or address ioctl returned -1 I/O warning : failed to load external entity "/usr/share/ddccontrol-db/monitor/FUS080A.xml" Document not parsed successfully. ioctl(): No such device or address ioctl returned -1 DDC/CI at dev:/dev/i2c-4 is unusable (-1). If your graphics card need it, please check all the required kernel modules are loaded (i2c-dev, and your framebuffer driver). Any further hints? Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[Intel-gfx] ✓ Fi.CI.IGT: success for RFT drm/i915/tgl: Re-enable rps (rev2)
== Series Details == Series: RFT drm/i915/tgl: Re-enable rps (rev2) URL : https://patchwork.freedesktop.org/series/67398/ State : success == Summary == CI Bug Log - changes from CI_DRM_6980_full -> Patchwork_14599_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14599_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl4/igt@gem_ctx_isolat...@vecs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-kbl6/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_userptr_blits@coherency-sync: - shard-hsw: [PASS][5] -> [DMESG-WARN][6] ([fdo#111870]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-hsw4/igt@gem_userptr_bl...@coherency-sync.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-hsw1/igt@gem_userptr_bl...@coherency-sync.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([fdo#111870]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl3/igt@gem_userptr_bl...@dmabuf-sync.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-kbl2/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@sync-unmap: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([fdo#111870]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-glk4/igt@gem_userptr_bl...@sync-unmap.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-glk1/igt@gem_userptr_bl...@sync-unmap.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-apl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-apl6/igt@i915_pm_...@system-suspend-modeset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-apl1/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@i915_suspend@sysfs-reader: - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([fdo#103665] / [fdo#108767]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl7/igt@i915_susp...@sysfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-kbl2/igt@i915_susp...@sysfs-reader.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103184] / [fdo#103232]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-skl10/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-skl1/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#105363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-skl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +6 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [fdo#110403]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14599/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-co
[Intel-gfx] [PATCH 2/2] drm/i915: FB backing gem obj should reside in LMEM
If Local memory is supported by hardware, we want framebuffer backing
gem objects from local memory.
pin_to_display is failed, if the backing obj is not from LMEM.
This is developed on top of LMEM Basics
https://patchwork.freedesktop.org/series/67350/
v2:
memory regions are correctly assigned to obj->memory_regions [tvrtko]
migration failure is reported as debug log [Tvrtko]
v3:
Migration is dropped. only error is reported [Daniel]
mem region check is move to pin_to_display [Chris]
v4:
s/dev_priv/i915 [chris]
cc: Matthew Auld
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 55c3ab59e3aa..6bf211784f73 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -419,11 +419,19 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
const struct i915_ggtt_view *view,
unsigned int flags)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_vma *vma;
int ret;
assert_object_held(obj);
+ /* GEM Obj for frame buffer is expected to be in LMEM. */
+ if (HAS_LMEM(i915))
+ if (obj->mm.region->type != INTEL_LMEM) {
+ DRM_DEBUG_KMS("OBJ is not from LMEM\n");
+ return ERR_PTR(-EINVAL);
+ }
+
/*
* The display engine is not coherent with the LLC cache on gen6. As
* a result, we make sure that the pinning that is about to occur is
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
On Wed, Sep 25, 2019 at 06:05:42AM +0530, srinivasa...@intel.com wrote:
> From: Srinivasan S
>
> This patch avoids DP MST payload error message in dmesg, as it is trying
> to update the payload to the disconnected DP MST device. After DP MST
> device is disconnected we should not be updating the payload and
> hence remove the error.
>
> v2: Removed the connector status check and converted from error to debug.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111632
> Signed-off-by: Srinivasan S
Pushed to dinq. Thanks for the patch.
PS. Next time please use --in-reply-to when sending an updated patch
so that it's easier to keep track of the discussion.
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index eeeb3f933aa4..497a6ae0d2c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -215,7 +215,7 @@ static void intel_mst_disable_dp(struct intel_encoder
> *encoder,
>
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> if (ret) {
> - DRM_ERROR("failed to update payload %d\n", ret);
> + DRM_DEBUG_KMS("failed to update payload %d\n", ret);
> }
> if (old_crtc_state->has_audio)
> intel_audio_codec_disable(encoder,
> --
> 2.7.4
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise potential false lite-restore
On 01/10/2019 10:51, Chris Wilson wrote:
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poisoning the ringbuffer of the first context and trying
to trick a simple RING_TAIL update (i.e. lite-restore)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Then switch back to ce[0] for fun.
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 132 +
1 file changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 93f2fcdc49bf..b90b970a44b9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -79,6 +79,137 @@ static int live_sanitycheck(void *arg)
return err;
}
+static int live_unlite_restore(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct igt_spinner spin;
+ int err = -ENOMEM;
+
+ /*
+* Check that we can correctly context switch between 2 instances
+* on the same engine from the same parent context.
+*/
+
+ mutex_lock(&i915->drm.struct_mutex);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ if (igt_spinner_init(&spin, &i915->gt))
+ goto err_unlock;
+
+ ctx = kernel_context(i915);
+ if (!ctx)
+ goto err_spin;
+
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq[3];
+ struct igt_live_test t;
+ int n;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(&t, i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ ce[n] = intel_context_create(ctx, engine);
+ if (IS_ERR(ce[n])) {
+ err = PTR_ERR(ce[n]);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(ce[n]);
+ if (err)
+ goto err_ce;
If pinning fails err_ce path will underflow the unpin. Perhaps you need
to only store in ce[] when both steps have passed and keep it in a local
until then.
+
+ /*
+* Setup the pair of contexts such that if we
+* lite-restore using the RING_TAIL from ce[1] it
+* will execute garbage from ce[0]->ring.
+*/
+ memset(ce[n]->ring->vaddr,
+ POISON_INUSE,
+ ce[n]->ring->vma->size);
+ }
+ intel_ring_reset(ce[1]->ring, ce[1]->ring->vma->size / 2);
+ __execlists_update_reg_state(ce[1], engine);
+
+ rq[0] = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq[0])) {
+ err = PTR_ERR(rq[0]);
+ goto err_ce;
+ }
+
+ GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
+ i915_request_get(rq[0]);
+ i915_request_add(rq[0]);
+
+ if (!igt_wait_for_spinner(&spin, rq[0])) {
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ rq[1] = i915_request_create(ce[1]);
+ if (IS_ERR(rq[1])) {
+ err = PTR_ERR(rq[1]);
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+ GEM_BUG_ON(rq[1]->tail <= rq[0]->tail);
+
+ /* Ensure we do a completion switch from ce[0] to ce[1] */
+ i915_request_await_dma_fence(rq[1], &rq[0]->fence);
What do you mean by completion switch? You are setting up a dependency
so rq[1] (and rq[2]) won't be put into the elsp until spinner is ended
so it may not even be a context switch. Wouldn't you actually need the
opposite? I was expecting you would let the spinner run, make sure rq[1]
is in elsp and then count on time slicing to trigger a context switch.
Regards,
Tvrtko
+ i915_request_put(rq[0]);
+
+ i915_request_get(rq[1]);
+ i915_request_add(rq[1]);
+
+ /* And switch back to ce[0] for good measure */
+ rq[2] = i915_request_create(ce[0]);
+ if (IS_ERR(rq[2])) {
+ err = PTR_ERR(rq
Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
On Mon, Sep 30, 2019 at 11:37:41AM -0700, Lucas De Marchi wrote: > On Sun, Sep 22, 2019 at 10:08:02AM -0700, Manasi Navare wrote: > >In case of tiled displays when the two tiles are sent across two CRTCs > >over two separate DP SST connectors, we need a mechanism to synchronize > >the two CRTCs and their corresponding transcoders. > >So use the master-slave mode where there is one master corresponding > >to last horizontal and vertical tile that needs to be genlocked with > >all other slave tiles. > >This patch identifies saves the master transcoder in all the slave > >CRTC states. This is needed to select the master CRTC/transcoder > >while configuring transcoder port sync for the corresponding slaves. > > > >v4: > >* Rebase > >v3: > >* Use master_tramscoder instead of master_crtc for valid > >HW state readouts (Ville) > >v2: > >* Move this to intel_mode_set_pipe_config(Jani N, Ville) > >* Use slave_bitmask to save associated slaves in master crtc state (Ville) > > > >Cc: Daniel Vetter > >Cc: Ville Syrjälä > >Cc: Maarten Lankhorst > >Cc: Matt Roper > >Signed-off-by: Manasi Navare > >Reviewed-by: Maarten Lankhorst > >--- > > drivers/gpu/drm/i915/display/intel_display.c | 123 ++ > > drivers/gpu/drm/i915/display/intel_display.h | 3 + > > .../drm/i915/display/intel_display_types.h| 6 + > > 3 files changed, 132 insertions(+) > > > >diff --git a/drivers/gpu/drm/i915/display/intel_display.c > >b/drivers/gpu/drm/i915/display/intel_display.c > >index c05ba6af6226..4ff375d5852d 100644 > >--- a/drivers/gpu/drm/i915/display/intel_display.c > >+++ b/drivers/gpu/drm/i915/display/intel_display.c > >@@ -521,6 +521,24 @@ needs_modeset(const struct intel_crtc_state *state) > > return drm_atomic_crtc_needs_modeset(&state->base); > > } > > > >+bool > >+is_trans_port_sync_mode(struct drm_i915_private *dev_priv, > >+const struct intel_crtc_state *state) > > on TGL we now also need a master transcoder for DP-MST. I'm wondering if > we couldn't reuse the same mechanism so we would dissociate a little bit > the port_sync_mode from saving or searching for a master transcoder > in crtc_state. I think we want to track them separately to make the state checker etc. robust. But I do think we should likely use the same logic for picking all masters, and I think that logic should probably just be "lowest numbered pipe is the master". > > >@@ -12369,6 +12478,15 @@ intel_modeset_pipe_config(struct intel_crtc_state > >*pipe_config) > > drm_mode_set_crtcinfo(&pipe_config->base.adjusted_mode, > > CRTC_STEREO_DOUBLE); > > > >+/* Set the crtc_state defaults for trans_port_sync */ > >+pipe_config->master_transcoder = INVALID_TRANSCODER; > > could we get away with the INVALID_TRANSCODER by simply making > pipe_config->master_transcoder = pipe_config->cpu_transcoder? That would degrade the state checker I think. Ie. we could accidentally program the transcoder to be its own master and wouldn't even notice. We would also need to add extra logic to check for this when programming things and that would just result in more wtfs when reading the code. > > then we can always make sure it's assigned to something valid > and use it in the cases it makes sense (port sync mode and dp-mst). > > Lucas De Marchi > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Describe structure members in documentation
Add missing descriptions of i915_perf_stream structure members
to documentation.
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
Cc: Robert Bragg
Signed-off-by: Anna Karas
---
drivers/gpu/drm/i915/i915_drv.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 337d8306416a..e269c92f227f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1130,14 +1130,43 @@ struct i915_perf_stream {
* @pinned_ctx: The OA context specific information.
*/
struct intel_context *pinned_ctx;
+
+ /**
+* @specific_ctx_id: The id of the specific context.
+*/
u32 specific_ctx_id;
+
+ /**
+* @specific_ctx_id_mask: The mask used to masking specific_ctx_id bits.
+*/
u32 specific_ctx_id_mask;
+ /**
+* @poll_check_timer: High resolution timer that will periodically
+* check for data in the circular OA buffer for notifying userspace
+* (e.g. during a read() or poll()).
+*/
struct hrtimer poll_check_timer;
+
+ /**
+* @poll_wq: The wait queue that hrtimer callback wakes when it
+* sees data ready to read in the circular OA buffer.
+*/
wait_queue_head_t poll_wq;
+
+ /**
+* @pollin: Whether there is data available to read.
+*/
bool pollin;
+ /**
+* @periodic: Whether periodic sampling is currently enabled.
+*/
bool periodic;
+
+ /**
+* @period_exponent: The OA unit sampling frequency is derived from
this.
+*/
int period_exponent;
/**
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise potential false lite-restore
Quoting Tvrtko Ursulin (2019-10-01 13:16:19)
>
> On 01/10/2019 10:51, Chris Wilson wrote:
> > +
> > + /*
> > + * Setup the pair of contexts such that if we
> > + * lite-restore using the RING_TAIL from ce[1] it
> > + * will execute garbage from ce[0]->ring.
> > + */
> > + memset(ce[n]->ring->vaddr,
> > +POISON_INUSE,
> > +ce[n]->ring->vma->size);
> > + }
> > + intel_ring_reset(ce[1]->ring, ce[1]->ring->vma->size / 2);
> > + __execlists_update_reg_state(ce[1], engine);
> > +
> > + rq[0] = igt_spinner_create_request(&spin, ce[0],
> > MI_ARB_CHECK);
> > + if (IS_ERR(rq[0])) {
> > + err = PTR_ERR(rq[0]);
> > + goto err_ce;
> > + }
> > +
> > + GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
> > + i915_request_get(rq[0]);
> > + i915_request_add(rq[0]);
> > +
> > + if (!igt_wait_for_spinner(&spin, rq[0])) {
> > + i915_request_put(rq[0]);
> > + goto err_ce;
> > + }
> > +
> > + rq[1] = i915_request_create(ce[1]);
> > + if (IS_ERR(rq[1])) {
> > + err = PTR_ERR(rq[1]);
> > + i915_request_put(rq[0]);
> > + goto err_ce;
> > + }
> > + GEM_BUG_ON(rq[1]->tail <= rq[0]->tail);
> > +
> > + /* Ensure we do a completion switch from ce[0] to ce[1] */
> > + i915_request_await_dma_fence(rq[1], &rq[0]->fence);
>
> What do you mean by completion switch? You are setting up a dependency
> so rq[1] (and rq[2]) won't be put into the elsp until spinner is ended
> so it may not even be a context switch. Wouldn't you actually need the
> opposite? I was expecting you would let the spinner run, make sure rq[1]
> is in elsp and then count on time slicing to trigger a context switch.
The test I had in mind was to have
ELSP[0] = ce[0]
ELSP[1] = ce[1]
and so chose to prevent any timeslicing reordering that. Same engine, so
it will add a wait-on-submit-fence (i.e. a no-op) but would install the
dependency link to prevent any reordering.
A second test to have the spinner running then using priority to preempt
it, seems like a good addition.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_crtc_background_color: overhaul to match upstream ABI (v5.1)
On Mon, Sep 30, 2019 at 10:18:17PM -0400, Martin Peres wrote:
> On 30/09/2019 19:13, Matt Roper wrote:
> > CRTC background color kernel patches were written about 2.5 years ago
> > and floated on the upstream mailing list, but since no opensource
> > userspace materialized, we never actually merged them. However the
> > corresponding IGT test did get merged and has basically been dead code
> > ever since.
> >
> > A couple years later we finally have an open source userspace
> > (ChromeOS), so lets update the IGT test to match the ABI that's actually
> > going upstream and to remove some of the cruft from the original test
> > that wouldn't actually work.
> >
> > It's worth noting that CRC's don't seem to work properly on Intel gen9.
> > The bspec does tell us that we must have one plane enabled before taking
> > a pipe-level ("dmux") CRC, so this test is violating that by disabling
> > all planes; it's quite possible that this is the source of the CRC
> > mismatch. If running on an Intel platform, you may want to run in
> > interactive mode ("--interactive-debug=bgcolor --skip-crc-compare") to
> > ensure that the colors being generated actually do match visually since
> > the CRC's can't be trusted.
>
> Hmm, landing a feature without automating testing for it is a bit too
> much to ask IMO.
>
> I have two proposals to make it happen:
>
> - Could we add a workaround for the affected intel platforms? If the
> problem really is because no planes are enabled, then surely a
> fully-transparent plane would be a sufficient workaround.
Just have to make sure that plane is the cursor since the blending
fail on the universal planes.
>
> - If CRCs really cannot be used for this, then we should use the
> chamelium for it. The idea would be to detect if the connector is
> connected to a chamelium, and if so use chamelium's CRC.
Third option would be to use the port crc instead.
>
> How does this sound?
>
> Martin
>
> >
> > v2:
> > - Swap red and blue ordering in property value to reflect change
> >in v2 of kernel series.
> >
> > v3:
> > - Minor updates to proposed uapi helpers (s/rgba/argb/).
> >
> > v4:
> > - General restructuring into pipe/color subtests.
> > - Use RGB2101010 framebuffers for comparison so that we match the bits
> >of precision that Intel hardware background color accepts
> >
> > v5:
> > - Re-enable CRC comparisons; just because these don't work on Intel
> >doesn't mean we shouldn't use them on other vendors' platforms
> >(Daniel).
> > - Use DRIVER_ANY rather than DRIVER_INTEL. (Heiko Stuebner)
> >
> > v5.1:
> > - Update commit message body discussion of CRC issues.
> >
> > Cc: igt-...@lists.freedesktop.org
> > Cc: Daniel Vetter
> > Cc: Heiko Stuebner
> > Signed-off-by: Matt Roper
> > ---
> > lib/igt_kms.c | 2 +-
> > tests/kms_crtc_background_color.c | 263 ++
> > 2 files changed, 127 insertions(+), 138 deletions(-)
> >
> > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > index e9b80b9b..9a7f0e23 100644
> > --- a/lib/igt_kms.c
> > +++ b/lib/igt_kms.c
> > @@ -391,7 +391,7 @@ const char * const
> > igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
> > };
> >
> > const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
> > - [IGT_CRTC_BACKGROUND] = "background_color",
> > + [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
> > [IGT_CRTC_CTM] = "CTM",
> > [IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
> > [IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
> > diff --git a/tests/kms_crtc_background_color.c
> > b/tests/kms_crtc_background_color.c
> > index 3df3401f..58cdd7a9 100644
> > --- a/tests/kms_crtc_background_color.c
> > +++ b/tests/kms_crtc_background_color.c
> > @@ -25,164 +25,153 @@
> > #include "igt.h"
> > #include
> >
> > -
> > IGT_TEST_DESCRIPTION("Test crtc background color feature");
> >
> > +/*
> > + * Paints a desired color into a full-screen primary plane and then
> > compares
> > + * that CRC with turning off all planes and setting the CRTC background to
> > the
> > + * same color.
> > + *
> > + * At least on current Intel platforms, the CRC tests appear to always
> > fail,
> > + * even though the resulting pipe output seems to be the same. The bspec
> > tells
> > + * us that we must have at least one plane turned on when taking a
> > pipe-level
> > + * CRC, so the fact that we're violating that may explain the failures. If
> > + * your platform gives failures for all tests, you may want to run with
> > + * --interactive-debug=bgcolor --skip-crc-compare to visually inspect that
> > the
> > + * background color matches the equivalent solid plane.
> > + */
> > +
> > typedef struct {
> > - int gfx_fd;
> > igt_display_t display;
> > - struct igt_fb fb;
> > - igt_crc_t ref_crc;
> > + int gfx_fd;
> > + igt_output_t *output;
> > igt_pipe_crc_t *pipe_crc;
> > + drmModeModeInfo *mode;
> > } data_t;
> >
> > -#define BLACK 0x00 /* BGR 8bpc *
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise potential false lite-restore
On 01/10/2019 13:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-01 13:16:19)
On 01/10/2019 10:51, Chris Wilson wrote:
+
+ /*
+ * Setup the pair of contexts such that if we
+ * lite-restore using the RING_TAIL from ce[1] it
+ * will execute garbage from ce[0]->ring.
+ */
+ memset(ce[n]->ring->vaddr,
+POISON_INUSE,
+ce[n]->ring->vma->size);
+ }
+ intel_ring_reset(ce[1]->ring, ce[1]->ring->vma->size / 2);
+ __execlists_update_reg_state(ce[1], engine);
+
+ rq[0] = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq[0])) {
+ err = PTR_ERR(rq[0]);
+ goto err_ce;
+ }
+
+ GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
+ i915_request_get(rq[0]);
+ i915_request_add(rq[0]);
+
+ if (!igt_wait_for_spinner(&spin, rq[0])) {
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ rq[1] = i915_request_create(ce[1]);
+ if (IS_ERR(rq[1])) {
+ err = PTR_ERR(rq[1]);
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+ GEM_BUG_ON(rq[1]->tail <= rq[0]->tail);
+
+ /* Ensure we do a completion switch from ce[0] to ce[1] */
+ i915_request_await_dma_fence(rq[1], &rq[0]->fence);
What do you mean by completion switch? You are setting up a dependency
so rq[1] (and rq[2]) won't be put into the elsp until spinner is ended
so it may not even be a context switch. Wouldn't you actually need the
opposite? I was expecting you would let the spinner run, make sure rq[1]
is in elsp and then count on time slicing to trigger a context switch.
The test I had in mind was to have
ELSP[0] = ce[0]
ELSP[1] = ce[1]
and so chose to prevent any timeslicing reordering that. Same engine, so
it will add a wait-on-submit-fence (i.e. a no-op) but would install the
dependency link to prevent any reordering.
Ah my bad, did not think about the same engine optimisation. Expand the
comment? :)
A second test to have the spinner running then using priority to preempt
it, seems like a good addition.
Priority it more controllable than timeslicing, true.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/9] drm/print: add and use drm_debug_enabled()
On Tuesday, 2019-10-01 14:03:55 +0300, Jani Nikula wrote:
> On Thu, 26 Sep 2019, Eric Engestrom wrote:
> > On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
> >> Hi all, v2 of [1], a little refactoring around drm_debug access to
> >> abstract it better. There shouldn't be any functional changes.
> >>
> >> I'd appreciate acks for merging the lot via drm-misc. If there are any
> >> objections to that, we'll need to postpone the last patch until
> >> everything has been merged and converted in drm-next.
> >>
> >> BR,
> >> Jani.
> >>
> >> Cc: Eric Engestrom
> >> Cc: Alex Deucher
> >> Cc: Christian König
> >> Cc: David (ChunMing) Zhou
> >> Cc: amd-...@lists.freedesktop.org
> >> Cc: Ben Skeggs
> >> Cc: nouv...@lists.freedesktop.org
> >> Cc: Rob Clark
> >> Cc: Sean Paul
> >> Cc: linux-arm-...@vger.kernel.org
> >> Cc: freedr...@lists.freedesktop.org
> >> Cc: Francisco Jerez
> >> Cc: Lucas Stach
> >> Cc: Russell King
> >> Cc: Christian Gmeiner
> >> Cc: etna...@lists.freedesktop.org
> >>
> >>
> >> [1] cover.1568375189.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1568375189.git.jani.nikula@intel.com
> >>
> >> Jani Nikula (9):
> >> drm/print: move drm_debug variable to drm_print.[ch]
> >> drm/print: add drm_debug_enabled()
> >> drm/i915: use drm_debug_enabled() to check for debug categories
> >> drm/print: rename drm_debug to __drm_debug to discourage use
> >
> > The above four patches are:
> > Reviewed-by: Eric Engestrom
> >
> > Did you check to make sure the `unlikely()` is propagated correctly
> > outside the `drm_debug_enabled()` call?
>
> I did now.
>
> Having drm_debug_enabled() as a macro vs. as an inline function does not
> seem to make a difference, so I think the inline is clearly preferrable.
Agreed :)
>
> However, for example
>
> unlikely(foo && drm_debug & DRM_UT_DP)
>
> does produce code different from
>
> (foo && drm_debug_enabled(DRM_UT_DP))
>
> indicating that the unlikely() within drm_debug_enabled() does not
> propagate to the whole condition. It's possible to retain the same
> assembly output with
>
> (unlikely(foo) && drm_debug_enabled(DRM_UT_DP))
>
> but it's unclear to me whether this is really worth it, either
> readability or performance wise.
>
> Thoughts?
That kind of code only happens 2 times, both in
drivers/gpu/drm/drm_dp_mst_topology.c (in patch 2/9), right?
I think your suggestion is the right thing to do here:
- if (unlikely(ret && drm_debug & DRM_UT_DP)) {
+ if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
It doesn't really cost much in readability (especially compared to what
it was before), and whether it's important performance wise I couldn't
tell, but I think it's best to keep the code optimised as it was before
unless there's a reason to drop it.
Lyude might know more since she wrote 2f015ec6eab69301fdcf5, if you want
to ping her?
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for TGL HAX drm/i915/tgl: Defer direct submission from interrupt context
== Series Details == Series: TGL HAX drm/i915/tgl: Defer direct submission from interrupt context URL : https://patchwork.freedesktop.org/series/67431/ State : success == Summary == CI Bug Log - changes from CI_DRM_6980_full -> Patchwork_14600_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_14600_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14600_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_14600_full: ### IGT changes ### Warnings * igt@gem_exec_reuse@contexts: - shard-skl: [INCOMPLETE][1] ([fdo#111875]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-skl8/igt@gem_exec_re...@contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-skl5/igt@gem_exec_re...@contexts.html Known issues Here are the changes found in Patchwork_14600_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_read@short-buffer-wakeup: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-apl3/igt@drm_r...@short-buffer-wakeup.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-apl2/igt@drm_r...@short-buffer-wakeup.html * igt@gem_ctx_isolation@vecs0-s3: - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103665]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl4/igt@gem_ctx_isolat...@vecs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-kbl6/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_exec_schedule@preempt-hang-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-iclb4/igt@gem_exec_sched...@preempt-hang-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-iclb5/igt@gem_exec_sched...@preempt-hang-bsd1.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#111870]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl3/igt@gem_userptr_bl...@dmabuf-sync.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-kbl4/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-hsw: [PASS][13] -> [DMESG-WARN][14] ([fdo#111870]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-hsw7/igt@gem_userptr_bl...@dmabuf-unsync.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-hsw5/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-glk9/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-glk1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-skl5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-skl1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([fdo#110741]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14600
[Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise potential false lite-restore
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poisoning the ringbuffer of the first context and trying
to trick a simple RING_TAIL update (i.e. lite-restore)
v2: Also check what happens if preempt ce[0] with ce[1] (both instances
on the same engine from the same parent context) [Tvrtko]
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 173 +
1 file changed, 173 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 93f2fcdc49bf..de498c38a006 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -79,6 +79,177 @@ static int live_sanitycheck(void *arg)
return err;
}
+static int live_unlite_restore(struct drm_i915_private *i915, int prio)
+{
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct igt_spinner spin;
+ int err = -ENOMEM;
+
+ /*
+* Check that we can correctly context switch between 2 instances
+* on the same engine from the same parent context.
+*/
+
+ mutex_lock(&i915->drm.struct_mutex);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ if (igt_spinner_init(&spin, &i915->gt))
+ goto err_unlock;
+
+ ctx = kernel_context(i915);
+ if (!ctx)
+ goto err_spin;
+
+ err = 0;
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq[2];
+ struct igt_live_test t;
+ int n;
+
+ if (prio && !intel_engine_has_preemption(engine))
+ continue;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(&t, i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ struct intel_context *tmp;
+
+ tmp = intel_context_create(ctx, engine);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(tmp);
+ if (err) {
+ intel_context_put(tmp);
+ goto err_ce;
+ }
+
+ /*
+* Setup the pair of contexts such that if we
+* lite-restore using the RING_TAIL from ce[1] it
+* will execute garbage from ce[0]->ring.
+*/
+ memset(tmp->ring->vaddr,
+ POISON_INUSE, /* IPEHR: 0x5a5a5a5a [hung!] */
+ tmp->ring->vma->size);
+
+ ce[n] = tmp;
+ }
+ intel_ring_reset(ce[1]->ring, ce[1]->ring->vma->size / 2);
+ __execlists_update_reg_state(ce[1], engine);
+
+ rq[0] = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq[0])) {
+ err = PTR_ERR(rq[0]);
+ goto err_ce;
+ }
+
+ GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
+ i915_request_get(rq[0]);
+ i915_request_add(rq[0]);
+
+ if (!igt_wait_for_spinner(&spin, rq[0])) {
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ rq[1] = i915_request_create(ce[1]);
+ if (IS_ERR(rq[1])) {
+ err = PTR_ERR(rq[1]);
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+ GEM_BUG_ON(rq[1]->tail <= rq[0]->tail);
+
+ if (!prio) {
+ /*
+* Ensure we do the switch to ce[1] on completion.
+*
+* rq[0] is already submitted, so this should reduce
+* to a no-op (a wait on a request on the same engine
+* uses the submit fence, not the completion fence),
+* but it will install a dependency on rq[1] for rq[0]
+* that will prevent the pair being reordered by
+* timeslicing.
+*/
+ i915_request_await_dma_fence(rq[1]
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
Thanks a lot Manasi, Ville, Mika, Jani, Lakshmi, for all your time in reviewing
this patch.
Best Regards,
> -Original Message-
> From: dri-devel On Behalf Of Ville
> Syrjälä
> Sent: Tuesday, October 1, 2019 5:31 PM
> To: S, Srinivasan
> Cc: Navare, Manasi D ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vudum,
> Lakshminarayana
> Subject: Re: [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC
> cable
>
> On Wed, Sep 25, 2019 at 06:05:42AM +0530, srinivasa...@intel.com wrote:
> > From: Srinivasan S
> >
> > This patch avoids DP MST payload error message in dmesg, as it is trying
> > to update the payload to the disconnected DP MST device. After DP MST
> > device is disconnected we should not be updating the payload and
> > hence remove the error.
> >
> > v2: Removed the connector status check and converted from error to debug.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111632
> > Signed-off-by: Srinivasan S
>
> Pushed to dinq. Thanks for the patch.
>
> PS. Next time please use --in-reply-to when sending an updated patch
> so that it's easier to keep track of the discussion.
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index eeeb3f933aa4..497a6ae0d2c0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -215,7 +215,7 @@ static void intel_mst_disable_dp(struct intel_encoder
> *encoder,
> >
> > ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > if (ret) {
> > - DRM_ERROR("failed to update payload %d\n", ret);
> > + DRM_DEBUG_KMS("failed to update payload %d\n", ret);
> > }
> > if (old_crtc_state->has_audio)
> > intel_audio_codec_disable(encoder,
> > --
> > 2.7.4
>
> --
> Ville Syrjälä
> Intel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise potential false lite-restore
On 01/10/2019 13:43, Chris Wilson wrote:
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poisoning the ringbuffer of the first context and trying
to trick a simple RING_TAIL update (i.e. lite-restore)
v2: Also check what happens if preempt ce[0] with ce[1] (both instances
on the same engine from the same parent context) [Tvrtko]
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 173 +
1 file changed, 173 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 93f2fcdc49bf..de498c38a006 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -79,6 +79,177 @@ static int live_sanitycheck(void *arg)
return err;
}
+static int live_unlite_restore(struct drm_i915_private *i915, int prio)
+{
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct igt_spinner spin;
+ int err = -ENOMEM;
+
+ /*
+* Check that we can correctly context switch between 2 instances
+* on the same engine from the same parent context.
+*/
+
+ mutex_lock(&i915->drm.struct_mutex);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ if (igt_spinner_init(&spin, &i915->gt))
+ goto err_unlock;
+
+ ctx = kernel_context(i915);
+ if (!ctx)
+ goto err_spin;
+
+ err = 0;
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq[2];
+ struct igt_live_test t;
+ int n;
+
+ if (prio && !intel_engine_has_preemption(engine))
+ continue;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(&t, i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ struct intel_context *tmp;
+
+ tmp = intel_context_create(ctx, engine);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(tmp);
+ if (err) {
+ intel_context_put(tmp);
+ goto err_ce;
+ }
+
+ /*
+* Setup the pair of contexts such that if we
+* lite-restore using the RING_TAIL from ce[1] it
+* will execute garbage from ce[0]->ring.
+*/
+ memset(tmp->ring->vaddr,
+ POISON_INUSE, /* IPEHR: 0x5a5a5a5a [hung!] */
+ tmp->ring->vma->size);
+
+ ce[n] = tmp;
+ }
+ intel_ring_reset(ce[1]->ring, ce[1]->ring->vma->size / 2);
+ __execlists_update_reg_state(ce[1], engine);
+
+ rq[0] = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq[0])) {
+ err = PTR_ERR(rq[0]);
+ goto err_ce;
+ }
+
+ GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
+ i915_request_get(rq[0]);
+ i915_request_add(rq[0]);
+
+ if (!igt_wait_for_spinner(&spin, rq[0])) {
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ rq[1] = i915_request_create(ce[1]);
+ if (IS_ERR(rq[1])) {
+ err = PTR_ERR(rq[1]);
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+ GEM_BUG_ON(rq[1]->tail <= rq[0]->tail);
+
+ if (!prio) {
+ /*
+* Ensure we do the switch to ce[1] on completion.
+*
+* rq[0] is already submitted, so this should reduce
+* to a no-op (a wait on a request on the same engine
+* uses the submit fence, not the completion fence),
+* but it will install a dependency on rq[1] for rq[0]
+* that will prevent the pair being reordered by
+* timeslicing.
+*/
+
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise potential false lite-restore
Quoting Tvrtko Ursulin (2019-10-01 13:59:14) > > On 01/10/2019 13:43, Chris Wilson wrote: > > + tasklet_kill(&engine->execlists.tasklet); /* flush submission > > */ > > Is this really needed, why? In a pathological case where we are using the tasklet (e.g. preemption and ksoftirqd active), it would then be possible for the spinner to complete (thanks to the igt_spinner_end below) before we process the preemption request (thus we would not perform a preemption request). Now it may still complete before the HW has a chance to process the ELSP submit, but that risk feels less likely. (We would need to wait on !execlists->pending with a timeout to be sure.) tasklet_kill() is while tasklet is queued and not run: yield(); I think we need only the one flush as we only really care about the first available execlists_submit_port that has both ELSP filled to check for a possible lite-restore between the different contexts. -Chris ___ 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/userptr: Never allow userptr into the mappable GGTT (rev3)
== Series Details == Series: drm/i915/userptr: Never allow userptr into the mappable GGTT (rev3) URL : https://patchwork.freedesktop.org/series/67349/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6980_full -> Patchwork_14601_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14601_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14601_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_14601_full: ### IGT changes ### Possible regressions * igt@gem_tiled_blits@normal: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl7/igt@gem_tiled_bl...@normal.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-kbl4/igt@gem_tiled_bl...@normal.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: [PASS][3] -> [FAIL][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl3/igt@gem_userptr_bl...@dmabuf-sync.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-kbl1/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-hsw: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-hsw7/igt@gem_userptr_bl...@dmabuf-unsync.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-hsw8/igt@gem_userptr_bl...@dmabuf-unsync.html - shard-snb: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-snb1/igt@gem_userptr_bl...@dmabuf-unsync.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-snb1/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@readonly-mmap-unsync: - shard-apl: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-apl8/igt@gem_userptr_bl...@readonly-mmap-unsync.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-apl7/igt@gem_userptr_bl...@readonly-mmap-unsync.html - shard-glk: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-glk4/igt@gem_userptr_bl...@readonly-mmap-unsync.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-glk6/igt@gem_userptr_bl...@readonly-mmap-unsync.html Warnings * igt@gem_userptr_blits@dmabuf-sync: - shard-snb: [DMESG-WARN][13] ([fdo#111870]) -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-snb2/igt@gem_userptr_bl...@dmabuf-sync.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-snb2/igt@gem_userptr_bl...@dmabuf-sync.html - shard-iclb: [DMESG-WARN][15] ([fdo#111870]) -> [FAIL][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-iclb1/igt@gem_userptr_bl...@dmabuf-sync.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-iclb2/igt@gem_userptr_bl...@dmabuf-sync.html - shard-hsw: [DMESG-WARN][17] ([fdo#111870]) -> [FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-hsw1/igt@gem_userptr_bl...@dmabuf-sync.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-hsw4/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-skl: [DMESG-WARN][19] ([fdo#111870]) -> [FAIL][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-skl2/igt@gem_userptr_bl...@dmabuf-unsync.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-skl7/igt@gem_userptr_bl...@dmabuf-unsync.html - shard-kbl: [DMESG-WARN][21] ([fdo#111870]) -> [FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-kbl3/igt@gem_userptr_bl...@dmabuf-unsync.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-kbl1/igt@gem_userptr_bl...@dmabuf-unsync.html Known issues Here are the changes found in Patchwork_14601_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-contexts-immediate: - shard-hsw: [PASS][23] -> [FAIL][24] ([fdo#105957]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6980/shard-hsw8/igt@gem_...@in-flight-contexts-immediate.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14601/shard-hsw7/igt@gem_...@in-flight-contexts-immediate.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][2
[Intel-gfx] [PATCH] drm/i915/display: split out intel_vga_client.[ch]
Split out code related to vga client and vga switcheroo
register/unregister and state handling from i915_drv.c and
intel_display.c.
It's a bit difficult to draw the line how much to move to the new file
from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo()
and i915_resume_switcheroo() in place was cleanest.
No functional changes.
Cc: Ville Syrjälä
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
It's also a bit fuzzy if this is a sensible split anyway. Could also
name it intel_vga and move these from intel_display.c there?
i915_vgacntrl_reg
i915_disable_vga
i915_redisable_vga
i915_redisable_vga_power_on
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 29
drivers/gpu/drm/i915/display/intel_display.h | 1 -
.../gpu/drm/i915/display/intel_vga_client.c | 140 ++
.../gpu/drm/i915/display/intel_vga_client.h | 14 ++
drivers/gpu/drm/i915/i915_drv.c | 94 +---
drivers/gpu/drm/i915/i915_drv.h | 3 +
7 files changed, 166 insertions(+), 118 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_vga_client.c
create mode 100644 drivers/gpu/drm/i915/display/intel_vga_client.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e04463d85401..ca770463e01f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -184,7 +184,8 @@ i915-y += \
display/intel_psr.o \
display/intel_quirks.o \
display/intel_sprite.o \
- display/intel_tc.o
+ display/intel_tc.o \
+ display/intel_vga_client.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
display/intel_opregion.o
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f1328c08f4ad..6278d62bc87d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17188,35 +17188,6 @@ void intel_modeset_driver_remove(struct
drm_i915_private *i915)
intel_fbc_cleanup_cfb(i915);
}
-/*
- * set vga decode state - true == enable VGA decode
- */
-int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool state)
-{
- unsigned reg = INTEL_GEN(dev_priv) >= 6 ? SNB_GMCH_CTRL :
INTEL_GMCH_CTRL;
- u16 gmch_ctrl;
-
- if (pci_read_config_word(dev_priv->bridge_dev, reg, &gmch_ctrl)) {
- DRM_ERROR("failed to read control word\n");
- return -EIO;
- }
-
- if (!!(gmch_ctrl & INTEL_GMCH_VGA_DISABLE) == !state)
- return 0;
-
- if (state)
- gmch_ctrl &= ~INTEL_GMCH_VGA_DISABLE;
- else
- gmch_ctrl |= INTEL_GMCH_VGA_DISABLE;
-
- if (pci_write_config_word(dev_priv->bridge_dev, reg, gmch_ctrl)) {
- DRM_ERROR("failed to write control word\n");
- return -EIO;
- }
-
- return 0;
-}
-
#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
struct intel_display_error_state {
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 4b9e18e5a263..a7b0d11a3316 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -579,7 +579,6 @@ void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init(struct drm_i915_private *i915);
void intel_modeset_driver_remove(struct drm_i915_private *i915);
-int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool state);
void intel_display_resume(struct drm_device *dev);
void i915_redisable_vga(struct drm_i915_private *dev_priv);
void i915_redisable_vga_power_on(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/display/intel_vga_client.c
b/drivers/gpu/drm/i915/display/intel_vga_client.c
new file mode 100644
index ..04ef1443f40e
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_vga_client.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "i915_drv.h"
+#include "intel_acpi.h"
+#include "intel_vga_client.h"
+
+static int
+intel_vga_client_set_state(struct drm_i915_private *i915, bool enable_decode)
+{
+ unsigned int reg = INTEL_GEN(i915) >= 6 ? SNB_GMCH_CTRL :
INTEL_GMCH_CTRL;
+ u16 gmch_ctrl;
+
+ if (pci_read_config_word(i915->bridge_dev, reg, &gmch_ctrl)) {
+ DRM_ERROR("failed to read control word\n");
+ return -EIO;
+ }
+
+ if (!!(gmch_ctrl & INTEL_GMCH_VGA_DISABLE) == !enable_decode)
+ return 0;
+
+ if (enable_decode)
+ gmch_ctrl &= ~INTEL_GMCH_VGA_DISABLE;
+ else
+ gmch_ctrl |= INTEL_GMCH_VGA_DISABLE;
+
+ if (pci_write_config_word(i915->bridge_dev, re
[Intel-gfx] [PATCH 0/2] Conclude load -> probe naming convention switch
Test-with: <20191001132728.14602-1-janusz.krzyszto...@linux.intel.com> The purpose is: * to fix incompatible names of new functions introduced meanwhile, * to complete postponed rename of module parameter. Will be tested with just submitted IGT counterpart using a trybot submission because I forgot to add a cover letter required for successful joint testing when I was submitting to igt-dev list, sorry. Thanks, Janusz Janusz Krzysztofik (2): drm/i915: Fix i915_inject_load_error() name to read *_probe_* drm/i915: Rename "inject_load_failure" module parameter .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 ++-- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +++--- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 ++- drivers/gpu/drm/i915/i915_gem.c | 4 ++-- drivers/gpu/drm/i915/i915_params.c| 2 +- drivers/gpu/drm/i915/i915_params.h| 2 +- drivers/gpu/drm/i915/i915_utils.c | 14 ++--- drivers/gpu/drm/i915/i915_utils.h | 12 +-- 9 files changed, 34 insertions(+), 32 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Fix i915_inject_load_error() name to read *_probe_*
Commit 50d84418f586 ("drm/i915: Add i915 to i915_inject_probe_failure")
introduced new functions unfortunately named incompatibly with rules
established by commit f2db53f14d3d ("drm/i915: Replace "_load" with
"_probe" consequently"). Fix it for consistency.
Suggested-by: Michał Wajdeczko
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 ++-
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/i915_utils.c | 4 ++--
drivers/gpu/drm/i915/i915_utils.h | 12 +--
7 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index f325d3dd564f..67e46c2af6df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1119,7 +1119,7 @@ int intel_guc_submission_enable(struct intel_guc *guc)
enum intel_engine_id id;
int err;
- err = i915_inject_load_error(gt->i915, -ENXIO);
+ err = i915_inject_probe_error(gt->i915, -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index d4625c97b4f9..8295ff971bcc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -35,7 +35,7 @@ static int intel_huc_rsa_data_create(struct intel_huc *huc)
void *vaddr;
int err;
- err = i915_inject_load_error(gt->i915, -ENXIO);
+ err = i915_inject_probe_error(gt->i915, -ENXIO);
if (err)
return err;
@@ -134,7 +134,7 @@ int intel_huc_auth(struct intel_huc *huc)
if (!intel_uc_fw_is_loaded(&huc->fw))
return -ENOEXEC;
- ret = i915_inject_load_error(gt->i915, -ENXIO);
+ ret = i915_inject_probe_error(gt->i915, -ENXIO);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 71ee7ab035cc..fb0d7bb712ab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -20,7 +20,7 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
int ret;
u32 guc_status;
- ret = i915_inject_load_error(gt->i915, -ENXIO);
+ ret = i915_inject_probe_error(gt->i915, -ENXIO);
if (ret)
return ret;
@@ -197,7 +197,7 @@ static int guc_enable_communication(struct intel_guc *guc)
GEM_BUG_ON(guc_communication_enabled(guc));
- ret = i915_inject_load_error(i915, -ENXIO);
+ ret = i915_inject_probe_error(i915, -ENXIO);
if (ret)
return ret;
@@ -368,7 +368,7 @@ static int uc_init_wopcm(struct intel_uc *uc)
GEM_BUG_ON(!(size & GUC_WOPCM_SIZE_MASK));
GEM_BUG_ON(size & ~GUC_WOPCM_SIZE_MASK);
- err = i915_inject_load_error(gt->i915, -ENXIO);
+ err = i915_inject_probe_error(gt->i915, -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index bd22bf11adad..f6830ec79a66 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -218,29 +218,31 @@ static void __force_fw_fetch_failures(struct intel_uc_fw
*uc_fw,
{
bool user = e == -EINVAL;
- if (i915_inject_load_error(i915, e)) {
+ if (i915_inject_probe_error(i915, e)) {
/* non-existing blob */
uc_fw->path = "";
uc_fw->user_overridden = user;
- } else if (i915_inject_load_error(i915, e)) {
+ } else if (i915_inject_probe_error(i915, e)) {
/* require next major version */
uc_fw->major_ver_wanted += 1;
uc_fw->minor_ver_wanted = 0;
uc_fw->user_overridden = user;
- } else if (i915_inject_load_error(i915, e)) {
+ } else if (i915_inject_probe_error(i915, e)) {
/* require next minor version */
uc_fw->minor_ver_wanted += 1;
uc_fw->user_overridden = user;
- } else if (uc_fw->major_ver_wanted && i915_inject_load_error(i915, e)) {
+ } else if (uc_fw->major_ver_wanted &&
+ i915_inject_probe_error(i915, e)) {
/* require prev major version */
uc_fw->major_ver_wanted -= 1;
uc_fw->minor_ver_wanted = 0;
uc_fw->user_overridden = user;
- } else if (uc_fw->minor_ver_wanted && i915_inject_load_error(i915, e)) {
+ } else if (uc_fw->minor_ver_wanted &&
+
[Intel-gfx] [PATCH 2/2] drm/i915: Rename "inject_load_failure" module parameter
Commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe"
consequently") deliberately left the name of the module parameter
unchanged as that would require a corresponding change on IGT size.
Now as the IGT side change has been submitted, complete the switch to
the "probe" nomenclature.
May affect custom user applications utilizing the old name.
Suggested-by: Joonas Lahtinen
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/i915_utils.c | 10 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..59a6586dae15 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -165,7 +165,7 @@ i915_param_named_unsafe(enable_dp_mst, bool, 0600,
"Enable multi-stream transport (MST) for new DisplayPort sinks.
(default: true)");
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
-i915_param_named_unsafe(inject_load_failure, uint, 0400,
+i915_param_named_unsafe(inject_probe_failure, uint, 0400,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
#endif
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index d29ade3b7de6..8c887413fc70 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -62,7 +62,7 @@ struct drm_printer;
param(int, mmio_debug, -IS_ENABLED(CONFIG_DRM_I915_DEBUG_MMIO)) \
param(int, edp_vswing, 0) \
param(int, reset, 2) \
- param(unsigned int, inject_load_failure, 0) \
+ param(unsigned int, inject_probe_failure, 0) \
param(int, fastboot, -1) \
param(int, enable_dpcd_backlight, 0) \
param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE) \
diff --git a/drivers/gpu/drm/i915/i915_utils.c
b/drivers/gpu/drm/i915/i915_utils.c
index e51bdb05da14..64affb87c284 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -57,22 +57,22 @@ static unsigned int i915_probe_fail_count;
int __i915_inject_probe_error(struct drm_i915_private *i915, int err,
const char *func, int line)
{
- if (i915_probe_fail_count >= i915_modparams.inject_load_failure)
+ if (i915_probe_fail_count >= i915_modparams.inject_probe_failure)
return 0;
- if (++i915_probe_fail_count < i915_modparams.inject_load_failure)
+ if (++i915_probe_fail_count < i915_modparams.inject_probe_failure)
return 0;
__i915_printk(i915, KERN_INFO,
"Injecting failure %d at checkpoint %u [%s:%d]\n",
- err, i915_modparams.inject_load_failure, func, line);
- i915_modparams.inject_load_failure = 0;
+ err, i915_modparams.inject_probe_failure, func, line);
+ i915_modparams.inject_probe_failure = 0;
return err;
}
bool i915_error_injected(void)
{
- return i915_probe_fail_count && !i915_modparams.inject_load_failure;
+ return i915_probe_fail_count && !i915_modparams.inject_probe_failure;
}
#endif
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/tgl: Restrict availables engines to rcs0 by default
CI is still unstable whenever we enable more than one engine, and we have not yet found a better hack than restricting it to using just rcs0. However, to allow testing to continue on the other engines by developers, we allow the available set of engines to be overridden on the command line with just the default set limited to [rcs0]. Signed-off-by: Chris Wilson Cc: Andi Shyti Cc: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 690da64ec256..9c8c7c8af394 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -406,6 +406,10 @@ static bool engine_available(struct drm_i915_private *i915, int id) if (!HAS_ENGINE(i915, id)) return false; + /* XXX reduced by default for CI stability XXX */ + if (IS_TIGERLAKE(i915) && i915_modparams.engines == -1u) + return id == RCS0; + if (!(i915_modparams.engines & param_bit[id])) return false; -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Use a modparam to restrict exposed engines
Allow the user to restrict the available set of engines via a module
parameter.
Signed-off-by: Chris Wilson
Cc: Stuart Summers
Cc: Andi Shyti
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Martin Peres
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 35 ---
drivers/gpu/drm/i915/i915_gem.c | 5
drivers/gpu/drm/i915/i915_params.c| 4 +++
drivers/gpu/drm/i915/i915_params.h| 1 +
4 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 80fd072ac719..690da64ec256 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -389,6 +389,29 @@ void intel_engines_cleanup(struct drm_i915_private *i915)
}
}
+static bool engine_available(struct drm_i915_private *i915, int id)
+{
+ /* uAPI -- modparam bits must be consistent between kernels */
+ static const unsigned int param_bit[] = {
+ [RCS0] = BIT(0),
+ [VCS0] = BIT(1),
+ [BCS0] = BIT(2),
+ [VECS0] = BIT(3),
+ [VCS1] = BIT(4),
+ [VCS2] = BIT(5),
+ [VCS3] = BIT(6),
+ [VECS1] = BIT(7),
+ };
+
+ if (!HAS_ENGINE(i915, id))
+ return false;
+
+ if (!(i915_modparams.engines & param_bit[id]))
+ return false;
+
+ return true;
+}
+
/**
* intel_engines_init_mmio() - allocate and prepare the Engine Command
Streamers
* @i915: the i915 device
@@ -397,7 +420,6 @@ void intel_engines_cleanup(struct drm_i915_private *i915)
*/
int intel_engines_init_mmio(struct drm_i915_private *i915)
{
- struct intel_device_info *device_info = mkwrite_device_info(i915);
const unsigned int engine_mask = INTEL_INFO(i915)->engine_mask;
unsigned int mask = 0;
unsigned int i;
@@ -411,7 +433,7 @@ int intel_engines_init_mmio(struct drm_i915_private *i915)
return -ENODEV;
for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
- if (!HAS_ENGINE(i915, i))
+ if (!engine_available(i915, i))
continue;
err = intel_engine_setup(&i915->gt, i);
@@ -421,14 +443,7 @@ int intel_engines_init_mmio(struct drm_i915_private *i915)
mask |= BIT(i);
}
- /*
-* Catch failures to update intel_engines table when the new engines
-* are added to the driver by a warning and disabling the forgotten
-* engines.
-*/
- if (WARN_ON(mask != engine_mask))
- device_info->engine_mask = mask;
-
+ mkwrite_device_info(i915)->engine_mask = mask;
RUNTIME_INFO(i915)->num_engines = hweight32(mask);
intel_gt_check_and_clear_faults(&i915->gt);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3d3fda4cae99..bb25731466a9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1308,6 +1308,11 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
{
int ret;
+ if (!RUNTIME_INFO(dev_priv)->num_engines) {
+ intel_gt_set_wedged_on_init(&dev_priv->gt);
+ return 0;
+ }
+
/* We need to fallback to 4K pages if host doesn't support huge gtt. */
if (intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
mkwrite_device_info(dev_priv)->page_sizes =
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..27813bd79aa8 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -44,6 +44,10 @@ i915_param_named(modeset, int, 0400,
"Use kernel modesetting [KMS] (0=disable, "
"1=on, -1=force vga console preference [default])");
+i915_param_named(engines, uint, 0400,
+ "Only expose selected command streamers [GPU engines] (0=disable GPU, "
+ "-1/0x enable all [default]). Each bit corresponds to a
different phyiscal engine: 0=RCS0, 1=VCS0, 2=BCS0, 3=VECS0, 4=VCS1, 5=VCS2,
6=VCS3, 7=VECS1");
+
i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
"(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index d29ade3b7de6..f876db78a59a 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,7 @@ struct drm_printer;
#define I915_PARAMS_FOR_EACH(param) \
param(char *, vbt_firmware, NULL) \
param(int, modeset, -1) \
+ param(unsigned int, engines, -1) \
param(int, lvds_channel_mode, 0) \
param(int, panel_use_ssc, -1) \
param(int, vbt_sdvo_panel_type, -1) \
--
2.23.0
___
Intel-gfx maili
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename "inject_load_failure" module parameter
Quoting Janusz Krzysztofik (2019-10-01 14:45:34)
> Commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe"
> consequently") deliberately left the name of the module parameter
> unchanged as that would require a corresponding change on IGT size.
> Now as the IGT side change has been submitted, complete the switch to
> the "probe" nomenclature.
>
> May affect custom user applications utilizing the old name.
It's an unsafe modparam that only is compiled in for debugging, with no
long term effect after modprobe. There are no user applications for
this.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename "inject_load_failure" module parameter
Hi Chris,
On Tuesday, October 1, 2019 3:57:27 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-01 14:45:34)
> > Commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe"
> > consequently") deliberately left the name of the module parameter
> > unchanged as that would require a corresponding change on IGT size.
> > Now as the IGT side change has been submitted, complete the switch to
> > the "probe" nomenclature.
> >
> > May affect custom user applications utilizing the old name.
>
> It's an unsafe modparam that only is compiled in for debugging, with no
> long term effect after modprobe. There are no user applications for
> this.
OK, I'll drop that sentence.
Thanks,
Janusz
> -Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/print: add drm_debug_enabled()
Add helper to check if a drm debug category is enabled. Convert drm core
to use it. No functional changes.
v2: Move unlikely() to drm_debug_enabled() (Eric)
v3: Keep unlikely() when combined with other conditions (Eric)
Cc: Eric Engestrom
Acked-by: Alex Deucher
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
drivers/gpu/drm/drm_edid.c| 2 +-
drivers/gpu/drm/drm_edid_load.c | 2 +-
drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
drivers/gpu/drm/drm_print.c | 4 ++--
drivers/gpu/drm/drm_vblank.c | 6 +++---
include/drm/drm_print.h | 5 +
8 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 7a26bfb5329c..0d466d3b0809 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1405,7 +1405,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_nonblocking_commit(state);
} else {
- if (unlikely(drm_debug & DRM_UT_STATE))
+ if (drm_debug_enabled(DRM_UT_STATE))
drm_atomic_print_state(state);
ret = drm_atomic_commit(state);
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index e6801db54d0f..6b14b63b8d62 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1179,7 +1179,7 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
}
}
out:
- if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
+ if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
struct drm_printer p = drm_debug_printer(DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
@@ -2322,7 +2322,7 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
idx += tosend + 1;
ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
- if (unlikely(ret && drm_debug & DRM_UT_DP)) {
+ if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
struct drm_printer p = drm_debug_printer(DBG_PREFIX);
drm_printf(&p, "sideband msg failed to send\n");
@@ -2389,7 +2389,7 @@ static void drm_dp_queue_down_tx(struct
drm_dp_mst_topology_mgr *mgr,
mutex_lock(&mgr->qlock);
list_add_tail(&txmsg->next, &mgr->tx_msg_downq);
- if (unlikely(drm_debug & DRM_UT_DP)) {
+ if (drm_debug_enabled(DRM_UT_DP)) {
struct drm_printer p = drm_debug_printer(DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3c9703b08491..0552175313cb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1651,7 +1651,7 @@ static void connector_bad_edid(struct drm_connector
*connector,
{
int i;
- if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+ if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
return;
dev_warn(connector->dev->dev,
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index d38b3b255926..37d8ba3ddb46 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector *connector,
const char *name,
u8 *edid;
int fwsize, builtin;
int i, valid_extensions = 0;
- bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
DRM_UT_KMS);
+ bool print_bad_edid = !connector->bad_edid_counter ||
drm_debug_enabled(DRM_UT_KMS);
builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
if (builtin >= 0) {
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index f8154316a3b0..ccfb5b33c5e3 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi,
int dc,
int i, ret;
u8 *dst;
- if (drm_debug & DRM_UT_DRIVER)
+ if (drm_debug_enabled(DRM_UT_DRIVER))
pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
__func__, dc, max_chunk);
@@ -907,7 +907,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, int
dc,
max_chunk = dbi->tx_buf9_len;
dst16 = dbi->tx_buf9;
- if (drm_debug & DRM_UT_DRIVER)
+ if (drm_debug_enabled(DRM_UT_DRIVER))
pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
__func__, dc, max_chunk);
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 1ade3a917c10..9a25d73c155c 100644
--- a/drivers/gpu/drm/drm_pr
Re: [Intel-gfx] [PATCH v2 0/9] drm/print: add and use drm_debug_enabled()
On Tue, 01 Oct 2019, Eric Engestrom wrote:
> On Tuesday, 2019-10-01 14:03:55 +0300, Jani Nikula wrote:
>> On Thu, 26 Sep 2019, Eric Engestrom wrote:
>> > On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
>> >> Hi all, v2 of [1], a little refactoring around drm_debug access to
>> >> abstract it better. There shouldn't be any functional changes.
>> >>
>> >> I'd appreciate acks for merging the lot via drm-misc. If there are any
>> >> objections to that, we'll need to postpone the last patch until
>> >> everything has been merged and converted in drm-next.
>> >>
>> >> BR,
>> >> Jani.
>> >>
>> >> Cc: Eric Engestrom
>> >> Cc: Alex Deucher
>> >> Cc: Christian König
>> >> Cc: David (ChunMing) Zhou
>> >> Cc: amd-...@lists.freedesktop.org
>> >> Cc: Ben Skeggs
>> >> Cc: nouv...@lists.freedesktop.org
>> >> Cc: Rob Clark
>> >> Cc: Sean Paul
>> >> Cc: linux-arm-...@vger.kernel.org
>> >> Cc: freedr...@lists.freedesktop.org
>> >> Cc: Francisco Jerez
>> >> Cc: Lucas Stach
>> >> Cc: Russell King
>> >> Cc: Christian Gmeiner
>> >> Cc: etna...@lists.freedesktop.org
>> >>
>> >>
>> >> [1] cover.1568375189.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1568375189.git.jani.nikula@intel.com
>> >>
>> >> Jani Nikula (9):
>> >> drm/print: move drm_debug variable to drm_print.[ch]
>> >> drm/print: add drm_debug_enabled()
>> >> drm/i915: use drm_debug_enabled() to check for debug categories
>> >> drm/print: rename drm_debug to __drm_debug to discourage use
>> >
>> > The above four patches are:
>> > Reviewed-by: Eric Engestrom
>> >
>> > Did you check to make sure the `unlikely()` is propagated correctly
>> > outside the `drm_debug_enabled()` call?
>>
>> I did now.
>>
>> Having drm_debug_enabled() as a macro vs. as an inline function does not
>> seem to make a difference, so I think the inline is clearly preferrable.
>
> Agreed :)
>
>>
>> However, for example
>>
>> unlikely(foo && drm_debug & DRM_UT_DP)
>>
>> does produce code different from
>>
>> (foo && drm_debug_enabled(DRM_UT_DP))
>>
>> indicating that the unlikely() within drm_debug_enabled() does not
>> propagate to the whole condition. It's possible to retain the same
>> assembly output with
>>
>> (unlikely(foo) && drm_debug_enabled(DRM_UT_DP))
>>
>> but it's unclear to me whether this is really worth it, either
>> readability or performance wise.
>>
>> Thoughts?
>
> That kind of code only happens 2 times, both in
> drivers/gpu/drm/drm_dp_mst_topology.c (in patch 2/9), right?
>
> I think your suggestion is the right thing to do here:
>
> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
> + if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
>
> It doesn't really cost much in readability (especially compared to what
> it was before), and whether it's important performance wise I couldn't
> tell, but I think it's best to keep the code optimised as it was before
> unless there's a reason to drop it.
>
> Lyude might know more since she wrote 2f015ec6eab69301fdcf5, if you want
> to ping her?
Just ended up sending the updated version with what you suggest and I
agree with; pedantically the change should be a separate patch anyway.
Thanks for your inputs.
BR,
Jani.
>
>>
>> BR,
>> Jani.
>>
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: split out intel_vga_client.[ch]
On Tue, Oct 01, 2019 at 04:43:53PM +0300, Jani Nikula wrote:
> Split out code related to vga client and vga switcheroo
> register/unregister and state handling from i915_drv.c and
> intel_display.c.
The two things don't really have anything in common except both have
"vga" in the name, so not sure it makes sense to put them in the same
place. OTOH they are pretty small so probably not worth it to have two
files.
Also the vgaarb stuff is still broken but I guess no one really cares.
>
> It's a bit difficult to draw the line how much to move to the new file
> from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo()
> and i915_resume_switcheroo() in place was cleanest.
>
> No functional changes.
>
> Cc: Ville Syrjälä
> Cc: Chris Wilson
> Signed-off-by: Jani Nikula
>
> ---
>
> It's also a bit fuzzy if this is a sensible split anyway. Could also
> name it intel_vga and move these from intel_display.c there?
>
> i915_vgacntrl_reg
> i915_disable_vga
> i915_redisable_vga
> i915_redisable_vga_power_on
Considering that's the only reason we register with vgaarb it probably
makes sense to move them as well.
> ---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/display/intel_display.c | 29
> drivers/gpu/drm/i915/display/intel_display.h | 1 -
> .../gpu/drm/i915/display/intel_vga_client.c | 140 ++
> .../gpu/drm/i915/display/intel_vga_client.h | 14 ++
> drivers/gpu/drm/i915/i915_drv.c | 94 +---
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> 7 files changed, 166 insertions(+), 118 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_vga_client.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_vga_client.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index e04463d85401..ca770463e01f 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -184,7 +184,8 @@ i915-y += \
> display/intel_psr.o \
> display/intel_quirks.o \
> display/intel_sprite.o \
> - display/intel_tc.o
> + display/intel_tc.o \
> + display/intel_vga_client.o
> i915-$(CONFIG_ACPI) += \
> display/intel_acpi.o \
> display/intel_opregion.o
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f1328c08f4ad..6278d62bc87d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -17188,35 +17188,6 @@ void intel_modeset_driver_remove(struct
> drm_i915_private *i915)
> intel_fbc_cleanup_cfb(i915);
> }
>
> -/*
> - * set vga decode state - true == enable VGA decode
> - */
> -int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool
> state)
> -{
> - unsigned reg = INTEL_GEN(dev_priv) >= 6 ? SNB_GMCH_CTRL :
> INTEL_GMCH_CTRL;
> - u16 gmch_ctrl;
> -
> - if (pci_read_config_word(dev_priv->bridge_dev, reg, &gmch_ctrl)) {
> - DRM_ERROR("failed to read control word\n");
> - return -EIO;
> - }
> -
> - if (!!(gmch_ctrl & INTEL_GMCH_VGA_DISABLE) == !state)
> - return 0;
> -
> - if (state)
> - gmch_ctrl &= ~INTEL_GMCH_VGA_DISABLE;
> - else
> - gmch_ctrl |= INTEL_GMCH_VGA_DISABLE;
> -
> - if (pci_write_config_word(dev_priv->bridge_dev, reg, gmch_ctrl)) {
> - DRM_ERROR("failed to write control word\n");
> - return -EIO;
> - }
> -
> - return 0;
> -}
> -
> #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
>
> struct intel_display_error_state {
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 4b9e18e5a263..a7b0d11a3316 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -579,7 +579,6 @@ void intel_display_print_error_state(struct
> drm_i915_error_state_buf *e,
> void intel_modeset_init_hw(struct drm_i915_private *i915);
> int intel_modeset_init(struct drm_i915_private *i915);
> void intel_modeset_driver_remove(struct drm_i915_private *i915);
> -int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool
> state);
> void intel_display_resume(struct drm_device *dev);
> void i915_redisable_vga(struct drm_i915_private *dev_priv);
> void i915_redisable_vga_power_on(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/display/intel_vga_client.c
> b/drivers/gpu/drm/i915/display/intel_vga_client.c
> new file mode 100644
> index ..04ef1443f40e
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_vga_client.c
> @@ -0,0 +1,140 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "i915_drv.h"
> +#include "intel_acpi.h"
> +#include "intel_vga_client.h"
> +
> +stat
[Intel-gfx] ✗ Fi.CI.BUILD: failure for HAX: Force kmemleak off
== Series Details == Series: HAX: Force kmemleak off URL : https://patchwork.freedesktop.org/series/67436/ State : failure == Summary == Applying: HAX: Force kmemleak off Using index info to reconstruct a base tree... M mm/kmemleak.c Falling back to patching base and 3-way merge... Auto-merging mm/kmemleak.c CONFLICT (content): Merge conflict in mm/kmemleak.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 HAX: Force kmemleak off 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: split out intel_vga_client.[ch]
Quoting Jani Nikula (2019-10-01 14:43:53) > Split out code related to vga client and vga switcheroo > register/unregister and state handling from i915_drv.c and > intel_display.c. > > It's a bit difficult to draw the line how much to move to the new file > from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo() > and i915_resume_switcheroo() in place was cleanest. > > No functional changes. > > Cc: Ville Syrjälä > Cc: Chris Wilson > Signed-off-by: Jani Nikula > > --- > > It's also a bit fuzzy if this is a sensible split anyway. Could also > name it intel_vga and move these from intel_display.c there? My initial thought that the switcheroo interface would remain in core, that it is more of a global power state that we currently just use for the legacy vga switching. The patch looks fine, on a pure mechanical pov, Reviewed-by: Chris Wilson For the sake of argument, could you float the split in the other direction? And maybe Ville has a good opinion on how it is meant to work :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix i915_inject_load_error() name to read *_probe_*
Quoting Janusz Krzysztofik (2019-10-01 14:45:33)
> Commit 50d84418f586 ("drm/i915: Add i915 to i915_inject_probe_failure")
> introduced new functions unfortunately named incompatibly with rules
> established by commit f2db53f14d3d ("drm/i915: Replace "_load" with
> "_probe" consequently"). Fix it for consistency.
>
> Suggested-by: Michał Wajdeczko
> Signed-off-by: Janusz Krzysztofik
> Cc: Michał Wajdeczko
> Cc: Michał Winiarski
> Cc: Piotr Piórkowski
> Cc: Tomasz Lis
> Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename "inject_load_failure" module parameter
Quoting Janusz Krzysztofik (2019-10-01 14:45:34)
> Commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe"
> consequently") deliberately left the name of the module parameter
> unchanged as that would require a corresponding change on IGT size.
> Now as the IGT side change has been submitted, complete the switch to
> the "probe" nomenclature.
>
> May affect custom user applications utilizing the old name.
>
> Suggested-by: Joonas Lahtinen
> Signed-off-by: Janusz Krzysztofik
> Cc: Michał Wajdeczko
> Cc: Michał Winiarski
> Cc: Piotr Piórkowski
> Cc: Tomasz Lis
> Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFT drm/i915/tgl: Re-enable rps (rev3)
== Series Details == Series: RFT drm/i915/tgl: Re-enable rps (rev3) URL : https://patchwork.freedesktop.org/series/67398/ State : warning == Summary == $ dim checkpatch origin/drm-tip 63d2c674198c RFT drm/i915/tgl: Re-enable rps -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:18: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 7 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/color: fix broken display in icl+
On Tue, Oct 01, 2019 at 11:03:08AM +0300, Jani Nikula wrote:
> On Tue, 01 Oct 2019, Swati Sharma wrote:
> > Premature gamma lut prepration and loading which was getting
> > reflected in first modeset causing different colors on
> > screen during boot.
> >
> > Issue: In BIOS, gamma is disabled by default. However,
> > legacy_read_luts() was getting called even before the legacy_load_luts()
> > which was setting crtc_state->base.gamma_lut and gamma_lut was
> > programmed with junk values which led to visual artifacts (different
> > colored screens instead of usual black during boot).
> >
> > Fix: Calling read_luts() only when gamma is enabled which will happen
> > after first modeset.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809
>
> I'm confused. Is there a current problem upstream after the revert
> 1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"")?
>
> Or does this fix a problem that only occurs in conjunction with the
> reverted commit? Then say so.
>
> Note inline.
>
> > Signed-off-by: Swati Sharma
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index f1328c08f4ad..f89aa4bb9f42 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -10528,7 +10528,9 @@ static bool haswell_get_pipe_config(struct
> > intel_crtc *crtc,
> > i9xx_get_pipe_color_config(pipe_config);
> > }
> >
> > - intel_color_get_config(pipe_config);
> > + if ((INTEL_GEN(dev_priv) >= 11 && (pipe_config->gamma_mode &
> > POST_CSC_GAMMA_ENABLE)) ||
> > + (INTEL_GEN(dev_priv) >= 9 && (pipe_config->gamma_enable)))
> > + intel_color_get_config(pipe_config);
>
> Put all of the conditions inside intel_color_get_config().
In fact inside the .read_luts() since these checks are platform
specific.
Also this check is wrong for CHV since it has a separate
enable knob for the CGM LUT (gamma_enable only deals with the
legacy LUT).
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 0/6] DC3CO Support for TGL
Resending this version v10 after adding Imre's RB and after fixing few code refactoring related comments provided by Imre. Anshuman Gupta (6): drm/i915/tgl: Add DC3CO required register and bits drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask drm/i915/tgl: Enable DC3CO state in "DC Off" power well drm/i915/tgl: Do modeset to enable and configure DC3CO exitline drm/i915/tgl: Switch between dc3co and dc5 based on display idleness drm/i915/tgl: Add DC3CO counter in i915_dmc_info drivers/gpu/drm/i915/display/intel_ddi.c | 93 ++- drivers/gpu/drm/i915/display/intel_display.c | 1 + .../drm/i915/display/intel_display_power.c| 154 -- .../drm/i915/display/intel_display_power.h| 3 + .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_psr.c | 114 - drivers/gpu/drm/i915/i915_debugfs.c | 7 + drivers/gpu/drm/i915/i915_drv.h | 4 + drivers/gpu/drm/i915/i915_params.c| 3 +- drivers/gpu/drm/i915/i915_reg.h | 10 ++ 10 files changed, 371 insertions(+), 19 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 2/6] drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask
Enable dc3co state in enable_dc module param and add dc3co
enable mask to allowed_dc_mask and gen9_dc_mask.
v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6
independently. [Animesh]
v2: Using a switch statement for cleaner code. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Animesh Manna
Reviewed-by: Imre Deak
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 29 +++
drivers/gpu/drm/i915/i915_params.c| 3 +-
2 files changed, 25 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 f1186bc23542..0b685c517bcb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -711,7 +711,11 @@ static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
u32 mask;
mask = DC_STATE_EN_UPTO_DC5;
- if (INTEL_GEN(dev_priv) >= 11)
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6
+ | DC_STATE_EN_DC9;
+ else if (IS_GEN(dev_priv, 11))
mask |= DC_STATE_EN_UPTO_DC6 | DC_STATE_EN_DC9;
else if (IS_GEN9_LP(dev_priv))
mask |= DC_STATE_EN_DC9;
@@ -3940,14 +3944,17 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
int requested_dc;
int max_dc;
- if (INTEL_GEN(dev_priv) >= 11) {
- max_dc = 2;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ max_dc = 4;
/*
* DC9 has a separate HW flow from the rest of the DC states,
* not depending on the DMC firmware. It's needed by system
* suspend/resume, so allow it unconditionally.
*/
mask = DC_STATE_EN_DC9;
+ } else if (IS_GEN(dev_priv, 11)) {
+ max_dc = 2;
+ mask = DC_STATE_EN_DC9;
} else if (IS_GEN(dev_priv, 10) || IS_GEN9_BC(dev_priv)) {
max_dc = 2;
mask = 0;
@@ -3966,7 +3973,7 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = enable_dc;
} else if (enable_dc == -1) {
requested_dc = max_dc;
- } else if (enable_dc > max_dc && enable_dc <= 2) {
+ } else if (enable_dc > max_dc && enable_dc <= 4) {
DRM_DEBUG_KMS("Adjusting requested max DC state (%d->%d)\n",
enable_dc, max_dc);
requested_dc = max_dc;
@@ -3975,10 +3982,20 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = max_dc;
}
- if (requested_dc > 1)
+ switch (requested_dc) {
+ case 4:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6;
+ break;
+ case 3:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC5;
+ break;
+ case 2:
mask |= DC_STATE_EN_UPTO_DC6;
- if (requested_dc > 0)
+ break;
+ case 1:
mask |= DC_STATE_EN_UPTO_DC5;
+ break;
+ }
DRM_DEBUG_KMS("Allowed DC state mask %02x\n", mask);
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..4f1806f65040 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,8 @@ i915_param_named(modeset, int, 0400,
i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
- "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
+ "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; "
+ "3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)");
i915_param_named_unsafe(enable_fbc, int, 0600,
"Enable frame buffer compression for power savings "
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: split out intel_vga_client.[ch]
On Tue, Oct 01, 2019 at 03:12:49PM +0100, Chris Wilson wrote: > Quoting Jani Nikula (2019-10-01 14:43:53) > > Split out code related to vga client and vga switcheroo > > register/unregister and state handling from i915_drv.c and > > intel_display.c. > > > > It's a bit difficult to draw the line how much to move to the new file > > from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo() > > and i915_resume_switcheroo() in place was cleanest. > > > > No functional changes. > > > > Cc: Ville Syrjälä > > Cc: Chris Wilson > > Signed-off-by: Jani Nikula > > > > --- > > > > It's also a bit fuzzy if this is a sensible split anyway. Could also > > name it intel_vga and move these from intel_display.c there? > > My initial thought that the switcheroo interface would remain in core, Yeah the switcheroo stuff should perhaps stays with the rest of the pm hooks. > that it is more of a global power state that we currently just use for > the legacy vga switching. > > The patch looks fine, on a pure mechanical pov, > Reviewed-by: Chris Wilson > > For the sake of argument, could you float the split in the other > direction? > > And maybe Ville has a good opinion on how it is meant to work :) > -Chris -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 5/6] drm/i915/tgl: Switch between dc3co and dc5 based on display idleness
DC3CO is useful power state, when DMC detects PSR2 idle frame
while an active video playback, playing 30fps video on 60hz panel
is the classic example of this use case.
B.Specs:49196 has a restriction to enable DC3CO only for Video Playback.
It will be worthy to enable DC3CO after completion of each pageflip
and switch back to DC5 when display is idle because driver doesn't
differentiate between video playback and a normal pageflip.
We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO
state only for ORIGIN_FLIP flush call, because DC3CO state has primarily
targeted for VPB use case. We are not interested here for frontbuffer
invalidates calls because that triggers PSR2 exit, which will
explicitly disable DC3CO.
DC5 and DC6 saves more power, but can't be entered during video
playback because there are not enough idle frames in a row to meet
most PSR2 panel deep sleep entry requirement typically 4 frames.
As PSR2 existing implementation is using minimum 6 idle frames for
deep sleep, it is safer to enable DC5/6 after 6 idle frames
(By scheduling a delayed work of 6 idle frames, once DC3CO has been
enabled after a pageflip).
After manually waiting for 6 idle frames DC5/6 will be enabled and
PSR2 deep sleep idle frames will be restored to 6 idle frames, at this
point DMC will triggers DC5/6 once PSR2 enters to deep sleep after
6 idle frames.
In future when we will enable S/W PSR2 tracking, we can change the
PSR2 required deep sleep idle frames to 1 so DMC can trigger the
DC5/6 immediately after S/W manual waiting of 6 idle frames get
complete.
v2: calculated s/w state to switch over dc3co when there is an
update. [Imre]
Used cancel_delayed_work_sync() in order to avoid any race
with already scheduled delayed work. [Imre]
v3: Cancel_delayed_work_sync() may blocked the commit work.
hence dropping it, dc5_idle_thread() checks the valid wakeref before
putting the reference count, which avoids any chances of dropping
a zero wakeref. [Imre (IRC)]
v4: Used frontbuffer flush mechanism. [Imre]
v5: Used psr.pipe to extract frontbuffer busy bits. [Imre]
Used cancel_delayed_work_sync() in encoder disable path. [Imre]
Used mod_delayed_work() instead of cancelling and scheduling a
delayed work. [Imre]
Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep
sleep. [Imre]
Removed DC5_REQ_IDLE_FRAMES macro. [Imre]
v6: Used dc3co_exitline check instead of TGL and dc3co allowed_dc_mask
checks, used delayed_work_pending with the psr lock and removed the
psr2_deep_slp_disabled flag. [Imre]
v7: Code refactoring, moved most of functional code to inte_psr.c [Imre]
Using frontbuffer_bits on psr.pipe check instead of
busy_frontbuffer_bits. [Imre]
Calculating dc3co_exit_delay in intel_psr_enable_locked. [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Imre Deak
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 45 +++
.../drm/i915/display/intel_display_power.h| 2 +
drivers/gpu/drm/i915/display/intel_psr.c | 114 +-
drivers/gpu/drm/i915/i915_drv.h | 3 +
4 files changed, 163 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 67ba92dd8366..9fddebfda169 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -886,6 +886,51 @@ lookup_power_well(struct drm_i915_private *dev_priv,
return &dev_priv->power_domains.power_wells[0];
}
+/**
+ * intel_display_power_set_target_dc_state - Set target dc state.
+ * @dev_priv: i915 device
+ * @state: state which needs to be set as target_dc_state.
+ *
+ * This function set the "DC off" power well target_dc_state,
+ * based upon this target_dc_stste, "DC off" power well will
+ * enable desired DC state.
+ */
+void intel_display_power_set_target_dc_state(struct drm_i915_private *dev_priv,
+u32 state)
+{
+ struct i915_power_well *power_well;
+ bool dc_off_enabled;
+ struct i915_power_domains *power_domains = &dev_priv->power_domains;
+
+ mutex_lock(&power_domains->lock);
+ power_well = lookup_power_well(dev_priv, SKL_DISP_DC_OFF);
+
+ if (WARN_ON(!power_well))
+ goto unlock;
+
+ state = sanitize_target_dc_state(dev_priv, state);
+
+ if (state == dev_priv->csr.target_dc_state)
+ goto unlock;
+
+ dc_off_enabled = power_well->desc->ops->is_enabled(dev_priv,
+ power_well);
+ /*
+* If DC off power well is disabled, need to enable and disable the
+* DC off power well to effect target DC state.
+*/
+ if (!dc_off_enabled)
+ power_well->desc->ops->enable(dev_priv, power_well);
+
+ dev_priv->csr.target_dc_state
[Intel-gfx] [PATCH v10 6/6] drm/i915/tgl: Add DC3CO counter in i915_dmc_info
Adding DC3CO counter in i915_dmc_info debugfs will be
useful for DC3CO validation.
DMC firmware uses DMC_DEBUG3 register as DC3CO counter
register on TGL, as per B.Specs DMC_DEBUG3 is general
purpose register.
v1: comment modification for DMC_DBUG3.
using GEN >= 12 check instead of IS_TIGERLAKE()
to print DMC_DEBUG3 counter value.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Imre Deak
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fec9fb7cc384..a3882e6abf68 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2413,6 +2413,13 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
if (INTEL_GEN(dev_priv) >= 12) {
dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
+ /*
+* NOTE: DMC_DEBUG3 is a general purpose reg.
+* According to B.Specs:49196 DMC f/w reuses DC5/6 counter
+* reg for DC3CO debugging and validation,
+* but TGL DMC f/w is using DMC_DEBUG3 reg for DC3CO counter.
+*/
+ seq_printf(m, "DC3CO count: %d\n", I915_READ(DMC_DEBUG3));
} else {
dc5_reg = IS_BROXTON(dev_priv) ? BXT_CSR_DC3_DC5_COUNT :
SKL_CSR_DC3_DC5_COUNT;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 188d3b382627..e2940501d7a6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7267,6 +7267,8 @@ enum {
#define TGL_DMC_DEBUG_DC5_COUNT_MMIO(0x101084)
#define TGL_DMC_DEBUG_DC6_COUNT_MMIO(0x101088)
+#define DMC_DEBUG3 _MMIO(0x101090)
+
/* interrupts */
#define DE_MASTER_IRQ_CONTROL (1 << 31)
#define DE_SPRITEB_FLIP_DONE(1 << 29)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 1/6] drm/i915/tgl: Add DC3CO required register and bits
Adding following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
DC3CO enable bit will be used by driver to make DC3CO
ready for DMC f/w and status bit will be used as DC3CO
entry status.
2. Transcoder EXITLINE register and its bit fields and mask.
Transcoder EXITLINE enable bit represents PSR2 idle frame
reset should be applied at exit line and exitlines mask
represent required number of scanlines at which DC3CO
exit happens.
B.Specs:49196
v1: Use of REG_BIT and using extra space for EXITLINE_ macro
definition. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Animesh Manna
Reviewed-by: Imre Deak
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 058aa5ca8b73..188d3b382627 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4144,6 +4144,7 @@ enum {
#define _VTOTAL_A 0x6000c
#define _VBLANK_A 0x60010
#define _VSYNC_A 0x60014
+#define _EXITLINE_A0x60018
#define _PIPEASRC 0x6001c
#define _BCLRPAT_A 0x60020
#define _VSYNCSHIFT_A 0x60028
@@ -4190,11 +4191,16 @@ enum {
#define VTOTAL(trans) _MMIO_TRANS2(trans, _VTOTAL_A)
#define VBLANK(trans) _MMIO_TRANS2(trans, _VBLANK_A)
#define VSYNC(trans) _MMIO_TRANS2(trans, _VSYNC_A)
+#define EXITLINE(trans)_MMIO_TRANS2(trans, _EXITLINE_A)
#define BCLRPAT(trans) _MMIO_TRANS2(trans, _BCLRPAT_A)
#define VSYNCSHIFT(trans) _MMIO_TRANS2(trans, _VSYNCSHIFT_A)
#define PIPESRC(trans) _MMIO_TRANS2(trans, _PIPEASRC)
#define PIPE_MULT(trans) _MMIO_TRANS2(trans, _PIPE_MULT_A)
+#define EXITLINE_ENABLE REG_BIT(31)
+#define EXITLINE_MASKREG_GENMASK(12, 0)
+#define EXITLINE_SHIFT 0
+
/*
* HSW+ eDP PSR registers
*
@@ -10288,6 +10294,8 @@ enum skl_power_gate {
/* GEN9 DC */
#define DC_STATE_EN_MMIO(0x45504)
#define DC_STATE_DISABLE 0
+#define DC_STATE_EN_DC3CO REG_BIT(30)
+#define DC_STATE_DC3CO_STATUS REG_BIT(29)
#define DC_STATE_EN_UPTO_DC5 (1 << 0)
#define DC_STATE_EN_DC9 (1 << 3)
#define DC_STATE_EN_UPTO_DC6 (2 << 0)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 4/6] drm/i915/tgl: Do modeset to enable and configure DC3CO exitline
DC3CO enabling B.Specs sequence requires to enable end configure
exit scanlines to TRANS_EXITLINE register, programming this register
has to be part of modeset sequence as this can't be change when
transcoder or port is enabled.
When system boots with only eDP panel there may not be real
modeset as BIOS has already programmed the necessary registers,
therefore it needs to force a modeset to enable and configure
DC3CO exitline.
v1: Computing dc3co_exitline crtc state from a DP encoder
compute config. [Imre]
Enabling and disabling DC3CO PSR2 transcoder exitline from
encoder pre_enable and post_disable hooks. [Imre]
Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre]
v2: Code refactoring for symmetry and to avoid exported function. [Imre]
Removing IS_TIGERLAKE check from compute_config, adding PIPE_A
restriction and clearing dc3co_exitline state if crtc is not active
or it is not PSR2 capable in dc3co exitline compute_config. [Imre]
Using GEN >= 12 check in dc3co exitline get_config. [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Imre Deak
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 93 ++-
drivers/gpu/drm/i915/display/intel_display.c | 1 +
.../drm/i915/display/intel_display_types.h| 1 +
3 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b463e51f8b45..032c455446ec 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -45,6 +45,7 @@
#include "intel_lspcon.h"
#include "intel_panel.h"
#include "intel_psr.h"
+#include "intel_sprite.h"
#include "intel_tc.h"
#include "intel_vdsc.h"
@@ -3332,6 +,86 @@ static void intel_ddi_disable_fec_state(struct
intel_encoder *encoder,
POSTING_READ(intel_dp->regs.dp_tp_ctl);
}
+static void
+tgl_clear_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
+{
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+ u32 val;
+
+ if (!cstate->dc3co_exitline)
+ return;
+
+ val = I915_READ(EXITLINE(cstate->cpu_transcoder));
+ val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
+ I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+}
+
+static void
+tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
+{
+ u32 val, exit_scanlines;
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+
+ if (!cstate->dc3co_exitline)
+ return;
+
+ exit_scanlines = cstate->dc3co_exitline;
+ exit_scanlines <<= EXITLINE_SHIFT;
+ val = I915_READ(EXITLINE(cstate->cpu_transcoder));
+ val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
+ val |= exit_scanlines;
+ val |= EXITLINE_ENABLE;
+ I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+}
+
+static void tgl_dc3co_exitline_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *cstate)
+{
+ u32 exit_scanlines;
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+ u32 crtc_vdisplay = cstate->base.adjusted_mode.crtc_vdisplay;
+
+ cstate->dc3co_exitline = 0;
+
+ if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC3CO))
+ return;
+
+ /* B.Specs:49196 DC3CO only works with pipeA and DDIA.*/
+ if (to_intel_crtc(cstate->base.crtc)->pipe != PIPE_A ||
+ encoder->port != PORT_A)
+ return;
+
+ if (!cstate->has_psr2 || !cstate->base.active)
+ return;
+
+ /*
+* DC3CO Exit time 200us B.Spec 49196
+* PSR2 transcoder Early Exit scanlines = ROUNDUP(200 / line time) + 1
+*/
+ exit_scanlines =
+ intel_usecs_to_scanlines(&cstate->base.adjusted_mode, 200) + 1;
+
+ if (WARN_ON(exit_scanlines > crtc_vdisplay))
+ return;
+
+ cstate->dc3co_exitline = crtc_vdisplay - exit_scanlines;
+ DRM_DEBUG_KMS("DC3CO exit scanlines %d\n", cstate->dc3co_exitline);
+}
+
+static void tgl_dc3co_exitline_get_config(struct intel_crtc_state *crtc_state)
+{
+ u32 val;
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+
+ if (INTEL_GEN(dev_priv) < 12)
+ return;
+
+ val = I915_READ(EXITLINE(crtc_state->cpu_transcoder));
+
+ if (val & EXITLINE_ENABLE)
+ crtc_state->dc3co_exitline = val & EXITLINE_MASK;
+}
+
static void tgl_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
@@ -3344,6 +3425,7 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder
*encoder,
int level = intel_ddi_dp_level(intel_dp);
enum transcoder transcoder =
[Intel-gfx] [PATCH v10 3/6] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
Add target_dc_state and used by set_target_dc_state API
in order to enable DC3CO state with existing DC states.
target_dc_state will enable/disable the desired DC state in
DC_STATE_EN reg when "DC Off" power well gets disable/enable.
v2: commit log improvement.
v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre]
Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre]
Moved transcoder psr2 exit line enablement from tgl_allow_dc3co()
to a appropriate place haswell_crtc_enable(). [Imre]
Changed the DC3CO power well enabled call back logic as
recommended in review comments. [Imre]
v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)]
v5: using udelay() instead of waiting for DC3CO exit status.
v6: Fixed minor unwanted change.
v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO.
v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask
in "DC off" power well callback. [Imre]
Adding "DC off" power well id to older platforms. [Imre]
Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre]
v9: Used switch case for target DC state in
gen9_dc_off_power_well_disable(), checking DC3CO state against
allowed DC mask, using WARN_ON() in
tgl_set_target_dc_state(). [Imre]
v10: Code refactoring and using sanitize_target_dc_state(). [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Imre Deak
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 80 ---
.../drm/i915/display/intel_display_power.h| 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
3 files changed, 73 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0b685c517bcb..67ba92dd8366 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -785,6 +785,52 @@ static void gen9_set_dc_state(struct drm_i915_private
*dev_priv, u32 state)
dev_priv->csr.dc_state = val & mask;
}
+static u32
+sanitize_target_dc_state(struct drm_i915_private *dev_priv,
+u32 target_dc_state)
+{
+ u32 states[] = {
+ DC_STATE_EN_UPTO_DC6,
+ DC_STATE_EN_UPTO_DC5,
+ DC_STATE_EN_DC3CO,
+ DC_STATE_DISABLE,
+ };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(states) - 1; i++) {
+ if (target_dc_state != states[i])
+ continue;
+
+ if (dev_priv->csr.allowed_dc_mask & target_dc_state)
+ break;
+
+ target_dc_state = states[i + 1];
+ }
+
+ return target_dc_state;
+}
+
+static void tgl_enable_dc3co(struct drm_i915_private *dev_priv)
+{
+ DRM_DEBUG_KMS("Enabling DC3CO\n");
+ gen9_set_dc_state(dev_priv, DC_STATE_EN_DC3CO);
+}
+
+static void tgl_disable_dc3co(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ DRM_DEBUG_KMS("Disabling DC3CO\n");
+ val = I915_READ(DC_STATE_EN);
+ val &= ~DC_STATE_DC3CO_STATUS;
+ I915_WRITE(DC_STATE_EN, val);
+ gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+ /*
+* Delay of 200us DC3CO Exit time B.Spec 49196
+*/
+ usleep_range(200, 210);
+}
+
static void bxt_enable_dc9(struct drm_i915_private *dev_priv)
{
assert_can_enable_dc9(dev_priv);
@@ -952,7 +998,8 @@ static void bxt_verify_ddi_phy_power_wells(struct
drm_i915_private *dev_priv)
static bool gen9_dc_off_power_well_enabled(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
+ return ((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC3CO) == 0 &&
+ (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0);
}
static void gen9_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
@@ -968,6 +1015,11 @@ static void gen9_disable_dc_states(struct
drm_i915_private *dev_priv)
{
struct intel_cdclk_state cdclk_state = {};
+ if (dev_priv->csr.target_dc_state == DC_STATE_EN_DC3CO) {
+ tgl_disable_dc3co(dev_priv);
+ return;
+ }
+
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
dev_priv->display.get_cdclk(dev_priv, &cdclk_state);
@@ -1000,10 +1052,17 @@ static void gen9_dc_off_power_well_disable(struct
drm_i915_private *dev_priv,
if (!dev_priv->csr.dmc_payload)
return;
- if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC6)
+ switch (dev_priv->csr.target_dc_state) {
+ case DC_STATE_EN_DC3CO:
+ tgl_enable_dc3co(dev_priv);
+ break;
+ case DC_STATE_EN_UPTO_DC6:
skl_enable_dc6(dev_priv);
- else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
+ break;
+
Re: [Intel-gfx] [PATCH] drm/i915/color: fix broken display in icl+
On 01-Oct-19 7:51 PM, Ville Syrjälä wrote:
On Tue, Oct 01, 2019 at 11:03:08AM +0300, Jani Nikula wrote:
On Tue, 01 Oct 2019, Swati Sharma wrote:
Premature gamma lut prepration and loading which was getting
reflected in first modeset causing different colors on
screen during boot.
Issue: In BIOS, gamma is disabled by default. However,
legacy_read_luts() was getting called even before the legacy_load_luts()
which was setting crtc_state->base.gamma_lut and gamma_lut was
programmed with junk values which led to visual artifacts (different
colored screens instead of usual black during boot).
Fix: Calling read_luts() only when gamma is enabled which will happen
after first modeset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809
I'm confused. Is there a current problem upstream after the revert
1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"")?
Or does this fix a problem that only occurs in conjunction with the
reverted commit? Then say so.
Note inline.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f1328c08f4ad..f89aa4bb9f42 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10528,7 +10528,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
i9xx_get_pipe_color_config(pipe_config);
}
- intel_color_get_config(pipe_config);
+ if ((INTEL_GEN(dev_priv) >= 11 && (pipe_config->gamma_mode &
POST_CSC_GAMMA_ENABLE)) ||
+ (INTEL_GEN(dev_priv) >= 9 && (pipe_config->gamma_enable)))
+ intel_color_get_config(pipe_config);
Put all of the conditions inside intel_color_get_config().
In fact inside the .read_luts() since these checks are platform
specific.
Also this check is wrong for CHV since it has a separate
enable knob for the CGM LUT (gamma_enable only deals with the
legacy LUT) >
Inside read_luts() I already have. But the issue is first read_lut()
will happen before load_lut() and it will replace
crtc_state->base.gamma_lut and gamma_lut will be programmed with junk
values which led to multiple colored screens. So we need a check to call
intel_color_get_config() itself.
--
~Swati Sharma
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: split out intel_vga_client.[ch]
On Tue, 01 Oct 2019, Ville Syrjälä wrote: > On Tue, Oct 01, 2019 at 03:12:49PM +0100, Chris Wilson wrote: >> Quoting Jani Nikula (2019-10-01 14:43:53) >> > Split out code related to vga client and vga switcheroo >> > register/unregister and state handling from i915_drv.c and >> > intel_display.c. >> > >> > It's a bit difficult to draw the line how much to move to the new file >> > from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo() >> > and i915_resume_switcheroo() in place was cleanest. >> > >> > No functional changes. >> > >> > Cc: Ville Syrjälä >> > Cc: Chris Wilson >> > Signed-off-by: Jani Nikula >> > >> > --- >> > >> > It's also a bit fuzzy if this is a sensible split anyway. Could also >> > name it intel_vga and move these from intel_display.c there? >> >> My initial thought that the switcheroo interface would remain in core, > > Yeah the switcheroo stuff should perhaps stays with the rest of the pm hooks. Okay, so keep all of switcheroo in i915_drv.c, and move all the vgaarb stuff (incl the ones I mentioned from intel_display.c) to intel_vga.[ch]? > >> that it is more of a global power state that we currently just use for >> the legacy vga switching. >> >> The patch looks fine, on a pure mechanical pov, >> Reviewed-by: Chris Wilson >> >> For the sake of argument, could you float the split in the other >> direction? Please elaborate. Move switcheroo higher in the call chain? BR, Jani. >> >> And maybe Ville has a good opinion on how it is meant to work :) >> -Chris -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: split out intel_vga_client.[ch]
Quoting Jani Nikula (2019-10-01 15:28:51) > On Tue, 01 Oct 2019, Ville Syrjälä wrote: > > On Tue, Oct 01, 2019 at 03:12:49PM +0100, Chris Wilson wrote: > >> For the sake of argument, could you float the split in the other > >> direction? > > Please elaborate. Move switcheroo higher in the call chain? I was thinking along the lines of pulling switcheroo into i915/i915_vga_client.c and seeing where that lead. I leave the details to the poor soul pulling at the stands of spaghetti. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/color: fix broken display in icl+
HI,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjälä
> Sent: tiistai 1. lokakuuta 2019 17.21
> To: Nikula, Jani
> Cc: intel-gfx@lists.freedesktop.org; Nautiyal, Ankit K
>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/color: fix broken display in icl+
>
> On Tue, Oct 01, 2019 at 11:03:08AM +0300, Jani Nikula wrote:
> > On Tue, 01 Oct 2019, Swati Sharma wrote:
> > > Premature gamma lut prepration and loading which was getting
> > > reflected in first modeset causing different colors on screen during
> > > boot.
> > >
> > > Issue: In BIOS, gamma is disabled by default. However,
> > > legacy_read_luts() was getting called even before the
> > > legacy_load_luts() which was setting crtc_state->base.gamma_lut and
> > > gamma_lut was programmed with junk values which led to visual
> > > artifacts (different colored screens instead of usual black during boot).
> > >
> > > Fix: Calling read_luts() only when gamma is enabled which will
> > > happen after first modeset.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809
> >
> > I'm confused. Is there a current problem upstream after the revert
> > 1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"")?
> >
> > Or does this fix a problem that only occurs in conjunction with the
> > reverted commit? Then say so.
> >
> > Note inline.
> >
> > > Signed-off-by: Swati Sharma
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index f1328c08f4ad..f89aa4bb9f42 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -10528,7 +10528,9 @@ static bool haswell_get_pipe_config(struct
> intel_crtc *crtc,
> > > i9xx_get_pipe_color_config(pipe_config);
> > > }
> > >
> > > - intel_color_get_config(pipe_config);
> > > + if ((INTEL_GEN(dev_priv) >= 11 && (pipe_config->gamma_mode &
> POST_CSC_GAMMA_ENABLE)) ||
> > > +(INTEL_GEN(dev_priv) >= 9 && (pipe_config->gamma_enable)))
> > > + intel_color_get_config(pipe_config);
> >
> > Put all of the conditions inside intel_color_get_config().
>
> In fact inside the .read_luts() since these checks are platform specific.
>
> Also this check is wrong for CHV since it has a separate enable knob for the
> CGM LUT
> (gamma_enable only deals with the legacy LUT).
Could this be also reason that on BSW I was able to see some color issue with
BSW on latest drm-tip still with Tapani?
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/color: fix broken display in icl+
On Tue, Oct 01, 2019 at 07:58:39PM +0530, Sharma, Swati2 wrote:
> On 01-Oct-19 7:51 PM, Ville Syrjälä wrote:
> > On Tue, Oct 01, 2019 at 11:03:08AM +0300, Jani Nikula wrote:
> >> On Tue, 01 Oct 2019, Swati Sharma wrote:
> >>> Premature gamma lut prepration and loading which was getting
> >>> reflected in first modeset causing different colors on
> >>> screen during boot.
> >>>
> >>> Issue: In BIOS, gamma is disabled by default. However,
> >>> legacy_read_luts() was getting called even before the legacy_load_luts()
> >>> which was setting crtc_state->base.gamma_lut and gamma_lut was
> >>> programmed with junk values which led to visual artifacts (different
> >>> colored screens instead of usual black during boot).
> >>>
> >>> Fix: Calling read_luts() only when gamma is enabled which will happen
> >>> after first modeset.
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809
> >>
> >> I'm confused. Is there a current problem upstream after the revert
> >> 1b8588741fdc ("Revert "drm/i915/color: Extract icl_read_luts()"")?
> >>
> >> Or does this fix a problem that only occurs in conjunction with the
> >> reverted commit? Then say so.
> >>
> >> Note inline.
> >>
> >>> Signed-off-by: Swati Sharma
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_display.c | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >>> b/drivers/gpu/drm/i915/display/intel_display.c
> >>> index f1328c08f4ad..f89aa4bb9f42 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >>> @@ -10528,7 +10528,9 @@ static bool haswell_get_pipe_config(struct
> >>> intel_crtc *crtc,
> >>> i9xx_get_pipe_color_config(pipe_config);
> >>> }
> >>>
> >>> - intel_color_get_config(pipe_config);
> >>> + if ((INTEL_GEN(dev_priv) >= 11 && (pipe_config->gamma_mode &
> >>> POST_CSC_GAMMA_ENABLE)) ||
> >>> +(INTEL_GEN(dev_priv) >= 9 && (pipe_config->gamma_enable)))
> >>> + intel_color_get_config(pipe_config);
> >>
> >> Put all of the conditions inside intel_color_get_config().
> >
> > In fact inside the .read_luts() since these checks are platform
> > specific.
> >
> > Also this check is wrong for CHV since it has a separate
> > enable knob for the CGM LUT (gamma_enable only deals with the
> > legacy LUT) >
> Inside read_luts() I already have. But the issue is first read_lut()
> will happen before load_lut() and it will replace
> crtc_state->base.gamma_lut and gamma_lut will be programmed with junk
> values which led to multiple colored screens. So we need a check to call
> intel_color_get_config() itself.
That doesn't make sense. If you're already checking these then
adding a second check won't change anything.
Also state readout is meant to just blindly readout the hardware state.
If the LUT used by the BIOS is enabled and not something we want to
use then we need to sanitize it after the readout.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: Fix i915_inject_load_error() name to read *_probe_*
Commit 50d84418f586 ("drm/i915: Add i915 to i915_inject_probe_failure")
introduced new functions unfortunately named incompatibly with rules
established by commit f2db53f14d3d ("drm/i915: Replace "_load" with
"_probe" consequently"). Fix it for consistency.
Suggested-by: Michał Wajdeczko
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 ++-
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/i915_utils.c | 4 ++--
drivers/gpu/drm/i915/i915_utils.h | 12 +--
7 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index f325d3dd564f..67e46c2af6df 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1119,7 +1119,7 @@ int intel_guc_submission_enable(struct intel_guc *guc)
enum intel_engine_id id;
int err;
- err = i915_inject_load_error(gt->i915, -ENXIO);
+ err = i915_inject_probe_error(gt->i915, -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index d4625c97b4f9..8295ff971bcc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -35,7 +35,7 @@ static int intel_huc_rsa_data_create(struct intel_huc *huc)
void *vaddr;
int err;
- err = i915_inject_load_error(gt->i915, -ENXIO);
+ err = i915_inject_probe_error(gt->i915, -ENXIO);
if (err)
return err;
@@ -134,7 +134,7 @@ int intel_huc_auth(struct intel_huc *huc)
if (!intel_uc_fw_is_loaded(&huc->fw))
return -ENOEXEC;
- ret = i915_inject_load_error(gt->i915, -ENXIO);
+ ret = i915_inject_probe_error(gt->i915, -ENXIO);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 71ee7ab035cc..fb0d7bb712ab 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -20,7 +20,7 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
int ret;
u32 guc_status;
- ret = i915_inject_load_error(gt->i915, -ENXIO);
+ ret = i915_inject_probe_error(gt->i915, -ENXIO);
if (ret)
return ret;
@@ -197,7 +197,7 @@ static int guc_enable_communication(struct intel_guc *guc)
GEM_BUG_ON(guc_communication_enabled(guc));
- ret = i915_inject_load_error(i915, -ENXIO);
+ ret = i915_inject_probe_error(i915, -ENXIO);
if (ret)
return ret;
@@ -368,7 +368,7 @@ static int uc_init_wopcm(struct intel_uc *uc)
GEM_BUG_ON(!(size & GUC_WOPCM_SIZE_MASK));
GEM_BUG_ON(size & ~GUC_WOPCM_SIZE_MASK);
- err = i915_inject_load_error(gt->i915, -ENXIO);
+ err = i915_inject_probe_error(gt->i915, -ENXIO);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index bd22bf11adad..f6830ec79a66 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -218,29 +218,31 @@ static void __force_fw_fetch_failures(struct intel_uc_fw
*uc_fw,
{
bool user = e == -EINVAL;
- if (i915_inject_load_error(i915, e)) {
+ if (i915_inject_probe_error(i915, e)) {
/* non-existing blob */
uc_fw->path = "";
uc_fw->user_overridden = user;
- } else if (i915_inject_load_error(i915, e)) {
+ } else if (i915_inject_probe_error(i915, e)) {
/* require next major version */
uc_fw->major_ver_wanted += 1;
uc_fw->minor_ver_wanted = 0;
uc_fw->user_overridden = user;
- } else if (i915_inject_load_error(i915, e)) {
+ } else if (i915_inject_probe_error(i915, e)) {
/* require next minor version */
uc_fw->minor_ver_wanted += 1;
uc_fw->user_overridden = user;
- } else if (uc_fw->major_ver_wanted && i915_inject_load_error(i915, e)) {
+ } else if (uc_fw->major_ver_wanted &&
+ i915_inject_probe_error(i915, e)) {
/* require prev major version */
uc_fw->major_ver_wanted -= 1;
uc_fw->minor_ver_wanted = 0;
uc_fw->user_overridden = user;
- } else if (uc_fw->minor_ver_wanted && i915_inject_load_error(i915, e)) {
+ } else if (uc_f
Re: [Intel-gfx] [PATCH] drm/i915/display: split out intel_vga_client.[ch]
On Tue, Oct 01, 2019 at 05:28:51PM +0300, Jani Nikula wrote: > On Tue, 01 Oct 2019, Ville Syrjälä wrote: > > On Tue, Oct 01, 2019 at 03:12:49PM +0100, Chris Wilson wrote: > >> Quoting Jani Nikula (2019-10-01 14:43:53) > >> > Split out code related to vga client and vga switcheroo > >> > register/unregister and state handling from i915_drv.c and > >> > intel_display.c. > >> > > >> > It's a bit difficult to draw the line how much to move to the new file > >> > from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo() > >> > and i915_resume_switcheroo() in place was cleanest. > >> > > >> > No functional changes. > >> > > >> > Cc: Ville Syrjälä > >> > Cc: Chris Wilson > >> > Signed-off-by: Jani Nikula > >> > > >> > --- > >> > > >> > It's also a bit fuzzy if this is a sensible split anyway. Could also > >> > name it intel_vga and move these from intel_display.c there? > >> > >> My initial thought that the switcheroo interface would remain in core, > > > > Yeah the switcheroo stuff should perhaps stays with the rest of the pm > > hooks. > > Okay, so keep all of switcheroo in i915_drv.c, and move all the vgaarb > stuff (incl the ones I mentioned from intel_display.c) to > intel_vga.[ch]? I can get behind that plan. > > > > >> that it is more of a global power state that we currently just use for > >> the legacy vga switching. > >> > >> The patch looks fine, on a pure mechanical pov, > >> Reviewed-by: Chris Wilson > >> > >> For the sake of argument, could you float the split in the other > >> direction? > > Please elaborate. Move switcheroo higher in the call chain? > > BR, > Jani. > > > >> > >> And maybe Ville has a good opinion on how it is meant to work :) > >> -Chris > > -- > Jani Nikula, Intel Open Source Graphics Center -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Rename "inject_load_failure" module parameter
Commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe"
consequently") deliberately left the name of the module parameter
unchanged as that would require a corresponding change on IGT size.
Now as the IGT side change has been submitted, complete the switch to
the "probe" nomenclature.
Suggested-by: Joonas Lahtinen
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/i915_utils.c | 10 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..59a6586dae15 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -165,7 +165,7 @@ i915_param_named_unsafe(enable_dp_mst, bool, 0600,
"Enable multi-stream transport (MST) for new DisplayPort sinks.
(default: true)");
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
-i915_param_named_unsafe(inject_load_failure, uint, 0400,
+i915_param_named_unsafe(inject_probe_failure, uint, 0400,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
#endif
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index d29ade3b7de6..8c887413fc70 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -62,7 +62,7 @@ struct drm_printer;
param(int, mmio_debug, -IS_ENABLED(CONFIG_DRM_I915_DEBUG_MMIO)) \
param(int, edp_vswing, 0) \
param(int, reset, 2) \
- param(unsigned int, inject_load_failure, 0) \
+ param(unsigned int, inject_probe_failure, 0) \
param(int, fastboot, -1) \
param(int, enable_dpcd_backlight, 0) \
param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE) \
diff --git a/drivers/gpu/drm/i915/i915_utils.c
b/drivers/gpu/drm/i915/i915_utils.c
index e51bdb05da14..64affb87c284 100644
--- a/drivers/gpu/drm/i915/i915_utils.c
+++ b/drivers/gpu/drm/i915/i915_utils.c
@@ -57,22 +57,22 @@ static unsigned int i915_probe_fail_count;
int __i915_inject_probe_error(struct drm_i915_private *i915, int err,
const char *func, int line)
{
- if (i915_probe_fail_count >= i915_modparams.inject_load_failure)
+ if (i915_probe_fail_count >= i915_modparams.inject_probe_failure)
return 0;
- if (++i915_probe_fail_count < i915_modparams.inject_load_failure)
+ if (++i915_probe_fail_count < i915_modparams.inject_probe_failure)
return 0;
__i915_printk(i915, KERN_INFO,
"Injecting failure %d at checkpoint %u [%s:%d]\n",
- err, i915_modparams.inject_load_failure, func, line);
- i915_modparams.inject_load_failure = 0;
+ err, i915_modparams.inject_probe_failure, func, line);
+ i915_modparams.inject_probe_failure = 0;
return err;
}
bool i915_error_injected(void)
{
- return i915_probe_fail_count && !i915_modparams.inject_load_failure;
+ return i915_probe_fail_count && !i915_modparams.inject_probe_failure;
}
#endif
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] drm/i915: Conclude load -> probe naming convention switch
Test-with: <20191001142724.16472-2-janusz.krzyszto...@linux.intel.com> The purpose is: * to fix incompatible names of new functions introduced meanwhile, * to complete postponed rename of module parameter. v2: * drop unnecessary statement about custom user applications from commit message of 2/2, there are no such (Chris), * add R-b (thanks Chris), * use correct message ID of (also rerolled) IGT counterpart to be tested with. Janusz Krzysztofik (2): drm/i915: Fix i915_inject_load_error() name to read *_probe_* drm/i915: Rename "inject_load_failure" module parameter .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 ++-- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 +++--- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 20 ++- drivers/gpu/drm/i915/i915_gem.c | 4 ++-- drivers/gpu/drm/i915/i915_params.c| 2 +- drivers/gpu/drm/i915/i915_params.h| 2 +- drivers/gpu/drm/i915/i915_utils.c | 14 ++--- drivers/gpu/drm/i915/i915_utils.h | 12 +-- 9 files changed, 34 insertions(+), 32 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for RFT drm/i915/tgl: Re-enable rps (rev3)
== Series Details ==
Series: RFT drm/i915/tgl: Re-enable rps (rev3)
URL : https://patchwork.freedesktop.org/series/67398/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6984 -> Patchwork_14604
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14604/index.html
Known issues
Here are the changes found in Patchwork_14604 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-short:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6984/fi-icl-u3/igt@gem_mmap_...@basic-short.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14604/fi-icl-u3/igt@gem_mmap_...@basic-short.html
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724] /
[fdo#111214])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6984/fi-icl-u3/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14604/fi-icl-u3/igt@i915_module_l...@reload.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [INCOMPLETE][5] ([fdo#103927] / [fdo#111381]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6984/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14604/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_reloc@basic-cpu:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6984/fi-icl-u3/igt@gem_exec_re...@basic-cpu.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14604/fi-icl-u3/igt@gem_exec_re...@basic-cpu.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
[fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
Participating hosts (53 -> 45)
--
Additional (1): fi-byt-j1900
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-kbl-7500u fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6984 -> Patchwork_14604
CI-20190529: 20190529
CI_DRM_6984: 04d34ff324cf346bc962bb43eaa15572cafab08c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14604: 63d2c674198cbd0825a848b6a84c0cd83a65e4cf @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
63d2c674198c RFT drm/i915/tgl: Re-enable rps
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14604/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/rect: Add drm_rect_translate_to()
On Tue, Oct 01, 2019 at 12:26:52PM +0300, Jani Nikula wrote:
> On Mon, 30 Sep 2019, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a helper to translate a rectangle to an absolute position.
> >
> > Signed-off-by: Ville Syrjälä
>
> The series is
>
> Reviewed-by: Jani Nikula
>
Thanks. 1-2 pushed to drm-misc-next.
>
>
> > ---
> > include/drm/drm_rect.h | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> > index 6195820aa5c5..fc7c14627ee2 100644
> > --- a/include/drm/drm_rect.h
> > +++ b/include/drm/drm_rect.h
> > @@ -106,6 +106,20 @@ static inline void drm_rect_translate(struct drm_rect
> > *r, int dx, int dy)
> > r->y2 += dy;
> > }
> >
> > +/**
> > + * drm_rect_translate_to - translate the rectangle to an absolute position
> > + * @r: rectangle to be tranlated
> > + * @x: horizontal position
> > + * @y: vertical position
> > + *
> > + * Move rectangle @r to @x in the horizontal direction,
> > + * and to @y in the vertical direction.
> > + */
> > +static inline void drm_rect_translate_to(struct drm_rect *r, int x, int y)
> > +{
> > + drm_rect_translate(r, x - r->x1, y - r->y1);
> > +}
> > +
> > /**
> > * drm_rect_downscale - downscale a rectangle
> > * @r: rectangle to be downscaled
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [RFC PATCH] iommu/vt-d: Fix IOMMU field not populated on device hot re-plug
Hi Baolu, On Tuesday, September 3, 2019 9:41:23 AM CEST Janusz Krzysztofik wrote: > Hi Baolu, > > On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote: > > Hi Janusz, > > > > On 9/2/19 4:37 PM, Janusz Krzysztofik wrote: > > >> I am not saying that keeping data is not acceptable. I just want to > > >> check whether there are any other solutions. > > > Then reverting 458b7c8e0dde and applying this patch still resolves the > issue > > > for me. No errors appear when mappings are unmapped on device close > > > after > the > > > device has been removed, and domain info preserved on device removal is > > > successfully reused on device re-plug. > > > > This patch doesn't look good to me although I agree that keeping data is > > acceptable. Any progress with that? Which mailing list should I watch for updates? Thanks, Janusz > > It updates dev->archdata.iommu, but leaves the hardware > > context/pasid table unchanged. This might cause problems somewhere. > > > > > > > > Is there anything else I can do to help? > > > > Can you please tell me how to reproduce the problem? > > The most simple way to reproduce the issue, assuming there are no non-Intel > graphics adapters installed, is to run the following shell commands: > > #!/bin/sh > # load i915 module > modprobe i915 > # open an i915 device and keep it open in background > cat /dev/dri/card0 >/dev/null & > sleep 2 > # simulate device unplug > echo 1 >/sys/class/drm/card0/device/remove > # make the background process close the device on exit > kill $! > > Thanks, > Janusz > > > > Keeping the per > > device domain info while device is unplugged is a bit dangerous because > > info->dev might be a wild pointer. We need to work out a clean fix. > > > > > > > > Thanks, > > > Janusz > > > > > > > Best regards, > > Baolu > > > > > > >
Re: [Intel-gfx] [PATCH v3] drm/print: add drm_debug_enabled()
On Tuesday, 2019-10-01 17:06:14 +0300, Jani Nikula wrote:
> Add helper to check if a drm debug category is enabled. Convert drm core
> to use it. No functional changes.
>
> v2: Move unlikely() to drm_debug_enabled() (Eric)
>
> v3: Keep unlikely() when combined with other conditions (Eric)
>
> Cc: Eric Engestrom
Reviewed-by: Eric Engestrom
> Acked-by: Alex Deucher
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
> drivers/gpu/drm/drm_edid.c| 2 +-
> drivers/gpu/drm/drm_edid_load.c | 2 +-
> drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
> drivers/gpu/drm/drm_print.c | 4 ++--
> drivers/gpu/drm/drm_vblank.c | 6 +++---
> include/drm/drm_print.h | 5 +
> 8 files changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 7a26bfb5329c..0d466d3b0809 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1405,7 +1405,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_nonblocking_commit(state);
> } else {
> - if (unlikely(drm_debug & DRM_UT_STATE))
> + if (drm_debug_enabled(DRM_UT_STATE))
> drm_atomic_print_state(state);
>
> ret = drm_atomic_commit(state);
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index e6801db54d0f..6b14b63b8d62 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1179,7 +1179,7 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> }
> }
> out:
> - if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
> + if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> @@ -2322,7 +2322,7 @@ static int process_single_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr,
> idx += tosend + 1;
>
> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
> + if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>
> drm_printf(&p, "sideband msg failed to send\n");
> @@ -2389,7 +2389,7 @@ static void drm_dp_queue_down_tx(struct
> drm_dp_mst_topology_mgr *mgr,
> mutex_lock(&mgr->qlock);
> list_add_tail(&txmsg->next, &mgr->tx_msg_downq);
>
> - if (unlikely(drm_debug & DRM_UT_DP)) {
> + if (drm_debug_enabled(DRM_UT_DP)) {
> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(&p, txmsg);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3c9703b08491..0552175313cb 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1651,7 +1651,7 @@ static void connector_bad_edid(struct drm_connector
> *connector,
> {
> int i;
>
> - if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> + if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
> return;
>
> dev_warn(connector->dev->dev,
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index d38b3b255926..37d8ba3ddb46 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector *connector,
> const char *name,
> u8 *edid;
> int fwsize, builtin;
> int i, valid_extensions = 0;
> - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
> DRM_UT_KMS);
> + bool print_bad_edid = !connector->bad_edid_counter ||
> drm_debug_enabled(DRM_UT_KMS);
>
> builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
> if (builtin >= 0) {
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index f8154316a3b0..ccfb5b33c5e3 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi,
> int dc,
> int i, ret;
> u8 *dst;
>
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
> pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>__func__, dc, max_chunk);
>
> @@ -907,7 +907,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi,
> int dc,
> max_chunk = dbi->tx_buf9_len;
> dst16 = dbi->tx_buf9;
>
> - if (drm_debug & DRM_UT_DRIVER)
> + if (drm_debug_enabled(DRM_UT_DRIVER))
> pr_debug("[
[Intel-gfx] ✓ Fi.CI.IGT: success for lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers (rev2)
== Series Details == Series: lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers (rev2) URL : https://patchwork.freedesktop.org/series/67405/ State : success == Summary == CI Bug Log - changes from CI_DRM_6981_full -> Patchwork_14602_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14602_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-apl3/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-apl6/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_exec_reloc@basic-write-gtt-active: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([fdo#106107]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-skl10/igt@gem_exec_re...@basic-write-gtt-active.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-skl3/igt@gem_exec_re...@basic-write-gtt-active.html * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +22 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-iclb2/igt@gem_exec_sched...@out-order-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-iclb8/igt@gem_exec_sched...@out-order-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-iclb8/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][9] -> [FAIL][10] ([fdo#103375]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-kbl7/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-kbl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_userptr_blits@coherency-sync: - shard-hsw: [PASS][11] -> [DMESG-WARN][12] ([fdo#111870]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-hsw7/igt@gem_userptr_bl...@coherency-sync.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-hsw5/igt@gem_userptr_bl...@coherency-sync.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([fdo#111870]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-kbl1/igt@gem_userptr_bl...@dmabuf-sync.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-kbl3/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-skl8/igt@gem_userptr_bl...@dmabuf-sync.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-skl10/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-glk1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-glk4/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([fdo#111870]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-iclb2/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-iclb6/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html * igt@gem_userptr_blits@sync-unmap-after-close: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([fdo#109385] / [fdo#111870]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-apl6/igt@gem_userptr_bl...@sync-unmap-after-close.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-apl6/igt@gem_userptr_bl...@sync-unmap-after-close.html * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#103184] / [fdo#103232]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6981/shard-skl3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14602/shard-skl3/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html *
[Intel-gfx] [PATCH] drm/i915/display: abstract all vgaarb access to intel_vga.[ch]
Split out the code related to vga client and vgaarb all over the place
into new intel_vga.[ch]. No functional changes.
Cc: Ville Syrjälä
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 97 +--
drivers/gpu/drm/i915/display/intel_display.h | 3 -
.../drm/i915/display/intel_display_power.c| 24 +--
drivers/gpu/drm/i915/display/intel_vga.c | 160 ++
drivers/gpu/drm/i915/display/intel_vga.h | 18 ++
drivers/gpu/drm/i915/i915_drv.c | 30 +---
drivers/gpu/drm/i915/i915_pci.c | 1 -
drivers/gpu/drm/i915/i915_suspend.c | 3 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 -
10 files changed, 194 insertions(+), 146 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_vga.c
create mode 100644 drivers/gpu/drm/i915/display/intel_vga.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e04463d85401..d2b53b5add81 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -184,7 +184,8 @@ i915-y += \
display/intel_psr.o \
display/intel_quirks.o \
display/intel_sprite.o \
- display/intel_tc.o
+ display/intel_tc.o \
+ display/intel_vga.o
i915-$(CONFIG_ACPI) += \
display/intel_acpi.o \
display/intel_opregion.o
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f1328c08f4ad..d99c59e97568 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
@@ -79,6 +78,7 @@
#include "intel_sideband.h"
#include "intel_sprite.h"
#include "intel_tc.h"
+#include "intel_vga.h"
/* Primary plane formats for gen <= 3 */
static const u32 i8xx_primary_formats[] = {
@@ -4241,7 +4241,7 @@ __intel_display_resume(struct drm_device *dev,
int i, ret;
intel_modeset_setup_hw_state(dev, ctx);
- i915_redisable_vga(to_i915(dev));
+ intel_vga_redisable(to_i915(dev));
if (!state)
return 0;
@@ -15994,35 +15994,6 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
}
-static i915_reg_t i915_vgacntrl_reg(struct drm_i915_private *dev_priv)
-{
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- return VLV_VGACNTRL;
- else if (INTEL_GEN(dev_priv) >= 5)
- return CPU_VGACNTRL;
- else
- return VGACNTRL;
-}
-
-/* Disable the VGA plane that we never use */
-static void i915_disable_vga(struct drm_i915_private *dev_priv)
-{
- struct pci_dev *pdev = dev_priv->drm.pdev;
- u8 sr1;
- i915_reg_t vga_reg = i915_vgacntrl_reg(dev_priv);
-
- /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */
- vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO);
- outb(SR01, VGA_SR_INDEX);
- sr1 = inb(VGA_SR_DATA);
- outb(sr1 | 1<<5, VGA_SR_DATA);
- vga_put(pdev, VGA_RSRC_LEGACY_IO);
- udelay(300);
-
- I915_WRITE(vga_reg, VGA_DISP_DISABLE);
- POSTING_READ(vga_reg);
-}
-
void intel_modeset_init_hw(struct drm_i915_private *i915)
{
intel_update_cdclk(i915);
@@ -16288,7 +16259,7 @@ int intel_modeset_init(struct drm_i915_private *i915)
intel_update_max_cdclk(i915);
/* Just disable it once at startup */
- i915_disable_vga(i915);
+ intel_vga_disable(i915);
intel_setup_outputs(i915);
drm_modeset_lock_all(dev);
@@ -16647,39 +16618,6 @@ static void intel_sanitize_encoder(struct
intel_encoder *encoder)
icl_sanitize_encoder_pll_mapping(encoder);
}
-void i915_redisable_vga_power_on(struct drm_i915_private *dev_priv)
-{
- i915_reg_t vga_reg = i915_vgacntrl_reg(dev_priv);
-
- if (!(I915_READ(vga_reg) & VGA_DISP_DISABLE)) {
- DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n");
- i915_disable_vga(dev_priv);
- }
-}
-
-void i915_redisable_vga(struct drm_i915_private *dev_priv)
-{
- intel_wakeref_t wakeref;
-
- /*
-* This function can be called both from intel_modeset_setup_hw_state or
-* at a very early point in our resume sequence, where the power well
-* structures are not yet restored. Since this function is at a very
-* paranoid "someone might have enabled VGA while we were not looking"
-* level, just check if the power well is enabled instead of trying to
-* follow the "don't touch the power well if we don't need it" policy
-* the rest of the driver uses.
-*/
- wakeref = intel_display_power_get_if_enabled(dev_priv,
-POWER_DOMAIN_VGA);
- if (!wakeref)
- return;
-
-
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Initialise breadcrumb lists on the virtual engine (rev2)
== Series Details == Series: drm/i915: Initialise breadcrumb lists on the virtual engine (rev2) URL : https://patchwork.freedesktop.org/series/67373/ State : failure == Summary == Applying: drm/i915: Initialise breadcrumb lists on the virtual engine Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gt/intel_lrc.c No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: split out intel_vga_client.[ch]
On Tue, 01 Oct 2019, Ville Syrjälä wrote: > On Tue, Oct 01, 2019 at 05:28:51PM +0300, Jani Nikula wrote: >> On Tue, 01 Oct 2019, Ville Syrjälä wrote: >> > On Tue, Oct 01, 2019 at 03:12:49PM +0100, Chris Wilson wrote: >> >> Quoting Jani Nikula (2019-10-01 14:43:53) >> >> > Split out code related to vga client and vga switcheroo >> >> > register/unregister and state handling from i915_drv.c and >> >> > intel_display.c. >> >> > >> >> > It's a bit difficult to draw the line how much to move to the new file >> >> > from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo() >> >> > and i915_resume_switcheroo() in place was cleanest. >> >> > >> >> > No functional changes. >> >> > >> >> > Cc: Ville Syrjälä >> >> > Cc: Chris Wilson >> >> > Signed-off-by: Jani Nikula >> >> > >> >> > --- >> >> > >> >> > It's also a bit fuzzy if this is a sensible split anyway. Could also >> >> > name it intel_vga and move these from intel_display.c there? >> >> >> >> My initial thought that the switcheroo interface would remain in core, >> > >> > Yeah the switcheroo stuff should perhaps stays with the rest of the pm >> > hooks. >> >> Okay, so keep all of switcheroo in i915_drv.c, and move all the vgaarb >> stuff (incl the ones I mentioned from intel_display.c) to >> intel_vga.[ch]? > > I can get behind that plan. Patch in your inbox, I'll look into switcheroo later. BR, Jani. > >> >> > >> >> that it is more of a global power state that we currently just use for >> >> the legacy vga switching. >> >> >> >> The patch looks fine, on a pure mechanical pov, >> >> Reviewed-by: Chris Wilson >> >> >> >> For the sake of argument, could you float the split in the other >> >> direction? >> >> Please elaborate. Move switcheroo higher in the call chain? >> >> BR, >> Jani. >> >> >> >> >> >> And maybe Ville has a good opinion on how it is meant to work :) >> >> -Chris >> >> -- >> Jani Nikula, Intel Open Source Graphics Center -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915: Create dumb buffer from LMEM (rev2)
== Series Details ==
Series: series starting with [1/2] drm/i915: Create dumb buffer from LMEM (rev2)
URL : https://patchwork.freedesktop.org/series/67428/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
AR drivers/gpu/drm/i915/built-in.a
CC [M] drivers/gpu/drm/i915/gem/i915_gem_domain.o
drivers/gpu/drm/i915/gem/i915_gem_domain.c: In function
‘i915_gem_object_pin_to_display_plane’:
drivers/gpu/drm/i915/gem/i915_gem_domain.c:429:6: error: implicit declaration
of function ‘HAS_LMEM’; did you mean ‘HAS_GMCH’?
[-Werror=implicit-function-declaration]
if (HAS_LMEM(i915))
^~~~
HAS_GMCH
drivers/gpu/drm/i915/gem/i915_gem_domain.c:430:14: error: ‘struct ’
has no member named ‘region’
if (obj->mm.region->type != INTEL_LMEM) {
^
drivers/gpu/drm/i915/gem/i915_gem_domain.c:430:31: error: ‘INTEL_LMEM’
undeclared (first use in this function); did you mean ‘INTEL_GM45’?
if (obj->mm.region->type != INTEL_LMEM) {
^~
INTEL_GM45
drivers/gpu/drm/i915/gem/i915_gem_domain.c:430:31: note: each undeclared
identifier is reported only once for each function it appears in
cc1: all warnings being treated as errors
scripts/Makefile.build:265: recipe for target
'drivers/gpu/drm/i915/gem/i915_gem_domain.o' failed
make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_domain.o] Error 1
scripts/Makefile.build:509: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:509: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:509: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1670: recipe for target 'drivers' failed
make: *** [drivers] Error 2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Limit MST modes based on plane size too
From: Ville Syrjälä
When adding the max plane size checks to the .mode_valid() hooks
I naturally forgot about MST. Take care of that one as well.
Cc: Manasi Navare
Cc: Sean Paul
Cc: José Roberto de Souza
Cc: Maarten Lankhorst
Fixes: 2d20411e25a3 ("drm/i915: Don't advertise modes that exceed the max plane
size")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index df4f35c10a69..2203be28ea01 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -424,6 +424,7 @@ static enum drm_mode_status
intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
@@ -451,7 +452,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
if (mode_rate > max_rate || mode->clock > max_dotclk)
return MODE_CLOCK_HIGH;
- return MODE_OK;
+ return intel_mode_valid_max_plane_size(dev_priv, mode);
}
static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector
*connector,
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Polish intel_tv_mode_valid()
From: Ville Syrjälä Drop the tv_mode NULL check since intel_tv_mode_find() never actually returns NULL, and flip the condition around so that the MODE_OK case is at the end, which is customary to all the other .mode_valid() implementations. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_tv.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_tv.c b/drivers/gpu/drm/i915/display/intel_tv.c index b70221f5112a..71c3f7e5df7d 100644 --- a/drivers/gpu/drm/i915/display/intel_tv.c +++ b/drivers/gpu/drm/i915/display/intel_tv.c @@ -961,11 +961,10 @@ intel_tv_mode_valid(struct drm_connector *connector, return MODE_CLOCK_HIGH; /* Ensure TV refresh is close to desired refresh */ - if (tv_mode && abs(tv_mode->refresh - drm_mode_vrefresh(mode) * 1000) - < 1000) - return MODE_OK; + if (abs(tv_mode->refresh - drm_mode_vrefresh(mode) * 1000) >= 1000) + return MODE_CLOCK_RANGE; - return MODE_CLOCK_RANGE; + return MODE_OK; } static int -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise potential false lite-restore
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poisoning the ringbuffer of the first context and trying
to trick a simple RING_TAIL update (i.e. lite-restore)
v2: Also check what happens if preempt ce[0] with ce[1] (both instances
on the same engine from the same parent context) [Tvrtko]
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
Fixup GEM_BUG_ON to look at rq->tail only after it is set!
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 174 +
1 file changed, 174 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 93f2fcdc49bf..f4d6a1b734ae 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -79,6 +79,178 @@ static int live_sanitycheck(void *arg)
return err;
}
+static int live_unlite_restore(struct drm_i915_private *i915, int prio)
+{
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ struct igt_spinner spin;
+ int err = -ENOMEM;
+
+ /*
+* Check that we can correctly context switch between 2 instances
+* on the same engine from the same parent context.
+*/
+
+ mutex_lock(&i915->drm.struct_mutex);
+ wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+
+ if (igt_spinner_init(&spin, &i915->gt))
+ goto err_unlock;
+
+ ctx = kernel_context(i915);
+ if (!ctx)
+ goto err_spin;
+
+ err = 0;
+ for_each_engine(engine, i915, id) {
+ struct intel_context *ce[2] = {};
+ struct i915_request *rq[2];
+ struct igt_live_test t;
+ int n;
+
+ if (prio && !intel_engine_has_preemption(engine))
+ continue;
+
+ if (!intel_engine_can_store_dword(engine))
+ continue;
+
+ if (igt_live_test_begin(&t, i915, __func__, engine->name)) {
+ err = -EIO;
+ break;
+ }
+
+ for (n = 0; n < ARRAY_SIZE(ce); n++) {
+ struct intel_context *tmp;
+
+ tmp = intel_context_create(ctx, engine);
+ if (IS_ERR(tmp)) {
+ err = PTR_ERR(tmp);
+ goto err_ce;
+ }
+
+ err = intel_context_pin(tmp);
+ if (err) {
+ intel_context_put(tmp);
+ goto err_ce;
+ }
+
+ /*
+* Setup the pair of contexts such that if we
+* lite-restore using the RING_TAIL from ce[1] it
+* will execute garbage from ce[0]->ring.
+*/
+ memset(tmp->ring->vaddr,
+ POISON_INUSE, /* IPEHR: 0x5a5a5a5a [hung!] */
+ tmp->ring->vma->size);
+
+ ce[n] = tmp;
+ }
+ GEM_BUG_ON(!ce[1]->ring->size);
+ intel_ring_reset(ce[1]->ring, ce[1]->ring->size / 2);
+ __execlists_update_reg_state(ce[1], engine);
+
+
+ rq[0] = igt_spinner_create_request(&spin, ce[0], MI_ARB_CHECK);
+ if (IS_ERR(rq[0])) {
+ err = PTR_ERR(rq[0]);
+ goto err_ce;
+ }
+
+ i915_request_get(rq[0]);
+ i915_request_add(rq[0]);
+ GEM_BUG_ON(rq[0]->tail > ce[1]->ring->emit);
+
+ if (!igt_wait_for_spinner(&spin, rq[0])) {
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ rq[1] = i915_request_create(ce[1]);
+ if (IS_ERR(rq[1])) {
+ err = PTR_ERR(rq[1]);
+ i915_request_put(rq[0]);
+ goto err_ce;
+ }
+
+ if (!prio) {
+ /*
+* Ensure we do the switch to ce[1] on completion.
+*
+* rq[0] is already submitted, so this should reduce
+* to a no-op (a wait on a request on the same engine
+* uses the submit fence, not the completion fence),
+* but it will install a dependency on rq[1] for rq[0]
+* that will prevent the pair being reordered by
+* timeslicing.
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Describe structure members in documentation
== Series Details ==
Series: drm/i915: Describe structure members in documentation
URL : https://patchwork.freedesktop.org/series/67442/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6985 -> Patchwork_14607
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/index.html
Known issues
Here are the changes found in Patchwork_14607 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] /
[fdo#111381])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6985/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [PASS][3] -> [FAIL][4] ([fdo#109483])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6985/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@prime_busy@basic-wait-after-default:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6985/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/fi-icl-u3/igt@prime_b...@basic-wait-after-default.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6985/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
- fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6985/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][11] ([fdo#102614]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6985/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
[fdo#111736]: https://bugs.freedesktop.org/show_bug.cgi?id=111736
Participating hosts (51 -> 46)
--
Additional (2): fi-cml-h fi-apl-guc
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6985 -> Patchwork_14607
CI-20190529: 20190529
CI_DRM_6985: 75d23ba38b952a5f3d0fc42baf1df2d15c5e74b1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14607: dafb0e4db5d73ca8538b6b512eb69610ef3f7591 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dafb0e4db5d7 drm/i915: Describe structure members in documentation
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14607/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/display: split out intel_vga_client.[ch]
== Series Details == Series: drm/i915/display: split out intel_vga_client.[ch] URL : https://patchwork.freedesktop.org/series/67447/ State : warning == Summary == $ dim checkpatch origin/drm-tip b1b290f96d25 drm/i915/display: split out intel_vga_client.[ch] -:91: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #91: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 363 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Conclude load -> probe naming convention switch
== Series Details == Series: Conclude load -> probe naming convention switch URL : https://patchwork.freedesktop.org/series/67448/ State : failure == Summary == Series 67448 revision 1 Test-with: <20191001132728.14602-1-janusz.krzyszto...@linux.intel.com> not found ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
