[Intel-gfx] ✓ Fi.CI.BAT: success for Security mitigation for Intel Gen7/7.5 HWs
== Series Details == Series: Security mitigation for Intel Gen7/7.5 HWs URL : https://patchwork.freedesktop.org/series/73745/ State : success == Summary == CI Bug Log - changes from CI_DRM_7979 -> Patchwork_16654 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16654/index.html Known issues Here are the changes found in Patchwork_16654 that come from known issues: ### IGT changes ### Issues hit * igt@gem_close_race@basic-threads: - fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16654/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html Warnings * igt@gem_exec_parallel@fds: - fi-byt-n2820: [FAIL][3] ([i915#694]) -> [TIMEOUT][4] ([fdo#112271] / [i915#1084]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-byt-n2820/igt@gem_exec_paral...@fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16654/fi-byt-n2820/igt@gem_exec_paral...@fds.html * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [INCOMPLETE][5] ([CI#94] / [i915#460]) -> [FAIL][6] ([CI#94]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16654/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084 [i915#460]: https://gitlab.freedesktop.org/drm/intel/issues/460 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816 Participating hosts (45 -> 42) -- Additional (4): fi-glk-dsi fi-ivb-3770 fi-skl-6600u fi-bsw-n3050 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-ilk-650 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7979 -> Patchwork_16654 CI-20190529: 20190529 CI_DRM_7979: 45d61ea8faa5bdb50719bed2de3dd2ef8e6f5a12 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16654: 00161707fff085f7754fa9a73c5922f864e54236 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 00161707fff0 drm/i915/gen7: Clear all EU/L3 residual contexts ce61523e6b22 drm/i915: Add mechanism to submit a context WA on ring submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16654/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/i915_pm_rpm: Only check for suspend failures after each debugfs entry
On 2020-02-20 19:41, Chris Wilson wrote:
> Since we check before and then after each debugfs entry, we do not need
> to check before each time as well. We will error out as soon as it does
> fail, at all other times we know the system to be idle.
>
> No impact on runtime for glk (which apparently is one of the better
> behaving systems).
>
> Signed-off-by: Chris Wilson
> Cc: Martin Peres
I don't like this patch because the first read might not have the gpu
suspended, and there shouldn't be much overhead in checking twice rather
than once.
What's your rationale here?
To me, the issue is that some platforms suspend in milliseconds while
some take seconds, and that might be indicative a real bug in the driver.
Martin
> ---
> tests/i915/i915_pm_rpm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
> index 0c2821122..bf412b5cc 100644
> --- a/tests/i915/i915_pm_rpm.c
> +++ b/tests/i915/i915_pm_rpm.c
> @@ -932,9 +932,6 @@ static int read_entry(const char *filepath,
> int fd;
> int rc;
>
> - igt_assert_f(wait_for_suspended(), "Before opening: %s (%s)\n",
> - filepath + pathinfo->base, filepath);
> -
> fd = open(filepath, O_RDONLY | O_NONBLOCK);
> if (fd < 0) {
> igt_debug("Failed to open '%s': %m\n", filepath);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] sw_sync: Use fixed runtime for sync_expired_merge
On 2020-02-20 18:57, Chris Wilson wrote:
> Convert from using a fixed number of iterations (1 million), to using a
> fixed runtime so that we have predictable (and shorter!) run times across
> a wide variety of machines.
>
> Signed-off-by: Chris Wilson
> Cc: Martin Peres
Thanks for making this test more reasonable :) Strength is in execution
count, not execution time :)
Reviewed-by: Martin Peres
> ---
> tests/sw_sync.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index 626b6d39f..6e439496d 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -747,30 +747,27 @@ static void
> test_sync_multi_producer_single_consumer(void)
>
> static void test_sync_expired_merge(void)
> {
> - int iterations = 1 << 20;
> int timeline;
> - int i;
> - int fence_expired, fence_merged;
> + int expired;
>
> timeline = sw_sync_timeline_create();
>
> sw_sync_timeline_inc(timeline, 100);
> - fence_expired = sw_sync_timeline_create_fence(timeline, 1);
> - igt_assert_f(sync_fence_wait(fence_expired, 0) == 0,
> + expired = sw_sync_timeline_create_fence(timeline, 1);
> + igt_assert_f(sync_fence_wait(expired, 0) == 0,
>"Failure waiting for expired fence\n");
>
> - fence_merged = sync_fence_merge(fence_expired, fence_expired);
> - close(fence_merged);
> + close(sync_fence_merge(expired, expired));
>
> - for (i = 0; i < iterations; i++) {
> - int fence = sync_fence_merge(fence_expired, fence_expired);
> + igt_until_timeout(2) {
> + int fence = sync_fence_merge(expired, expired);
>
> igt_assert_f(sync_fence_wait(fence, -1) == 0,
>"Failure waiting on fence\n");
> close(fence);
> }
>
> - close(fence_expired);
> + close(expired);
> }
>
> static void test_sync_random_merge(void)
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_eio: Trim kms workload
On 2020-02-20 18:53, Chris Wilson wrote:
> We don't need to try reset-stress on every engine with the display, just
> once is enough to stress any interlinkage.
If you say so :)
>
> This should reduce the runtime to 10s.
That would be appreciated!
>
> Signed-off-by: Chris Wilson
> Cc: Martin Peres
The only difference between the previous behaviour and the new one
introduced by the patch is that reset_stress() is called for only the
default exec engine as opposed to all of them previously. So, the patch is:
Reviewed-by: Martin Peres
> ---
> tests/i915/gem_eio.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> index 0fe51efeb..1ec609410 100644
> --- a/tests/i915/gem_eio.c
> +++ b/tests/i915/gem_eio.c
> @@ -898,8 +898,14 @@ static void test_kms(int i915, igt_display_t *dpy)
>
> test_inflight(i915, 0);
> if (gem_has_contexts(i915)) {
> - test_reset_stress(i915, 0);
> - test_reset_stress(i915, TEST_WEDGE);
> + uint32_t ctx = context_create_safe(i915);
> +
> + reset_stress(i915, ctx,
> + "default", I915_EXEC_DEFAULT, 0);
> + reset_stress(i915, ctx,
> + "default", I915_EXEC_DEFAULT, TEST_WEDGE);
> +
> + gem_context_destroy(i915, ctx);
> }
>
> *shared = 1;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Security mitigation for Intel Gen7/7.5 HWs
== Series Details == Series: Security mitigation for Intel Gen7/7.5 HWs URL : https://patchwork.freedesktop.org/series/73745/ State : warning == Summary == $ dim checkpatch origin/drm-tip ce61523e6b22 drm/i915: Add mechanism to submit a context WA on ring submission 00161707fff0 drm/i915/gen7: Clear all EU/L3 residual contexts -:44: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #44: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 585 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Security mitigation for Intel Gen7/7.5 HWs
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73743/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7979 -> Patchwork_16653
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/index.html
Known issues
Here are the changes found in Patchwork_16653 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2] ([CI#80] / [i915#424])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- fi-kbl-7500u: [PASS][3] -> [TIMEOUT][4] ([fdo#112271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
- fi-bdw-5557u: [PASS][5] -> [TIMEOUT][6] ([fdo#112271])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
Warnings
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [INCOMPLETE][7] ([i915#45]) -> [TIMEOUT][8]
([fdo#112271] / [i915#1084] / [i915#816])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_parallel@fds:
- fi-byt-n2820: [FAIL][9] ([i915#694]) -> [TIMEOUT][10] ([fdo#112271]
/ [i915#1084])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-byt-n2820/igt@gem_exec_paral...@fds.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/fi-byt-n2820/igt@gem_exec_paral...@fds.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [INCOMPLETE][11] ([CI#94] / [i915#460]) -> [FAIL][12]
([CI#94])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7979/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#460]: https://gitlab.freedesktop.org/drm/intel/issues/460
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
Participating hosts (45 -> 45)
--
Additional (5): fi-bsw-n3050 fi-glk-dsi fi-bwr-2160 fi-ivb-3770 fi-skl-6600u
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-ctg-p8600 fi-byt-clapper
fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7979 -> Patchwork_16653
CI-20190529: 20190529
CI_DRM_7979: 45d61ea8faa5bdb50719bed2de3dd2ef8e6f5a12 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16653: 49dc47834a5e83d9d0b9b879edd6b336ea77e8d9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
49dc47834a5e drm/i915/gen7: Clear all EU/L3 residual contexts
a3dc644c8ea3 drm/i915: Add mechanism to submit a context WA on ring submission
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16653/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 Security mitigation for Intel Gen7/7.5 HWs
== Series Details == Series: Security mitigation for Intel Gen7/7.5 HWs URL : https://patchwork.freedesktop.org/series/73743/ State : warning == Summary == $ dim checkpatch origin/drm-tip a3dc644c8ea3 drm/i915: Add mechanism to submit a context WA on ring submission 49dc47834a5e drm/i915/gen7: Clear all EU/L3 residual contexts -:44: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #44: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 585 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.
This security mitigation changes does not triggers any performance
regression. Performance is on par with current drm-tips.
v2: Add igt generated header file for CB kernel assembled with Mesa tool
and addressed use of Kernel macro for ptr_align comment.
v3: Resolve Sparse warnings with newly generated, and imported CB
kernel.
v4: Include new igt generated CB kernel for gen7 and gen7.5. Also
add code formatting and compiler warnings changes (Chris Wilson)
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 402 ++
drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 +
drivers/gpu/drm/i915/gt/hsw_clear_kernel.c| 61 +++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/gt/ivb_clear_kernel.c| 61 +++
7 files changed, 556 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
create mode 100644 drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
create mode 100644 drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b314d44ded5e..ebe3a160f588 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+ gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
new file mode 100644
index ..de595b66a746
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gen7_renderclear.h"
+#include "i915_drv.h"
+#include "intel_gpu_commands.h"
+
+#define MAX_URB_ENTRIES 64
+#define STATE_SIZE (4 * 1024)
+#define GT3_INLINE_DATA_DELAYS 0x1E00
+#define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
+
+struct cb_kernel {
+ const void *data;
+ u32 size;
+};
+
+#define CB_KERNEL(name) { .data = (name), .size = sizeof(name) }
+
+#include "ivb_clear_kernel.c"
+static const struct cb_kernel cb_kernel_ivb = CB_KERNEL(ivb_clear_kernel);
+
+#include "hsw_clear_kernel.c"
+static const struct cb_kernel cb_kernel_hsw = CB_KERNEL(hsw_clear_kernel);
+
+struct batch_chunk {
+ struct i915_vma *vma;
+ u32 offset;
+ u32 *start;
+ u32 *end;
+ u32 max_items;
+};
+
+struct batch_vals {
+ u32 max_primitives;
+ u32 max_urb_entries;
+ u32 cmd_size;
+ u32 state_size;
+ u32 state_start;
+ u32 batch_size;
+ u32 surface_height;
+ u32 surface_width;
+ u32 scratch_size;
+ u32 max_size;
+};
+
+static void
+batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
+{
+ if (IS_HASWELL(i915)) {
+ bv->max_primitives = 280;
+ bv->max_urb_entries = MAX_URB_ENTRIES;
+ bv->surface_height = 16 * 16;
+ bv->surface_width = 32 * 2 * 16;
+ } else {
+ bv->max_primitives = 128;
+ bv->max_urb_entries = MAX_URB_ENTRIES / 2;
+ bv->surface_height = 16 * 8;
+ bv->surface_width = 32 * 16;
+ }
+ bv->cmd_size = bv->max_primitives * 4096;
+ bv->state_size = STATE_SIZE;
+ bv->state_start = bv->cmd_size;
+ bv->batch_size = bv->cmd_size + bv->state_size;
+ bv->scratch_size = bv->surface_height * bv->surface_width;
+ bv->max_size = bv->batch_size + bv->scratch_size;
+}
+
+static void batch_init(struct batch_chunk *bc,
+ struct i915_vma *vma,
+ u32 *start, u32 offset, u32 max_bytes)
+{
+ bc->vma = vma;
+ bc->offset = offset;
+ bc->start = start + bc->offset / sizeof(*bc->start);
+ bc->end = bc->start;
+ bc->max_items = max_bytes / sizeof(*bc->start);
+}
+
+static u32 batch_offset(const struct batch_chunk *bc, u32 *cs)
+{
+ return (cs - bc->start) * sizeof(*bc->start) + bc->offset;
+}
+
+static u32 batch_addr(const struct batch_chunk *bc)
+{
+ return bc->vma->node.start;
+}
+
+static void batch_add(struct batch_chunk *bc, const u32 d)
+{
+ GEM_BUG_ON((bc->end - bc->start) >=
[Intel-gfx] [PATCH v4 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
v2: Update vm_alias params to point to correct address space "vm" due to
changes made in the patch "f21613797bae98773"
v3-v4: none
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 134 +-
1 file changed, 130 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index f70b903a98bc..593710558b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1360,7 +1360,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1435,7 +1437,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1550,13 +1552,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context->vm));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = >wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce->vm));
if (ret)
return ret;
@@ -1564,7 +1609,7 @@ static int switch_context(struct i915_request *rq)
if (ce->state) {
u32 flags;
- GEM_BUG_ON(rq->engine->id != RCS0);
+ GEM_BUG_ON(engine->id != RCS0);
/* For resource streamer on HSW+ and power context elsewhere */
BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
@@ -1576,7 +1621,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1585,6 +1630,20 @@ static int
[Intel-gfx] [PATCH v4 0/2] Security mitigation for Intel Gen7/7.5 HWs
Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access Products affected: -- Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics. Mitigation Summary -- This patch provides mitigation for Gen7 and Gen7.5 hardware only. Patch for Gen9 devices have been provided and merged to Linux mainline, and backported to stable kernels. Note that Gen8 is not impacted due to a previously implemented workaround. The mitigation involves submitting a custom EU kernel prior to every context restore, in order to forcibly clear down residual EU and URB resources. The custom CB kernels are generated/assembled automatically, using Mesa (an open source tool) and IGT GPU tool - assembly sources are provided with IGT source code. This security mitigation change does not trigger any known performance regression. Performance is on par with current mainline/drm-tip. Note on Address Space Isolation (Full PPGTT) Isolation of EU kernel assets should be considered complementary to the existing support for address space isolation (aka Full PPGTT), since without address space isolation there is minimal value in preventing leakage between EU contexts. Full PPGTT has long been supported on Gen Gfx devices since Gen8, and protection against EU residual leakage is a welcome addition for these newer platforms. By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only as a hardware development feature for anticipated Gen8 productization. Support was never intended for, or provided to the Linux kernels for these platforms. Recent work (still ongoing) to the mainline kernel is retroactively providing this support, but due to the level of complexity it is not practical to attempt to backport this to earlier stable kernels. Since without Full PPGTT, EU residuals protection has questionable benefit, *there are no plans to provide stable kernel backports for this patch series.* Mika Kuoppala (1): drm/i915: Add mechanism to submit a context WA on ring submission Prathap Kumar Valsan (1): drm/i915/gen7: Clear all EU/L3 residual contexts drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/gen7_renderclear.c| 402 ++ drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 + drivers/gpu/drm/i915/gt/hsw_clear_kernel.c| 61 +++ drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 135 +- drivers/gpu/drm/i915/gt/ivb_clear_kernel.c| 61 +++ 7 files changed, 685 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h create mode 100644 drivers/gpu/drm/i915/gt/hsw_clear_kernel.c create mode 100644 drivers/gpu/drm/i915/gt/ivb_clear_kernel.c -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
v2: Update vm_alias params to point to correct address space "vm" due to
changes made in the patch "f21613797bae98773"
v3-v4: none
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 134 +-
1 file changed, 130 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index f70b903a98bc..593710558b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1360,7 +1360,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1435,7 +1437,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1550,13 +1552,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context->vm));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = >wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce->vm));
if (ret)
return ret;
@@ -1564,7 +1609,7 @@ static int switch_context(struct i915_request *rq)
if (ce->state) {
u32 flags;
- GEM_BUG_ON(rq->engine->id != RCS0);
+ GEM_BUG_ON(engine->id != RCS0);
/* For resource streamer on HSW+ and power context elsewhere */
BUILD_BUG_ON(HSW_MI_RS_SAVE_STATE_EN != MI_SAVE_EXT_STATE_EN);
@@ -1576,7 +1621,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1585,6 +1630,20 @@ static int
[Intel-gfx] [PATCH 0/2] Security mitigation for Intel Gen7/7.5 HWs
Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access Products affected: -- Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics. Mitigation Summary -- This patch provides mitigation for Gen7 and Gen7.5 hardware only. Patch for Gen9 devices have been provided and merged to Linux mainline, and backported to stable kernels. Note that Gen8 is not impacted due to a previously implemented workaround. The mitigation involves submitting a custom EU kernel prior to every context restore, in order to forcibly clear down residual EU and URB resources. The custom CB kernels are generated/assembled automatically, using Mesa (an open source tool) and IGT GPU tool - assembly sources are provided with IGT source code. This security mitigation change does not trigger any known performance regression. Performance is on par with current mainline/drm-tip. Note on Address Space Isolation (Full PPGTT) Isolation of EU kernel assets should be considered complementary to the existing support for address space isolation (aka Full PPGTT), since without address space isolation there is minimal value in preventing leakage between EU contexts. Full PPGTT has long been supported on Gen Gfx devices since Gen8, and protection against EU residual leakage is a welcome addition for these newer platforms. By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only as a hardware development feature for anticipated Gen8 productization. Support was never intended for, or provided to the Linux kernels for these platforms. Recent work (still ongoing) to the mainline kernel is retroactively providing this support, but due to the level of complexity it is not practical to attempt to backport this to earlier stable kernels. Since without Full PPGTT, EU residuals protection has questionable benefit, *there are no plans to provide stable kernel backports for this patch series.* Mika Kuoppala (1): drm/i915: Add mechanism to submit a context WA on ring submission Prathap Kumar Valsan (1): drm/i915/gen7: Clear all EU/L3 residual contexts drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/gen7_renderclear.c| 402 ++ drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 + drivers/gpu/drm/i915/gt/hsw_clear_kernel.c| 61 +++ drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 135 +- drivers/gpu/drm/i915/gt/ivb_clear_kernel.c| 61 +++ 7 files changed, 685 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h create mode 100644 drivers/gpu/drm/i915/gt/hsw_clear_kernel.c create mode 100644 drivers/gpu/drm/i915/gt/ivb_clear_kernel.c -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.
This security mitigation changes does not triggers any performance
regression. Performance is on par with current drm-tips.
v2: Add igt generated header file for CB kernel assembled with Mesa tool
and addressed use of Kernel macro for ptr_align comment.
v3: Resolve Sparse warnings with newly generated, and imported CB
kernel.
v4: Include new igt generated CB kernel for gen7 and gen7.5. Also
add code formatting and compiler warnings changes (Chris Wilson)
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 402 ++
drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 +
drivers/gpu/drm/i915/gt/hsw_clear_kernel.c| 61 +++
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/gt/ivb_clear_kernel.c| 61 +++
7 files changed, 556 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
create mode 100644 drivers/gpu/drm/i915/gt/hsw_clear_kernel.c
create mode 100644 drivers/gpu/drm/i915/gt/ivb_clear_kernel.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b314d44ded5e..ebe3a160f588 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+ gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
new file mode 100644
index ..de595b66a746
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gen7_renderclear.h"
+#include "i915_drv.h"
+#include "intel_gpu_commands.h"
+
+#define MAX_URB_ENTRIES 64
+#define STATE_SIZE (4 * 1024)
+#define GT3_INLINE_DATA_DELAYS 0x1E00
+#define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
+
+struct cb_kernel {
+ const void *data;
+ u32 size;
+};
+
+#define CB_KERNEL(name) { .data = (name), .size = sizeof(name) }
+
+#include "ivb_clear_kernel.c"
+static const struct cb_kernel cb_kernel_ivb = CB_KERNEL(ivb_clear_kernel);
+
+#include "hsw_clear_kernel.c"
+static const struct cb_kernel cb_kernel_hsw = CB_KERNEL(hsw_clear_kernel);
+
+struct batch_chunk {
+ struct i915_vma *vma;
+ u32 offset;
+ u32 *start;
+ u32 *end;
+ u32 max_items;
+};
+
+struct batch_vals {
+ u32 max_primitives;
+ u32 max_urb_entries;
+ u32 cmd_size;
+ u32 state_size;
+ u32 state_start;
+ u32 batch_size;
+ u32 surface_height;
+ u32 surface_width;
+ u32 scratch_size;
+ u32 max_size;
+};
+
+static void
+batch_get_defaults(struct drm_i915_private *i915, struct batch_vals *bv)
+{
+ if (IS_HASWELL(i915)) {
+ bv->max_primitives = 280;
+ bv->max_urb_entries = MAX_URB_ENTRIES;
+ bv->surface_height = 16 * 16;
+ bv->surface_width = 32 * 2 * 16;
+ } else {
+ bv->max_primitives = 128;
+ bv->max_urb_entries = MAX_URB_ENTRIES / 2;
+ bv->surface_height = 16 * 8;
+ bv->surface_width = 32 * 16;
+ }
+ bv->cmd_size = bv->max_primitives * 4096;
+ bv->state_size = STATE_SIZE;
+ bv->state_start = bv->cmd_size;
+ bv->batch_size = bv->cmd_size + bv->state_size;
+ bv->scratch_size = bv->surface_height * bv->surface_width;
+ bv->max_size = bv->batch_size + bv->scratch_size;
+}
+
+static void batch_init(struct batch_chunk *bc,
+ struct i915_vma *vma,
+ u32 *start, u32 offset, u32 max_bytes)
+{
+ bc->vma = vma;
+ bc->offset = offset;
+ bc->start = start + bc->offset / sizeof(*bc->start);
+ bc->end = bc->start;
+ bc->max_items = max_bytes / sizeof(*bc->start);
+}
+
+static u32 batch_offset(const struct batch_chunk *bc, u32 *cs)
+{
+ return (cs - bc->start) * sizeof(*bc->start) + bc->offset;
+}
+
+static u32 batch_addr(const struct batch_chunk *bc)
+{
+ return bc->vma->node.start;
+}
+
+static void batch_add(struct batch_chunk *bc, const u32 d)
+{
+ GEM_BUG_ON((bc->end - bc->start) >=
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lspcon: Make sure link rate did not exceed downstream and lspcon limitation (rev2)
== Series Details ==
Series: drm/i915/lspcon: Make sure link rate did not exceed downstream and
lspcon limitation (rev2)
URL : https://patchwork.freedesktop.org/series/73012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7978 -> Patchwork_16652
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/index.html
Known issues
Here are the changes found in Patchwork_16652 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402])
+2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-tgl-y/igt@gem_mmap_...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111096] / [i915#323])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-snb-2520m: [PASS][5] -> [FAIL][6] ([i915#978])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-snb-2520m/igt@kms_flip@basic-flip-vs-wf_vblank.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-snb-2520m/igt@kms_flip@basic-flip-vs-wf_vblank.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [INCOMPLETE][7] ([i915#694] / [i915#816]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][9] ([i915#585]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling:
- fi-tgl-y: [DMESG-WARN][11] ([CI#94] / [i915#402]) -> [PASS][12]
+1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html
Warnings
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][13] ([fdo#109315]) -> [SKIP][14] ([fdo#109315]
/ [i915#585])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
* igt@kms_chamelium@dp-edid-read:
- fi-icl-u3: [SKIP][15] ([fdo#109284] / [fdo#111827] / [i915#585])
-> [SKIP][16] ([fdo#109284] / [fdo#111827])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-icl-u3/igt@kms_chamel...@dp-edid-read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-icl-u3/igt@kms_chamel...@dp-edid-read.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-icl-u3: [SKIP][17] ([fdo#109284] / [fdo#111827]) ->
[SKIP][18] ([fdo#109284] / [fdo#111827] / [i915#585])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7978/fi-icl-u3/igt@kms_chamel...@dp-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16652/fi-icl-u3/igt@kms_chamel...@dp-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#978]: https://gitlab.freedesktop.org/drm/intel/issues/978
Participating hosts (49 -> 42)
--
Additional (2): fi-blb-e6850 fi-ivb-3770
Missing
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired
== Series Details == Series: drm/i915/userptr: Don't activate MMU notifier if no pages can be acquired URL : https://patchwork.freedesktop.org/series/73641/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16620_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16620_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +10 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +9 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +22 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-iclb6/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb3/igt@gem_exec_sched...@reorder-wide-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-iclb1/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_partial_pwrite_pread@write-snoop: - shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw6/igt@gem_partial_pwrite_pr...@write-snoop.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-hsw8/igt@gem_partial_pwrite_pr...@write-snoop.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#644]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb7/igt@gem_pp...@flink-and-close-vma-leak.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-tglb8/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#69]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl2/igt@gem_soft...@noreloc-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-skl2/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#413]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@i915_pm_...@waitboost.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-iclb5/igt@i915_pm_...@waitboost.html * igt@i915_selftest@live_gt_lrc: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#1233]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@live_gt_lrc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-tglb5/igt@i915_selftest@live_gt_lrc.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl7/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#79]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@kms_f...@flip-vs-expired-vblank.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16620/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@plain-flip-fb-recreate: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#34]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl6/igt@kms_f...@plain-flip-fb-recreate.html [26]:
Re: [Intel-gfx] [PATCH] drm/i915/huc: Fix error reported by I915_PARAM_HUC_STATUS
On 2/12/2020 5:54 AM, Fosha, Robert M wrote:
On 2/11/20 11:57 AM, Michal Wajdeczko wrote:
On Tue, 11 Feb 2020 18:53:05 +0100, Fosha, Robert M
wrote:
On 2/4/20 4:43 PM, Ye, Tony wrote:
On 1/27/2020 1:41 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-23 15:38:52)
On Thu, 23 Jan 2020 16:02:17 +0100, Chris Wilson
wrote:
> Quoting Daniele Ceraolo Spurio (2020-01-22 23:52:33)
>>
>>
>> On 1/22/20 11:48 AM, Michal Wajdeczko wrote:
>> > From commit 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt
over i915
>> > in GuC/HuC paths") we stopped using HUC_STATUS error -ENODEV
only
>> > to indicate lack of HuC hardware and we started to use this
error
>> > also for all other cases when HuC was not in use or supported.
>> >
>> > Fix that by relying again on HAS_GT_UC macro, since currently
>> > used function intel_huc_is_supported() is based on HuC firmware
>> > support which could be unsupported also due to force disabled
>> > GuC firmware.
>> >
>> > Signed-off-by: Michal Wajdeczko
>> > Cc: Daniele Ceraolo Spurio
>> > Cc: Michal Wajdeczko
>> > Cc: Tony Ye
>>
>> Reviewed-by: Daniele Ceraolo Spurio
>
> Once upon a time did you (Michal) not argue we should indicate
the lack
> of firmware in the error code? Something like
>
> if (!HAS_GT_UC(gt->i915))
> return -ENODEV;
>
> if (!intel_huc_is_supported(huc))
> return -ENOEXEC;
Yes, we discussed this here [1] together with [2] but we didn't
conclude our discussion due to different opinions on how represent
some states, in particular "manually disabled" state.
In this patch I just wanted to restore old notation.
But we can start new discussion, here is summary:
--+--+--+--
HuC state | today* | option A | option B
--+--+--+--
no HuC hardware | -ENODEV | -ENODEV | -ENODEV
GuC fw disabled | 0 | 0 | -EOPNOTSUPP
HuC fw disabled | 0 | 0 | -EOPNOTSUPP
HuC fw missing | 0 | -ENOPKG | -ENOEXEC
HuC fw error | 0 | -ENOEXEC | -ENOEXEC
HuC fw fail | 0 | -EACCES | 0
HuC authenticated | 1 | 1 | 1
--+--+--+--
By fw fail, you mean we loaded the firmware (to our knowledge)
correctly, but HUC_STATUS is not reported as valid?
If so, I support option B. I like the idea of saying
"no HuC" (machine too old)
"no firmware" (user action, or lack thereof)
0 (fw unhappy)
1 (fw reports success)
In between states for failures in fw loading? Not so sure. But I
can see
the nicety in distinguishing between lack of firmware and some random
failure in loading the firmware (the former being user action
required
to rectify, command line parameter whatever and the latter being the
firmware file is either invalid or a stray neutrino prevented
loading).
Imo the error messages should be about why we cannot probe/trust the
HUC_STATUS register. If everything is setup correctly then the
returned
value should be from reading the register. I dislike only
returning 1 if
supported, and converting a valid read of 0 into another error.
So Option B :)
But I'm not sure that option B is consistent in error reporting, as
"fw unhappy" is definitely an serious error but is represented as
plain
non-error "0" status, while "fw disabled" (user action) is treated
as error
--+--
HuC state | option B
--+--
no HuC hardware | -ENODEV
GuC fw disabled | -EOPNOTSUPP -> user decision, why error?
HuC fw disabled | -EOPNOTSUPP -> user decision, why error?
HuC fw missing | -ENOEXEC
HuC fw error | -ENOEXEC
HuC fw fail | 0 -> unlikely, but still fw/hw error
HuC authenticated | 1
--+--
On other hand, option A treats all error conditions as errors, leaving
status codes only for normal operations: disabled(0)/authenticated(1):
--+--
HuC state | option A
--+--
no HuC hardware | -ENODEV -> you shouldn't ask
GuC fw disabled | 0 -> user decision, not an error
HuC fw disabled | 0 -> user decision, not an error
HuC fw missing | -ENOPKG -> fw not installed correctly
HuC fw error | -ENOEXEC -> bad/wrong fw
HuC fw fail | -EACCES -> fw/hw error
HuC authenticated | 1
--+--
Vote for Option A.
Regards,
Tony
Are we ok to move forward on this? Michal, are you working on
updating the patch?
I can update the patch, but I don't know which option to implement:
Tony votes for Option A, Chris for Option B, what's your choice?
Michal
I don't have a preference and would trust both Tony and Chris over
myself. However, if Tony is using HuC more I would vote for his prefered
option.
-Rob
Option B takes enable_guc=0|1 (user doesn't want to load HuC FW) as
error, and
[Intel-gfx] [PATCH v2] drm/i915/lspcon: Make sure link rate did not exceed downstream and lspcon limitation
While mode setting, driver would calculate mode rate based on
resolution and bpp. And choose the best bpp that did not exceed
DP bandwidtd.
But LSPCON had more restriction due to it convert DP to HDMI.
Driver should respect HDMI's bandwidth limitation if LSPCON
was active. This change would ignore the bpp when its required
output bandwidth already over HDMI 2.0 or 1.4 spec.
v2: convert info->max_tmds_clock to byte clock for comparison.
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Jani Nikula
Cc: Cooper Chiou
Cc: Sam McNally
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
drivers/gpu/drm/i915/display/intel_lspcon.c | 10 ++
drivers/gpu/drm/i915/display/intel_lspcon.h | 1 +
3 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6ea0cb8e85e1..3a352847aff4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1993,6 +1993,9 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
const struct link_config_limits *limits)
{
struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
+ struct intel_connector *connector = intel_dp->attached_connector;
+ const struct drm_display_info *info = >base.display_info;
+ struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
int bpp, clock, lane_count;
int mode_rate, link_clock, link_avail;
@@ -2002,6 +2005,21 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
output_bpp);
+ /*
+* Bypass this mode if require bandwidth over downstream
+* limitation or HDMI spec when LSPCON active.
+*/
+ if (lspcon->active) {
+ int max_clock_rate = lspcon_max_rate(lspcon);
+
+ if (info->max_tmds_clock)
+ max_clock_rate = min(max_clock_rate,
+
DIV_ROUND_UP(info->max_tmds_clock * 24, 8));
+
+ if (mode_rate > max_clock_rate)
+ continue;
+ }
+
for (clock = limits->min_clock; clock <= limits->max_clock;
clock++) {
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count;
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_lspcon.c
index d807c5648c87..3b0438356a88 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
@@ -518,6 +518,16 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
buf, ret);
}
+int lspcon_max_rate(struct intel_lspcon *lspcon)
+{
+ enum drm_lspcon_mode current_mode = lspcon_get_current_mode(lspcon);
+
+ if (current_mode == DRM_LSPCON_MODE_LS)
+ return DIV_ROUND_UP(34 * 24, 8);
+
+ return DIV_ROUND_UP(60 * 24, 8);
+}
+
u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
b/drivers/gpu/drm/i915/display/intel_lspcon.h
index 37cfddf8a9c5..b584c02ab33b 100644
--- a/drivers/gpu/drm/i915/display/intel_lspcon.h
+++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
@@ -18,6 +18,7 @@ struct intel_lspcon;
bool lspcon_init(struct intel_digital_port *intel_dig_port);
void lspcon_resume(struct intel_lspcon *lspcon);
void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
+int lspcon_max_rate(struct intel_lspcon *lspcon);
void lspcon_write_infoframe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 5.6-rc2
We have a fix for this issue, still going through review. https://gitlab.freedesktop.org/drm/intel/issues/1151 On Fri, 2020-02-21 at 11:38 +1000, Dave Airlie wrote: > looping in intel-gfx + Jani. > > On Tue, 18 Feb 2020 at 05:20, sinisa wrote: > > > > On 2020-02-16 22:32, Linus Torvalds wrote: > > > ... > > > Chris Wilson (19): > > > drm/i915/pmu: Correct the rc6 offset upon enabling > > > drm/i915/gem: Take local vma references for the parser > > > drm/i915/selftests: Add a mock i915_vma to the mock_ring > > > drm/i915/gt: Use the BIT when checking the flags, not the > > index > > > drm/i915/execlists: Leave resetting ring to intel_ring > > > drm/i915/gem: Store mmap_offsets in an rbtree rather than > > a > > plain list > > > drm/i915: Don't show the blank process name for > > internal/simulated errors > > > drm/i915/gem: Detect overflow in calculating dumb buffer > > size > > > drm/i915: Check activity on i915_vma after confirming > > pin_count==0 > > > drm/i915: Stub out i915_gpu_coredump_put > > > drm/i915: Tighten atomicity of i915_active_acquire vs > > i915_active_release > > > drm/i915/gt: Acquire ce->active before ce->pin_count/ce- > > >pin_mutex > > > drm/i915/gem: Tighten checks and acquiring the mmap object > > > drm/i915: Keep track of request among the scheduling lists > > > drm/i915/gt: Allow temporary suspension of inflight > > requests > > > drm/i915/execlists: Offline error capture > > > drm/i915/execlists: Take a reference while capturing the > > guilty > > request > > > drm/i915/execlists: Reclaim the hanging virtual request > > > drm/i915: Mark the removal of the i915_request from the > > sched.link > > > ... > > > > Something from here makes my Toshiba Portege Z30-A (CPU is i5-4210U > > with > > integrated graphics) to to only get black screen when loading i915 > > driver. > > > > Happens the same in rc1 and rc2, works OK with all previous > > kernels. > > > > > > Here is relevant part of the dmesg output: > > > > > > [4.643848] i915 :00:02.0: vgaarb: deactivate vga console > > [4.645363] Console: switching to colour dummy device 80x25 > > [4.667372] [drm] Supports vblank timestamp caching Rev 2 > > (21.10.2013). > > [4.667379] [drm] Driver supports precise vblank timestamp > > query. > > [4.667743] i915 :00:02.0: vgaarb: changed VGA decodes: > > olddecodes=io+mem,decodes=io+mem:owns=io+mem > > [4.682355] [ cut here ] > > [4.682389] WARNING: CPU: 3 PID: 459 at > > drivers/gpu/drm/drm_atomic.c:296 > > drm_atomic_get_crtc_state+0xf8/0x110 [drm] > > [4.682394] Modules linked in: iTCO_wdt iTCO_vendor_support > > nls_iso8859_1 snd_hda_codec_realtek i915(+) fuse nls_cp437 > > snd_hda_codec_generic vfat fat iwlwifi uvcvideo ledtrig_audio > > aesni_intel(+) drm_kms_helper videobuf2_vmalloc crypto_simd > > snd_hda_intel videobuf2_memops cec snd_intel_dspcfg rc_core > > videobuf2_v4l2 cryptd snd_hda_codec glue_helper videobuf2_common > > cfg80211 drm pcspkr videodev snd_hda_core wmi_bmof snd_hwdep > > snd_pcm > > toshiba_acpi mc e1000e snd_timer sparse_keymap fb_sys_fops > > syscopyarea > > sysfillrect industrialio lpc_ich snd sysimgblt i2c_algo_bit > > toshiba_bluetooth soundcore thermal rfkill intel_smartconnect ac > > button > > xfs libcrc32c xhci_pci xhci_hcd rtsx_pci_sdmmc mmc_core ehci_pci > > ehci_hcd usbcore crc32c_intel rtsx_pci serio_raw battery wmi video > > l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppox sg > > ppp_mppe ppp_generic slhc libarc4 dm_multipath dm_mod scsi_dh_rdac > > scsi_dh_emc scsi_dh_alua > > [4.682455] CPU: 3 PID: 459 Comm: systemd-udevd Not tainted > > 5.6.0-rc2-1.g327abc9-default #1 openSUSE Tumbleweed (unreleased) > > [4.682460] Hardware name: TOSHIBA PORTEGE Z30-A/PORTEGE Z30-A, > > BIOS > > Version 4.30 04/26/2018 > > [4.682486] RIP: 0010:drm_atomic_get_crtc_state+0xf8/0x110 [drm] > > [4.682490] Code: 89 2c 11 48 89 98 f0 01 00 00 48 8b 4d 20 8b > > 55 60 > > e8 2c aa 00 00 48 8b 04 24 48 83 c4 08 5b 5d 41 5c c3 48 98 e9 4e > > ff ff > > ff <0f> 0b e9 28 ff ff ff 48 c7 c0 f4 ff ff ff e9 3b ff ff ff 0f 1f > > 44 > > [4.682497] RSP: :aa5bc04338a8 EFLAGS: 00010246 > > [4.682500] RAX: RBX: 9c97862c1000 RCX: > > 9c979101ed08 > > [4.682504] RDX: 002d RSI: RDI: > > 9c97862c1000 > > [4.682507] RBP: 9c97862c7800 R08: 0079 R09: > > 0079 > > [4.682510] R10: 002d R11: 0005 R12: > > > > [4.682513] R13: 9c97862c7800 R14: 9c97862c0800 R15: > > c0ee0f80 > > [4.682517] FS: 7f65d2c92dc0() > > GS:9c9792ec() > > knlGS: > > [4.682521] CS: 0010 DS: ES: CR0: 80050033 > > [4.682524] CR2: 7f016d25b610
Re: [Intel-gfx] Linux 5.6-rc2
looping in intel-gfx + Jani. On Tue, 18 Feb 2020 at 05:20, sinisa wrote: > > > On 2020-02-16 22:32, Linus Torvalds wrote: > > ... > > Chris Wilson (19): > > drm/i915/pmu: Correct the rc6 offset upon enabling > > drm/i915/gem: Take local vma references for the parser > > drm/i915/selftests: Add a mock i915_vma to the mock_ring > > drm/i915/gt: Use the BIT when checking the flags, not the index > > drm/i915/execlists: Leave resetting ring to intel_ring > > drm/i915/gem: Store mmap_offsets in an rbtree rather than a > plain list > > drm/i915: Don't show the blank process name for > internal/simulated errors > > drm/i915/gem: Detect overflow in calculating dumb buffer size > > drm/i915: Check activity on i915_vma after confirming pin_count==0 > > drm/i915: Stub out i915_gpu_coredump_put > > drm/i915: Tighten atomicity of i915_active_acquire vs > i915_active_release > > drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex > > drm/i915/gem: Tighten checks and acquiring the mmap object > > drm/i915: Keep track of request among the scheduling lists > > drm/i915/gt: Allow temporary suspension of inflight requests > > drm/i915/execlists: Offline error capture > > drm/i915/execlists: Take a reference while capturing the guilty > request > > drm/i915/execlists: Reclaim the hanging virtual request > > drm/i915: Mark the removal of the i915_request from the sched.link > > ... > > Something from here makes my Toshiba Portege Z30-A (CPU is i5-4210U with > integrated graphics) to to only get black screen when loading i915 driver. > > Happens the same in rc1 and rc2, works OK with all previous kernels. > > > Here is relevant part of the dmesg output: > > > [4.643848] i915 :00:02.0: vgaarb: deactivate vga console > [4.645363] Console: switching to colour dummy device 80x25 > [4.667372] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [4.667379] [drm] Driver supports precise vblank timestamp query. > [4.667743] i915 :00:02.0: vgaarb: changed VGA decodes: > olddecodes=io+mem,decodes=io+mem:owns=io+mem > [4.682355] [ cut here ] > [4.682389] WARNING: CPU: 3 PID: 459 at > drivers/gpu/drm/drm_atomic.c:296 drm_atomic_get_crtc_state+0xf8/0x110 [drm] > [4.682394] Modules linked in: iTCO_wdt iTCO_vendor_support > nls_iso8859_1 snd_hda_codec_realtek i915(+) fuse nls_cp437 > snd_hda_codec_generic vfat fat iwlwifi uvcvideo ledtrig_audio > aesni_intel(+) drm_kms_helper videobuf2_vmalloc crypto_simd > snd_hda_intel videobuf2_memops cec snd_intel_dspcfg rc_core > videobuf2_v4l2 cryptd snd_hda_codec glue_helper videobuf2_common > cfg80211 drm pcspkr videodev snd_hda_core wmi_bmof snd_hwdep snd_pcm > toshiba_acpi mc e1000e snd_timer sparse_keymap fb_sys_fops syscopyarea > sysfillrect industrialio lpc_ich snd sysimgblt i2c_algo_bit > toshiba_bluetooth soundcore thermal rfkill intel_smartconnect ac button > xfs libcrc32c xhci_pci xhci_hcd rtsx_pci_sdmmc mmc_core ehci_pci > ehci_hcd usbcore crc32c_intel rtsx_pci serio_raw battery wmi video > l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppox sg > ppp_mppe ppp_generic slhc libarc4 dm_multipath dm_mod scsi_dh_rdac > scsi_dh_emc scsi_dh_alua > [4.682455] CPU: 3 PID: 459 Comm: systemd-udevd Not tainted > 5.6.0-rc2-1.g327abc9-default #1 openSUSE Tumbleweed (unreleased) > [4.682460] Hardware name: TOSHIBA PORTEGE Z30-A/PORTEGE Z30-A, BIOS > Version 4.30 04/26/2018 > [4.682486] RIP: 0010:drm_atomic_get_crtc_state+0xf8/0x110 [drm] > [4.682490] Code: 89 2c 11 48 89 98 f0 01 00 00 48 8b 4d 20 8b 55 60 > e8 2c aa 00 00 48 8b 04 24 48 83 c4 08 5b 5d 41 5c c3 48 98 e9 4e ff ff > ff <0f> 0b e9 28 ff ff ff 48 c7 c0 f4 ff ff ff e9 3b ff ff ff 0f 1f 44 > [4.682497] RSP: :aa5bc04338a8 EFLAGS: 00010246 > [4.682500] RAX: RBX: 9c97862c1000 RCX: > 9c979101ed08 > [4.682504] RDX: 002d RSI: RDI: > 9c97862c1000 > [4.682507] RBP: 9c97862c7800 R08: 0079 R09: > 0079 > [4.682510] R10: 002d R11: 0005 R12: > > [4.682513] R13: 9c97862c7800 R14: 9c97862c0800 R15: > c0ee0f80 > [4.682517] FS: 7f65d2c92dc0() GS:9c9792ec() > knlGS: > [4.682521] CS: 0010 DS: ES: CR0: 80050033 > [4.682524] CR2: 7f016d25b610 CR3: 00030f634004 CR4: > 001606e0 > [4.682527] Call Trace: > [4.682551] drm_atomic_add_affected_connectors+0x2e/0x110 [drm] > [4.682569] drm_atomic_helper_check_modeset+0x492/0x770 [drm_kms_helper] > [4.682641] intel_atomic_check+0x93/0xcc0 [i915] > [4.682657] ? drm_atomic_helper_duplicate_state+0x148/0x170 > [drm_kms_helper] > [4.682723] intel_modeset_init+0xe55/0x1180 [i915] > [4.682777]
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm_device managed resources
== Series Details == Series: drm_device managed resources URL : https://patchwork.freedesktop.org/series/73633/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16618_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16618_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16618_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_16618_full: ### IGT changes ### Possible regressions * igt@gem_ctx_param@basic-default: - shard-hsw: [PASS][1] -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw6/igt@gem_ctx_pa...@basic-default.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-hsw2/igt@gem_ctx_pa...@basic-default.html - shard-snb: [PASS][3] -> [FAIL][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb5/igt@gem_ctx_pa...@basic-default.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-snb1/igt@gem_ctx_pa...@basic-default.html - shard-tglb: [PASS][5] -> [FAIL][6] +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb6/igt@gem_ctx_pa...@basic-default.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-tglb5/igt@gem_ctx_pa...@basic-default.html * igt@gem_ctx_param@root-set-no-zeromap-enabled: - shard-glk: [PASS][7] -> [FAIL][8] +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk7/igt@gem_ctx_pa...@root-set-no-zeromap-enabled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-glk7/igt@gem_ctx_pa...@root-set-no-zeromap-enabled.html - shard-iclb: [PASS][9] -> [FAIL][10] +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_ctx_pa...@root-set-no-zeromap-enabled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-iclb5/igt@gem_ctx_pa...@root-set-no-zeromap-enabled.html - shard-apl: [PASS][11] -> [FAIL][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl6/igt@gem_ctx_pa...@root-set-no-zeromap-enabled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-apl7/igt@gem_ctx_pa...@root-set-no-zeromap-enabled.html * igt@gem_render_copy@yf-tiled-ccs-to-y-tiled: - shard-kbl: [PASS][13] -> [FAIL][14] +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl4/igt@gem_render_c...@yf-tiled-ccs-to-y-tiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-kbl2/igt@gem_render_c...@yf-tiled-ccs-to-y-tiled.html - shard-skl: [PASS][15] -> [FAIL][16] +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@gem_render_c...@yf-tiled-ccs-to-y-tiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-skl10/igt@gem_render_c...@yf-tiled-ccs-to-y-tiled.html * igt@i915_selftest@mock_timelines: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@i915_selftest@mock_timelines.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-iclb4/igt@i915_selftest@mock_timelines.html - shard-skl: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl7/igt@i915_selftest@mock_timelines.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-skl3/igt@i915_selftest@mock_timelines.html - shard-tglb: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@mock_timelines.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-tglb2/igt@i915_selftest@mock_timelines.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-ytiled: - shard-tglb: [PASS][23] -> [SKIP][24] +16 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_draw_...@draw-method-xrgb2101010-render-ytiled.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16618/shard-tglb2/igt@kms_draw_...@draw-method-xrgb2101010-render-ytiled.html * igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb: - shard-iclb: [PASS][25] -> [SKIP][26] +17 similar issues [25]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Distribute switch variables for initialization (rev2)
== Series Details ==
Series: drm/i915: Distribute switch variables for initialization (rev2)
URL : https://patchwork.freedesktop.org/series/73690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7977 -> Patchwork_16651
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/index.html
Known issues
Here are the changes found in Patchwork_16651 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [PASS][1] -> [FAIL][2] ([CI#94])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_gtt:
- fi-tgl-y: [PASS][3] -> [TIMEOUT][4] ([CI#94] / [fdo#112126] /
[fdo#112271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@i915_selftest@live_gtt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/fi-tgl-y/igt@i915_selftest@live_gtt.html
* igt@prime_vgem@basic-gtt:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([CI#94] / [i915#402])
+2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@prime_v...@basic-gtt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/fi-tgl-y/igt@prime_v...@basic-gtt.html
Possible fixes
* igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y: [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8]
+1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
* igt@i915_selftest@live_execlists:
- fi-tgl-y: [INCOMPLETE][9] ([CI#94] / [i915#647]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/fi-tgl-y/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][11] ([i915#877]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- {fi-tgl-dsi}: [TIMEOUT][13] ([fdo#112126] / [fdo#112271]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-dsi/igt@i915_selftest@live_gtt.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/fi-tgl-dsi/igt@i915_selftest@live_gtt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#112126]: https://bugs.freedesktop.org/show_bug.cgi?id=112126
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#647]: https://gitlab.freedesktop.org/drm/intel/issues/647
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 42)
--
Additional (2): fi-hsw-peppy fi-cfl-8109u
Missing(9): fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bsw-kefka fi-bdw-samus fi-byt-clapper fi-skl-6600u
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7977 -> Patchwork_16651
CI-20190529: 20190529
CI_DRM_7977: 055793baa45ba27e36b40f1299cfaa19388b592d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16651: 514832edec7b53f1e100f802ae193102c63f22c9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
514832edec7b drm/i915: Distribute switch variables for initialization
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16651/index.html
___
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/tgl: Allow DC5/DC6 entry while PG2 is active
== Series Details ==
Series: drm/i915/tgl: Allow DC5/DC6 entry while PG2 is active
URL : https://patchwork.freedesktop.org/series/73739/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7977 -> Patchwork_16650
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16650:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_active:
- {fi-tgl-dsi}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-dsi/igt@i915_selftest@live_active.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-tgl-dsi/igt@i915_selftest@live_active.html
Known issues
Here are the changes found in Patchwork_16650 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([CI#80] / [fdo#106070]
/ [i915#424])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: [PASS][5] -> [FAIL][6] ([i915#217])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-edid-read:
- fi-icl-u2: [PASS][7] -> [FAIL][8] ([fdo#109635] / [i915#217])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([CI#94] / [i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-tgl-y: [INCOMPLETE][11] ([CI#94] / [i915#647]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@i915_selftest@live_execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-tgl-y/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][13] ([i915#877]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- {fi-tgl-dsi}: [TIMEOUT][15] ([fdo#112126] / [fdo#112271]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-dsi/igt@i915_selftest@live_gtt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-tgl-dsi/igt@i915_selftest@live_gtt.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [DMESG-WARN][17] ([CI#94] / [i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16650/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#112126]: https://bugs.freedesktop.org/show_bug.cgi?id=112126
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#647]: https://gitlab.freedesktop.org/drm/intel/issues/647
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 41)
--
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Force PSR probe only after full initialization (rev6)
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev6)
URL : https://patchwork.freedesktop.org/series/73436/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7977 -> Patchwork_16649
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16649 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16649, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16649:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_uncore:
- fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-bwr-2160/igt@i915_selftest@live_uncore.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-bwr-2160/igt@i915_selftest@live_uncore.html
Known issues
Here are the changes found in Patchwork_16649 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-hsw-4770r: [PASS][3] -> [TIMEOUT][4] ([fdo#112271] / [i915#1084])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-hsw-4770r/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-hsw-4770r/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [PASS][5] -> [FAIL][6] ([CI#94])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_gtt:
- fi-kbl-7500u: [PASS][7] -> [TIMEOUT][8] ([fdo#112271])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([CI#94] / [i915#402])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-tgl-y: [INCOMPLETE][11] ([CI#94] / [i915#647]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@i915_selftest@live_execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-tgl-y/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][13] ([i915#877]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- {fi-tgl-dsi}: [TIMEOUT][15] ([fdo#112126] / [fdo#112271]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-dsi/igt@i915_selftest@live_gtt.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-tgl-dsi/igt@i915_selftest@live_gtt.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [DMESG-WARN][17] ([CI#94] / [i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7977/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16649/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#112126]: https://bugs.freedesktop.org/show_bug.cgi?id=112126
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#647]: https://gitlab.freedesktop.org/drm/intel/issues/647
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 45)
--
Additional (3): fi-hsw-peppy fi-byt-n2820 fi-cfl-8109u
Missing(7): fi-ehl-1 fi-hsw-4200u fi-byt-squawks
[Intel-gfx] [PATCH v2] drm/i915: Distribute switch variables for initialization
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.
To avoid these problems, move such variables into the "case" where
they're used or lift them up into the main function body.
drivers/gpu/drm/i915/display/intel_display.c: In function
‘check_digital_port_conflicts’:
drivers/gpu/drm/i915/display/intel_display.c:12963:17: warning: statement will
never be executed [-Wswitch-unreachable]
12963 |unsigned int port_mask;
| ^
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_get_fifo_size’:
drivers/gpu/drm/i915/intel_pm.c:474:7: warning: statement will never be
executed [-Wswitch-unreachable]
474 | u32 dsparb, dsparb2, dsparb3;
| ^~
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_atomic_update_fifo’:
drivers/gpu/drm/i915/intel_pm.c:1997:7: warning: statement will never be
executed [-Wswitch-unreachable]
1997 | u32 dsparb, dsparb2, dsparb3;
| ^~
[1] https://bugs.llvm.org/show_bug.cgi?id=44916
Signed-off-by: Kees Cook
---
v2: remove port_mask entirely (Ville Syrjälä)
v1: https://lore.kernel.org/lkml/20200220062258.68854-1-keesc...@chromium.org
---
drivers/gpu/drm/i915/display/intel_display.c | 7 ++-
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 064dd99bbc49..5f8c61932e82 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12960,7 +12960,6 @@ static bool check_digital_port_conflicts(struct
intel_atomic_state *state)
WARN_ON(!connector_state->crtc);
switch (encoder->type) {
- unsigned int port_mask;
case INTEL_OUTPUT_DDI:
if (WARN_ON(!HAS_DDI(to_i915(dev
break;
@@ -12968,13 +12967,11 @@ static bool check_digital_port_conflicts(struct
intel_atomic_state *state)
case INTEL_OUTPUT_DP:
case INTEL_OUTPUT_HDMI:
case INTEL_OUTPUT_EDP:
- port_mask = 1 << encoder->port;
-
/* the same port mustn't appear more than once */
- if (used_ports & port_mask)
+ if (used_ports & BIT(encoder->port))
ret = false;
- used_ports |= port_mask;
+ used_ports |= BIT(encoder->port);
break;
case INTEL_OUTPUT_DP_MST:
used_mst_ports |=
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bd2d30ecc030..17d8833787c4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -469,9 +469,9 @@ static void vlv_get_fifo_size(struct intel_crtc_state
*crtc_state)
struct vlv_fifo_state *fifo_state = _state->wm.vlv.fifo_state;
enum pipe pipe = crtc->pipe;
int sprite0_start, sprite1_start;
+ u32 dsparb, dsparb2, dsparb3;
switch (pipe) {
- u32 dsparb, dsparb2, dsparb3;
case PIPE_A:
dsparb = I915_READ(DSPARB);
dsparb2 = I915_READ(DSPARB2);
@@ -1969,6 +1969,7 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
const struct vlv_fifo_state *fifo_state =
_state->wm.vlv.fifo_state;
int sprite0_start, sprite1_start, fifo_size;
+ u32 dsparb, dsparb2, dsparb3;
if (!crtc_state->fifo_changed)
return;
@@ -1994,7 +1995,6 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
spin_lock(>lock);
switch (crtc->pipe) {
- u32 dsparb, dsparb2, dsparb3;
case PIPE_A:
dsparb = intel_uncore_read_fw(uncore, DSPARB);
dsparb2 = intel_uncore_read_fw(uncore, DSPARB2);
--
2.20.1
--
Kees Cook
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: conversion to struct drm_device based logging macros. (rev2)
== Series Details == Series: drm/i915/perf: conversion to struct drm_device based logging macros. (rev2) URL : https://patchwork.freedesktop.org/series/73589/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16617_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16617_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +11 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-iclb6/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_partial_pwrite_pread@reads: - shard-hsw: [PASS][9] -> [FAIL][10] ([i915#694]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@gem_partial_pwrite_pr...@reads.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-hsw8/igt@gem_partial_pwrite_pr...@reads.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#454]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@i915_pm...@dc6-psr.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl4/igt@i915_susp...@debugfs-reader.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-apl6/igt@i915_susp...@debugfs-reader.html * igt@kms_flip@flip-vs-absolute-wf_vblank: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#488]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-tglb8/igt@kms_flip@flip-vs-absolute-wf_vblank.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-iclb8/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-kbl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([i915#69]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl5/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16617/shard-skl5/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109276]) +22 similar issues [25]:
Re: [Intel-gfx] [PATCH] drm/i915: Distribute switch variables for initialization
On Thu, Feb 20, 2020 at 12:21:14PM +0200, Jani Nikula wrote:
> On Wed, 19 Feb 2020, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be automatically initialized with compiler instrumentation (as
> > they are not part of any execution flow). With GCC's proposed automatic
> > stack variable initialization feature, this triggers a warning (and they
> > don't get initialized). Clang's automatic stack variable initialization
> > (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> > doesn't initialize such variables[1]. Note that these warnings (or silent
> > skipping) happen before the dead-store elimination optimization phase,
> > so even when the automatic initializations are later elided in favor of
> > direct initializations, the warnings remain.
> >
> > To avoid these problems, move such variables into the "case" where
> > they're used or lift them up into the main function body.
> >
> > drivers/gpu/drm/i915/display/intel_display.c: In function
> > ‘check_digital_port_conflicts’:
> > drivers/gpu/drm/i915/display/intel_display.c:12963:17: warning: statement
> > will never be executed [-Wswitch-unreachable]
> > 12963 |unsigned int port_mask;
> > | ^
> >
> > drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_get_fifo_size’:
> > drivers/gpu/drm/i915/intel_pm.c:474:7: warning: statement will never be
> > executed [-Wswitch-unreachable]
> > 474 | u32 dsparb, dsparb2, dsparb3;
> > | ^~
> > drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_atomic_update_fifo’:
> > drivers/gpu/drm/i915/intel_pm.c:1997:7: warning: statement will never be
> > executed [-Wswitch-unreachable]
> > 1997 | u32 dsparb, dsparb2, dsparb3;
> > | ^~
> >
> > [1] https://bugs.llvm.org/show_bug.cgi?id=44916
> >
> > Signed-off-by: Kees Cook
>
> Reviewed-by: Jani Nikula
Thanks!
>
> If you look at i915/Makefile, you'll see that we don't shy away from
> enabling lots of extra warnings, and we run our CI with -Werror to keep
> it clean. It does not seem like -Wswitch-unreachable does me any good,
> though... is it new?
It's already enabled by default, but the GCC feature that tweaks it
doesn't exist yet. But it points out a problem that exists for Clang
today, but Clang doesn't actually warn on (yet). So this is a fix to
avoid the silent Clang problem and fix future warnings before they
happen.
-Kees
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c |6 --
> > drivers/gpu/drm/i915/intel_pm.c |4 ++--
> > 2 files changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 064dd99bbc49..c829cd26f99e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -12960,14 +12960,15 @@ static bool check_digital_port_conflicts(struct
> > intel_atomic_state *state)
> > WARN_ON(!connector_state->crtc);
> >
> > switch (encoder->type) {
> > - unsigned int port_mask;
> > case INTEL_OUTPUT_DDI:
> > if (WARN_ON(!HAS_DDI(to_i915(dev
> > break;
> > /* else, fall through */
> > case INTEL_OUTPUT_DP:
> > case INTEL_OUTPUT_HDMI:
> > - case INTEL_OUTPUT_EDP:
> > + case INTEL_OUTPUT_EDP: {
> > + unsigned int port_mask;
> > +
> > port_mask = 1 << encoder->port;
> >
> > /* the same port mustn't appear more than once */
> > @@ -12976,6 +12977,7 @@ static bool check_digital_port_conflicts(struct
> > intel_atomic_state *state)
> >
> > used_ports |= port_mask;
> > break;
> > + }
> > case INTEL_OUTPUT_DP_MST:
> > used_mst_ports |=
> > 1 << encoder->port;
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index bd2d30ecc030..17d8833787c4 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -469,9 +469,9 @@ static void vlv_get_fifo_size(struct intel_crtc_state
> > *crtc_state)
> > struct vlv_fifo_state *fifo_state = _state->wm.vlv.fifo_state;
> > enum pipe pipe = crtc->pipe;
> > int sprite0_start, sprite1_start;
> > + u32 dsparb, dsparb2, dsparb3;
> >
> > switch (pipe) {
> > - u32 dsparb, dsparb2, dsparb3;
> > case PIPE_A:
> > dsparb = I915_READ(DSPARB);
> > dsparb2 = I915_READ(DSPARB2);
> > @@ -1969,6 +1969,7 @@ static void vlv_atomic_update_fifo(struct
> > intel_atomic_state *state,
> > const struct vlv_fifo_state *fifo_state =
> > _state->wm.vlv.fifo_state;
> > int sprite0_start, sprite1_start,
[Intel-gfx] [PATCH] drm/i915/tgl: Allow DC5/DC6 entry while PG2 is active
On gen12, we no longer need to disable DC5/DC6 when when PG2 is in use
(which translates to cases where we're using VDSC on pipe A).
Bspec: 49193
Cc: Lucas De Marchi
Cc: José Roberto de Souza
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_display_power.c | 16 +++-
.../gpu/drm/i915/display/intel_display_power.h | 1 +
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 8ba68ec6dc24..1d21a850e933 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -926,10 +926,16 @@ void intel_display_power_set_target_dc_state(struct
drm_i915_private *dev_priv,
static void assert_can_enable_dc5(struct drm_i915_private *dev_priv)
{
- bool pg2_enabled = intel_display_power_well_is_enabled(dev_priv,
- SKL_DISP_PW_2);
+ enum i915_power_well_id high_pg;
- WARN_ONCE(pg2_enabled, "PG2 not disabled to enable DC5.\n");
+ /* Power wells at this level and above must be disabled for DC5 entry */
+ if (INTEL_GEN(dev_priv) >= 12)
+ high_pg = TGL_DISP_PW_3;
+ else
+ high_pg = SKL_DISP_PW_2;
+
+ WARN_ONCE(intel_display_power_well_is_enabled(dev_priv, high_pg),
+ "Power wells above platform's DC5 limit still enabled.\n");
WARN_ONCE((intel_de_read(dev_priv, DC_STATE_EN) & DC_STATE_EN_UPTO_DC5),
"DC5 already programmed to be enabled.\n");
@@ -2712,7 +2718,7 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_INIT))
#define TGL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
- TGL_PW_2_POWER_DOMAINS |\
+ TGL_PW_3_POWER_DOMAINS |\
BIT_ULL(POWER_DOMAIN_MODESET) | \
BIT_ULL(POWER_DOMAIN_AUX_A) | \
BIT_ULL(POWER_DOMAIN_AUX_B) | \
@@ -3908,7 +3914,7 @@ static const struct i915_power_well_desc
tgl_power_wells[] = {
.name = "power well 3",
.domains = TGL_PW_3_POWER_DOMAINS,
.ops = _power_well_ops,
- .id = DISP_PW_ID_NONE,
+ .id = TGL_DISP_PW_3,
{
.hsw.regs = _power_well_regs,
.hsw.idx = ICL_PW_CTL_IDX_PW_3,
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 601e000ffd0d..da64a5edae7a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -100,6 +100,7 @@ enum i915_power_well_id {
SKL_DISP_PW_MISC_IO,
SKL_DISP_PW_1,
SKL_DISP_PW_2,
+ TGL_DISP_PW_3,
SKL_DISP_DC_OFF,
};
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/psr: Force PSR probe only after full initialization
Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
once to enable PSR") was forcing the state compute too earlier
causing errors because not everything was initialized, so here
moving to the end of i915_driver_modeset_probe() when the display is
all initialized.
Also fixing the place where it disarm the force probe as during the
atomic check phase errors could happen like the ones due locking and
it would cause PSR to never be enabled if that happens.
Leaving the disarm to the atomic commit phase, intel_psr_enable() or
intel_psr_update() will be called even if the current state do not
allow PSR to be enabled.
v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
v3: Check intel_dp before get dev_priv
v4:
- renamed intel_psr_force_mode_changed_set() to
intel_psr_set_force_mode_changed()
- removed the set parameter from intel_psr_set_force_mode_changed()
- not calling intel_psr_set_force_mode_changed() from
intel_psr_enable/update(), directly setting it after the same checks
that intel_psr_set_force_mode_changed() does
- moved intel_psr_set_force_mode_changed() arm call to
i915_driver_modeset_probe() as it is a better for a PSR call, all the
functions calls happening between the old and the new function call
will cause issue
Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute phase once to
enable PSR")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
Tested-by: Ross Zwisler
Reported-by: Ross Zwisler
Cc: Gwan-gyeong Mun
Cc: Jani Nikula
Cc: Anshuman Gupta
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 25
drivers/gpu/drm/i915/display/intel_psr.h | 1 +
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 2 +-
4 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index b4942b6445ae..7e754201f54d 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -936,10 +936,12 @@ void intel_psr_enable(struct intel_dp *intel_dp,
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- if (!crtc_state->has_psr)
+ if (!CAN_PSR(dev_priv) || dev_priv->psr.dp != intel_dp)
return;
- if (drm_WARN_ON(_priv->drm, !CAN_PSR(dev_priv)))
+ dev_priv->psr.force_mode_changed = false;
+
+ if (!crtc_state->has_psr)
return;
drm_WARN_ON(_priv->drm, dev_priv->drrs.dp);
@@ -1099,6 +1101,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
if (!CAN_PSR(dev_priv) || READ_ONCE(psr->dp) != intel_dp)
return;
+ dev_priv->psr.force_mode_changed = false;
+
mutex_lock(_priv->psr.lock);
enable = crtc_state->has_psr && psr_global_enabled(dev_priv);
@@ -1629,7 +1633,7 @@ void intel_psr_atomic_check(struct drm_connector
*connector,
struct drm_crtc_state *crtc_state;
if (!CAN_PSR(dev_priv) || !new_state->crtc ||
- dev_priv->psr.initially_probed)
+ !dev_priv->psr.force_mode_changed)
return;
intel_connector = to_intel_connector(connector);
@@ -1640,5 +1644,18 @@ void intel_psr_atomic_check(struct drm_connector
*connector,
crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
new_state->crtc);
crtc_state->mode_changed = true;
- dev_priv->psr.initially_probed = true;
+}
+
+void intel_psr_set_force_mode_changed(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv;
+
+ if (!intel_dp)
+ return;
+
+ dev_priv = dp_to_i915(intel_dp);
+ if (!CAN_PSR(dev_priv) || intel_dp != dev_priv->psr.dp)
+ return;
+
+ dev_priv->psr.force_mode_changed = true;
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
b/drivers/gpu/drm/i915/display/intel_psr.h
index c58a1d438808..274fc6bb6221 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.h
+++ b/drivers/gpu/drm/i915/display/intel_psr.h
@@ -40,5 +40,6 @@ bool intel_psr_enabled(struct intel_dp *intel_dp);
void intel_psr_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
+void intel_psr_set_force_mode_changed(struct intel_dp *intel_dp);
#endif /* __INTEL_PSR_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 759d333448e1..066934327345 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -58,6 +58,7 @@
#include "display/intel_hotplug.h"
#include "display/intel_overlay.h"
#include "display/intel_pipe_crc.h"
+#include "display/intel_psr.h"
#include "display/intel_sprite.h"
#include "display/intel_vga.h"
@@ -264,6 +265,8 @@ static int
Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
On 2/20/20 9:08 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
On 2/20/20 7:04 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 770baba621b3..48de7624d49c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct
drm_device *dev, struct dma_buf *dma_buf)
return ERR_PTR(ret);
}
+/**
+ * amdgpu_dma_buf_move_notify - _notify implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that
the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct ttm_operation_ctx ctx = { false, false };
+ struct ttm_placement placement = {};
+ struct amdgpu_vm_bo_base *bo_base;
+ int r;
+
+ if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+ return;
+
+ r = ttm_bo_validate(>tbo, , );
+ if (r) {
+ DRM_ERROR("Failed to invalidate DMA-buf
import (%d))\n", r);
+ return;
+ }
+
+ for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
+ struct amdgpu_vm *vm = bo_base->vm;
+ struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+ if (ticket) {
Yeah so this is kinda why I've been a total pain about the
exact semantics
of the move_notify hook. I think we should flat-out require
that importers
_always_ have a ticket attach when they call this, and that
they can cope
with additional locks being taken (i.e. full EDEADLCK) handling.
Simplest way to force that contract is to add a dummy 2nd
ww_mutex lock to
the dma_resv object, which we then can take #ifdef
CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
Now the real disaster is how we handle deadlocks. Two issues:
- Ideally we'd keep any lock we've taken locked until the
end, it helps
needless backoffs. I've played around a bit with that
but not even poc
level, just an idea:
https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
Idea is essentially to track a list of objects we had to
lock as part of
the ttm_bo_validate of the main object.
- Second one is if we get a EDEADLCK on one of these
sublocks (like the
one here). We need to pass that up the entire callchain,
including a
temporary reference (we have to drop locks to do the
ww_mutex_lock_slow
call), and need a custom callback to drop that temporary reference
(since that's all driver specific, might even be
internal ww_mutex and
not anything remotely looking like a normal dma_buf).
This probably
needs the exec util helpers from ttm, but at the
dma_resv level, so that
we can do something like this:
struct dma_resv_ticket {
struct ww_acquire_ctx base;
/* can be set by anyone (including other drivers)
that got hold of
* this ticket and had to acquire some new lock. This
lock might
* protect anything, including driver-internal stuff, and isn't
* required to be a dma_buf or even just a dma_resv. */
struct ww_mutex *contended_lock;
/* callback which the driver (which might be a dma-buf exporter
* and not matching the driver that started this
locking ticket)
* sets together with @contended_lock, for the main
driver to drop
* when it calls dma_resv_unlock on the contended_lock. */
void (drop_ref*)(struct ww_mutex *contended_lock);
};
This is all supremely nasty (also ttm_bo_validate would need to be
improved to handle these sublocks and random new objects
that could force
a ww_mutex_lock_slow).
Just a short comment on this:
Neither the currently used wait-die or the wound-wait algorithm
*strictly* requires a slow lock on the contended lock. For
wait-die it's
just very convenient since it makes us sleep instead of spinning with
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Introduce struct drm_device based WARN* and use them in i915 (rev7)
== Series Details == Series: drm: Introduce struct drm_device based WARN* and use them in i915 (rev7) URL : https://patchwork.freedesktop.org/series/72035/ State : success == Summary == CI Bug Log - changes from CI_DRM_7976 -> Patchwork_16648 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/index.html Known issues Here are the changes found in Patchwork_16648 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-bsw-n3050: [PASS][1] -> [INCOMPLETE][2] ([i915#392]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live_sanitycheck: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([i915#585]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html * igt@kms_chamelium@hdmi-crc-fast: - fi-icl-u2: [PASS][5] -> [FAIL][6] ([fdo#109635] / [i915#217]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html * igt@prime_self_import@basic-llseek-bad: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([CI#94] / [i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html Possible fixes * igt@gem_close_race@basic-threads: - fi-hsw-peppy: [TIMEOUT][9] ([fdo#112271] / [i915#1084]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][11] ([CI#94]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live_gem_contexts: - fi-hsw-peppy: [DMESG-FAIL][13] ([i915#722]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@prime_vgem@basic-gtt: - fi-tgl-y: [DMESG-WARN][17] ([CI#94] / [i915#402]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-tgl-y/igt@prime_v...@basic-gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-tgl-y/igt@prime_v...@basic-gtt.html Warnings * igt@amdgpu/amd_prime@amd-to-i915: - fi-icl-u3: [SKIP][19] ([fdo#109315] / [i915#585]) -> [SKIP][20] ([fdo#109315]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7976/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16648/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#392]: https://gitlab.freedesktop.org/drm/intel/issues/392 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585 [i915#722]: https://gitlab.freedesktop.org/drm/intel/issues/722 Participating hosts (53 -> 37) -- Missing(16): fi-ilk-m540 fi-kbl-7560u fi-hsw-4200u fi-glk-dsi fi-byt-squawks fi-bwr-2160
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Introduce struct drm_device based WARN* and use them in i915 (rev7)
== Series Details == Series: drm: Introduce struct drm_device based WARN* and use them in i915 (rev7) URL : https://patchwork.freedesktop.org/series/72035/ State : warning == Summary == $ dim checkpatch origin/drm-tip f3e1e10ac32d drm/i915/display/cdclk: Make WARN* drm specific where drm_priv ptr is available 37b11379faf7 drm/i915/display/ddi: Make WARN* drm specific where drm_device ptr is available 0a9eccf2eb1a drm/i915/display/display: Make WARN* drm specific where drm_device ptr is available -:497: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #497: FILE: drivers/gpu/drm/i915/display/intel_display.c:10699: + drm_WARN_ON(dev, !pll->info->funcs->get_hw_state(dev_priv, pll, +_config->dpll_hw_state)); total: 0 errors, 0 warnings, 1 checks, 657 lines checked bca7c0209467 drm/i915/display/power: Make WARN* drm specific where drm_priv ptr is available 714a69f8bd80 drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available 7fd6b4d78e27 drm/i915/display/hdcp: Make WARN* drm specific where drm_priv ptr is available -:103: WARNING:LONG_LINE: line over 100 characters #103: FILE: drivers/gpu/drm/i915/display/intel_hdcp.c:1604: + drm_WARN_ON(_priv->drm, !(intel_de_read(dev_priv, HDCP2_STATUS(dev_priv, cpu_transcoder, port)) & total: 0 errors, 1 warnings, 0 checks, 56 lines checked 820962439df7 drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available 5e643f5a8467 drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available -:293: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #293: FILE: drivers/gpu/drm/i915/gvt/handlers.c:1373: + drm_WARN_ONCE(>drm, 1, + "VM(%d): iGVT-g doesn't support GuC\n", -:307: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #307: FILE: drivers/gpu/drm/i915/gvt/handlers.c:1389: + drm_WARN(>drm, 1, + "VM(%d): Use physical address for TRTT!\n", total: 0 errors, 0 warnings, 2 checks, 519 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Program MBUS with rmw during initialization (rev2)
On Mon, Feb 10, 2020 at 10:20:17PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Program MBUS with rmw during > initialization (rev2) > URL : https://patchwork.freedesktop.org/series/72950/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_7903 -> Patchwork_16509 > > > Summary > --- > > **WARNING** > > Minor unknown changes coming with Patchwork_16509 need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_16509, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_16509: > > ### IGT changes ### > > Warnings > > * igt@i915_pm_rpm@module-reload: > - fi-ivb-3770:[SKIP][1] ([fdo#109271]) -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-ivb-3770/igt@i915_pm_...@module-reload.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-ivb-3770/igt@i915_pm_...@module-reload.html Unrelated IVB issue; wouldn't be caused by this patch. Patchwork also shows clean results for the shards CI, although I can't find the results mail in my inbox. Applied to dinq. Thanks Matt Atwood for the reviews. Matt > > > Known issues > > > Here are the changes found in Patchwork_16509 that come from known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_parallel@basic: > - fi-byt-n2820: [PASS][3] -> [TIMEOUT][4] ([fdo#112271]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-byt-n2820/igt@gem_exec_paral...@basic.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-byt-n2820/igt@gem_exec_paral...@basic.html > > * igt@i915_selftest@live_blt: > - fi-hsw-4770r: [PASS][5] -> [DMESG-FAIL][6] ([i915#553] / > [i915#725]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-hsw-4770r/igt@i915_selftest@live_blt.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-hsw-4770r/igt@i915_selftest@live_blt.html > > > Possible fixes > > * igt@i915_selftest@live_blt: > - fi-bsw-n3050: [INCOMPLETE][7] ([i915#392]) -> [PASS][8] >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-bsw-n3050/igt@i915_selftest@live_blt.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-bsw-n3050/igt@i915_selftest@live_blt.html > - fi-hsw-4770:[DMESG-FAIL][9] ([i915#553] / [i915#725]) -> > [PASS][10] >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-hsw-4770/igt@i915_selftest@live_blt.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-hsw-4770/igt@i915_selftest@live_blt.html > > * igt@i915_selftest@live_gem_contexts: > - fi-cfl-8700k: [DMESG-FAIL][11] ([i915#623]) -> [PASS][12] >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html > - fi-byt-n2820: [DMESG-FAIL][13] ([i915#1052]) -> [PASS][14] >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html > - fi-cfl-guc: [INCOMPLETE][15] ([CI#80] / [fdo#106070] / > [i915#424]) -> [PASS][16] >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html > - fi-cml-s: [DMESG-FAIL][17] ([i915#877]) -> [PASS][18] >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-cml-s/igt@i915_selftest@live_gem_contexts.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-cml-s/igt@i915_selftest@live_gem_contexts.html > > * igt@i915_selftest@live_gtt: > - fi-bdw-5557u: [TIMEOUT][19] ([fdo#112271]) -> [PASS][20] >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7903/fi-bdw-5557u/igt@i915_selftest@live_gtt.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16509/fi-bdw-5557u/igt@i915_selftest@live_gtt.html > > > [CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80 > [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 > [fdo#109271]:
Re: [Intel-gfx] [PATCH v2-resend] drm/i915/psr: Force PSR probe only after full initialization
On Thu, 2020-02-20 at 09:41 +0530, Anshuman Gupta wrote:
> On 2020-02-18 at 23:53:28 +0530, José Roberto de Souza wrote:
> > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
> > phase
> > once to enable PSR") was forcing the state compute too earlier
> > causing errors because not everything was initialized, so here
> > moving to i915_driver_register() when everything is ready and
> > driver
> > is registering into the rest of the system.
> >
> > Also fixing the place where it disarm the force probe as during the
> > atomic check phase errors could happen like the ones due locking
> > and
> > it would cause PSR to never be enabled if that happens.
> > Leaving the disarm to the atomic commit phase, intel_psr_enable()
> > or
> > intel_psr_update() will be called even if the current state do not
> > allow PSR to be enabled.
> Is it possible to having a psr state in intel crtc state to do this,
> this can be used in future when will have dual psr display?
When we implement that we would probably move i915_psr to intel_crtc,
just not sure how we would handle when the connector changes its CRTC
but that is something to handle in the future.
>
> intel_psr_fastset_force() also forcing the fastset when psr mode
> change from debugfs, may be intel_psr_force_mode_changed_set(true)
> can get rid of that.
They are different, intel_psr_fastset_force() will do a atomic commit
and change the PSR state while intel_psr_force_mode_changed_set() will
just make sure that the pipe attached to the eDP panel will have its
state computed and checked in the next atomic commit.
> > v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
> >
> > Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute
> > phase once to enable PSR")
> > Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
> > Reported-by: Ross Zwisler
> > Tested-by: Ross Zwisler
> > Cc: Gwan-gyeong Mun
> > Cc: Jani Nikula
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 18 --
> > drivers/gpu/drm/i915/display/intel_psr.h | 1 +
> > drivers/gpu/drm/i915/i915_drv.c | 3 +++
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > 4 files changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index b4942b6445ae..35bafd281deb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -936,6 +936,8 @@ void intel_psr_enable(struct intel_dp
> > *intel_dp,
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >
> > + intel_psr_force_mode_changed_set(intel_dp, false);
> > +
> > if (!crtc_state->has_psr)
> > return;
> >
> > @@ -1096,6 +1098,8 @@ void intel_psr_update(struct intel_dp
> > *intel_dp,
> > struct i915_psr *psr = _priv->psr;
> > bool enable, psr2_enable;
> >
> > + intel_psr_force_mode_changed_set(intel_dp, false);
> > +
> > if (!CAN_PSR(dev_priv) || READ_ONCE(psr->dp) != intel_dp)
> > return;
> >
> > @@ -1629,7 +1633,7 @@ void intel_psr_atomic_check(struct
> > drm_connector *connector,
> > struct drm_crtc_state *crtc_state;
> >
> > if (!CAN_PSR(dev_priv) || !new_state->crtc ||
> > - dev_priv->psr.initially_probed)
> > + !dev_priv->psr.force_mode_changed)
> > return;
> >
> > intel_connector = to_intel_connector(connector);
> > @@ -1640,5 +1644,15 @@ void intel_psr_atomic_check(struct
> > drm_connector *connector,
> > crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> >new_state->crtc);
> > crtc_state->mode_changed = true;
> > - dev_priv->psr.initially_probed = true;
> > +}
> > +
> > +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> > bool set)
> > +{
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > + if (!CAN_PSR(dev_priv) || !intel_dp ||
> > !intel_dp_is_edp(intel_dp) ||
> > + intel_dp != dev_priv->psr.dp)
> > + return;
> > +
> > + dev_priv->psr.force_mode_changed = set;
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
> > b/drivers/gpu/drm/i915/display/intel_psr.h
> > index c58a1d438808..27a70468e2b9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.h
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.h
> > @@ -40,5 +40,6 @@ bool intel_psr_enabled(struct intel_dp
> > *intel_dp);
> > void intel_psr_atomic_check(struct drm_connector *connector,
> > struct drm_connector_state *old_state,
> > struct drm_connector_state *new_state);
> > +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> > bool set);
> >
> > #endif /* __INTEL_PSR_H__ */
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index
Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Force PSR probe only after full initialization
On Thu, 2020-02-20 at 12:39 +, Mun, Gwan-gyeong wrote:
> On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
> > phase
> > once to enable PSR") was forcing the state compute too earlier
> > causing errors because not everything was initialized, so here
> > moving to i915_driver_register() when everything is ready and
> > driver
> > is registering into the rest of the system.
> >
> > Also fixing the place where it disarm the force probe as during the
> > atomic check phase errors could happen like the ones due locking
> > and
> > it would cause PSR to never be enabled if that happens.
> > Leaving the disarm to the atomic commit phase, intel_psr_enable()
> > or
> > intel_psr_update() will be called even if the current state do not
> > allow PSR to be enabled.
> >
> > v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
> > v3: Check intel_dp before get dev_priv
> >
> > Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute
> > phase
> > once to enable PSR")
> > Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
> > Tested-by: Ross Zwisler
> > Reported-by: Ross Zwisler
> > Cc: Gwan-gyeong Mun
> > Cc: Jani Nikula
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 22
> > --
> > drivers/gpu/drm/i915/display/intel_psr.h | 1 +
> > drivers/gpu/drm/i915/i915_drv.c | 3 +++
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > 4 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index b4942b6445ae..2a0f7354fba5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -936,6 +936,8 @@ void intel_psr_enable(struct intel_dp
> > *intel_dp,
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >
> > + intel_psr_force_mode_changed_set(intel_dp, false);
> > +
> Hi,
> intel_psr_enable() and intel_psr_update already have checking routine
> for CAN_PSR and has_psr.
> therefore we don't need to check twice here.
Minor overhead but if you really want I can remove the function call
and just do a dev_priv->psr.force_mode_changed = false; for
intel_psr_enable/update
> And if there are no issues that moving "disarming force_mode_changed"
> to intel_psr_compute_config(),
> can we move them to intel_psr_compute_config()?
atomic check can fail at any point so we could disarm the mode_changed,
fail, retry(because the return was EAGAIN) and then PSR will not be
enabled.
>
> > if (!crtc_state->has_psr)
> > return;
> >
> > @@ -1096,6 +1098,8 @@ void intel_psr_update(struct intel_dp
> > *intel_dp,
> > struct i915_psr *psr = _priv->psr;
> > bool enable, psr2_enable;
> >
> > + intel_psr_force_mode_changed_set(intel_dp, false);
> > +
> > if (!CAN_PSR(dev_priv) || READ_ONCE(psr->dp) != intel_dp)
> > return;
> >
> > @@ -1629,7 +1633,7 @@ void intel_psr_atomic_check(struct
> > drm_connector *connector,
> > struct drm_crtc_state *crtc_state;
> >
> > if (!CAN_PSR(dev_priv) || !new_state->crtc ||
> > - dev_priv->psr.initially_probed)
> > + !dev_priv->psr.force_mode_changed)
> > return;
> >
> > intel_connector = to_intel_connector(connector);
> > @@ -1640,5 +1644,19 @@ void intel_psr_atomic_check(struct
> > drm_connector *connector,
> > crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> >new_state->crtc);
> > crtc_state->mode_changed = true;
> > - dev_priv->psr.initially_probed = true;
> > +}
> > +
> > +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> > bool set)
> IMHO, it would be better intel_psr_set_force_mode_changed() as a
> function name.
Okay
> > +{
> > + struct drm_i915_private *dev_priv;
> > +
> > + if (!intel_dp)
> > + return;
> > +
> > + dev_priv = dp_to_i915(intel_dp);
> > + if (!CAN_PSR(dev_priv) || !intel_dp_is_edp(intel_dp) ||
> > + intel_dp != dev_priv->psr.dp)
> > + return;
> > +
> > + dev_priv->psr.force_mode_changed = set;
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
> > b/drivers/gpu/drm/i915/display/intel_psr.h
> > index c58a1d438808..27a70468e2b9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.h
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.h
> > @@ -40,5 +40,6 @@ bool intel_psr_enabled(struct intel_dp
> > *intel_dp);
> > void intel_psr_atomic_check(struct drm_connector *connector,
> > struct drm_connector_state *old_state,
> > struct drm_connector_state *new_state);
> > +void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp,
> > bool set);
> >
> > #endif /* __INTEL_PSR_H__ */
> > diff --git
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev2)
== Series Details ==
Series: drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev2)
URL : https://patchwork.freedesktop.org/series/73718/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7975 -> Patchwork_16647
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16647 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16647, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16647:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-pnv-d510:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-pnv-d510/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-pnv-d510/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
- fi-gdg-551: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-gdg-551/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-gdg-551/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_busy@basic@flip}:
- fi-icl-guc: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-icl-guc/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-icl-guc/igt@kms_busy@ba...@flip.html
- fi-hsw-4770:[PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-hsw-4770/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-hsw-4770/igt@kms_busy@ba...@flip.html
- {fi-tgl-u}: [PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-u/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-tgl-u/igt@kms_busy@ba...@flip.html
- {fi-kbl-7560u}: NOTRUN -> [INCOMPLETE][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-kbl-7560u/igt@kms_busy@ba...@flip.html
- fi-cfl-guc: [PASS][12] -> [INCOMPLETE][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-cfl-guc/igt@kms_busy@ba...@flip.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-cfl-guc/igt@kms_busy@ba...@flip.html
- fi-bsw-n3050: [PASS][14] -> [INCOMPLETE][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-bsw-n3050/igt@kms_busy@ba...@flip.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-bsw-n3050/igt@kms_busy@ba...@flip.html
- fi-skl-guc: [PASS][16] -> [INCOMPLETE][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-skl-guc/igt@kms_busy@ba...@flip.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-skl-guc/igt@kms_busy@ba...@flip.html
- fi-ilk-650: [PASS][18] -> [INCOMPLETE][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-ilk-650/igt@kms_busy@ba...@flip.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-ilk-650/igt@kms_busy@ba...@flip.html
- fi-icl-y: [PASS][20] -> [INCOMPLETE][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-icl-y/igt@kms_busy@ba...@flip.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-icl-y/igt@kms_busy@ba...@flip.html
- fi-hsw-4770r: [PASS][22] -> [INCOMPLETE][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-hsw-4770r/igt@kms_busy@ba...@flip.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-hsw-4770r/igt@kms_busy@ba...@flip.html
- fi-skl-6700k2: [PASS][24] -> [INCOMPLETE][25]
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-skl-6700k2/igt@kms_busy@ba...@flip.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-skl-6700k2/igt@kms_busy@ba...@flip.html
- fi-icl-u2: [PASS][26] -> [INCOMPLETE][27]
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-icl-u2/igt@kms_busy@ba...@flip.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/fi-icl-u2/igt@kms_busy@ba...@flip.html
- fi-hsw-peppy: [PASS][28] -> [INCOMPLETE][29]
[28]:
[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev2)
== Series Details == Series: drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev2) URL : https://patchwork.freedesktop.org/series/73718/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage is ready (#1) MODPOST 121 modules ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! scripts/Makefile.modpost:93: recipe for target '__modpost' failed make[1]: *** [__modpost] Error 1 Makefile:1281: recipe for target 'modules' failed make: *** [modules] Error 2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16647/build_32bit.log ___ 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/tgl: Program MBUS_ABOX{1, 2}_CTL during display init
On Mon, Feb 03, 2020 at 05:10:32PM -0800, Matt Roper wrote:
> On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL
> during display initialization, but on gen12 we're now supposed to
> program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well.
>
> v2:
> - Program registers with rmw to preserve contents of unrelated bits.
> - Switch to the new display uncore helpers.
>
> Bspec: 49213
> Bspec: 50096
> Cc: Stanislav Lisovskiy
Reviewed-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 4
> drivers/gpu/drm/i915/i915_reg.h| 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 529319c962e8..f638691cda6e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4516,6 +4516,10 @@ static void icl_mbus_init(struct drm_i915_private
> *dev_priv)
> MBUS_ABOX_BW_CREDIT(1);
>
> intel_de_rmw(dev_priv, MBUS_ABOX_CTL, mask, val);
> + if (INTEL_GEN(dev_priv) >= 12) {
> + intel_de_rmw(dev_priv, MBUS_ABOX1_CTL, mask, val);
> + intel_de_rmw(dev_priv, MBUS_ABOX2_CTL, mask, val);
> + }
> }
>
> static void hsw_assert_cdclk(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0bd431f6a011..d3df704ee099 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2865,6 +2865,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define MI_ARB_STATE _MMIO(0x20e4) /* 915+ only */
>
> #define MBUS_ABOX_CTL_MMIO(0x45038)
> +#define MBUS_ABOX1_CTL _MMIO(0x45048)
> +#define MBUS_ABOX2_CTL _MMIO(0x4504C)
> #define MBUS_ABOX_BW_CREDIT_MASK (3 << 20)
> #define MBUS_ABOX_BW_CREDIT(x) ((x) << 20)
> #define MBUS_ABOX_B_CREDIT_MASK (0xF << 16)
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Program MBUS with rmw during initialization
On Mon, Feb 03, 2020 at 05:10:31PM -0800, Matt Roper wrote:
> It wasn't terribly clear from the bspec's wording, but after discussion
> with the hardware folks, it turns out that we need to preserve the
> pre-existing contents of the MBUS ABOX control register when
> initializing a few specific bits.
>
> Bspec: 49213
> Bspec: 50096
> Fixes: 4cb4585e5a7f ("drm/i915/icl: initialize MBus during display init")
> Cc: Stanislav Lisovskiy
Reviewed-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 6d91e180db99..529319c962e8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -4504,14 +4504,18 @@ static void icl_dbuf_disable(struct drm_i915_private
> *dev_priv)
>
> static void icl_mbus_init(struct drm_i915_private *dev_priv)
> {
> - u32 val;
> + u32 mask, val;
>
> + mask = MBUS_ABOX_BT_CREDIT_POOL1_MASK |
> + MBUS_ABOX_BT_CREDIT_POOL2_MASK |
> + MBUS_ABOX_B_CREDIT_MASK |
> + MBUS_ABOX_BW_CREDIT_MASK;
> val = MBUS_ABOX_BT_CREDIT_POOL1(16) |
> - MBUS_ABOX_BT_CREDIT_POOL2(16) |
> - MBUS_ABOX_B_CREDIT(1) |
> - MBUS_ABOX_BW_CREDIT(1);
> + MBUS_ABOX_BT_CREDIT_POOL2(16) |
> + MBUS_ABOX_B_CREDIT(1) |
> + MBUS_ABOX_BW_CREDIT(1);
>
> - intel_de_write(dev_priv, MBUS_ABOX_CTL, val);
> + intel_de_rmw(dev_priv, MBUS_ABOX_CTL, mask, val);
> }
>
> static void hsw_assert_cdclk(struct drm_i915_private *dev_priv)
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Extend Wa_1606931601 for all steppings.
== Series Details == Series: drm/i915: Extend Wa_1606931601 for all steppings. URL : https://patchwork.freedesktop.org/series/73621/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16616_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16616_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16616_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_16616_full: ### IGT changes ### Possible regressions * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb2/igt@gem_exec_balan...@hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16616/shard-tglb5/igt@gem_exec_balan...@hang.html New tests - New tests have been introduced between CI_DRM_7963_full and Patchwork_16616_full: ### New IGT tests (54) ### * igt@i915_pm_backlight@bad-brightness: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 0.01] s * igt@i915_pm_backlight@fade: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 2.58] s * igt@i915_pm_backlight@fade_with_dpms: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 8.39] s * igt@i915_pm_backlight@fade_with_suspend: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.49] s * igt@i915_pm_lpsp@edp-native: - Statuses : 8 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_lpsp@edp-panel-fitter: - Statuses : 8 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_lpsp@non-edp: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.11] s * igt@i915_pm_lpsp@screens-disabled: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.05] s * igt@i915_pm_rc6_residency@media-rc6-accuracy: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_rc6_residency@rc6-accuracy: - Statuses : 7 pass(s) - Exec time: [3.0, 3.00] s * igt@i915_pm_rpm@cursor: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 41.77] s * igt@i915_pm_rpm@cursor-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 37.57] s * igt@i915_pm_rpm@debugfs-forcewake-user: - Statuses : 7 pass(s) - Exec time: [10.46, 14.15] s * igt@i915_pm_rpm@debugfs-read: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 80.94] s * igt@i915_pm_rpm@dpms-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.82] s * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 13.40] s * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 3.92] s * igt@i915_pm_rpm@dpms-non-lpsp: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0, 0.16] s * igt@i915_pm_rpm@drm-resources-equal: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 11.06] s * igt@i915_pm_rpm@fences: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 17.19] s * igt@i915_pm_rpm@fences-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 10.90] s * igt@i915_pm_rpm@gem-evict-pwrite: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 3.93] s * igt@i915_pm_rpm@gem-execbuf: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 13.95] s * igt@i915_pm_rpm@gem-execbuf-stress: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 42.58] s * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - Statuses : 8 skip(s) - Exec time: [0.0, 0.00] s * igt@i915_pm_rpm@gem-idle: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 8.89] s * igt@i915_pm_rpm@gem-pread: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 6.39] s * igt@i915_pm_rpm@i2c: - Statuses : 6 pass(s) - Exec time: [0.95, 11.25] s * igt@i915_pm_rpm@legacy-planes: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 169.57] s * igt@i915_pm_rpm@legacy-planes-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 146.68] s * igt@i915_pm_rpm@modeset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.92] s * igt@i915_pm_rpm@modeset-lpsp-stress: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 50.92] s * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 16.86] s * igt@i915_pm_rpm@modeset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 4.14] s * igt@i915_pm_rpm@modeset-non-lpsp-stress: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 9.64] s *
[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP 2.2 Comp fixes
== Series Details ==
Series: HDCP 2.2 Comp fixes
URL : https://patchwork.freedesktop.org/series/73708/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7975 -> Patchwork_16646
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/index.html
Known issues
Here are the changes found in Patchwork_16646 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-tgl-y/igt@gem_flink_ba...@double-flink.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-hsw-4770r: [TIMEOUT][5] ([fdo#112271] / [i915#1084]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-hsw-4770r/igt@gem_close_r...@basic-threads.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-hsw-4770r/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][7] ([CI#94]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@gem_mmap@basic:
- fi-tgl-y: [DMESG-WARN][9] ([CI#94] / [i915#402]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@gem_m...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-tgl-y/igt@gem_m...@basic.html
* igt@i915_selftest@live_execlists:
- fi-tgl-y: [INCOMPLETE][11] ([CI#94] / [i915#647]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-tgl-y/igt@i915_selftest@live_execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-tgl-y/igt@i915_selftest@live_execlists.html
- fi-icl-y: [DMESG-FAIL][13] ([fdo#108569]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-icl-y/igt@i915_selftest@live_execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-icl-y/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [DMESG-WARN][15] ([i915#585]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [FAIL][17] ([i915#262]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
Warnings
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][19] ([fdo#109315]) -> [SKIP][20] ([fdo#109315]
/ [i915#585])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][21] ([fdo#111096] / [i915#323]) -> [FAIL][22]
([fdo#111407])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7975/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16646/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).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[Intel-gfx] [PATCH] drm/i915/tgl: Add Wa_1409085225, Wa_14010229206
Disable Push Constant buffer addition for TGL.
v2: typos, add additional Wa reference
v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit
message.
Bspec: 52890
Cc: Rafael Antognolli
Cc: Matt Roper
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 7cc8a7fc53c7..5db9a9fa9ca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1334,6 +1334,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_masked_en(wal,
GEN7_ROW_CHICKEN2,
GEN12_DISABLE_EARLY_READ);
+ /*
+ * Wa_1409085225:tgl
+ * Wa_14010229206:tgl
+ */
+ WA_SET_BIT_MASKED(GEN9_ROW_CHICKEN4, GEN12_DISABLE_TDL_PUSH);
}
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b09c1d6dc0aa..4d6342a2883e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9153,6 +9153,9 @@ enum {
#define PUSH_CONSTANT_DEREF_DISABLE (1 << 8)
#define GEN11_TDL_CLOCK_GATING_FIX_DISABLE (1 << 1)
+#define GEN9_ROW_CHICKEN4 _MMIO(0xe48c)
+#define GEN12_DISABLE_TDL_PUSHREG_BIT(9)
+
#define HSW_ROW_CHICKEN3 _MMIO(0xe49c)
#define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
--
2.21.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Extend Wa_1606931601 for all steppings.
From: Anusha Srivatsa
According to BSpec. Wa_1606931601 applies for all
TGL steppings.This patch moves the WA implementation
out of A0 only block of rcs_engine_wa_init().
The WA is has also been referred to by an alternate name
Wa_1607090982.
Bspec: 46045,52890
Fixes: 3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982")
Cc: Mika Kuoppala
Signed-off-by: Anusha Srivatsa
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 887e0dc701f7..7cc8a7fc53c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1329,6 +1329,13 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
{
struct drm_i915_private *i915 = engine->i915;
+ if (IS_TIGERLAKE(i915)) {
+ /* Wa_1606931601:tgl */
+ wa_masked_en(wal,
+GEN7_ROW_CHICKEN2,
+GEN12_DISABLE_EARLY_READ);
+ }
+
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
/* Wa_1606700617:tgl */
wa_masked_en(wal,
@@ -1360,11 +1367,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal,
GEN7_FF_THREAD_MODE,
GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
-
- /* Wa_1606931601:tgl */
- wa_masked_en(wal,
-GEN7_ROW_CHICKEN2,
-GEN12_DISABLE_EARLY_READ);
}
if (IS_GEN(i915, 11)) {
--
2.21.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
> On 2/20/20 7:04 PM, Daniel Vetter wrote:
> > On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> > > On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > > > On 2/18/20 10:01 PM, Daniel Vetter wrote:
> > > > > On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
> > > > > wrote:
> > > > > > On 2/17/20 6:55 PM, Daniel Vetter wrote:
> > > > > > > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> > > > > > > > Implement the importer side of unpinned DMA-buf handling.
> > > > > > > >
> > > > > > > > v2: update page tables immediately
> > > > > > > >
> > > > > > > > Signed-off-by: Christian König
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
> > > > > > > > -
> > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
> > > > > > > > 2 files changed, 71 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > > > index 770baba621b3..48de7624d49c 100644
> > > > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > > > @@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct
> > > > > > > > drm_device *dev, struct dma_buf *dma_buf)
> > > > > > > > return ERR_PTR(ret);
> > > > > > > > }
> > > > > > > >
> > > > > > > > +/**
> > > > > > > > + * amdgpu_dma_buf_move_notify - _notify
> > > > > > > > implementation
> > > > > > > > + *
> > > > > > > > + * @attach: the DMA-buf attachment
> > > > > > > > + *
> > > > > > > > + * Invalidate the DMA-buf attachment, making sure that
> > > > > > > > the we re-create the
> > > > > > > > + * mapping before the next use.
> > > > > > > > + */
> > > > > > > > +static void
> > > > > > > > +amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> > > > > > > > +{
> > > > > > > > + struct drm_gem_object *obj = attach->importer_priv;
> > > > > > > > + struct ww_acquire_ctx *ticket =
> > > > > > > > dma_resv_locking_ctx(obj->resv);
> > > > > > > > + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> > > > > > > > + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> > > > > > > > + struct ttm_operation_ctx ctx = { false, false };
> > > > > > > > + struct ttm_placement placement = {};
> > > > > > > > + struct amdgpu_vm_bo_base *bo_base;
> > > > > > > > + int r;
> > > > > > > > +
> > > > > > > > + if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
> > > > > > > > + return;
> > > > > > > > +
> > > > > > > > + r = ttm_bo_validate(>tbo, , );
> > > > > > > > + if (r) {
> > > > > > > > + DRM_ERROR("Failed to invalidate DMA-buf
> > > > > > > > import (%d))\n", r);
> > > > > > > > + return;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + for (bo_base = bo->vm_bo; bo_base; bo_base =
> > > > > > > > bo_base->next) {
> > > > > > > > + struct amdgpu_vm *vm = bo_base->vm;
> > > > > > > > + struct dma_resv *resv =
> > > > > > > > vm->root.base.bo->tbo.base.resv;
> > > > > > > > +
> > > > > > > > + if (ticket) {
> > > > > > > Yeah so this is kinda why I've been a total pain about the
> > > > > > > exact semantics
> > > > > > > of the move_notify hook. I think we should flat-out require
> > > > > > > that importers
> > > > > > > _always_ have a ticket attach when they call this, and that
> > > > > > > they can cope
> > > > > > > with additional locks being taken (i.e. full EDEADLCK) handling.
> > > > > > >
> > > > > > > Simplest way to force that contract is to add a dummy 2nd
> > > > > > > ww_mutex lock to
> > > > > > > the dma_resv object, which we then can take #ifdef
> > > > > > > CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
> > > > > > >
> > > > > > > Now the real disaster is how we handle deadlocks. Two issues:
> > > > > > >
> > > > > > > - Ideally we'd keep any lock we've taken locked until the
> > > > > > > end, it helps
> > > > > > > needless backoffs. I've played around a bit with that
> > > > > > > but not even poc
> > > > > > > level, just an idea:
> > > > > > >
> > > > > > > https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
> > > > > > >
> > > > > > >
> > > > > > > Idea is essentially to track a list of objects we had to
> > > > > > > lock as part of
> > > > > > > the ttm_bo_validate of the main object.
> > > > > > >
> > > > > > > - Second one is if we get a EDEADLCK on one of these
> > > > > > > sublocks (like the
> > > > > > > one here). We need to pass that up the entire callchain,
> > > > > > > including a
> > > > > > > temporary reference (we have to drop locks to do the
> > > > > > > ww_mutex_lock_slow
> > > > > > > call), and need a
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915: Fix broken transcoder err state
On Thu, Feb 20, 2020 at 07:16:32PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 10:55:28PM +0530, Anshuman Gupta wrote:
> > Skip the transcoder whose pipe is disabled while
> > initializing transcoder error state in 3 non-contiguous
> > display pipe system.
> >
> > v2:
> > - Don't skip EDP_TRANSCODER error state. [Ville]
> > - Use a helper has_transcoder(). [Ville]
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Anshuman Gupta
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> > drivers/gpu/drm/i915/display/intel_display_types.h | 14 ++
> > drivers/gpu/drm/i915/i915_drv.h| 2 ++
> > 3 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 5333f7a7db42..a3649020ea97 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -19051,7 +19051,7 @@ intel_display_capture_error_state(struct
> > drm_i915_private *dev_priv)
> > for (i = 0; i < ARRAY_SIZE(error->transcoder); i++) {
> > enum transcoder cpu_transcoder = transcoders[i];
> >
> > - if (!INTEL_INFO(dev_priv)->trans_offsets[cpu_transcoder])
> > + if (!has_transcoder(dev_priv, cpu_transcoder))
> > continue;
> >
> > error->transcoder[i].available = true;
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 14e3d78fef7c..d359f1636ba8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1626,4 +1626,18 @@ static inline u32 intel_plane_ggtt_offset(const
> > struct intel_plane_state *state)
> > return i915_ggtt_offset(state->vma);
> > }
> >
> > +static inline bool
> > +has_transcoder(struct drm_i915_private *dev_priv, enum transcoder
> > transcoder) {
>
> { is in the wrong place.
Oh and 'cpu_transcoder' is the variable name used everwhere else. Pls
stick to established patterns if possible.
>
> > + switch (transcoder) {
> > + case TRANSCODER_EDP:
> > + return HAS_TRANSCODER_EDP(dev_priv);
> > + case TRANSCODER_DSI_0:
> > + return HAS_TRANSCODER_DSI0(dev_priv);
> > + case TRANSCODER_DSI_1:
> > + return HAS_TRANSCODER_DSI1(dev_priv);
>
> The error capture so far doesn't care about DSI, so I wouldn't bother
> with these for now.
>
> > + default:
> > + return INTEL_INFO(dev_priv)->pipe_mask & BIT(transcoder);
> > + }
> > +}
>
> This functions has one user so no point in putting it into a header.
>
> > +
> > #endif /* __INTEL_DISPLAY_TYPES_H__ */
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index da509d9b8895..17bbaf7f0844 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1674,6 +1674,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> > #define HAS_FPGA_DBG_UNCLAIMED(dev_priv)
> > (INTEL_INFO(dev_priv)->has_fpga_dbg)
> > #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr)
> > #define HAS_TRANSCODER_EDP(dev_priv)
> > (INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_EDP] != 0)
> > +#define HAS_TRANSCODER_DSI0(dev_priv)
> > (INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_DSI_0] != 0)
> > +#define HAS_TRANSCODER_DSI1(dev_priv)
> > (INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_DSI_1] != 0)
> >
> > #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)->has_rc6)
> > #define HAS_RC6p(dev_priv) (INTEL_INFO(dev_priv)->has_rc6p)
> > --
> > 2.24.0
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
On 2/20/20 7:04 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 770baba621b3..48de7624d49c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct
drm_device *dev, struct dma_buf *dma_buf)
return ERR_PTR(ret);
}
+/**
+ * amdgpu_dma_buf_move_notify - _notify implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that
the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct ttm_operation_ctx ctx = { false, false };
+ struct ttm_placement placement = {};
+ struct amdgpu_vm_bo_base *bo_base;
+ int r;
+
+ if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+ return;
+
+ r = ttm_bo_validate(>tbo, , );
+ if (r) {
+ DRM_ERROR("Failed to invalidate DMA-buf
import (%d))\n", r);
+ return;
+ }
+
+ for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
+ struct amdgpu_vm *vm = bo_base->vm;
+ struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+ if (ticket) {
Yeah so this is kinda why I've been a total pain about the
exact semantics
of the move_notify hook. I think we should flat-out require
that importers
_always_ have a ticket attach when they call this, and that
they can cope
with additional locks being taken (i.e. full EDEADLCK) handling.
Simplest way to force that contract is to add a dummy 2nd
ww_mutex lock to
the dma_resv object, which we then can take #ifdef
CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
Now the real disaster is how we handle deadlocks. Two issues:
- Ideally we'd keep any lock we've taken locked until the
end, it helps
needless backoffs. I've played around a bit with that
but not even poc
level, just an idea:
https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
Idea is essentially to track a list of objects we had to
lock as part of
the ttm_bo_validate of the main object.
- Second one is if we get a EDEADLCK on one of these
sublocks (like the
one here). We need to pass that up the entire callchain,
including a
temporary reference (we have to drop locks to do the
ww_mutex_lock_slow
call), and need a custom callback to drop that temporary reference
(since that's all driver specific, might even be
internal ww_mutex and
not anything remotely looking like a normal dma_buf).
This probably
needs the exec util helpers from ttm, but at the
dma_resv level, so that
we can do something like this:
struct dma_resv_ticket {
struct ww_acquire_ctx base;
/* can be set by anyone (including other drivers)
that got hold of
* this ticket and had to acquire some new lock. This
lock might
* protect anything, including driver-internal stuff, and isn't
* required to be a dma_buf or even just a dma_resv. */
struct ww_mutex *contended_lock;
/* callback which the driver (which might be a dma-buf exporter
* and not matching the driver that started this
locking ticket)
* sets together with @contended_lock, for the main
driver to drop
* when it calls dma_resv_unlock on the contended_lock. */
void (drop_ref*)(struct ww_mutex *contended_lock);
};
This is all supremely nasty (also ttm_bo_validate would need to be
improved to handle these sublocks and random new objects
that could force
a ww_mutex_lock_slow).
Just a short comment on this:
Neither the currently used wait-die or the wound-wait algorithm
*strictly* requires a slow lock on the contended lock. For
wait-die it's
just very convenient since it makes us sleep instead of spinning with
-EDEADLK on the contended lock. For wound-wait IIRC one could just
immediately restart the whole locking transaction after an
-EDEADLK, and
the
[Intel-gfx] ✗ Fi.CI.IGT: failure for Security mitigation for Intel Gen7/7.5 HWs
== Series Details == Series: Security mitigation for Intel Gen7/7.5 HWs URL : https://patchwork.freedesktop.org/series/73615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16614_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16614_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16614_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_16614_full: ### IGT changes ### Possible regressions * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb2/igt@gem_exec_balan...@hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16614/shard-tglb6/igt@gem_exec_balan...@hang.html New tests - New tests have been introduced between CI_DRM_7963_full and Patchwork_16614_full: ### New IGT tests (54) ### * igt@i915_pm_backlight@bad-brightness: - Statuses : 3 pass(s) 3 skip(s) - Exec time: [0.0, 0.01] s * igt@i915_pm_backlight@fade: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 2.59] s * igt@i915_pm_backlight@fade_with_dpms: - Statuses : 3 pass(s) 3 skip(s) - Exec time: [0.0, 8.39] s * igt@i915_pm_backlight@fade_with_suspend: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 4.50] s * igt@i915_pm_lpsp@edp-native: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_lpsp@edp-panel-fitter: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_lpsp@non-edp: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_lpsp@screens-disabled: - Statuses : 6 skip(s) - Exec time: [0.0] s * igt@i915_pm_rc6_residency@media-rc6-accuracy: - Statuses : 6 skip(s) - Exec time: [0.0] s * igt@i915_pm_rc6_residency@rc6-accuracy: - Statuses : 7 pass(s) - Exec time: [3.00] s * igt@i915_pm_rpm@cursor: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 41.08] s * igt@i915_pm_rpm@cursor-dpms: - Statuses : 5 pass(s) 1 skip(s) - Exec time: [0.0, 41.58] s * igt@i915_pm_rpm@debugfs-forcewake-user: - Statuses : 6 pass(s) - Exec time: [10.45, 14.29] s * igt@i915_pm_rpm@debugfs-read: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 80.88] s * igt@i915_pm_rpm@dpms-lpsp: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 0.82] s * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 13.35] s * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - Statuses : 2 pass(s) 4 skip(s) - Exec time: [0.0, 4.24] s * igt@i915_pm_rpm@dpms-non-lpsp: - Statuses : 3 pass(s) 3 skip(s) - Exec time: [0.0, 0.16] s * igt@i915_pm_rpm@drm-resources-equal: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 11.05] s * igt@i915_pm_rpm@fences: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 14.84] s * igt@i915_pm_rpm@fences-dpms: - Statuses : 5 pass(s) 1 skip(s) - Exec time: [0.0, 16.65] s * igt@i915_pm_rpm@gem-evict-pwrite: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 3.94] s * igt@i915_pm_rpm@gem-execbuf: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 15.16] s * igt@i915_pm_rpm@gem-execbuf-stress: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 42.74] s * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - Statuses : 7 skip(s) - Exec time: [0.0, 0.00] s * igt@i915_pm_rpm@gem-idle: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 8.99] s * igt@i915_pm_rpm@gem-pread: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 6.35] s * igt@i915_pm_rpm@i2c: - Statuses : 6 pass(s) - Exec time: [1.22, 11.27] s * igt@i915_pm_rpm@legacy-planes: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 169.68] s * igt@i915_pm_rpm@legacy-planes-dpms: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 146.58] s * igt@i915_pm_rpm@modeset-lpsp: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 4.85] s * igt@i915_pm_rpm@modeset-lpsp-stress: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 49.55] s * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - Statuses : 3 pass(s) 3 skip(s) - Exec time: [0.0, 17.75] s * igt@i915_pm_rpm@modeset-non-lpsp: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 4.18] s * igt@i915_pm_rpm@modeset-non-lpsp-stress: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 7.47] s * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait: - Statuses : 3 pass(s) 4 skip(s) - Exec
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Remove require_force_probe protection
== Series Details == Series: drm/i915/tgl: Remove require_force_probe protection URL : https://patchwork.freedesktop.org/series/73613/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16613_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16613_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16613_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_16613_full: ### IGT changes ### Possible regressions * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb2/igt@gem_exec_balan...@hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16613/shard-tglb1/igt@gem_exec_balan...@hang.html New tests - New tests have been introduced between CI_DRM_7963_full and Patchwork_16613_full: ### New IGT tests (54) ### * igt@i915_pm_backlight@bad-brightness: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 0.03] s * igt@i915_pm_backlight@fade: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 2.60] s * igt@i915_pm_backlight@fade_with_dpms: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 5.00] s * igt@i915_pm_backlight@fade_with_suspend: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 4.50] s * igt@i915_pm_lpsp@edp-native: - Statuses : 8 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_lpsp@edp-panel-fitter: - Statuses : 8 skip(s) - Exec time: [0.0, 0.05] s * igt@i915_pm_lpsp@non-edp: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.12] s * igt@i915_pm_lpsp@screens-disabled: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_rc6_residency@media-rc6-accuracy: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_rc6_residency@rc6-accuracy: - Statuses : 8 pass(s) - Exec time: [3.00] s * igt@i915_pm_rpm@cursor: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 45.52] s * igt@i915_pm_rpm@cursor-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 36.78] s * igt@i915_pm_rpm@debugfs-forcewake-user: - Statuses : 7 pass(s) - Exec time: [10.41, 14.24] s * igt@i915_pm_rpm@debugfs-read: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 80.93] s * igt@i915_pm_rpm@dpms-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.81] s * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 9.74] s * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 4.13] s * igt@i915_pm_rpm@dpms-non-lpsp: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0, 0.16] s * igt@i915_pm_rpm@drm-resources-equal: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 9.64] s * igt@i915_pm_rpm@fences: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 14.70] s * igt@i915_pm_rpm@fences-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 12.82] s * igt@i915_pm_rpm@gem-evict-pwrite: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 3.96] s * igt@i915_pm_rpm@gem-execbuf: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 15.30] s * igt@i915_pm_rpm@gem-execbuf-stress: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 42.82] s * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - Statuses : 1 incomplete(s) 7 skip(s) - Exec time: [0.0, 0.00] s * igt@i915_pm_rpm@gem-idle: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 9.09] s * igt@i915_pm_rpm@gem-pread: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 6.33] s * igt@i915_pm_rpm@i2c: - Statuses : 7 pass(s) - Exec time: [0.95, 11.18] s * igt@i915_pm_rpm@legacy-planes: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 169.80] s * igt@i915_pm_rpm@legacy-planes-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 146.58] s * igt@i915_pm_rpm@modeset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.93] s * igt@i915_pm_rpm@modeset-lpsp-stress: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 49.59] s * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 18.02] s * igt@i915_pm_rpm@modeset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 3.93] s * igt@i915_pm_rpm@modeset-non-lpsp-stress: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 7.29] s *
Re: [Intel-gfx] [PATCH 09/12] drm: Shrink drm_display_mode timings
On Thu, Feb 20, 2020 at 07:19:08PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Store the timings (apart from the clock) as u16. The uapi mode
> > struct already uses u16 for everything so using something bigger
> > internally doesn't really help us.
> >
> > Signed-off-by: Ville Syrjälä
>
> Makes sense I guess. This could mean some implicit pointer math is now no
> longer auto-upgraded to big enough integers though ...
u16 promotes to int. So can't really see how this would go wrong. Well,
unless someone is using these to store some larger intermediate values.
>
> Reviewed-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/drm_modes.c | 7 --
> > include/drm/drm_modes.h | 46 ++---
> > 2 files changed, 23 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 0e7c9ba241c4..cc9fc52f9f7c 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1917,13 +1917,6 @@ EXPORT_SYMBOL(drm_mode_create_from_cmdline_mode);
> > void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
> >const struct drm_display_mode *in)
> > {
> > - WARN(in->hdisplay > USHRT_MAX || in->hsync_start > USHRT_MAX ||
> > -in->hsync_end > USHRT_MAX || in->htotal > USHRT_MAX ||
> > -in->hskew > USHRT_MAX || in->vdisplay > USHRT_MAX ||
> > -in->vsync_start > USHRT_MAX || in->vsync_end > USHRT_MAX ||
> > -in->vtotal > USHRT_MAX || in->vscan > USHRT_MAX,
> > -"timing values too large for mode info\n");
> > -
> > out->clock = in->clock;
> > out->hdisplay = in->hdisplay;
> > out->hsync_start = in->hsync_start;
> > diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> > index b28c0234fcd7..b585074945b5 100644
> > --- a/include/drm/drm_modes.h
> > +++ b/include/drm/drm_modes.h
> > @@ -278,16 +278,16 @@ struct drm_display_mode {
> > * Pixel clock in kHz.
> > */
> > int clock; /* in kHz */
> > - int hdisplay;
> > - int hsync_start;
> > - int hsync_end;
> > - int htotal;
> > - int hskew;
> > - int vdisplay;
> > - int vsync_start;
> > - int vsync_end;
> > - int vtotal;
> > - int vscan;
> > + u16 hdisplay;
> > + u16 hsync_start;
> > + u16 hsync_end;
> > + u16 htotal;
> > + u16 hskew;
> > + u16 vdisplay;
> > + u16 vsync_start;
> > + u16 vsync_end;
> > + u16 vtotal;
> > + u16 vscan;
> > /**
> > * @flags:
> > *
> > @@ -356,19 +356,19 @@ struct drm_display_mode {
> > * difference is exactly a factor of 10.
> > */
> > int crtc_clock;
> > - int crtc_hdisplay;
> > - int crtc_hblank_start;
> > - int crtc_hblank_end;
> > - int crtc_hsync_start;
> > - int crtc_hsync_end;
> > - int crtc_htotal;
> > - int crtc_hskew;
> > - int crtc_vdisplay;
> > - int crtc_vblank_start;
> > - int crtc_vblank_end;
> > - int crtc_vsync_start;
> > - int crtc_vsync_end;
> > - int crtc_vtotal;
> > + u16 crtc_hdisplay;
> > + u16 crtc_hblank_start;
> > + u16 crtc_hblank_end;
> > + u16 crtc_hsync_start;
> > + u16 crtc_hsync_end;
> > + u16 crtc_htotal;
> > + u16 crtc_hskew;
> > + u16 crtc_vdisplay;
> > + u16 crtc_vblank_start;
> > + u16 crtc_vblank_end;
> > + u16 crtc_vsync_start;
> > + u16 crtc_vsync_end;
> > + u16 crtc_vtotal;
> >
> > /**
> > * @private_flags:
> > --
> > 2.24.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
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 09/12] drm: Shrink drm_display_mode timings
On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the timings (apart from the clock) as u16. The uapi mode
> struct already uses u16 for everything so using something bigger
> internally doesn't really help us.
>
> Signed-off-by: Ville Syrjälä
Makes sense I guess. This could mean some implicit pointer math is now no
longer auto-upgraded to big enough integers though ...
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_modes.c | 7 --
> include/drm/drm_modes.h | 46 ++---
> 2 files changed, 23 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 0e7c9ba241c4..cc9fc52f9f7c 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1917,13 +1917,6 @@ EXPORT_SYMBOL(drm_mode_create_from_cmdline_mode);
> void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out,
> const struct drm_display_mode *in)
> {
> - WARN(in->hdisplay > USHRT_MAX || in->hsync_start > USHRT_MAX ||
> - in->hsync_end > USHRT_MAX || in->htotal > USHRT_MAX ||
> - in->hskew > USHRT_MAX || in->vdisplay > USHRT_MAX ||
> - in->vsync_start > USHRT_MAX || in->vsync_end > USHRT_MAX ||
> - in->vtotal > USHRT_MAX || in->vscan > USHRT_MAX,
> - "timing values too large for mode info\n");
> -
> out->clock = in->clock;
> out->hdisplay = in->hdisplay;
> out->hsync_start = in->hsync_start;
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index b28c0234fcd7..b585074945b5 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -278,16 +278,16 @@ struct drm_display_mode {
>* Pixel clock in kHz.
>*/
> int clock; /* in kHz */
> - int hdisplay;
> - int hsync_start;
> - int hsync_end;
> - int htotal;
> - int hskew;
> - int vdisplay;
> - int vsync_start;
> - int vsync_end;
> - int vtotal;
> - int vscan;
> + u16 hdisplay;
> + u16 hsync_start;
> + u16 hsync_end;
> + u16 htotal;
> + u16 hskew;
> + u16 vdisplay;
> + u16 vsync_start;
> + u16 vsync_end;
> + u16 vtotal;
> + u16 vscan;
> /**
>* @flags:
>*
> @@ -356,19 +356,19 @@ struct drm_display_mode {
>* difference is exactly a factor of 10.
>*/
> int crtc_clock;
> - int crtc_hdisplay;
> - int crtc_hblank_start;
> - int crtc_hblank_end;
> - int crtc_hsync_start;
> - int crtc_hsync_end;
> - int crtc_htotal;
> - int crtc_hskew;
> - int crtc_vdisplay;
> - int crtc_vblank_start;
> - int crtc_vblank_end;
> - int crtc_vsync_start;
> - int crtc_vsync_end;
> - int crtc_vtotal;
> + u16 crtc_hdisplay;
> + u16 crtc_hblank_start;
> + u16 crtc_hblank_end;
> + u16 crtc_hsync_start;
> + u16 crtc_hsync_end;
> + u16 crtc_htotal;
> + u16 crtc_hskew;
> + u16 crtc_vdisplay;
> + u16 crtc_vblank_start;
> + u16 crtc_vblank_end;
> + u16 crtc_vsync_start;
> + u16 crtc_vsync_end;
> + u16 crtc_vtotal;
>
> /**
>* @private_flags:
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/12] drm: Shrink mode->type to u8
On Wed, Feb 19, 2020 at 10:35:39PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We only have 7 bits defined for mode->type. Shrink the storage to u8.
>
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_modes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 2bb2b1a8592a..5c20285cc317 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -270,7 +270,7 @@ struct drm_display_mode {
>*which are stuck around for hysterical raisins only. No one has an
>*idea what they were meant for. Don't use.
>*/
> - unsigned int type;
> + u8 type;
Unfortunately DRM_MODE_TYPE_DRIVER is the largest and still in use,
otherwise we could have cut off a few more bits here :-)
Reviewed-by: Daniel Vetter
>
> /**
>* @clock:
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
On Thu, Feb 20, 2020 at 05:33:09PM +0200, Ville Syrjälä wrote: > On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 20:36, Ville Syrjala > > wrote: > > > > > > From: Ville Syrjälä > > > > > > The driver never sets mode->private_flags so copying > > > it back and forth is entirely pointless. Stop doing it. > > > > > > Also drop private_flags from the tracepoint. > > > > > > Cc: Rob Clark > > > Cc: Sean Paul > > > Cc: linux-arm-...@vger.kernel.org > > > Cc: freedr...@lists.freedesktop.org > > > Signed-off-by: Ville Syrjälä > > > > Perhaps the msm team has a WIP which makes use of it ? > > Maybe if it's one of them five year projects. But anyways, > with an atomic driver there are certainly better ways to > handle this. Yeah with atomic you have your display mode in drm_crtc_state, which you're subposed to subclass so that you can have terabytes of private state. At least in theory :-) ->private_flags was really only useful in pre-atomic drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > On 2/18/20 10:01 PM, Daniel Vetter wrote:
> > > On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
> > > wrote:
> > > > On 2/17/20 6:55 PM, Daniel Vetter wrote:
> > > > > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> > > > > > Implement the importer side of unpinned DMA-buf handling.
> > > > > >
> > > > > > v2: update page tables immediately
> > > > > >
> > > > > > Signed-off-by: Christian König
> > > > > > ---
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
> > > > > > -
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
> > > > > > 2 files changed, 71 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > index 770baba621b3..48de7624d49c 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > @@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct
> > > > > > drm_device *dev, struct dma_buf *dma_buf)
> > > > > > return ERR_PTR(ret);
> > > > > > }
> > > > > >
> > > > > > +/**
> > > > > > + * amdgpu_dma_buf_move_notify - _notify implementation
> > > > > > + *
> > > > > > + * @attach: the DMA-buf attachment
> > > > > > + *
> > > > > > + * Invalidate the DMA-buf attachment, making sure that
> > > > > > the we re-create the
> > > > > > + * mapping before the next use.
> > > > > > + */
> > > > > > +static void
> > > > > > +amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> > > > > > +{
> > > > > > + struct drm_gem_object *obj = attach->importer_priv;
> > > > > > + struct ww_acquire_ctx *ticket =
> > > > > > dma_resv_locking_ctx(obj->resv);
> > > > > > + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> > > > > > + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> > > > > > + struct ttm_operation_ctx ctx = { false, false };
> > > > > > + struct ttm_placement placement = {};
> > > > > > + struct amdgpu_vm_bo_base *bo_base;
> > > > > > + int r;
> > > > > > +
> > > > > > + if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
> > > > > > + return;
> > > > > > +
> > > > > > + r = ttm_bo_validate(>tbo, , );
> > > > > > + if (r) {
> > > > > > + DRM_ERROR("Failed to invalidate DMA-buf
> > > > > > import (%d))\n", r);
> > > > > > + return;
> > > > > > + }
> > > > > > +
> > > > > > + for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
> > > > > > + struct amdgpu_vm *vm = bo_base->vm;
> > > > > > + struct dma_resv *resv =
> > > > > > vm->root.base.bo->tbo.base.resv;
> > > > > > +
> > > > > > + if (ticket) {
> > > > > Yeah so this is kinda why I've been a total pain about the
> > > > > exact semantics
> > > > > of the move_notify hook. I think we should flat-out require
> > > > > that importers
> > > > > _always_ have a ticket attach when they call this, and that
> > > > > they can cope
> > > > > with additional locks being taken (i.e. full EDEADLCK) handling.
> > > > >
> > > > > Simplest way to force that contract is to add a dummy 2nd
> > > > > ww_mutex lock to
> > > > > the dma_resv object, which we then can take #ifdef
> > > > > CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
> > > > >
> > > > > Now the real disaster is how we handle deadlocks. Two issues:
> > > > >
> > > > > - Ideally we'd keep any lock we've taken locked until the
> > > > > end, it helps
> > > > > needless backoffs. I've played around a bit with that
> > > > > but not even poc
> > > > > level, just an idea:
> > > > >
> > > > > https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
> > > > >
> > > > >
> > > > > Idea is essentially to track a list of objects we had to
> > > > > lock as part of
> > > > > the ttm_bo_validate of the main object.
> > > > >
> > > > > - Second one is if we get a EDEADLCK on one of these
> > > > > sublocks (like the
> > > > > one here). We need to pass that up the entire callchain,
> > > > > including a
> > > > > temporary reference (we have to drop locks to do the
> > > > > ww_mutex_lock_slow
> > > > > call), and need a custom callback to drop that temporary reference
> > > > > (since that's all driver specific, might even be
> > > > > internal ww_mutex and
> > > > > not anything remotely looking like a normal dma_buf).
> > > > > This probably
> > > > > needs the exec util helpers from ttm, but at the
> > > > > dma_resv level, so that
> > > > > we can do something like this:
> > > > >
> > > > > struct dma_resv_ticket {
> > > > > struct ww_acquire_ctx base;
> > > > >
> > > > > /* can be set by anyone (including other drivers)
> > > > > that got
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,01/10] drm/i915/debugfs: Pass guc_log struct to i915_guc_log_info
== Series Details == Series: series starting with [CI,01/10] drm/i915/debugfs: Pass guc_log struct to i915_guc_log_info URL : https://patchwork.freedesktop.org/series/73610/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16611_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16611_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16611_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_16611_full: ### IGT changes ### Possible regressions * igt@gem_exec_balancer@bonded-slice: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@gem_exec_balan...@bonded-slice.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16611/shard-tglb3/igt@gem_exec_balan...@bonded-slice.html New tests - New tests have been introduced between CI_DRM_7963_full and Patchwork_16611_full: ### New IGT tests (58) ### * igt@i915_pm_backlight@bad-brightness: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 0.01] s * igt@i915_pm_backlight@basic-brightness: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.23] s * igt@i915_pm_backlight@fade: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 2.59] s * igt@i915_pm_backlight@fade_with_dpms: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.92] s * igt@i915_pm_backlight@fade_with_suspend: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 5.02] s * igt@i915_pm_lpsp@edp-native: - Statuses : 8 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_lpsp@edp-panel-fitter: - Statuses : 8 skip(s) - Exec time: [0.0, 0.05] s * igt@i915_pm_lpsp@non-edp: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.11] s * igt@i915_pm_lpsp@screens-disabled: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_rc6_residency@media-rc6-accuracy: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_rc6_residency@rc6-accuracy: - Statuses : 8 pass(s) - Exec time: [3.00] s * igt@i915_pm_rpm@basic-pci-d3-state: - Statuses : 7 pass(s) - Exec time: [0.17, 4.97] s * igt@i915_pm_rpm@basic-rte: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [1.33, 11.39] s * igt@i915_pm_rpm@cursor: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 41.33] s * igt@i915_pm_rpm@cursor-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 40.58] s * igt@i915_pm_rpm@debugfs-forcewake-user: - Statuses : 7 pass(s) - Exec time: [10.31, 14.12] s * igt@i915_pm_rpm@debugfs-read: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 80.91] s * igt@i915_pm_rpm@dpms-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.82] s * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 13.42] s * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 3.93] s * igt@i915_pm_rpm@dpms-non-lpsp: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0, 0.16] s * igt@i915_pm_rpm@drm-resources-equal: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 11.08] s * igt@i915_pm_rpm@fences: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 17.06] s * igt@i915_pm_rpm@fences-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 12.76] s * igt@i915_pm_rpm@gem-evict-pwrite: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 3.93] s * igt@i915_pm_rpm@gem-execbuf: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 14.10] s * igt@i915_pm_rpm@gem-execbuf-stress: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 42.76] s * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - Statuses : 8 skip(s) - Exec time: [0.0, 0.01] s * igt@i915_pm_rpm@gem-idle: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 9.21] s * igt@i915_pm_rpm@gem-pread: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 6.37] s * igt@i915_pm_rpm@i2c: - Statuses : 6 pass(s) - Exec time: [1.39, 11.37] s * igt@i915_pm_rpm@legacy-planes: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 169.75] s * igt@i915_pm_rpm@legacy-planes-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 150.38] s * igt@i915_pm_rpm@modeset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.97] s * igt@i915_pm_rpm@modeset-lpsp-stress: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 55.05] s *
Re: [Intel-gfx] [PATCH v2] drm/i915/ehl: Donot reuse icl get and put dplls
On Wed, Feb 19, 2020 at 04:32:50PM -0800, Radhakrishna Sripada wrote:
Elkhartlake does not have as many PLL combinations as Icelake.
Use a simpler get pll function and reuse intel_put_pll for ehl.
v2: Fix the build error
Suggested-by: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +++-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 57 +++
2 files changed, 54 insertions(+), 14 deletions(-)
but is it changing the pll assigments? is it fixing anything? That's
what important to know in the commit message. By the
insertion/deletions, doesn't really look simpler if previous code was
working.
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee7d54ccd3e6..9bb6ccb5b3ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10763,10 +10763,15 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
return;
}
- pipe_config->icl_port_dplls[port_dpll_id].pll =
- intel_get_shared_dpll_by_id(dev_priv, id);
+ if (!IS_ELKHARTLAKE(dev_priv)) {
+ pipe_config->icl_port_dplls[port_dpll_id].pll =
+ intel_get_shared_dpll_by_id(dev_priv, id);
- icl_set_active_port_dpll(pipe_config, port_dpll_id);
+ icl_set_active_port_dpll(pipe_config, port_dpll_id);
+ } else {
+ pipe_config->shared_dpll =
+ intel_get_shared_dpll_by_id(dev_priv, id);
isn't this change independent and the real change ?
Lucas De Marchi
+ }
}
static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index e5bfe5245276..6092abc2b875 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3016,8 +3016,7 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
intel_atomic_get_new_crtc_state(state, crtc);
struct icl_port_dpll *port_dpll =
_state->icl_port_dplls[ICL_PORT_DPLL_DEFAULT];
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum port port = encoder->port;
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
unsigned long dpll_mask;
if (!icl_calc_dpll_state(crtc_state, encoder, _dpll->hw_state)) {
@@ -3027,13 +3026,7 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
return false;
}
- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
- dpll_mask =
- BIT(DPLL_ID_EHL_DPLL4) |
- BIT(DPLL_ID_ICL_DPLL1) |
- BIT(DPLL_ID_ICL_DPLL0);
- else
- dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
port_dpll->pll = intel_find_shared_dpll(state, crtc,
_dpll->hw_state,
@@ -3154,6 +3147,48 @@ static void icl_put_dplls(struct intel_atomic_state
*state,
}
}
+static bool ehl_get_dpll(struct intel_atomic_state *state,
+struct intel_crtc *crtc,
+struct intel_encoder *encoder)
+{
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ struct intel_shared_dpll *pll;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum port port = encoder->port;
+ unsigned long dpll_mask;
+
+
+ if (!icl_calc_dpll_state(crtc_state, encoder,
_state->dpll_hw_state)) {
+ DRM_DEBUG_KMS("Could not calculate combo PHY PLL state.\n");
+
+ return false;
+ }
+
+ if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
+ dpll_mask =
+ BIT(DPLL_ID_EHL_DPLL4) |
+ BIT(DPLL_ID_ICL_DPLL1) |
+ BIT(DPLL_ID_ICL_DPLL0);
+ else
+ dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+
+ pll = intel_find_shared_dpll(state, crtc,
+_state->dpll_hw_state,
+dpll_mask);
+ if (!pll) {
+ DRM_DEBUG_KMS("No PLL selected\n");
+ return false;
+ }
+
+ intel_reference_shared_dpll(state, crtc,
+ pll, _state->dpll_hw_state);
+
+ crtc_state->shared_dpll = pll;
+
+ return true;
+}
+
static bool mg_pll_get_hw_state(struct drm_i915_private *dev_priv,
struct intel_shared_dpll *pll,
struct intel_dpll_hw_state *hw_state)
@@ -3751,8 +3786,8 @@ static
[Intel-gfx] [PATCH i-g-t] i915/i915_pm_rpm: Only check for suspend failures after each debugfs entry
Since we check before and then after each debugfs entry, we do not need
to check before each time as well. We will error out as soon as it does
fail, at all other times we know the system to be idle.
No impact on runtime for glk (which apparently is one of the better
behaving systems).
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
tests/i915/i915_pm_rpm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
index 0c2821122..bf412b5cc 100644
--- a/tests/i915/i915_pm_rpm.c
+++ b/tests/i915/i915_pm_rpm.c
@@ -932,9 +932,6 @@ static int read_entry(const char *filepath,
int fd;
int rc;
- igt_assert_f(wait_for_suspended(), "Before opening: %s (%s)\n",
-filepath + pathinfo->base, filepath);
-
fd = open(filepath, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
igt_debug("Failed to open '%s': %m\n", filepath);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be still repeated for each known mmap-offset
mapping type while effectively exercising GTT mapping type only. As
that may be confusing, fix it.
It has been assumed that the modified macro is still suitable for use
inside gem_mmap_offset test itself. Would that not be case,
gem_mmap_offset could redefine the macro back to its initial form for
internal use.
v2: Move extra condition to a separate function and call it via
for_each_if(), in case we need to fix it again in future (Chris)
v3: Fix blind copy-paste
Suggested-by: Michał Winiarski
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
lib/i915/gem_mman.c | 5 +
lib/i915/gem_mman.h | 7 +--
tests/i915/gem_ctx_sseu.c| 2 +-
tests/i915/gem_exec_params.c | 2 +-
tests/i915/gem_madvise.c | 18 ++
tests/i915/gem_mmap_offset.c | 10 +-
tests/i915/i915_pm_rpm.c | 2 +-
7 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 08ae67696..93bef2bfc 100644
--- a/lib/i915/gem_mman.c
+++ b/lib/i915/gem_mman.c
@@ -60,6 +60,11 @@ bool gem_has_mmap_offset(int fd)
return gtt_version >= 4;
}
+bool gem_has_mmap_offset_type(int fd, const struct mmap_offset *t)
+{
+ return gem_has_mmap_offset(fd) || t->type == I915_MMAP_OFFSET_GTT;
+}
+
/**
* __gem_mmap__gtt:
* @fd: open i915 drm file descriptor
diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
index 4fc6a0186..2c4a7a00b 100644
--- a/lib/i915/gem_mman.h
+++ b/lib/i915/gem_mman.h
@@ -101,10 +101,13 @@ extern const struct mmap_offset {
unsigned int domain;
} mmap_offset_types[];
-#define for_each_mmap_offset_type(__t) \
+bool gem_has_mmap_offset_type(int fd, const struct mmap_offset *t);
+
+#define for_each_mmap_offset_type(fd, __t) \
for (const struct mmap_offset *__t = mmap_offset_types; \
(__t)->name; \
-(__t)++)
+(__t)++) \
+ for_each_if(gem_has_mmap_offset_type((fd), (__t)))
#endif /* GEM_MMAN_H */
diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
index d558c8baa..3bef11b51 100644
--- a/tests/i915/gem_ctx_sseu.c
+++ b/tests/i915/gem_ctx_sseu.c
@@ -531,7 +531,7 @@ igt_main
test_invalid_sseu(fd);
igt_subtest_with_dynamic("mmap-args") {
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(fd, t) {
igt_dynamic_f("%s", t->name)
test_mmapped_args(fd, t);
}
diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index e2912685b..cf7ea3065 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -244,7 +244,7 @@ static void mmapped(int i915)
buf = gem_create(i915, 4096);
handle = batch_create(i915);
- for_each_mmap_offset_type(t) { /* repetitive! */
+ for_each_mmap_offset_type(i915, t) { /* repetitive! */
struct drm_i915_gem_execbuffer2 *execbuf;
struct drm_i915_gem_exec_object2 *exec;
diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
index e8716a891..54c9befff 100644
--- a/tests/i915/gem_madvise.c
+++ b/tests/i915/gem_madvise.c
@@ -62,12 +62,13 @@ dontneed_before_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
gem_madvise(fd, handle, I915_MADV_DONTNEED);
@@ -93,7 +94,11 @@ dontneed_before_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigsegv);
signal(SIGSEGV, old_sigbus);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
@@ -103,12 +108,13 @@ dontneed_after_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
ptr = __gem_mmap_offset(fd, handle, 0, OBJECT_SIZE,
@@ -134,7 +140,11 @@ dontneed_after_mmap(void)
munmap(ptr, OBJECT_SIZE);
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza wrote:
> dGFX have local memory so it do not have aperture and do not support
> CPU fences but even for iGFX it have a small number of fences.
>
> As replacement for fences to track frontbuffer modifications by CPU
> we have a software tracking that is already in used by FBC and PSR.
> PSR don't support fences so it shows that this tracking is reliable.
>
> So lets make fences a nice-to-have to activate FBC for GEN9+, this
> will allow us to enable FBC for dGFXs and iGFXs even when there is no
> available fence.
>
> We do not set fences to rotated planes but FBC only have restrictions
> against 16bpp, so adding it here.
>
> Also adding a new check for the tiling format, fences are only set
> to X and Y tiled planes but again FBC don't have any restrictions
> against tiling so adding linear as supported as well, other formats
> should be added after tested but IGT only supports drawing in thse
> 3 formats.
>
> intel_fbc_hw_tracking_covers_screen() maybe can also have the same
> treatment as fences but BSpec is not clear if the size limitation is
> for hardware tracking or general use of FBC and I don't have a 5K
> display to test it, so keeping as is for safety.
>
> v2:
> - Added tiling and pixel format rotation checks
> - Changed the GEN version not requiring fences to 11 from 9, DDX
> needs some changes but it don't have support for GEN11+
>
> v3:
> - Changed back to GEN9+
> - Moved GEN test to inside of tiling_is_valid()
>
> Cc: Daniel Vetter
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 45
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 2 files changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 1d76e3646a25..a0d1d661a006 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -585,7 +585,7 @@ static bool stride_is_valid(struct drm_i915_private
> *dev_priv,
> }
>
> static bool pixel_format_is_valid(struct drm_i915_private *dev_priv,
> - u32 pixel_format)
> + u32 pixel_format, unsigned int rotation)
> {
> switch (pixel_format) {
> case DRM_FORMAT_XRGB:
> @@ -599,6 +599,9 @@ static bool pixel_format_is_valid(struct drm_i915_private
> *dev_priv,
> /* WaFbcOnly1to1Ratio:ctg */
> if (IS_G4X(dev_priv))
> return false;
> + if ((rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270)) &&
> + INTEL_GEN(dev_priv) >= 9)
> + return false;
Would still would prefer a rotations_is_valid() or some such thing.
> return true;
> default:
> return false;
> @@ -639,6 +642,22 @@ static bool intel_fbc_hw_tracking_covers_screen(struct
> intel_crtc *crtc)
> return effective_w <= max_w && effective_h <= max_h;
> }
>
> +static bool tiling_is_valid(struct drm_i915_private *dev_priv,
> + uint64_t modifier)
> +{
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + if (INTEL_GEN(dev_priv) >= 9)
> + return true;
Have we checked that eg. fbcon cursor still blinks correctly
with FBC active and all?
> + return false;
> + case I915_FORMAT_MOD_X_TILED:
> + case I915_FORMAT_MOD_Y_TILED:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
>const struct intel_crtc_state
> *crtc_state,
>const struct intel_plane_state
> *plane_state)
> @@ -672,6 +691,7 @@ static void intel_fbc_update_state_cache(struct
> intel_crtc *crtc,
>
> cache->fb.format = fb->format;
> cache->fb.stride = fb->pitches[0];
> + cache->fb.modifier = fb->modifier;
>
> drm_WARN_ON(_priv->drm, plane_state->flags & PLANE_HAS_FENCE &&
> !plane_state->vma->fence);
> @@ -720,23 +740,33 @@ static bool intel_fbc_can_activate(struct intel_crtc
> *crtc)
> return false;
> }
>
> - /* The use of a CPU fence is mandatory in order to detect writes
> - * by the CPU to the scanout and trigger updates to the FBC.
> + /* The use of a CPU fence is one of two ways to detect writes by the
> + * CPU to the scanout and trigger updates to the FBC.
> + *
> + * The other method is by software tracking(see
> + * intel_fbc_invalidate/flush()), it will manually notify FBC and nuke
> + * the current compressed buffer and recompress it.
>*
>* Note that is possible for a tiled surface to be unmappable (and
> - * so have no fence
Re: [Intel-gfx] [PATCH v2 7/7] drm/i915: Fix broken num_entries in skl_ddb_allocation_overlaps
On Tue, Feb 11, 2020 at 10:55:32PM +0530, Anshuman Gupta wrote:
> skl_ddb_allocation_overlaps() num_entries hass been passed as
> INTEL_NUM_PIPES, it should be I915_MAX_PIPES.
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6fdaeb019fef..dd77324206bc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15475,7 +15475,6 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
> struct intel_crtc *crtc;
> struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
> - const u8 num_pipes = INTEL_NUM_PIPES(dev_priv);
> u8 update_pipes = 0, modeset_pipes = 0;
> int i;
>
> @@ -15512,7 +15511,7 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
> continue;
>
> if
> (skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
> - entries, num_pipes,
> pipe))
> + entries,
> I915_MAX_PIPES, pipe))
> continue;
>
> entries[pipe] = new_crtc_state->wm.skl.ddb;
> @@ -15550,7 +15549,7 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
> continue;
>
> WARN_ON(skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
> - entries, num_pipes, pipe));
> + entries, I915_MAX_PIPES,
> pipe));
>
> entries[pipe] = new_crtc_state->wm.skl.ddb;
> modeset_pipes &= ~BIT(pipe);
> @@ -15585,7 +15584,7 @@ static void skl_commit_modeset_enables(struct
> intel_atomic_state *state)
> continue;
>
> WARN_ON(skl_ddb_allocation_overlaps(_crtc_state->wm.skl.ddb,
> - entries, num_pipes, pipe));
> + entries, I915_MAX_PIPES,
> pipe));
>
> entries[pipe] = new_crtc_state->wm.skl.ddb;
> modeset_pipes &= ~BIT(pipe);
> --
> 2.24.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Double check bumping after the spinlock
== Series Details == Series: series starting with [1/2] drm/i915: Double check bumping after the spinlock URL : https://patchwork.freedesktop.org/series/73707/ State : success == Summary == CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16645 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/index.html New tests - New tests have been introduced between CI_DRM_7973 and Patchwork_16645: ### New IGT tests (4) ### * igt@i915_pm_backlight@basic-brightness: - Statuses : 1 dmesg-warn(s) 13 pass(s) 22 skip(s) - Exec time: [0.0, 0.22] s * igt@i915_pm_rpm@basic-pci-d3-state: - Statuses : 1 dmesg-warn(s) 25 pass(s) 10 skip(s) - Exec time: [0.0, 6.74] s * igt@i915_pm_rpm@basic-rte: - Statuses : 1 dmesg-warn(s) 25 pass(s) 10 skip(s) - Exec time: [0.45, 17.72] s * igt@i915_pm_rps@basic-api: - Statuses : 31 pass(s) 5 skip(s) - Exec time: [0.0, 0.02] s Known issues Here are the changes found in Patchwork_16645 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_gtt: - fi-hsw-4770r: [PASS][1] -> [TIMEOUT][2] ([fdo#112271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-4770r/igt@i915_selftest@live_gtt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-hsw-4770r/igt@i915_selftest@live_gtt.html * igt@prime_self_import@basic-llseek-size: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html Possible fixes * igt@gem_exec_parallel@contexts: - fi-byt-n2820: [FAIL][5] ([i915#694]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_exec_paral...@contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-byt-n2820/igt@gem_exec_paral...@contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][7] ([i915#217]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@prime_self_import@basic-llseek-bad: - fi-tgl-y: [DMESG-WARN][9] ([CI#94] / [i915#402]) -> [PASS][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html Warnings * igt@amdgpu/amd_prime@amd-to-i915: - fi-icl-u3: [SKIP][11] ([fdo#109315]) -> [SKIP][12] ([fdo#109315] / [i915#585]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [FAIL][14] ([fdo#111096] / [i915#323]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 Participating hosts (49 -> 39) -- Additional (4): fi-kbl-soraka fi-skl-lmem fi-ivb-3770 fi-pnv-d510 Missing(14): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-skl-6770hq fi-hsw-peppy fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-8109u fi-bsw-kefka fi-bdw-samus fi-bsw-nick fi-skl-6600u Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7973 -> Patchwork_16645 CI-20190529: 20190529 CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: Fix wrongly populated plane possible_crtcs bit mask
On Tue, Feb 11, 2020 at 10:55:29PM +0530, Anshuman Gupta wrote:
> As a disabled pipe in pipe_mask is not having a valid intel crtc,
> driver wrongly populates the possible_crtcs mask while initializing
> the plane for a CRTC. Fixing up the plane possible_crtcs mask.
>
> changes since RFC:
> - Simplify the possible_crtcs initialization. [Ville]
>
> v2:
> - Removed the unnecessary stack garbage possible_crtcs to
> drm_universal_plane_init. [Ville]
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 13 +
> drivers/gpu/drm/i915/display/intel_sprite.c | 5 +
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a3649020ea97..5ba0b40fbfde 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16768,6 +16768,18 @@ static void intel_crtc_free(struct intel_crtc *crtc)
> kfree(crtc);
> }
>
> +static void intel_plane_possible_crtcs_init(struct drm_i915_private
> *dev_priv)
> +{
> + struct intel_plane *plane;
> +
> + for_each_intel_plane(_priv->drm, plane) {
> + struct intel_crtc *crtc;
> +
> + crtc = intel_get_crtc_for_pipe(dev_priv, plane->pipe);
> + plane->base.possible_crtcs = drm_crtc_mask(>base);
> + }
> +}
> +
> static int intel_crtc_init(struct drm_i915_private *dev_priv, enum pipe pipe)
> {
> struct intel_plane *primary, *cursor;
> @@ -17964,6 +17976,7 @@ int intel_modeset_init(struct drm_i915_private *i915)
> }
> }
>
> + intel_plane_possible_crtcs_init(i915);
> intel_shared_dpll_init(dev);
> intel_update_fdi_pll_freq(i915);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 7abeefe8dce5..b5c7b271a1a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -3011,7 +3011,6 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> struct intel_plane *plane;
> enum drm_plane_type plane_type;
> unsigned int supported_rotations;
> - unsigned int possible_crtcs;
> const u64 *modifiers;
> const u32 *formats;
> int num_formats;
> @@ -3066,10 +3065,8 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> else
> plane_type = DRM_PLANE_TYPE_OVERLAY;
>
> - possible_crtcs = BIT(pipe);
> -
> ret = drm_universal_plane_init(_priv->drm, >base,
> -possible_crtcs, plane_funcs,
> +0, plane_funcs,
> formats, num_formats, modifiers,
> plane_type,
> "plane %d%c", plane_id + 1,
> --
> 2.24.0
--
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 v2 3/7] drm/i915: Fix broken transcoder err state
On Tue, Feb 11, 2020 at 10:55:28PM +0530, Anshuman Gupta wrote:
> Skip the transcoder whose pipe is disabled while
> initializing transcoder error state in 3 non-contiguous
> display pipe system.
>
> v2:
> - Don't skip EDP_TRANSCODER error state. [Ville]
> - Use a helper has_transcoder(). [Ville]
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display_types.h | 14 ++
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5333f7a7db42..a3649020ea97 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -19051,7 +19051,7 @@ intel_display_capture_error_state(struct
> drm_i915_private *dev_priv)
> for (i = 0; i < ARRAY_SIZE(error->transcoder); i++) {
> enum transcoder cpu_transcoder = transcoders[i];
>
> - if (!INTEL_INFO(dev_priv)->trans_offsets[cpu_transcoder])
> + if (!has_transcoder(dev_priv, cpu_transcoder))
> continue;
>
> error->transcoder[i].available = true;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 14e3d78fef7c..d359f1636ba8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1626,4 +1626,18 @@ static inline u32 intel_plane_ggtt_offset(const struct
> intel_plane_state *state)
> return i915_ggtt_offset(state->vma);
> }
>
> +static inline bool
> +has_transcoder(struct drm_i915_private *dev_priv, enum transcoder
> transcoder) {
{ is in the wrong place.
> + switch (transcoder) {
> + case TRANSCODER_EDP:
> + return HAS_TRANSCODER_EDP(dev_priv);
> + case TRANSCODER_DSI_0:
> + return HAS_TRANSCODER_DSI0(dev_priv);
> + case TRANSCODER_DSI_1:
> + return HAS_TRANSCODER_DSI1(dev_priv);
The error capture so far doesn't care about DSI, so I wouldn't bother
with these for now.
> + default:
> + return INTEL_INFO(dev_priv)->pipe_mask & BIT(transcoder);
> + }
> +}
This functions has one user so no point in putting it into a header.
> +
> #endif /* __INTEL_DISPLAY_TYPES_H__ */
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index da509d9b8895..17bbaf7f0844 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1674,6 +1674,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg)
> #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr)
> #define HAS_TRANSCODER_EDP(dev_priv)
> (INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_EDP] != 0)
> +#define HAS_TRANSCODER_DSI0(dev_priv)
> (INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_DSI_0] != 0)
> +#define HAS_TRANSCODER_DSI1(dev_priv)
> (INTEL_INFO(dev_priv)->trans_offsets[TRANSCODER_DSI_1] != 0)
>
> #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)->has_rc6)
> #define HAS_RC6p(dev_priv)(INTEL_INFO(dev_priv)->has_rc6p)
> --
> 2.24.0
--
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 v2 2/7] drm/i915: Remove (pipe == crtc->index) assumption
On Tue, Feb 11, 2020 at 10:55:27PM +0530, Anshuman Gupta wrote:
> we can't have (pipe == crtc->index) assumption in
> driver in order to support 3 non-contiguous
> display pipe system.
>
> FIXME: Remove the WARN_ON(drm_crtc_index(>base) != crtc->pipe)
> when we will fix all such assumption.
>
> changes since RFC:
> - Added again removed (pipe == crtc->index) WARN_ON.
> - Pass drm_crtc_index instead of intel pipe in order to
> call drm_handle_vblank().
>
> v2:
> - used drm_crtc_handle_vblank()/drm_crtc_wait_one_vblank()
> instead of drm_handle_vblank/drm_wait_one_vblank(). [Jani]
> - introduced intel_handle_vblank() helper to avoid sprinkle
> of intel_crtc across irq_handlers. [Ville]
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8
> drivers/gpu/drm/i915/display/intel_display_types.h | 14 +-
> drivers/gpu/drm/i915/i915_irq.c| 14 +++---
> 3 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 80eebdc4c670..5333f7a7db42 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14395,11 +14395,11 @@ verify_single_dpll_state(struct drm_i915_private
> *dev_priv,
> if (new_crtc_state->hw.active)
> I915_STATE_WARN(!(pll->active_mask & crtc_mask),
> "pll active mismatch (expected pipe %c in
> active mask 0x%02x)\n",
> - pipe_name(drm_crtc_index(>base)),
> pll->active_mask);
> + pipe_name(crtc->pipe), pll->active_mask);
> else
> I915_STATE_WARN(pll->active_mask & crtc_mask,
> "pll active mismatch (didn't expect pipe %c in
> active mask 0x%02x)\n",
> - pipe_name(drm_crtc_index(>base)),
> pll->active_mask);
> + pipe_name(crtc->pipe), pll->active_mask);
>
> I915_STATE_WARN(!(pll->state.crtc_mask & crtc_mask),
> "pll enabled crtcs mismatch (expected 0x%x in
> 0x%02x)\n",
> @@ -14428,10 +14428,10 @@ verify_shared_dpll_state(struct intel_crtc *crtc,
>
> I915_STATE_WARN(pll->active_mask & crtc_mask,
> "pll active mismatch (didn't expect pipe %c in
> active mask)\n",
> - pipe_name(drm_crtc_index(>base)));
> + pipe_name(crtc->pipe));
> I915_STATE_WARN(pll->state.crtc_mask & crtc_mask,
> "pll enabled crtcs mismatch (found %x in
> enabled mask)\n",
> - pipe_name(drm_crtc_index(>base)));
> + pipe_name(crtc->pipe));
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 283c622f8ba1..14e3d78fef7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1595,11 +1595,23 @@ intel_crtc_has_dp_encoder(const struct
> intel_crtc_state *crtc_state)
>(1 << INTEL_OUTPUT_DP_MST) |
>(1 << INTEL_OUTPUT_EDP));
> }
> +
> static inline void
> intel_wait_for_vblank(struct drm_i915_private *dev_priv, enum pipe pipe)
> {
> - drm_wait_one_vblank(_priv->drm, pipe);
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> +
> + drm_crtc_wait_one_vblank(>base);
> +}
> +
> +static inline void
> +intel_handle_vblank(struct drm_i915_private *dev_priv, enum pipe pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> +
> + drm_crtc_handle_vblank(>base);
> }
There's no reason to put that into a header. Just put it into
i915_irq.c. With that
Reviewed-by: Ville Syrjälä
> +
> static inline void
> intel_wait_for_vblank_if_active(struct drm_i915_private *dev_priv, enum pipe
> pipe)
> {
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a26f2bf1b6ea..bfd3b34f2be3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1364,7 +1364,7 @@ static void i8xx_pipestat_irq_handler(struct
> drm_i915_private *dev_priv,
>
> for_each_pipe(dev_priv, pipe) {
> if (pipe_stats[pipe] & PIPE_VBLANK_INTERRUPT_STATUS)
> - drm_handle_vblank(_priv->drm, pipe);
> + intel_handle_vblank(dev_priv, pipe);
>
> if (pipe_stats[pipe] & PIPE_CRC_DONE_INTERRUPT_STATUS)
> i9xx_pipe_crc_irq_handler(dev_priv, pipe);
> @@ -1382,7 +1382,7 @@ static void i915_pipestat_irq_handler(struct
> drm_i915_private *dev_priv,
>
> for_each_pipe(dev_priv, pipe) {
> if
Re: [Intel-gfx] [PATCH i-g-t v2] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
Please ignore this submission, the code is broken. Sorry for that.
Janusz
On Thursday, February 20, 2020 6:08:19 PM CET Janusz Krzysztofik wrote:
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> API. However, when run on an older version of the driver, those
> subtests are believed to be still repeated for each known mmap-offset
> mapping type while effectively exercising GTT mapping type only. As
> that may be confusing, fix it.
>
> It has been assumed that the modified macro is still suitable for use
> inside gem_mmap_offset test itself. Would that not be case,
> gem_mmap_offset could redefine the macro back to its initial form for
> internal use.
>
> v2: Move extra condition to a separate function and call it via
> for_each_if(), in case we need to fix it again in future (Chris)
>
> Suggested-by: Michał Winiarski
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> ---
> lib/i915/gem_mman.c | 5 +
> lib/i915/gem_mman.h | 7 +--
> tests/i915/gem_ctx_sseu.c| 2 +-
> tests/i915/gem_exec_params.c | 2 +-
> tests/i915/gem_madvise.c | 18 ++
> tests/i915/gem_mmap_offset.c | 10 +-
> tests/i915/i915_pm_rpm.c | 2 +-
> 7 files changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> index 08ae67696..6fa8d1e8b 100644
> --- a/lib/i915/gem_mman.c
> +++ b/lib/i915/gem_mman.c
> @@ -60,6 +60,11 @@ bool gem_has_mmap_offset(int fd)
> return gtt_version >= 4;
> }
>
> +bool gem_has_mmap_offset_type(int fd, const struct mmap_offset *t);
> +{
> + return gem_has_mmap_offset(fd) || t->type == I915_MMAP_OFFSET_GTT;
> +}
> +
> /**
> * __gem_mmap__gtt:
> * @fd: open i915 drm file descriptor
> diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
> index 4fc6a0186..2c4a7a00b 100644
> --- a/lib/i915/gem_mman.h
> +++ b/lib/i915/gem_mman.h
> @@ -101,10 +101,13 @@ extern const struct mmap_offset {
> unsigned int domain;
> } mmap_offset_types[];
>
> -#define for_each_mmap_offset_type(__t) \
> +bool gem_has_mmap_offset_type(int fd, const struct mmap_offset *t);
> +
> +#define for_each_mmap_offset_type(fd, __t) \
> for (const struct mmap_offset *__t = mmap_offset_types; \
>(__t)->name; \
> - (__t)++)
> + (__t)++) \
> + for_each_if(gem_has_mmap_offset_type((fd), (__t)))
>
> #endif /* GEM_MMAN_H */
>
> diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
> index d558c8baa..3bef11b51 100644
> --- a/tests/i915/gem_ctx_sseu.c
> +++ b/tests/i915/gem_ctx_sseu.c
> @@ -531,7 +531,7 @@ igt_main
> test_invalid_sseu(fd);
>
> igt_subtest_with_dynamic("mmap-args") {
> - for_each_mmap_offset_type(t) {
> + for_each_mmap_offset_type(fd, t) {
> igt_dynamic_f("%s", t->name)
> test_mmapped_args(fd, t);
> }
> diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
> index e2912685b..cf7ea3065 100644
> --- a/tests/i915/gem_exec_params.c
> +++ b/tests/i915/gem_exec_params.c
> @@ -244,7 +244,7 @@ static void mmapped(int i915)
> buf = gem_create(i915, 4096);
> handle = batch_create(i915);
>
> - for_each_mmap_offset_type(t) { /* repetitive! */
> + for_each_mmap_offset_type(i915, t) { /* repetitive! */
> struct drm_i915_gem_execbuffer2 *execbuf;
> struct drm_i915_gem_exec_object2 *exec;
>
> diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
> index e8716a891..54c9befff 100644
> --- a/tests/i915/gem_madvise.c
> +++ b/tests/i915/gem_madvise.c
> @@ -62,12 +62,13 @@ dontneed_before_mmap(void)
> char *ptr;
> int fd;
>
> - for_each_mmap_offset_type(t) {
> + fd = drm_open_driver(DRIVER_INTEL);
> +
> + for_each_mmap_offset_type(fd, t) {
> sighandler_t old_sigsegv, old_sigbus;
>
> igt_debug("Mapping mode: %s\n", t->name);
>
> - fd = drm_open_driver(DRIVER_INTEL);
> handle = gem_create(fd, OBJECT_SIZE);
> gem_madvise(fd, handle, I915_MADV_DONTNEED);
>
> @@ -93,7 +94,11 @@ dontneed_before_mmap(void)
> munmap(ptr, OBJECT_SIZE);
> signal(SIGBUS, old_sigsegv);
> signal(SIGSEGV, old_sigbus);
> +
> + fd = drm_open_driver(DRIVER_INTEL);
> }
> +
> + close(fd);
> }
>
> static void
> @@ -103,12 +108,13 @@ dontneed_after_mmap(void)
> char *ptr;
> int fd;
>
> - for_each_mmap_offset_type(t) {
> + fd = drm_open_driver(DRIVER_INTEL);
> +
> + for_each_mmap_offset_type(fd, t) {
> sighandler_t old_sigsegv, old_sigbus;
>
>
[Intel-gfx] [PATCH i-g-t v2] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be still repeated for each known mmap-offset
mapping type while effectively exercising GTT mapping type only. As
that may be confusing, fix it.
It has been assumed that the modified macro is still suitable for use
inside gem_mmap_offset test itself. Would that not be case,
gem_mmap_offset could redefine the macro back to its initial form for
internal use.
v2: Move extra condition to a separate function and call it via
for_each_if(), in case we need to fix it again in future (Chris)
Suggested-by: Michał Winiarski
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
lib/i915/gem_mman.c | 5 +
lib/i915/gem_mman.h | 7 +--
tests/i915/gem_ctx_sseu.c| 2 +-
tests/i915/gem_exec_params.c | 2 +-
tests/i915/gem_madvise.c | 18 ++
tests/i915/gem_mmap_offset.c | 10 +-
tests/i915/i915_pm_rpm.c | 2 +-
7 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 08ae67696..6fa8d1e8b 100644
--- a/lib/i915/gem_mman.c
+++ b/lib/i915/gem_mman.c
@@ -60,6 +60,11 @@ bool gem_has_mmap_offset(int fd)
return gtt_version >= 4;
}
+bool gem_has_mmap_offset_type(int fd, const struct mmap_offset *t);
+{
+ return gem_has_mmap_offset(fd) || t->type == I915_MMAP_OFFSET_GTT;
+}
+
/**
* __gem_mmap__gtt:
* @fd: open i915 drm file descriptor
diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
index 4fc6a0186..2c4a7a00b 100644
--- a/lib/i915/gem_mman.h
+++ b/lib/i915/gem_mman.h
@@ -101,10 +101,13 @@ extern const struct mmap_offset {
unsigned int domain;
} mmap_offset_types[];
-#define for_each_mmap_offset_type(__t) \
+bool gem_has_mmap_offset_type(int fd, const struct mmap_offset *t);
+
+#define for_each_mmap_offset_type(fd, __t) \
for (const struct mmap_offset *__t = mmap_offset_types; \
(__t)->name; \
-(__t)++)
+(__t)++) \
+ for_each_if(gem_has_mmap_offset_type((fd), (__t)))
#endif /* GEM_MMAN_H */
diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
index d558c8baa..3bef11b51 100644
--- a/tests/i915/gem_ctx_sseu.c
+++ b/tests/i915/gem_ctx_sseu.c
@@ -531,7 +531,7 @@ igt_main
test_invalid_sseu(fd);
igt_subtest_with_dynamic("mmap-args") {
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(fd, t) {
igt_dynamic_f("%s", t->name)
test_mmapped_args(fd, t);
}
diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index e2912685b..cf7ea3065 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -244,7 +244,7 @@ static void mmapped(int i915)
buf = gem_create(i915, 4096);
handle = batch_create(i915);
- for_each_mmap_offset_type(t) { /* repetitive! */
+ for_each_mmap_offset_type(i915, t) { /* repetitive! */
struct drm_i915_gem_execbuffer2 *execbuf;
struct drm_i915_gem_exec_object2 *exec;
diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
index e8716a891..54c9befff 100644
--- a/tests/i915/gem_madvise.c
+++ b/tests/i915/gem_madvise.c
@@ -62,12 +62,13 @@ dontneed_before_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
gem_madvise(fd, handle, I915_MADV_DONTNEED);
@@ -93,7 +94,11 @@ dontneed_before_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigsegv);
signal(SIGSEGV, old_sigbus);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
@@ -103,12 +108,13 @@ dontneed_after_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
ptr = __gem_mmap_offset(fd, handle, 0, OBJECT_SIZE,
@@ -134,7 +140,11 @@ dontneed_after_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS,
[Intel-gfx] [PATCH v7 8/8] drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@@
identifier func, T;
@@
func(struct intel_vgpu *T,...) {
+struct drm_i915_private *i915 = T->gvt->dev_priv;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/gvt/cfg_space.c| 23 +++
drivers/gpu/drm/i915/gvt/display.c | 3 ++-
drivers/gpu/drm/i915/gvt/edid.c | 17 +-
drivers/gpu/drm/i915/gvt/gtt.c | 21 -
drivers/gpu/drm/i915/gvt/handlers.c | 20 -
drivers/gpu/drm/i915/gvt/interrupt.c| 15 -
drivers/gpu/drm/i915/gvt/kvmgt.c| 10 ++---
drivers/gpu/drm/i915/gvt/mmio.c | 30 +++--
drivers/gpu/drm/i915/gvt/mmio_context.c | 6 +++--
drivers/gpu/drm/i915/gvt/scheduler.c| 6 +++--
drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++--
11 files changed, 104 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 19cf1bbe059d..7fd16bab2f39 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -106,10 +106,13 @@ static void vgpu_pci_cfg_mem_write(struct intel_vgpu
*vgpu, unsigned int off,
int intel_vgpu_emulate_cfg_read(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
- if (WARN_ON(bytes > 4))
+ struct drm_i915_private *i915 = vgpu->gvt->dev_priv;
+
+ if (drm_WARN_ON(>drm, bytes > 4))
return -EINVAL;
- if (WARN_ON(offset + bytes > vgpu->gvt->device_info.cfg_space_size))
+ if (drm_WARN_ON(>drm,
+ offset + bytes > vgpu->gvt->device_info.cfg_space_size))
return -EINVAL;
memcpy(p_data, vgpu_cfg_space(vgpu) + offset, bytes);
@@ -297,34 +300,36 @@ static int emulate_pci_bar_write(struct intel_vgpu *vgpu,
unsigned int offset,
int intel_vgpu_emulate_cfg_write(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
+ struct drm_i915_private *i915 = vgpu->gvt->dev_priv;
int ret;
- if (WARN_ON(bytes > 4))
+ if (drm_WARN_ON(>drm, bytes > 4))
return -EINVAL;
- if (WARN_ON(offset + bytes > vgpu->gvt->device_info.cfg_space_size))
+ if (drm_WARN_ON(>drm,
+ offset + bytes > vgpu->gvt->device_info.cfg_space_size))
return -EINVAL;
/* First check if it's PCI_COMMAND */
if (IS_ALIGNED(offset, 2) && offset == PCI_COMMAND) {
- if (WARN_ON(bytes > 2))
+ if (drm_WARN_ON(>drm, bytes > 2))
return -EINVAL;
return emulate_pci_command_write(vgpu, offset, p_data, bytes);
}
switch (rounddown(offset, 4)) {
case PCI_ROM_ADDRESS:
- if (WARN_ON(!IS_ALIGNED(offset, 4)))
+ if (drm_WARN_ON(>drm, !IS_ALIGNED(offset, 4)))
return -EINVAL;
return emulate_pci_rom_bar_write(vgpu, offset, p_data, bytes);
case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_5:
- if (WARN_ON(!IS_ALIGNED(offset, 4)))
+ if (drm_WARN_ON(>drm, !IS_ALIGNED(offset, 4)))
return -EINVAL;
return emulate_pci_bar_write(vgpu, offset, p_data, bytes);
case INTEL_GVT_PCI_SWSCI:
- if (WARN_ON(!IS_ALIGNED(offset, 4)))
+ if (drm_WARN_ON(>drm, !IS_ALIGNED(offset, 4)))
return -EINVAL;
ret = intel_vgpu_emulate_opregion_request(vgpu, *(u32 *)p_data);
if (ret)
@@ -332,7 +337,7 @@ int intel_vgpu_emulate_cfg_write(struct intel_vgpu *vgpu,
unsigned int offset,
break;
case INTEL_GVT_PCI_OPREGION:
- if (WARN_ON(!IS_ALIGNED(offset, 4)))
+ if (drm_WARN_ON(>drm, !IS_ALIGNED(offset, 4)))
return -EINVAL;
ret = intel_vgpu_opregion_base_write_handler(vgpu,
*(u32 *)p_data);
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index 9a9329fb8d64..9bfc0ae30157 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -320,9 +320,10 @@ static void clean_virtual_dp_monitor(struct intel_vgpu
*vgpu, int port_num)
static int setup_virtual_dp_monitor(struct intel_vgpu *vgpu, int port_num,
[Intel-gfx] [PATCH v7 7/8] drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/gvt/aperture_gm.c | 6 +++---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/gvt/display.c | 3 ++-
drivers/gpu/drm/i915/gvt/dmabuf.c | 4 ++--
drivers/gpu/drm/i915/gvt/edid.c | 2 +-
drivers/gpu/drm/i915/gvt/gvt.c | 4 ++--
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
8 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index 771420453f82..29eed8400647 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -134,11 +134,11 @@ void intel_vgpu_write_fence(struct intel_vgpu *vgpu,
assert_rpm_wakelock_held(_priv->runtime_pm);
- if (WARN_ON(fence >= vgpu_fence_sz(vgpu)))
+ if (drm_WARN_ON(_priv->drm, fence >= vgpu_fence_sz(vgpu)))
return;
reg = vgpu->fence.regs[fence];
- if (WARN_ON(!reg))
+ if (drm_WARN_ON(_priv->drm, !reg))
return;
fence_reg_lo = FENCE_REG_GEN6_LO(reg->id);
@@ -167,7 +167,7 @@ static void free_vgpu_fence(struct intel_vgpu *vgpu)
struct i915_fence_reg *reg;
u32 i;
- if (WARN_ON(!vgpu_fence_sz(vgpu)))
+ if (drm_WARN_ON(_priv->drm, !vgpu_fence_sz(vgpu)))
return;
intel_runtime_pm_get(_priv->runtime_pm);
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 21a176cd8acc..73a2891114a4 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1230,7 +1230,7 @@ static int gen8_decode_mi_display_flip(struct
parser_exec_state *s,
dword2 = cmd_val(s, 2);
v = (dword0 & GENMASK(21, 19)) >> 19;
- if (WARN_ON(v >= ARRAY_SIZE(gen8_plane_code)))
+ if (drm_WARN_ON(_priv->drm, v >= ARRAY_SIZE(gen8_plane_code)))
return -EBADRQC;
info->pipe = gen8_plane_code[v].pipe;
@@ -1250,7 +1250,7 @@ static int gen8_decode_mi_display_flip(struct
parser_exec_state *s,
info->stride_reg = SPRSTRIDE(info->pipe);
info->surf_reg = SPRSURF(info->pipe);
} else {
- WARN_ON(1);
+ drm_WARN_ON(_priv->drm, 1);
return -EBADRQC;
}
return 0;
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index e1c313da6c00..9a9329fb8d64 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -71,7 +71,8 @@ int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
{
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
- if (WARN_ON(pipe < PIPE_A || pipe >= I915_MAX_PIPES))
+ if (drm_WARN_ON(_priv->drm,
+ pipe < PIPE_A || pipe >= I915_MAX_PIPES))
return -EINVAL;
if (vgpu_vreg_t(vgpu, PIPECONF(pipe)) & PIPECONF_ENABLE)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 2477a1e5a166..b854bd243e11 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -67,11 +67,11 @@ static int vgpu_gem_get_pages(
u32 page_num;
fb_info = (struct intel_vgpu_fb_info *)obj->gvt_info;
- if (WARN_ON(!fb_info))
+ if (drm_WARN_ON(_priv->drm, !fb_info))
return -ENODEV;
vgpu = fb_info->obj->vgpu;
- if (WARN_ON(!vgpu))
+ if (drm_WARN_ON(_priv->drm, !vgpu))
return -ENODEV;
st = kmalloc(sizeof(*st), GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/gvt/edid.c b/drivers/gpu/drm/i915/gvt/edid.c
index 1fe6124918f1..97bf75890c7d 100644
--- a/drivers/gpu/drm/i915/gvt/edid.c
+++ b/drivers/gpu/drm/i915/gvt/edid.c
@@ -153,7 +153,7 @@ static int gmbus0_mmio_write(struct intel_vgpu *vgpu,
port = cnp_get_port_from_gmbus0(pin_select);
else
port = get_port_from_gmbus0(pin_select);
- if (WARN_ON(port < 0))
+
[Intel-gfx] [PATCH v7 6/8] drm/i915/display/hdcp: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 30e0a3aa9d57..229b4e329864 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -872,7 +872,8 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- if (WARN_ON(!intel_hdcp_in_use(dev_priv, cpu_transcoder, port))) {
+ if (drm_WARN_ON(_priv->drm,
+ !intel_hdcp_in_use(dev_priv, cpu_transcoder, port))) {
drm_err(_priv->drm,
"%s:%d HDCP link stopped encryption,%x\n",
connector->base.name, connector->base.base.id,
@@ -1561,8 +1562,9 @@ static int hdcp2_enable_encryption(struct intel_connector
*connector)
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
int ret;
- WARN_ON(intel_de_read(dev_priv, HDCP2_STATUS(dev_priv, cpu_transcoder,
port)) &
- LINK_ENCRYPTION_STATUS);
+ drm_WARN_ON(_priv->drm,
+ intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)) &
+ LINK_ENCRYPTION_STATUS);
if (hdcp->shim->toggle_signalling) {
ret = hdcp->shim->toggle_signalling(intel_dig_port, true);
if (ret) {
@@ -1599,8 +1601,8 @@ static int hdcp2_disable_encryption(struct
intel_connector *connector)
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
int ret;
- WARN_ON(!(intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)) &
- LINK_ENCRYPTION_STATUS));
+ drm_WARN_ON(_priv->drm, !(intel_de_read(dev_priv,
HDCP2_STATUS(dev_priv, cpu_transcoder, port)) &
+ LINK_ENCRYPTION_STATUS));
intel_de_write(dev_priv, HDCP2_CTL(dev_priv, cpu_transcoder, port),
intel_de_read(dev_priv, HDCP2_CTL(dev_priv,
cpu_transcoder, port)) & ~CTL_LINK_ENCRYPTION_REQ);
@@ -1720,7 +1722,8 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
goto out;
}
- if (WARN_ON(!intel_hdcp2_in_use(dev_priv, cpu_transcoder, port))) {
+ if (drm_WARN_ON(_priv->drm,
+ !intel_hdcp2_in_use(dev_priv, cpu_transcoder, port))) {
drm_err(_priv->drm,
"HDCP2.2 link stopped the encryption, %x\n",
intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)));
@@ -1916,7 +1919,7 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
return;
mutex_lock(_priv->hdcp_comp_mutex);
- WARN_ON(dev_priv->hdcp_comp_added);
+ drm_WARN_ON(_priv->drm, dev_priv->hdcp_comp_added);
dev_priv->hdcp_comp_added = true;
mutex_unlock(_priv->hdcp_comp_mutex);
@@ -1990,7 +1993,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
return -ENOENT;
mutex_lock(>mutex);
- WARN_ON(hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
+ drm_WARN_ON(_priv->drm,
+ hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
hdcp->content_type = content_type;
if (INTEL_GEN(dev_priv) >= 12) {
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 5/8] drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_dp.c | 120 ++--
1 file changed, 68 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 74986bc978c2..2bb783276652 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -325,7 +325,8 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
int size, max_rate = 0, vbt_max_rate;
/* This should only be done once */
- WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
+ drm_WARN_ON(_priv->drm,
+ intel_dp->source_rates || intel_dp->num_source_rates);
if (INTEL_GEN(dev_priv) >= 10) {
source_rates = cnl_rates;
@@ -757,10 +758,11 @@ vlv_power_sequencer_kick(struct intel_dp *intel_dp)
enum dpio_channel ch = vlv_pipe_to_channel(pipe);
u32 DP;
- if (WARN(intel_de_read(dev_priv, intel_dp->output_reg) & DP_PORT_EN,
-"skipping pipe %c power sequencer kick due to [ENCODER:%d:%s]
being active\n",
-pipe_name(pipe), intel_dig_port->base.base.base.id,
-intel_dig_port->base.base.name))
+ if (drm_WARN(_priv->drm,
+intel_de_read(dev_priv, intel_dp->output_reg) & DP_PORT_EN,
+"skipping pipe %c power sequencer kick due to
[ENCODER:%d:%s] being active\n",
+pipe_name(pipe), intel_dig_port->base.base.base.id,
+intel_dig_port->base.base.name))
return;
drm_dbg_kms(_priv->drm,
@@ -836,13 +838,16 @@ static enum pipe vlv_find_free_pps(struct
drm_i915_private *dev_priv)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
if (encoder->type == INTEL_OUTPUT_EDP) {
- WARN_ON(intel_dp->active_pipe != INVALID_PIPE &&
- intel_dp->active_pipe != intel_dp->pps_pipe);
+ drm_WARN_ON(_priv->drm,
+ intel_dp->active_pipe != INVALID_PIPE &&
+ intel_dp->active_pipe !=
+ intel_dp->pps_pipe);
if (intel_dp->pps_pipe != INVALID_PIPE)
pipes &= ~(1 << intel_dp->pps_pipe);
} else {
- WARN_ON(intel_dp->pps_pipe != INVALID_PIPE);
+ drm_WARN_ON(_priv->drm,
+ intel_dp->pps_pipe != INVALID_PIPE);
if (intel_dp->active_pipe != INVALID_PIPE)
pipes &= ~(1 << intel_dp->active_pipe);
@@ -865,10 +870,10 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
lockdep_assert_held(_priv->pps_mutex);
/* We should never land here with regular DP ports */
- WARN_ON(!intel_dp_is_edp(intel_dp));
+ drm_WARN_ON(_priv->drm, !intel_dp_is_edp(intel_dp));
- WARN_ON(intel_dp->active_pipe != INVALID_PIPE &&
- intel_dp->active_pipe != intel_dp->pps_pipe);
+ drm_WARN_ON(_priv->drm, intel_dp->active_pipe != INVALID_PIPE &&
+ intel_dp->active_pipe != intel_dp->pps_pipe);
if (intel_dp->pps_pipe != INVALID_PIPE)
return intel_dp->pps_pipe;
@@ -879,7 +884,7 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
* Didn't find one. This should not happen since there
* are two power sequencers and up to two eDP ports.
*/
- if (WARN_ON(pipe ==
[Intel-gfx] [PATCH v7 4/8] drm/i915/display/power: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
.../drm/i915/display/intel_display_power.c| 181 ++
1 file changed, 105 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 722399fc2ace..59b762137a54 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -183,8 +183,9 @@ static void intel_power_well_get(struct drm_i915_private
*dev_priv,
static void intel_power_well_put(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- WARN(!power_well->count, "Use count on power well %s is already zero",
-power_well->desc->name);
+ drm_WARN(_priv->drm, !power_well->count,
+"Use count on power well %s is already zero",
+power_well->desc->name);
if (!--power_well->count)
intel_power_well_disable(dev_priv, power_well);
@@ -294,7 +295,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
power_well->desc->name);
/* An AUX timeout is expected if the TBT DP tunnel is down. */
- WARN_ON(!power_well->desc->hsw.is_tc_tbt);
+ drm_WARN_ON(_priv->drm, !power_well->desc->hsw.is_tc_tbt);
}
}
@@ -347,8 +348,9 @@ static void gen9_wait_for_power_well_fuses(struct
drm_i915_private *dev_priv,
enum skl_power_gate pg)
{
/* Timeout 5us for PG#0, for other PGs 1us */
- WARN_ON(intel_de_wait_for_set(dev_priv, SKL_FUSE_STATUS,
- SKL_FUSE_PG_DIST_STATUS(pg), 1));
+ drm_WARN_ON(_priv->drm,
+ intel_de_wait_for_set(dev_priv, SKL_FUSE_STATUS,
+ SKL_FUSE_PG_DIST_STATUS(pg), 1));
}
static void hsw_power_well_enable(struct drm_i915_private *dev_priv,
@@ -423,7 +425,7 @@ icl_combo_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
enum phy phy = ICL_AUX_PW_TO_PHY(pw_idx);
u32 val;
- WARN_ON(!IS_ICELAKE(dev_priv));
+ drm_WARN_ON(_priv->drm, !IS_ICELAKE(dev_priv));
val = intel_de_read(dev_priv, regs->driver);
intel_de_write(dev_priv, regs->driver,
@@ -455,7 +457,7 @@ icl_combo_phy_aux_power_well_disable(struct
drm_i915_private *dev_priv,
enum phy phy = ICL_AUX_PW_TO_PHY(pw_idx);
u32 val;
- WARN_ON(!IS_ICELAKE(dev_priv));
+ drm_WARN_ON(_priv->drm, !IS_ICELAKE(dev_priv));
val = intel_de_read(dev_priv, ICL_PORT_CL_DW12(phy));
intel_de_write(dev_priv, ICL_PORT_CL_DW12(phy),
@@ -493,7 +495,7 @@ static int power_well_async_ref_count(struct
drm_i915_private *dev_priv,
int refs = hweight64(power_well->desc->domains &
async_put_domains_mask(_priv->power_domains));
- WARN_ON(refs > power_well->count);
+ drm_WARN_ON(_priv->drm, refs > power_well->count);
return refs;
}
@@ -523,7 +525,7 @@ static void icl_tc_port_assert_ref_held(struct
drm_i915_private *dev_priv,
continue;
dig_port = enc_to_dig_port(encoder);
- if (WARN_ON(!dig_port))
+ if (drm_WARN_ON(_priv->drm, !dig_port))
continue;
if (dig_port->aux_ch != aux_ch) {
@@ -534,10 +536,10 @@ static void icl_tc_port_assert_ref_held(struct
drm_i915_private *dev_priv,
break;
}
- if (WARN_ON(!dig_port))
+ if (drm_WARN_ON(_priv->drm, !dig_port))
return;
- WARN_ON(!intel_tc_port_ref_held(dig_port));
+ drm_WARN_ON(_priv->drm, !intel_tc_port_ref_held(dig_port));
}
#else
@@ -623,15 +625,19 @@ static bool hsw_power_well_enabled(struct
drm_i915_private *dev_priv,
static void assert_can_enable_dc9(struct drm_i915_private *dev_priv)
{
- WARN_ONCE((intel_de_read(dev_priv, DC_STATE_EN) & DC_STATE_EN_DC9),
-
[Intel-gfx] [PATCH v7 1/8] drm/i915/display/cdclk: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 84 --
1 file changed, 48 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 146c2b9bb7fb..0741d643455b 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -525,7 +525,8 @@ static void vlv_program_pfi_credits(struct drm_i915_private
*dev_priv)
* FIXME is this guaranteed to clear
* immediately or should we poll for it?
*/
- WARN_ON(intel_de_read(dev_priv, GCI_CONTROL) & PFI_CREDIT_RESEND);
+ drm_WARN_ON(_priv->drm,
+ intel_de_read(dev_priv, GCI_CONTROL) & PFI_CREDIT_RESEND);
}
static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
@@ -727,12 +728,13 @@ static void bdw_set_cdclk(struct drm_i915_private
*dev_priv,
u32 val;
int ret;
- if (WARN((intel_de_read(dev_priv, LCPLL_CTL) &
- (LCPLL_PLL_DISABLE | LCPLL_PLL_LOCK |
- LCPLL_CD_CLOCK_DISABLE | LCPLL_ROOT_CD_CLOCK_DISABLE |
- LCPLL_CD2X_CLOCK_DISABLE | LCPLL_POWER_DOWN_ALLOW |
- LCPLL_CD_SOURCE_FCLK)) != LCPLL_PLL_LOCK,
-"trying to change cdclk frequency with cdclk not enabled\n"))
+ if (drm_WARN(_priv->drm,
+(intel_de_read(dev_priv, LCPLL_CTL) &
+ (LCPLL_PLL_DISABLE | LCPLL_PLL_LOCK |
+ LCPLL_CD_CLOCK_DISABLE | LCPLL_ROOT_CD_CLOCK_DISABLE |
+ LCPLL_CD2X_CLOCK_DISABLE | LCPLL_POWER_DOWN_ALLOW |
+ LCPLL_CD_SOURCE_FCLK)) != LCPLL_PLL_LOCK,
+"trying to change cdclk frequency with cdclk not
enabled\n"))
return;
ret = sandybridge_pcode_write(dev_priv,
@@ -842,15 +844,16 @@ static void skl_dpll0_update(struct drm_i915_private
*dev_priv,
if ((val & LCPLL_PLL_ENABLE) == 0)
return;
- if (WARN_ON((val & LCPLL_PLL_LOCK) == 0))
+ if (drm_WARN_ON(_priv->drm, (val & LCPLL_PLL_LOCK) == 0))
return;
val = intel_de_read(dev_priv, DPLL_CTRL1);
- if (WARN_ON((val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
- DPLL_CTRL1_SSC(SKL_DPLL0) |
- DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
- DPLL_CTRL1_OVERRIDE(SKL_DPLL0)))
+ if (drm_WARN_ON(_priv->drm,
+ (val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
+ DPLL_CTRL1_SSC(SKL_DPLL0) |
+ DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
+ DPLL_CTRL1_OVERRIDE(SKL_DPLL0)))
return;
switch (val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0)) {
@@ -952,7 +955,7 @@ static void skl_dpll0_enable(struct drm_i915_private
*dev_priv, int vco)
{
u32 val;
- WARN_ON(vco != 810 && vco != 864);
+ drm_WARN_ON(_priv->drm, vco != 810 && vco != 864);
/*
* We always enable DPLL0 with the lowest link rate possible, but still
@@ -1017,7 +1020,8 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
* use the corresponding VCO freq as that always leads to using the
* minimum 308MHz CDCLK.
*/
- WARN_ON_ONCE(IS_SKYLAKE(dev_priv) && vco == 864);
+ drm_WARN_ON_ONCE(_priv->drm,
+IS_SKYLAKE(dev_priv) && vco == 864);
ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
SKL_CDCLK_PREPARE_FOR_CHANGE,
@@ -1032,8 +1036,9 @@ static void skl_set_cdclk(struct drm_i915_private
*dev_priv,
/* Choose frequency for this cdclk */
switch (cdclk) {
default:
- WARN_ON(cdclk != dev_priv->cdclk.hw.bypass);
- WARN_ON(vco != 0);
+ drm_WARN_ON(_priv->drm,
+ cdclk != dev_priv->cdclk.hw.bypass);
+ drm_WARN_ON(_priv->drm, vco != 0);
[Intel-gfx] [PATCH v7 3/8] drm/i915/display/display: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display.c | 237 +++
1 file changed, 135 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 48fe3d2e0fa3..526097ba5040 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -203,9 +203,9 @@ int vlv_get_cck_clock(struct drm_i915_private *dev_priv,
val = vlv_cck_read(dev_priv, reg);
divider = val & CCK_FREQUENCY_VALUES;
- WARN((val & CCK_FREQUENCY_STATUS) !=
-(divider << CCK_FREQUENCY_STATUS_SHIFT),
-"%s change in progress\n", name);
+ drm_WARN(_priv->drm, (val & CCK_FREQUENCY_STATUS) !=
+(divider << CCK_FREQUENCY_STATUS_SHIFT),
+"%s change in progress\n", name);
return DIV_ROUND_CLOSEST(ref_freq << 1, divider + 1);
}
@@ -882,7 +882,7 @@ static bool vlv_PLL_is_optimal(struct drm_device *dev, int
target_freq,
return calculated_clock->p > best_clock->p;
}
- if (WARN_ON_ONCE(!target_freq))
+ if (drm_WARN_ON_ONCE(dev, !target_freq))
return false;
*error_ppm = div_u64(100ULL *
@@ -1090,7 +1090,8 @@ intel_wait_for_pipe_off(const struct intel_crtc_state
*old_crtc_state)
/* Wait for the Pipe State to go off */
if (intel_de_wait_for_clear(dev_priv, reg,
I965_PIPECONF_ACTIVE, 100))
- WARN(1, "pipe_off wait timed out\n");
+ drm_WARN(_priv->drm, 1,
+"pipe_off wait timed out\n");
} else {
intel_wait_for_pipe_scanline_stopped(crtc);
}
@@ -1205,7 +1206,7 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
enum pipe panel_pipe = INVALID_PIPE;
bool locked = true;
- if (WARN_ON(HAS_DDI(dev_priv)))
+ if (drm_WARN_ON(_priv->drm, HAS_DDI(dev_priv)))
return;
if (HAS_PCH_SPLIT(dev_priv)) {
@@ -1241,7 +1242,8 @@ void assert_panel_unlocked(struct drm_i915_private
*dev_priv, enum pipe pipe)
pp_reg = PP_CONTROL(0);
port_sel = intel_de_read(dev_priv, PP_ON_DELAYS(0)) &
PANEL_PORT_SELECT_MASK;
- WARN_ON(port_sel != PANEL_PORT_SELECT_LVDS);
+ drm_WARN_ON(_priv->drm,
+ port_sel != PANEL_PORT_SELECT_LVDS);
intel_lvds_port_enabled(dev_priv, LVDS, _pipe);
}
@@ -1482,7 +1484,9 @@ static void chv_enable_pll(struct intel_crtc *crtc,
* DPLLB VGA mode also seems to cause problems.
* We should always have it disabled.
*/
- WARN_ON((intel_de_read(dev_priv, DPLL(PIPE_B)) &
DPLL_VGA_MODE_DIS) == 0);
+ drm_WARN_ON(_priv->drm,
+ (intel_de_read(dev_priv, DPLL(PIPE_B)) &
+DPLL_VGA_MODE_DIS) == 0);
} else {
intel_de_write(dev_priv, DPLL_MD(pipe),
pipe_config->dpll_hw_state.dpll_md);
@@ -1630,10 +1634,11 @@ void vlv_wait_port_ready(struct drm_i915_private
*dev_priv,
if (intel_de_wait_for_register(dev_priv, dpll_reg,
port_mask, expected_mask, 1000))
- WARN(1, "timed out waiting for [ENCODER:%d:%s] port ready: got
0x%x, expected 0x%x\n",
-dport->base.base.base.id, dport->base.base.name,
-
[Intel-gfx] [PATCH v7 2/8] drm/i915/display/ddi: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(>drm,
...)
|
-WARN_ON(
+drm_WARN_ON(>drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(>drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(>drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_ddi.c | 92 +---
1 file changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ff292dfe2dd3..9f7d1d7189ae 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1006,18 +1006,18 @@ static int intel_ddi_hdmi_level(struct intel_encoder
*encoder)
intel_ddi_get_buf_trans_hdmi(dev_priv, _entries);
default_entry = 6;
} else {
- WARN(1, "ddi translation table missing\n");
+ drm_WARN(_priv->drm, 1, "ddi translation table missing\n");
return 0;
}
- if (WARN_ON_ONCE(n_entries == 0))
+ if (drm_WARN_ON_ONCE(_priv->drm, n_entries == 0))
return 0;
level = intel_bios_hdmi_level_shift(encoder);
if (level < 0)
level = default_entry;
- if (WARN_ON_ONCE(level >= n_entries))
+ if (drm_WARN_ON_ONCE(_priv->drm, level >= n_entries))
level = n_entries - 1;
return level;
@@ -1075,9 +1075,9 @@ static void intel_prepare_hdmi_ddi_buffers(struct
intel_encoder *encoder,
ddi_translations = intel_ddi_get_buf_trans_hdmi(dev_priv, _entries);
- if (WARN_ON_ONCE(!ddi_translations))
+ if (drm_WARN_ON_ONCE(_priv->drm, !ddi_translations))
return;
- if (WARN_ON_ONCE(level >= n_entries))
+ if (drm_WARN_ON_ONCE(_priv->drm, level >= n_entries))
level = n_entries - 1;
/* If we're boosting the current, set bit 31 of trans1 */
@@ -1208,7 +1208,7 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
/* Configure Port Clock Select */
ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc_state->shared_dpll);
intel_de_write(dev_priv, PORT_CLK_SEL(PORT_E), ddi_pll_sel);
- WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
+ drm_WARN_ON(_priv->drm, ddi_pll_sel != PORT_CLK_SEL_SPLL);
/* Start the training iterating through available voltages and emphasis,
* testing each value twice. */
@@ -1317,8 +1317,9 @@ intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
}
if (num_encoders != 1)
- WARN(1, "%d encoders on crtc for pipe %c\n", num_encoders,
-pipe_name(crtc->pipe));
+ drm_WARN(dev, 1, "%d encoders on crtc for pipe %c\n",
+num_encoders,
+pipe_name(crtc->pipe));
BUG_ON(ret == NULL);
return ret;
@@ -1476,7 +1477,7 @@ int cnl_calc_wrpll_link(struct drm_i915_private *dev_priv,
dco_freq += (((pll_state->cfgcr0 & DPLL_CFGCR0_DCO_FRACTION_MASK) >>
DPLL_CFGCR0_DCO_FRACTION_SHIFT) * ref_clock) / 0x8000;
- if (WARN_ON(p0 == 0 || p1 == 0 || p2 == 0))
+ if (drm_WARN_ON(_priv->drm, p0 == 0 || p1 == 0 || p2 == 0))
return 0;
return dco_freq / (p0 * p1 * p2 * 5);
@@ -1664,7 +1665,7 @@ static void cnl_ddi_clock_get(struct intel_encoder
*encoder,
link_clock = 405000;
break;
default:
- WARN(1, "Unsupported link rate\n");
+ drm_WARN(_priv->drm, 1, "Unsupported link rate\n");
break;
}
link_clock *= 2;
@@ -1756,12 +1757,12 @@ static void hsw_ddi_clock_get(struct intel_encoder
*encoder,
else if (pll == SPLL_FREQ_2700MHz)
[Intel-gfx] [PATCH v7 0/8] drm: Introduce struct drm_device based WARN* and use them in i915
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel include device information in the backtrace, so we know what device the warnings originate from. Similar to this, add new struct drm_device based drm_WARN* macros. These macros include device information in the backtrace, so we know what device the warnings originate from. Knowing the device specific information in the backtrace would be helpful in development all around. This patch series aims to convert calls of WARN(), WARN_ON(), WARN_ONCE() and WARN_ON_ONCE() in i915 driver to use the drm device-specific variants automatically wherever struct device pointer is available. To do this, this patch series - - introduces new struct drm_device based WARN* macros - automatically converts WARN* with device specific dev_WARN* variants using coccinelle semantic patch scripts. The goal is to convert all the calls of WARN* with drm_WARN* in i915, but there are still cases where device pointer is not readily available in some functions (or I missed them somehow) using WARN* hence some manual churning is needed. Handle such remaining cases separately later. changes since v6: - rebase unmerged patches onto drm-tip (07350317e4b2 dm-tip: 2020y-02m-20d-12h-11m-40s UTC integration manifest) changes since v5: - rebase unmerged patches onto drm-tip (db0579be2554 drm-tip: 2020y-02m-05d-10h-51m-13s UTC integration manifest) changes since v4: - Address Jani's comment - split major i915/display related conversions per file into seperate patches so that non conflicting patches can be merged. changes since v3: - rebase pending unmerged patches on drm-tip (bc626bbb5b6e drm-tip: 2020y-01m-25d-14h-28m-41s UTC integration manifest) changes since v2: - rebase pending unmerged patches on drm-tip changes since v1: - Address Jani's review comments - Fix typo in comment of patch 0001 - Get rid of helper functions - Split patches by directory Changes since RFC at [1] - Introduce drm_WARN* macros and use them as suggested by Sam and Jani - Get rid of extra local variables [1] https://patchwork.freedesktop.org/series/71668/ Pankaj Bharadiya (8): drm/i915/display/cdclk: Make WARN* drm specific where drm_priv ptr is available drm/i915/display/ddi: Make WARN* drm specific where drm_device ptr is available drm/i915/display/display: Make WARN* drm specific where drm_device ptr is available drm/i915/display/power: Make WARN* drm specific where drm_priv ptr is available drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available drm/i915/display/hdcp: Make WARN* drm specific where drm_priv ptr is available drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available drivers/gpu/drm/i915/display/intel_cdclk.c| 84 --- drivers/gpu/drm/i915/display/intel_ddi.c | 92 --- drivers/gpu/drm/i915/display/intel_display.c | 237 ++ .../drm/i915/display/intel_display_power.c| 181 +++-- drivers/gpu/drm/i915/display/intel_dp.c | 120 + drivers/gpu/drm/i915/display/intel_hdcp.c | 20 +- drivers/gpu/drm/i915/gvt/aperture_gm.c| 6 +- drivers/gpu/drm/i915/gvt/cfg_space.c | 23 +- drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 +- drivers/gpu/drm/i915/gvt/display.c| 6 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 4 +- drivers/gpu/drm/i915/gvt/edid.c | 19 +- drivers/gpu/drm/i915/gvt/gtt.c| 21 +- drivers/gpu/drm/i915/gvt/gvt.c| 4 +- drivers/gpu/drm/i915/gvt/handlers.c | 22 +- drivers/gpu/drm/i915/gvt/interrupt.c | 15 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 10 +- drivers/gpu/drm/i915/gvt/mmio.c | 30 ++- drivers/gpu/drm/i915/gvt/mmio_context.c | 8 +- drivers/gpu/drm/i915/gvt/scheduler.c | 6 +- drivers/gpu/drm/i915/gvt/vgpu.c | 6 +- 21 files changed, 537 insertions(+), 381 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
On Thu, 20 Feb 2020 at 14:28, Ville Syrjälä wrote: > > On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala > > wrote: > > > > > > From: Ville Syrjälä > > > > > > struct drm_display_mode is extremely fat. Put it on diet. > > > > > > Some stats for the whole series: > > > > > > 64bit sizeof(struct drm_display_mode): > > > 200 -> 136 bytes (-32%) > > > > > > 64bit bloat-o-meter -c drm.ko: > > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) > > > Function old new delta > > > ... > > > Total: Before=189430, After=188779, chg -0.34% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=11667, After=11667, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes 1000 680-320 > > > edid_est_modes 34002312 -1088 > > > edid_cea_modes_193 54003672 -1728 > > > drm_dmt_modes 17600 11968 -5632 > > > edid_cea_modes_1 25400 17272 -8128 > > > Total: Before=71239, After=54343, chg -23.72% > > > > > > > > > 64bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547) > > > ... > > > Total: Before=272336, After=254789, chg -6.44% > > > > > > > > > 32bit sizeof(struct drm_display_mode): > > > 184 -> 120 bytes (-34%) > > > > > > 32bit bloat-o-meter -c drm.ko > > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625) > > > Function old new delta > > > ... > > > Total: Before=172359, After=171734, chg -0.36% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=4227, After=4227, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes920 600-320 > > > edid_est_modes 31282040 -1088 > > > edid_cea_modes_193 49683240 -1728 > > > drm_dmt_modes 16192 10560 -5632 > > > edid_cea_modes_1 23368 15240 -8128 > > > Total: Before=59230, After=42334, chg -28.53% > > > > > > 32bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521) > > > ... > > > Total: Before=235816, After=218295, chg -7.43% > > > > > > > > > Some ideas for further reduction: > > > - Convert mode->name to a pointer (saves 24/28 bytes in the > > > struct but would often require a heap alloc for the name (though > > > typical mode name is <10 bytes so still overall win perhaps) > > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only > > > place where we have to preserve the user provided name, elsewhere > > > could pehaps just generate on demand? Not sure how tricky this > > > would get. > > > > The series does some great work, with future work reaching the cache > > line for 64bit. > > Doing much more than that might be an overkill IMHO. > > > > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there, > > avoiding the heap alloc/calc on demand fun. > > While also ensuring the name is sufficiently large for the next decade or > > so. > > Unfortunately it's part of the uabi. So can't change it without some > risk of userspace breakage. > Right the define is in the uABI. More importantly userspace can provide a drm_mode_modeinfo blob, with a name[32], which we cannot store in the kernel drm_display_mode::name[24]. One might get away with returning -EINVAL if the actual name given by the user is > 24. Since you've found a better way, there's on point in risking it. -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] sw_sync: Use fixed runtime for sync_expired_merge
Convert from using a fixed number of iterations (1 million), to using a
fixed runtime so that we have predictable (and shorter!) run times across
a wide variety of machines.
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
tests/sw_sync.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 626b6d39f..6e439496d 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -747,30 +747,27 @@ static void test_sync_multi_producer_single_consumer(void)
static void test_sync_expired_merge(void)
{
- int iterations = 1 << 20;
int timeline;
- int i;
- int fence_expired, fence_merged;
+ int expired;
timeline = sw_sync_timeline_create();
sw_sync_timeline_inc(timeline, 100);
- fence_expired = sw_sync_timeline_create_fence(timeline, 1);
- igt_assert_f(sync_fence_wait(fence_expired, 0) == 0,
+ expired = sw_sync_timeline_create_fence(timeline, 1);
+ igt_assert_f(sync_fence_wait(expired, 0) == 0,
"Failure waiting for expired fence\n");
- fence_merged = sync_fence_merge(fence_expired, fence_expired);
- close(fence_merged);
+ close(sync_fence_merge(expired, expired));
- for (i = 0; i < iterations; i++) {
- int fence = sync_fence_merge(fence_expired, fence_expired);
+ igt_until_timeout(2) {
+ int fence = sync_fence_merge(expired, expired);
igt_assert_f(sync_fence_wait(fence, -1) == 0,
"Failure waiting on fence\n");
close(fence);
}
- close(fence_expired);
+ close(expired);
}
static void test_sync_random_merge(void)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_eio: Trim kms workload
We don't need to try reset-stress on every engine with the display, just
once is enough to stress any interlinkage.
This should reduce the runtime to 10s.
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
tests/i915/gem_eio.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index 0fe51efeb..1ec609410 100644
--- a/tests/i915/gem_eio.c
+++ b/tests/i915/gem_eio.c
@@ -898,8 +898,14 @@ static void test_kms(int i915, igt_display_t *dpy)
test_inflight(i915, 0);
if (gem_has_contexts(i915)) {
- test_reset_stress(i915, 0);
- test_reset_stress(i915, TEST_WEDGE);
+ uint32_t ctx = context_create_safe(i915);
+
+ reset_stress(i915, ctx,
+"default", I915_EXEC_DEFAULT, 0);
+ reset_stress(i915, ctx,
+"default", I915_EXEC_DEFAULT, TEST_WEDGE);
+
+ gem_context_destroy(i915, ctx);
}
*shared = 1;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Double check bumping after the spinlock
== Series Details ==
Series: series starting with [1/2] drm/i915: Double check bumping after the
spinlock
URL : https://patchwork.freedesktop.org/series/73707/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00c160893898 drm/i915: Double check bumping after the spinlock
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a79ca656b648 ("drm/i915: Push
the wakeref->count deferral to the backend")'
#10:
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
e5bc0f843da3 drm/i915: Protect i915_request_await_start from early waits
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Refactor Gen11+ SAGV support
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16644
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16644 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16644, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16644:
### IGT changes ###
Possible regressions
* igt@debugfs_test@read_all_entries:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-hsw-peppy/igt@debugfs_test@read_all_entries.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-pnv-d510/igt@run...@aborted.html
- fi-hsw-peppy: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-hsw-peppy/igt@run...@aborted.html
- fi-gdg-551: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-gdg-551/igt@run...@aborted.html
- fi-byt-n2820: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-byt-n2820/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-ivb-3770/igt@run...@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-blb-e6850/igt@run...@aborted.html
Warnings
* igt@runner@aborted:
- fi-elk-e7500: [FAIL][9] ([fdo#110446]) -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-elk-e7500/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-elk-e7500/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-ehl-1}: NOTRUN -> [FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-ehl-1/igt@run...@aborted.html
New tests
-
New tests have been introduced between CI_DRM_7973 and Patchwork_16644:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses :
- Exec time: [None] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses :
- Exec time: [None] s
* igt@i915_pm_rpm@basic-rte:
- Statuses :
- Exec time: [None] s
* igt@i915_pm_rps@basic-api:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_16644 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-bsw-nick:[PASS][12] -> [INCOMPLETE][13] ([i915#392])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-nick/igt@gem_exec_susp...@basic-s0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-bsw-nick/igt@gem_exec_susp...@basic-s0.html
- fi-bdw-5557u: [PASS][14] -> [INCOMPLETE][15] ([i915#146])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bdw-5557u/igt@gem_exec_susp...@basic-s0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-bdw-5557u/igt@gem_exec_susp...@basic-s0.html
- fi-bsw-n3050: [PASS][16] -> [INCOMPLETE][17] ([i915#392])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html
- fi-byt-n2820: [PASS][18] -> [INCOMPLETE][19] ([i915#45])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_exec_susp...@basic-s0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-byt-n2820/igt@gem_exec_susp...@basic-s0.html
Warnings
* igt@runner@aborted:
- fi-kbl-8809g: [FAIL][20] ([i915#1209]) -> [FAIL][21] ([i915#192] /
[i915#193] / [i915#194])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-8809g/igt@run...@aborted.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-kbl-8809g/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Refactor Gen11+ SAGV support
== Series Details == Series: Refactor Gen11+ SAGV support URL : https://patchwork.freedesktop.org/series/73703/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915: Start passing latency as parameter Okay! Commit: drm/i915: Introduce skl_plane_wm_level accessor. Okay! Commit: drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state Okay! Commit: drm/i915: Refactor intel_can_enable_sagv +drivers/gpu/drm/i915/intel_pm.c:3851:6: warning: symbol 'intel_compute_sagv_mask' was not declared. Should it be static? +drivers/gpu/drm/i915/intel_pm.c:3905:6: warning: symbol 'intel_calculate_sagv_result' was not declared. Should it be static? Commit: drm/i915: Added required new PCode commands Okay! Commit: drm/i915: Restrict qgv points which don't have enough bandwidth. Okay! Commit: drm/i915: Enable SAGV support for Gen12 Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Refactor Gen11+ SAGV support
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5d070083c766 drm/i915: Start passing latency as parameter
0ada6eb4565d drm/i915: Introduce skl_plane_wm_level accessor.
8ba23cf9 drm/i915: Init obj state in
intel_atomic_get_old/new_global_obj_state
-:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#12:
also in intel_atomic_get_old_global_obj_state and
intel_atomic_get_new_global_obj_state
-:45: WARNING:LINE_SPACING: Missing a blank line after declarations
#45: FILE: drivers/gpu/drm/i915/display/intel_bw.c:395:
+ struct intel_global_state *bw_state;
+ bw_state = intel_atomic_get_new_global_obj_state(state,
_priv->bw_obj);
total: 0 errors, 2 warnings, 0 checks, 49 lines checked
44d1ee8de76a drm/i915: Refactor intel_can_enable_sagv
-:77: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#77:
when using skl_plane_wm_level accessor, as we had previously for Gen11+
-:204: CHECK:LINE_SPACING: Please don't use multiple blank lines
#204: FILE: drivers/gpu/drm/i915/display/intel_global_state.h:87:
+
-:299: CHECK:LINE_SPACING: Please don't use multiple blank lines
#299: FILE: drivers/gpu/drm/i915/intel_pm.c:3812:
+
+
-:360: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'state->active_pipes == dev_priv->active_pipes'
#360: FILE: drivers/gpu/drm/i915/intel_pm.c:3873:
+ if ((state->active_pipes == dev_priv->active_pipes) &&
+ (total_affected_planes == 0)) {
-:360: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'total_affected_planes == 0'
#360: FILE: drivers/gpu/drm/i915/intel_pm.c:3873:
+ if ((state->active_pipes == dev_priv->active_pipes) &&
+ (total_affected_planes == 0)) {
-:406: WARNING:LINE_SPACING: Missing a blank line after declarations
#406: FILE: drivers/gpu/drm/i915/intel_pm.c:3919:
+ int active_pipe_bit = dev_priv->active_pipes & BIT(pipe);
+ if (active_pipe_bit) {
-:594: CHECK:LINE_SPACING: Please don't use multiple blank lines
#594: FILE: drivers/gpu/drm/i915/intel_pm.c:4831:
+
+
-:687: WARNING:LONG_LINE: line over 100 characters
#687: FILE: drivers/gpu/drm/i915/intel_pm.c:5904:
+ old_wm->sagv_wm0.min_ddb_alloc :
old_wm->wm[0].min_ddb_alloc;
-:690: WARNING:LONG_LINE: line over 100 characters
#690: FILE: drivers/gpu/drm/i915/intel_pm.c:5907:
+ new_wm->sagv_wm0.min_ddb_alloc :
new_wm->wm[0].min_ddb_alloc;
-:802: WARNING:LONG_LINE: line over 100 characters
#802: FILE: drivers/gpu/drm/i915/intel_pm.c:6146:
+
_crtc_state->wm.skl.optimal.planes[plane_id])) {
total: 0 errors, 5 warnings, 5 checks, 729 lines checked
0acee8e77bfd drm/i915: Added required new PCode commands
e96fefdd8ad6 drm/i915: Restrict qgv points which don't have enough bandwidth.
b0b1b0e549ad drm/i915: Enable SAGV support for Gen12
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 49/52] drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call
Den 19.02.2020 11.21, skrev Daniel Vetter: > Allows us to drop the drm_driver.release callback from all > drivers, and remove the mipi_dbi_release() function. > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Eric Anholt > Cc: David Lechner > Cc: Kamlesh Gurudasani > Cc: "Noralf Trønnes" > Cc: Sam Ravnborg > --- Reviewed-by: Noralf Trønnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 48/52] drm/mipi-dbi: Move drm_mode_config_init into mipi library
Den 19.02.2020 11.21, skrev Daniel Vetter: > 7/7 drivers agree that's the right choice, let's do this. > > This avoids duplicating the same old error checking code over all 7 > drivers, which is the motivation here. > > Signed-off-by: Daniel Vetter > --- Reviewed-by: Noralf Trønnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/52] drm/repaper: Drop explicit drm_mode_config_cleanup call
Den 19.02.2020 11.21, skrev Daniel Vetter: > Allows us to drop the drm_driver.release callback. > > Signed-off-by: Daniel Vetter > Cc: "Noralf Trønnes" > --- Reviewed-by: Noralf Trønnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/52] drm/repaper: Use drmm_add_final_kfree
Den 19.02.2020 11.20, skrev Daniel Vetter: > With this we can drop the final kfree from the release function. > > Signed-off-by: Daniel Vetter > Cc: "Noralf Trønnes" > --- Reviewed-by: Noralf Trønnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/52] drm/mipi_dbi: Use drmm_add_final_kfree in all drivers
Den 19.02.2020 11.20, skrev Daniel Vetter: > They all share mipi_dbi_release so we need to switch them all > together. With this we can drop the final kfree from the release > function. > > Aside, I think we could perhaps have a tiny additional helper for > these mipi_dbi drivers, the first few lines around devm_drm_dev_init > are all the same (except for the drm_driver pointer). > > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Cc: Eric Anholt > Cc: David Lechner > Cc: Kamlesh Gurudasani > Cc: "Noralf Trønnes" > Cc: Sam Ravnborg > Signed-off-by: Daniel Vetter > --- I really would have preferred having devm_drm_dev_alloc() in this series, drmm_add_final_kfree() is rather odd. But I can wait: Reviewed-by: Noralf Trønnes I have tested the whole series on tiny/mi0283qt: Tested-by: Noralf Trønnes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add support for HDCP 1.4 over MST connectors (rev4)
== Series Details == Series: drm/i915: Add support for HDCP 1.4 over MST connectors (rev4) URL : https://patchwork.freedesktop.org/series/70393/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16610_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_7963_full and Patchwork_16610_full: ### New IGT tests (58) ### * igt@i915_pm_backlight@bad-brightness: - Statuses : 3 pass(s) 3 skip(s) - Exec time: [0.0, 0.01] s * igt@i915_pm_backlight@basic-brightness: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.23] s * igt@i915_pm_backlight@fade: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 2.59] s * igt@i915_pm_backlight@fade_with_dpms: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.99] s * igt@i915_pm_backlight@fade_with_suspend: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.45] s * igt@i915_pm_lpsp@edp-native: - Statuses : 8 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_lpsp@edp-panel-fitter: - Statuses : 8 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_lpsp@non-edp: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.11] s * igt@i915_pm_lpsp@screens-disabled: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_rc6_residency@media-rc6-accuracy: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_rc6_residency@rc6-accuracy: - Statuses : 8 pass(s) - Exec time: [3.00] s * igt@i915_pm_rpm@basic-pci-d3-state: - Statuses : 7 pass(s) - Exec time: [0.17, 5.03] s * igt@i915_pm_rpm@basic-rte: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [1.32, 11.52] s * igt@i915_pm_rpm@cursor: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 41.20] s * igt@i915_pm_rpm@cursor-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 36.77] s * igt@i915_pm_rpm@debugfs-forcewake-user: - Statuses : 6 pass(s) - Exec time: [10.31, 14.15] s * igt@i915_pm_rpm@debugfs-read: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 81.00] s * igt@i915_pm_rpm@dpms-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.82] s * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 13.42] s * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 4.15] s * igt@i915_pm_rpm@dpms-non-lpsp: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0, 0.19] s * igt@i915_pm_rpm@drm-resources-equal: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 9.59] s * igt@i915_pm_rpm@fences: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 14.76] s * igt@i915_pm_rpm@fences-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 16.75] s * igt@i915_pm_rpm@gem-evict-pwrite: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 3.97] s * igt@i915_pm_rpm@gem-execbuf: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 15.28] s * igt@i915_pm_rpm@gem-execbuf-stress: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 42.81] s * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - Statuses : 8 skip(s) - Exec time: [0.0, 0.00] s * igt@i915_pm_rpm@gem-idle: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 9.16] s * igt@i915_pm_rpm@gem-pread: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 6.40] s * igt@i915_pm_rpm@i2c: - Statuses : 7 pass(s) - Exec time: [0.94, 11.16] s * igt@i915_pm_rpm@legacy-planes: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 169.67] s * igt@i915_pm_rpm@legacy-planes-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 169.80] s * igt@i915_pm_rpm@modeset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.93] s * igt@i915_pm_rpm@modeset-lpsp-stress: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 55.03] s * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 18.49] s * igt@i915_pm_rpm@modeset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 3.94] s * igt@i915_pm_rpm@modeset-non-lpsp-stress: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 9.13] s * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 7.06] s * igt@i915_pm_rpm@modeset-pc8-residency-stress: - Statuses : 8 skip(s) - Exec time: [0.0] s * igt@i915_pm_rpm@modeset-stress-extra-wait: - Statuses : 6 pass(s) 1 skip(s) - Exec time: [0.0, 72.02] s * igt@i915_pm_rpm@pc8-residency: - Statuses : 8 skip(s) - Exec time: [0.0] s * igt@i915_pm_rpm@pm-caching: - Statuses : 7 pass(s) 1 skip(s) - Exec time:
Re: [Intel-gfx] [PATCH 39/52] drm/stm: Drop explicit drm_mode_config_cleanup call
On Thu, Feb 20, 2020 at 3:19 PM Philippe CORNU wrote: > > Hi Daniel, > > On 2/19/20 11:21 AM, Daniel Vetter wrote: > > It's right above the drm_dev_put(). > > > > Aside: Another driver with a bit much devm_kzalloc, which should > > probably use drmm_kzalloc instead ... > > > > Signed-off-by: Daniel Vetter > > Cc: Yannick Fertre > > Cc: Philippe Cornu > > Cc: Benjamin Gaignard > > Cc: Vincent Abriou > > Cc: Maxime Coquelin > > Cc: Alexandre Torgue > > Cc: linux-st...@st-md-mailman.stormreply.com > > Cc: linux-arm-ker...@lists.infradead.org > > --- > > drivers/gpu/drm/stm/drv.c | 10 -- > > 1 file changed, 4 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c > > index ea9fcbdc68b3..5b374531dd8c 100644 > > --- a/drivers/gpu/drm/stm/drv.c > > +++ b/drivers/gpu/drm/stm/drv.c > > @@ -88,7 +88,9 @@ static int drv_load(struct drm_device *ddev) > > > > ddev->dev_private = (void *)ldev; > > > > - drm_mode_config_init(ddev); > > + ret = drm_mode_config_init(ddev); > > + if (ret) > > + return ret; > > > > /* > >* set max width and height as default value. > > @@ -103,7 +105,7 @@ static int drv_load(struct drm_device *ddev) > > > > ret = ltdc_load(ddev); > > if (ret) > > - goto err; > > + return ret; > > > > drm_mode_config_reset(ddev); > > drm_kms_helper_poll_init(ddev); > > @@ -111,9 +113,6 @@ static int drv_load(struct drm_device *ddev) > > platform_set_drvdata(pdev, ddev); > > > > return 0; > > -err: > > - drm_mode_config_cleanup(ddev); > > - return ret; > > } > > > > static void drv_unload(struct drm_device *ddev) > > @@ -122,7 +121,6 @@ static void drv_unload(struct drm_device *ddev) > > > > drm_kms_helper_poll_fini(ddev); > > ltdc_unload(ddev); > > - drm_mode_config_cleanup(ddev); > > } > > > > static __maybe_unused int drv_suspend(struct device *dev) > > > > Thank you for your patch, > For this stm part, > Acked-by: Philippe Cornu > > note: we will handle devm_kzalloc() asap, thanks. Note that as-is you can't just blindly switch devm_kzalloc over to drmm_kzalloc for the structures containing a drm_* object, or you'll just replace one type of use-after free with another one (and probably worse, since the new one will hit you on normal driver unload too). There's a bit more work needed in this area, this here is just the first steps and a heads up. And removing the devm_kzalloc would result in lots of code added for a bunch of kfree() all over, not so great option either. I'd say wait for the next round :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Use intel_plane_data_rate for min_cdclk calculation
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate and which is also used in bandwidth
calculations. However for calculating min_cdclk we have another
piece of code, doing almost same calculation, but a bit differently
and in a different place. However as both are actually part of same
formula, probably would be wise to use plane data rate calculations
as a basis anyway, thus avoiding code duplication and possible bugs
related to this.
Another thing is that I've noticed that during min_cdclk calculations
we account for plane scaling, while for plane data rate, we don't.
crtc->pixel_rate seems to account only for pipe ratio, however it is
clearly stated in BSpec that plane data rate also need to account
plane ratio as well.
So what this commit does is:
- Adds a plane ratio calculation to intel_plane_data_rate
- Removes redundant calculations from skl_plane_min_cdclk which is
used for gen9+ and now uses intel_plane_data_rate as a basis from
there as well.
v2: - Don't use 64 division if not needed(Ville Syrjälä)
- Now use intel_plane_pixel_rate as a basis for calculations both
at intel_plane_data_rate and skl_plane_min_cdclk(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 22 +++-
.../gpu/drm/i915/display/intel_atomic_plane.h | 3 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 26 +++
3 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index c86d7a35c816..3bd7ea9bf1b4 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -133,11 +133,31 @@ intel_plane_destroy_state(struct drm_plane *plane,
kfree(plane_state);
}
+unsigned int intel_plane_pixel_rate(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
+{
+ unsigned int src_w, src_h, dst_w, dst_h;
+
+ src_w = drm_rect_width(_state->uapi.src) >> 16;
+ src_h = drm_rect_height(_state->uapi.src) >> 16;
+ dst_w = drm_rect_width(_state->uapi.dst);
+ dst_h = drm_rect_height(_state->uapi.dst);
+
+ /* Downscaling limits the maximum pixel rate */
+ dst_w = min(src_w, dst_w);
+ dst_h = min(src_h, dst_h);
+
+ return DIV_ROUND_UP(mul_u32_u32(crtc_state->pixel_rate,
+ src_w * src_h),
+ mul_u32_u32(dst_w, dst_h));
+}
+
unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int cpp;
+ unsigned int plane_pixel_rate = intel_plane_pixel_rate(crtc_state,
plane_state);
if (!plane_state->uapi.visible)
return 0;
@@ -153,7 +173,7 @@ unsigned int intel_plane_data_rate(const struct
intel_crtc_state *crtc_state,
if (fb->format->is_yuv && fb->format->num_planes > 1)
cpp *= 4;
- return cpp * crtc_state->pixel_rate;
+ return mul_u32_u32(plane_pixel_rate, cpp);
}
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index 2bcf15e34728..a6bbf42bae1f 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -18,6 +18,9 @@ struct intel_plane_state;
extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
+unsigned int intel_plane_pixel_rate(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state
*plane_state);
+
unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
void intel_plane_copy_uapi_to_hw_state(struct intel_plane_state *plane_state,
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 7abeefe8dce5..4fa3081e2074 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -330,9 +330,9 @@ bool icl_is_hdr_plane(struct drm_i915_private *dev_priv,
enum plane_id plane_id)
}
static void
-skl_plane_ratio(const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state,
- unsigned int *num, unsigned int *den)
+skl_plane_bpp_constraints(const struct intel_crtc_state *crtc_state,
+
Re: [Intel-gfx] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
Quoting Chris Wilson (2020-02-20 16:09:14)
> Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> > Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> > introduced a macro that makes it easy to repeat a test body within a
> > loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> > API. However, when run on an older version of the driver, those
> > subtests are believed to be still repeated for each known mmap-offset
> > mapping type while effectively exercising GTT mapping type only. As
> > that may be confusing, fix it.
> >
> > It has been assumed that the modified macro is still suitable for use
> > inside gem_mmap_offset test itself. Would that not be case,
> > gem_mmap_offset could redefine the macro back to its initial form for
> > internal use.
> >
> > Suggested-by: Michał Winiarski
> > Signed-off-by: Janusz Krzysztofik
> > Cc: Chris Wilson
> > ---
> > lib/i915/gem_mman.h | 5 +++--
> > tests/i915/gem_ctx_sseu.c| 2 +-
> > tests/i915/gem_exec_params.c | 2 +-
> > tests/i915/gem_madvise.c | 18 ++
> > tests/i915/gem_mmap_offset.c | 10 +-
> > tests/i915/i915_pm_rpm.c | 2 +-
> > 6 files changed, 25 insertions(+), 14 deletions(-)
> >
> > diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
> > index 4fc6a0186..491767023 100644
> > --- a/lib/i915/gem_mman.h
> > +++ b/lib/i915/gem_mman.h
> > @@ -101,9 +101,10 @@ extern const struct mmap_offset {
> > unsigned int domain;
> > } mmap_offset_types[];
> >
> > -#define for_each_mmap_offset_type(__t) \
> > +#define for_each_mmap_offset_type(fd, __t) \
> > for (const struct mmap_offset *__t = mmap_offset_types; \
> > -(__t)->name; \
> > +(__t)->name && (gem_has_mmap_offset(fd) || \
> > +(__t)->type == I915_MMAP_OFFSET_GTT); \
>
> Sigh.
>
> extern bool gem_has_mmap_offset_type(int i915, const struct mmap_offset *t);
>
> && gem_has_mmap_offset_type(fd, t)
Sorry, make that
for_each_if(gem_has_mmap_offset_type(i915, t))
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> API. However, when run on an older version of the driver, those
> subtests are believed to be still repeated for each known mmap-offset
> mapping type while effectively exercising GTT mapping type only. As
> that may be confusing, fix it.
>
> It has been assumed that the modified macro is still suitable for use
> inside gem_mmap_offset test itself. Would that not be case,
> gem_mmap_offset could redefine the macro back to its initial form for
> internal use.
>
> Suggested-by: Michał Winiarski
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> ---
> lib/i915/gem_mman.h | 5 +++--
> tests/i915/gem_ctx_sseu.c| 2 +-
> tests/i915/gem_exec_params.c | 2 +-
> tests/i915/gem_madvise.c | 18 ++
> tests/i915/gem_mmap_offset.c | 10 +-
> tests/i915/i915_pm_rpm.c | 2 +-
> 6 files changed, 25 insertions(+), 14 deletions(-)
>
> diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
> index 4fc6a0186..491767023 100644
> --- a/lib/i915/gem_mman.h
> +++ b/lib/i915/gem_mman.h
> @@ -101,9 +101,10 @@ extern const struct mmap_offset {
> unsigned int domain;
> } mmap_offset_types[];
>
> -#define for_each_mmap_offset_type(__t) \
> +#define for_each_mmap_offset_type(fd, __t) \
> for (const struct mmap_offset *__t = mmap_offset_types; \
> -(__t)->name; \
> +(__t)->name && (gem_has_mmap_offset(fd) || \
> +(__t)->type == I915_MMAP_OFFSET_GTT); \
Sigh.
extern bool gem_has_mmap_offset_type(int i915, const struct mmap_offset *t);
&& gem_has_mmap_offset_type(fd, t)
in case we need to fix it again in future.
-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 9/9] i915: Exercise I915_CONTEXT_PARAM_RINGSIZE
Quoting Janusz Krzysztofik (2020-02-20 15:57:24) > Hi Chris, > > On Monday, December 2, 2019 3:59:19 PM CET Chris Wilson wrote: > > Quoting Janusz Krzysztofik (2019-12-02 14:42:58) > > > Hi Chris, > > > > > > I have a few questions rather than comments. I hope they are worth > > > spending > > > your time. > > > > > > On Wednesday, November 13, 2019 1:52:40 PM CET Chris Wilson wrote: > > > > I915_CONTEXT_PARAM_RINGSIZE specifies how large to create the command > > > > ringbuffer for logical ring contects. This directly affects the number > > > > > > s/contects/contexts/ > > > > > > > of batches userspace can submit before blocking waiting for space. > > > > > > > > Signed-off-by: Chris Wilson > > Have you got this patch still queued somewhere? As UMD has accepted the > solution and are ready with changes on their side, I think we need to merge > it > soon, and the kernel side as well. Link? That's all I need to merge the kernel... -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 9/9] i915: Exercise I915_CONTEXT_PARAM_RINGSIZE
Hi Chris,
On Monday, December 2, 2019 3:59:19 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-12-02 14:42:58)
> > Hi Chris,
> >
> > I have a few questions rather than comments. I hope they are worth
> > spending
> > your time.
> >
> > On Wednesday, November 13, 2019 1:52:40 PM CET Chris Wilson wrote:
> > > I915_CONTEXT_PARAM_RINGSIZE specifies how large to create the command
> > > ringbuffer for logical ring contects. This directly affects the number
> >
> > s/contects/contexts/
> >
> > > of batches userspace can submit before blocking waiting for space.
> > >
> > > Signed-off-by: Chris Wilson
Have you got this patch still queued somewhere? As UMD has accepted the
solution and are ready with changes on their side, I think we need to merge it
soon, and the kernel side as well.
Thanks,
Janusz
> > > ---
> > > tests/Makefile.sources| 3 +
> > > tests/i915/gem_ctx_ringsize.c | 296 ++
> > > tests/meson.build | 1 +
> > > 3 files changed, 300 insertions(+)
> > > create mode 100644 tests/i915/gem_ctx_ringsize.c
> > >
> > > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > > index e17d43155..801fc52f3 100644
> > > --- a/tests/Makefile.sources
> > > +++ b/tests/Makefile.sources
> > > @@ -163,6 +163,9 @@ gem_ctx_param_SOURCES = i915/gem_ctx_param.c
> > > TESTS_progs += gem_ctx_persistence
> > > gem_ctx_persistence_SOURCES = i915/gem_ctx_persistence.c
> > >
> > > +TESTS_progs += gem_ctx_ringsize
> > > +gem_ctx_ringsize_SOURCES = i915/gem_ctx_ringsize.c
> > > +
> > > TESTS_progs += gem_ctx_shared
> > > gem_ctx_shared_SOURCES = i915/gem_ctx_shared.c
> > >
> > > diff --git a/tests/i915/gem_ctx_ringsize.c b/tests/i915/gem_ctx_ringsize.c
> > > new file mode 100644
> > > index 0..1450e8f0d
> > > --- /dev/null
> > > +++ b/tests/i915/gem_ctx_ringsize.c
> > > @@ -0,0 +1,296 @@
> > > +/*
> > > + * Copyright © 2019 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining
> > > a
> > > + * copy of this software and associated documentation files (the
> > > "Software"),
> > > + * to deal in the Software without restriction, including without
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute,
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the
> > > next
> > > + * paragraph) shall be included in all copies or substantial portions of
> > > the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> > > SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > > OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > > ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > > DEALINGS
> > > + * IN THE SOFTWARE.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include "drmtest.h" /* gem_quiescent_gpu()! */
> > > +#include "i915/gem_context.h"
> > > +#include "i915/gem_engine_topology.h"
> > > +#include "ioctl_wrappers.h" /* gem_wait()! */
> > > +#include "sw_sync.h"
> > > +
> > > +#define I915_CONTEXT_PARAM_RINGSIZE 0xc
> >
> > How are we going to handle symbol redefinition conflict which arises as
> > soon
> > as this symbol is also included from kernel headers (e.g. via
> > "i915/gem_engine_topology.h")?
>
> Final version we copy the headers form the kernel. Conflicts remind us
> when we forget.
>
> >
> > > +
> > > +static bool has_ringsize(int i915)
> > > +{
> > > + struct drm_i915_gem_context_param p = {
> > > + .param = I915_CONTEXT_PARAM_RINGSIZE,
> > > + };
> > > +
> > > + return __gem_context_get_param(i915, ) == 0;
> > > +}
> > > +
> > > +static void test_idempotent(int i915)
> > > +{
> > > + struct drm_i915_gem_context_param p = {
> > > + .param = I915_CONTEXT_PARAM_RINGSIZE,
> > > + };
> > > + uint32_t saved;
> > > +
> > > + /*
> > > + * Simple test to verify that we are able to read back the same
> > > + * value as we set.
> > > + */
> > > +
> > > + gem_context_get_param(i915, );
> > > + saved = p.value;
> > > +
> > > + for (uint32_t x = 1 << 12; x <= 128 << 12; x <<= 1) {
> >
> > I've noticed you are using two different notations for those
> > minimum/maximum
> > constants. I think that may be confusing. How about defining and using
> > macros?
>
> A range in pages...
>
> > > +
Re: [Intel-gfx] [PATCH v1] drm/i915: Use intel_plane_data_rate for min_cdclk calculation
On Thu, 2020-02-20 at 17:43 +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 05:23:47PM +0200, Stanislav Lisovskiy wrote:
> > There seems to be a bit of confusing redundancy in a way, how
> > plane data rate/min cdclk are calculated.
> > In fact both min cdclk, pixel rate and plane data rate are all
> > part of the same formula as per BSpec.
> >
> > However currently we have intel_plane_data_rate, which is used
> > to calculate plane data rate and which is also used in bandwidth
> > calculations. However for calculating min_cdclk we have another
> > piece of code, doing almost same calculation, but a bit differently
> > and in a different place. However as both are actually part of same
> > formula, probably would be wise to use plane data rate calculations
> > as a basis anyway, thus avoiding code duplication and possible bugs
> > related to this.
> >
> > Another thing is that I've noticed that during min_cdclk
> > calculations
> > we account for plane scaling, while for plane data rate, we don't.
> > crtc->pixel_rate seems to account only for pipe ratio, however it
> > is
> > clearly stated in BSpec that plane data rate also need to account
> > plane ratio as well.
> >
> > So what this commit does is:
> > - Adds a plane ratio calculation to intel_plane_data_rate
> > - Removes redundant calculations from skl_plane_min_cdclk which is
> > used for gen9+ and now uses intel_plane_data_rate as a basis from
> > there as well.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 16 ++-
> > drivers/gpu/drm/i915/display/intel_sprite.c | 46 +++--
> > --
> > 2 files changed, 41 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index c86d7a35c816..702dfa14d112 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -133,15 +133,27 @@ intel_plane_destroy_state(struct drm_plane
> > *plane,
> > kfree(plane_state);
> > }
> >
> > +
> > +
> > unsigned int intel_plane_data_rate(const struct intel_crtc_state
> > *crtc_state,
> >const struct intel_plane_state
> > *plane_state)
> > {
> > const struct drm_framebuffer *fb = plane_state->hw.fb;
> > unsigned int cpp;
> > + unsigned int src_w, src_h, dst_w, dst_h;
> >
> > if (!plane_state->uapi.visible)
> > return 0;
> >
> > + src_w = drm_rect_width(_state->uapi.src) >> 16;
> > + src_h = drm_rect_height(_state->uapi.src) >> 16;
> > + dst_w = drm_rect_width(_state->uapi.dst);
> > + dst_h = drm_rect_height(_state->uapi.dst);
> > +
> > + /* Downscaling limits the maximum pixel rate */
> > + dst_w = min(src_w, dst_w);
> > + dst_h = min(src_h, dst_h);
> > +
> > cpp = fb->format->cpp[0];
> >
> > /*
> > @@ -153,7 +165,9 @@ unsigned int intel_plane_data_rate(const struct
> > intel_crtc_state *crtc_state,
> > if (fb->format->is_yuv && fb->format->num_planes > 1)
> > cpp *= 4;
> >
> > - return cpp * crtc_state->pixel_rate;
> > + return DIV64_U64_ROUND_UP(mul_u32_u32(cpp * crtc_state-
> > >pixel_rate,
> > + src_w * src_h),
> > + mul_u32_u32(dst_w, dst_h));
>
> You don't need a 64bit divisor for this.
>
> > }
> >
> > int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index 7abeefe8dce5..75afb78ff1b0 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -330,24 +330,34 @@ bool icl_is_hdr_plane(struct drm_i915_private
> > *dev_priv, enum plane_id plane_id)
> > }
> >
> > static void
> > -skl_plane_ratio(const struct intel_crtc_state *crtc_state,
> > - const struct intel_plane_state *plane_state,
> > - unsigned int *num, unsigned int *den)
> > +skl_plane_bpp_constraints(const struct intel_crtc_state
> > *crtc_state,
> > + const struct intel_plane_state *plane_state,
> > + unsigned int *num, unsigned int *den)
> > {
> > struct drm_i915_private *dev_priv = to_i915(plane_state-
> > >uapi.plane->dev);
> > const struct drm_framebuffer *fb = plane_state->hw.fb;
> > + unsigned int cpp = fb->format->cpp[0];
> > +
> > + /*
> > +* Based on HSD#:1408715493
> > +* NV12 cpp == 4, P010 cpp == 8
> > +*
> > +* FIXME what is the logic behind this?
> > +*/
> > + if (fb->format->is_yuv && fb->format->num_planes > 1)
> > + cpp *= 4;
>
> This is ugly. I think we need a plane pixel rate instead of
> abusing the data rate as the pixel rate like this.
Yeah, agree, but that is all because of this HSD#-something workaround,
which is preventing to use
Re: [Intel-gfx] [PATCH v1] drm/i915: Use intel_plane_data_rate for min_cdclk calculation
On Thu, Feb 20, 2020 at 05:23:47PM +0200, Stanislav Lisovskiy wrote:
> There seems to be a bit of confusing redundancy in a way, how
> plane data rate/min cdclk are calculated.
> In fact both min cdclk, pixel rate and plane data rate are all
> part of the same formula as per BSpec.
>
> However currently we have intel_plane_data_rate, which is used
> to calculate plane data rate and which is also used in bandwidth
> calculations. However for calculating min_cdclk we have another
> piece of code, doing almost same calculation, but a bit differently
> and in a different place. However as both are actually part of same
> formula, probably would be wise to use plane data rate calculations
> as a basis anyway, thus avoiding code duplication and possible bugs
> related to this.
>
> Another thing is that I've noticed that during min_cdclk calculations
> we account for plane scaling, while for plane data rate, we don't.
> crtc->pixel_rate seems to account only for pipe ratio, however it is
> clearly stated in BSpec that plane data rate also need to account
> plane ratio as well.
>
> So what this commit does is:
> - Adds a plane ratio calculation to intel_plane_data_rate
> - Removes redundant calculations from skl_plane_min_cdclk which is
> used for gen9+ and now uses intel_plane_data_rate as a basis from
> there as well.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 16 ++-
> drivers/gpu/drm/i915/display/intel_sprite.c | 46 +++
> 2 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index c86d7a35c816..702dfa14d112 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -133,15 +133,27 @@ intel_plane_destroy_state(struct drm_plane *plane,
> kfree(plane_state);
> }
>
> +
> +
> unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
> const struct intel_plane_state *plane_state)
> {
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> unsigned int cpp;
> + unsigned int src_w, src_h, dst_w, dst_h;
>
> if (!plane_state->uapi.visible)
> return 0;
>
> + src_w = drm_rect_width(_state->uapi.src) >> 16;
> + src_h = drm_rect_height(_state->uapi.src) >> 16;
> + dst_w = drm_rect_width(_state->uapi.dst);
> + dst_h = drm_rect_height(_state->uapi.dst);
> +
> + /* Downscaling limits the maximum pixel rate */
> + dst_w = min(src_w, dst_w);
> + dst_h = min(src_h, dst_h);
> +
> cpp = fb->format->cpp[0];
>
> /*
> @@ -153,7 +165,9 @@ unsigned int intel_plane_data_rate(const struct
> intel_crtc_state *crtc_state,
> if (fb->format->is_yuv && fb->format->num_planes > 1)
> cpp *= 4;
>
> - return cpp * crtc_state->pixel_rate;
> + return DIV64_U64_ROUND_UP(mul_u32_u32(cpp * crtc_state->pixel_rate,
> + src_w * src_h),
> + mul_u32_u32(dst_w, dst_h));
You don't need a 64bit divisor for this.
> }
>
> int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 7abeefe8dce5..75afb78ff1b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -330,24 +330,34 @@ bool icl_is_hdr_plane(struct drm_i915_private
> *dev_priv, enum plane_id plane_id)
> }
>
> static void
> -skl_plane_ratio(const struct intel_crtc_state *crtc_state,
> - const struct intel_plane_state *plane_state,
> - unsigned int *num, unsigned int *den)
> +skl_plane_bpp_constraints(const struct intel_crtc_state *crtc_state,
> + const struct intel_plane_state *plane_state,
> + unsigned int *num, unsigned int *den)
> {
> struct drm_i915_private *dev_priv =
> to_i915(plane_state->uapi.plane->dev);
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> + unsigned int cpp = fb->format->cpp[0];
> +
> + /*
> + * Based on HSD#:1408715493
> + * NV12 cpp == 4, P010 cpp == 8
> + *
> + * FIXME what is the logic behind this?
> + */
> + if (fb->format->is_yuv && fb->format->num_planes > 1)
> + cpp *= 4;
This is ugly. I think we need a plane pixel rate instead of
abusing the data rate as the pixel rate like this.
>
> if (fb->format->cpp[0] == 8) {
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> *num = 10;
> - *den = 8;
> + *den = 8 * cpp;
> } else {
> *num = 9;
> - *den = 8;
> + *den
Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote: > On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote: > > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala > > wrote: > > > > > > From: Ville Syrjälä > > > > > > struct drm_display_mode is extremely fat. Put it on diet. > > > > > > Some stats for the whole series: > > > > > > 64bit sizeof(struct drm_display_mode): > > > 200 -> 136 bytes (-32%) > > > > > > 64bit bloat-o-meter -c drm.ko: > > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651) > > > Function old new delta > > > ... > > > Total: Before=189430, After=188779, chg -0.34% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=11667, After=11667, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes 1000 680-320 > > > edid_est_modes 34002312 -1088 > > > edid_cea_modes_193 54003672 -1728 > > > drm_dmt_modes 17600 11968 -5632 > > > edid_cea_modes_1 25400 17272 -8128 > > > Total: Before=71239, After=54343, chg -23.72% > > > > > > > > > 64bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547) > > > ... > > > Total: Before=272336, After=254789, chg -6.44% > > > > > > > > > 32bit sizeof(struct drm_display_mode): > > > 184 -> 120 bytes (-34%) > > > > > > 32bit bloat-o-meter -c drm.ko > > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625) > > > Function old new delta > > > ... > > > Total: Before=172359, After=171734, chg -0.36% > > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > > Data old new delta > > > Total: Before=4227, After=4227, chg +0.00% > > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896) > > > RO Data old new delta > > > edid_4k_modes920 600-320 > > > edid_est_modes 31282040 -1088 > > > edid_cea_modes_193 49683240 -1728 > > > drm_dmt_modes 16192 10560 -5632 > > > edid_cea_modes_1 23368 15240 -8128 > > > Total: Before=59230, After=42334, chg -28.53% > > > > > > 32bit bloat-o-meter drm.ko: > > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521) > > > ... > > > Total: Before=235816, After=218295, chg -7.43% > > > > > > > > > Some ideas for further reduction: > > > - Convert mode->name to a pointer (saves 24/28 bytes in the > > > struct but would often require a heap alloc for the name (though > > > typical mode name is <10 bytes so still overall win perhaps) > > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only > > > place where we have to preserve the user provided name, elsewhere > > > could pehaps just generate on demand? Not sure how tricky this > > > would get. > > > > The series does some great work, with future work reaching the cache > > line for 64bit. > > Doing much more than that might be an overkill IMHO. > > > > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there, > > avoiding the heap alloc/calc on demand fun. > > While also ensuring the name is sufficiently large for the next decade or > > so. > > Unfortunately it's part of the uabi. So can't change it without some > risk of userspace breakage. > > The least demanding option is probably to nuke export_head. We need > one bit to replace it, which we can get by either: > - stealing from eg. mode->type, or perhaps mode->private_flags > - nuke private_flags outright and replace it with a bool for this > purpose Looks like getting rid of private_flags is going to be pretty straightforward. I'll post patches for that once this first series lands. -- 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 05/12] drm/msm/dpu: Stop copying around mode->private_flags
On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote: > On Wed, 19 Feb 2020 at 20:36, Ville Syrjala > wrote: > > > > From: Ville Syrjälä > > > > The driver never sets mode->private_flags so copying > > it back and forth is entirely pointless. Stop doing it. > > > > Also drop private_flags from the tracepoint. > > > > Cc: Rob Clark > > Cc: Sean Paul > > Cc: linux-arm-...@vger.kernel.org > > Cc: freedr...@lists.freedesktop.org > > Signed-off-by: Ville Syrjälä > > Perhaps the msm team has a WIP which makes use of it ? Maybe if it's one of them five year projects. But anyways, with an atomic driver there are certainly better ways to handle this. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be still repeated for each known mmap-offset
mapping type while effectively exercising GTT mapping type only. As
that may be confusing, fix it.
It has been assumed that the modified macro is still suitable for use
inside gem_mmap_offset test itself. Would that not be case,
gem_mmap_offset could redefine the macro back to its initial form for
internal use.
Suggested-by: Michał Winiarski
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
lib/i915/gem_mman.h | 5 +++--
tests/i915/gem_ctx_sseu.c| 2 +-
tests/i915/gem_exec_params.c | 2 +-
tests/i915/gem_madvise.c | 18 ++
tests/i915/gem_mmap_offset.c | 10 +-
tests/i915/i915_pm_rpm.c | 2 +-
6 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
index 4fc6a0186..491767023 100644
--- a/lib/i915/gem_mman.h
+++ b/lib/i915/gem_mman.h
@@ -101,9 +101,10 @@ extern const struct mmap_offset {
unsigned int domain;
} mmap_offset_types[];
-#define for_each_mmap_offset_type(__t) \
+#define for_each_mmap_offset_type(fd, __t) \
for (const struct mmap_offset *__t = mmap_offset_types; \
-(__t)->name; \
+(__t)->name && (gem_has_mmap_offset(fd) || \
+(__t)->type == I915_MMAP_OFFSET_GTT); \
(__t)++)
#endif /* GEM_MMAN_H */
diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
index d558c8baa..3bef11b51 100644
--- a/tests/i915/gem_ctx_sseu.c
+++ b/tests/i915/gem_ctx_sseu.c
@@ -531,7 +531,7 @@ igt_main
test_invalid_sseu(fd);
igt_subtest_with_dynamic("mmap-args") {
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(fd, t) {
igt_dynamic_f("%s", t->name)
test_mmapped_args(fd, t);
}
diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index e2912685b..cf7ea3065 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -244,7 +244,7 @@ static void mmapped(int i915)
buf = gem_create(i915, 4096);
handle = batch_create(i915);
- for_each_mmap_offset_type(t) { /* repetitive! */
+ for_each_mmap_offset_type(i915, t) { /* repetitive! */
struct drm_i915_gem_execbuffer2 *execbuf;
struct drm_i915_gem_exec_object2 *exec;
diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
index e8716a891..54c9befff 100644
--- a/tests/i915/gem_madvise.c
+++ b/tests/i915/gem_madvise.c
@@ -62,12 +62,13 @@ dontneed_before_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
gem_madvise(fd, handle, I915_MADV_DONTNEED);
@@ -93,7 +94,11 @@ dontneed_before_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigsegv);
signal(SIGSEGV, old_sigbus);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
@@ -103,12 +108,13 @@ dontneed_after_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
ptr = __gem_mmap_offset(fd, handle, 0, OBJECT_SIZE,
@@ -134,7 +140,11 @@ dontneed_after_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigbus);
signal(SIGSEGV, old_sigsegv);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
diff --git a/tests/i915/gem_mmap_offset.c b/tests/i915/gem_mmap_offset.c
index f49d18e63..1ec963b25 100644
--- a/tests/i915/gem_mmap_offset.c
+++ b/tests/i915/gem_mmap_offset.c
@@ -128,7 +128,7 @@ static void basic_uaf(int i915)
{
const uint32_t obj_size = 4096;
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
uint32_t handle = gem_create(i915, obj_size);
uint8_t *expected, *buf, *addr;
@@ -176,7 +176,7 @@ static void
[Intel-gfx] [PATCH v1] drm/i915: Use intel_plane_data_rate for min_cdclk calculation
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate and which is also used in bandwidth
calculations. However for calculating min_cdclk we have another
piece of code, doing almost same calculation, but a bit differently
and in a different place. However as both are actually part of same
formula, probably would be wise to use plane data rate calculations
as a basis anyway, thus avoiding code duplication and possible bugs
related to this.
Another thing is that I've noticed that during min_cdclk calculations
we account for plane scaling, while for plane data rate, we don't.
crtc->pixel_rate seems to account only for pipe ratio, however it is
clearly stated in BSpec that plane data rate also need to account
plane ratio as well.
So what this commit does is:
- Adds a plane ratio calculation to intel_plane_data_rate
- Removes redundant calculations from skl_plane_min_cdclk which is
used for gen9+ and now uses intel_plane_data_rate as a basis from
there as well.
Signed-off-by: Stanislav Lisovskiy
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 16 ++-
drivers/gpu/drm/i915/display/intel_sprite.c | 46 +++
2 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index c86d7a35c816..702dfa14d112 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -133,15 +133,27 @@ intel_plane_destroy_state(struct drm_plane *plane,
kfree(plane_state);
}
+
+
unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int cpp;
+ unsigned int src_w, src_h, dst_w, dst_h;
if (!plane_state->uapi.visible)
return 0;
+ src_w = drm_rect_width(_state->uapi.src) >> 16;
+ src_h = drm_rect_height(_state->uapi.src) >> 16;
+ dst_w = drm_rect_width(_state->uapi.dst);
+ dst_h = drm_rect_height(_state->uapi.dst);
+
+ /* Downscaling limits the maximum pixel rate */
+ dst_w = min(src_w, dst_w);
+ dst_h = min(src_h, dst_h);
+
cpp = fb->format->cpp[0];
/*
@@ -153,7 +165,9 @@ unsigned int intel_plane_data_rate(const struct
intel_crtc_state *crtc_state,
if (fb->format->is_yuv && fb->format->num_planes > 1)
cpp *= 4;
- return cpp * crtc_state->pixel_rate;
+ return DIV64_U64_ROUND_UP(mul_u32_u32(cpp * crtc_state->pixel_rate,
+ src_w * src_h),
+ mul_u32_u32(dst_w, dst_h));
}
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 7abeefe8dce5..75afb78ff1b0 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -330,24 +330,34 @@ bool icl_is_hdr_plane(struct drm_i915_private *dev_priv,
enum plane_id plane_id)
}
static void
-skl_plane_ratio(const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state,
- unsigned int *num, unsigned int *den)
+skl_plane_bpp_constraints(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state,
+ unsigned int *num, unsigned int *den)
{
struct drm_i915_private *dev_priv =
to_i915(plane_state->uapi.plane->dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
+ unsigned int cpp = fb->format->cpp[0];
+
+ /*
+* Based on HSD#:1408715493
+* NV12 cpp == 4, P010 cpp == 8
+*
+* FIXME what is the logic behind this?
+*/
+ if (fb->format->is_yuv && fb->format->num_planes > 1)
+ cpp *= 4;
if (fb->format->cpp[0] == 8) {
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
*num = 10;
- *den = 8;
+ *den = 8 * cpp;
} else {
*num = 9;
- *den = 8;
+ *den = 8 * cpp;
}
} else {
*num = 1;
- *den = 1;
+ *den = cpp;
}
}
@@ -355,27 +365,23 @@ static int skl_plane_min_cdclk(const struct
intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv =
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12. (rev3)
== Series Details == Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12. (rev3) URL : https://patchwork.freedesktop.org/series/73332/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16609_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_7963_full and Patchwork_16609_full: ### New IGT tests (58) ### * igt@i915_pm_backlight@bad-brightness: - Statuses : 3 pass(s) 4 skip(s) - Exec time: [0.0, 0.03] s * igt@i915_pm_backlight@basic-brightness: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.23] s * igt@i915_pm_backlight@fade: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 2.59] s * igt@i915_pm_backlight@fade_with_dpms: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.82] s * igt@i915_pm_backlight@fade_with_suspend: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.50] s * igt@i915_pm_lpsp@edp-native: - Statuses : 8 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_lpsp@edp-panel-fitter: - Statuses : 8 skip(s) - Exec time: [0.0, 0.05] s * igt@i915_pm_lpsp@non-edp: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.12] s * igt@i915_pm_lpsp@screens-disabled: - Statuses : 1 pass(s) 7 skip(s) - Exec time: [0.0, 0.04] s * igt@i915_pm_rc6_residency@media-rc6-accuracy: - Statuses : 7 skip(s) - Exec time: [0.0] s * igt@i915_pm_rc6_residency@rc6-accuracy: - Statuses : 8 pass(s) - Exec time: [3.0, 3.00] s * igt@i915_pm_rpm@basic-pci-d3-state: - Statuses : 7 pass(s) - Exec time: [0.25, 5.05] s * igt@i915_pm_rpm@basic-rte: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [1.39, 11.47] s * igt@i915_pm_rpm@cursor: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 42.05] s * igt@i915_pm_rpm@cursor-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 41.34] s * igt@i915_pm_rpm@debugfs-forcewake-user: - Statuses : 7 pass(s) - Exec time: [10.41, 14.33] s * igt@i915_pm_rpm@debugfs-read: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 80.92] s * igt@i915_pm_rpm@dpms-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 0.82] s * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 13.41] s * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 4.04] s * igt@i915_pm_rpm@dpms-non-lpsp: - Statuses : 4 pass(s) 3 skip(s) - Exec time: [0.0, 0.18] s * igt@i915_pm_rpm@drm-resources-equal: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 11.01] s * igt@i915_pm_rpm@fences: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 16.98] s * igt@i915_pm_rpm@fences-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 13.00] s * igt@i915_pm_rpm@gem-evict-pwrite: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 3.92] s * igt@i915_pm_rpm@gem-execbuf: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 15.29] s * igt@i915_pm_rpm@gem-execbuf-stress: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 42.62] s * igt@i915_pm_rpm@gem-execbuf-stress-pc8: - Statuses : 8 skip(s) - Exec time: [0.0, 0.00] s * igt@i915_pm_rpm@gem-idle: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 9.14] s * igt@i915_pm_rpm@gem-pread: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 5.80] s * igt@i915_pm_rpm@i2c: - Statuses : 7 pass(s) - Exec time: [0.90, 11.25] s * igt@i915_pm_rpm@legacy-planes: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 169.38] s * igt@i915_pm_rpm@legacy-planes-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 146.76] s * igt@i915_pm_rpm@modeset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.94] s * igt@i915_pm_rpm@modeset-lpsp-stress: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 51.07] s * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 18.23] s * igt@i915_pm_rpm@modeset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 4.04] s * igt@i915_pm_rpm@modeset-non-lpsp-stress: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 8.14] s * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 7.36] s * igt@i915_pm_rpm@modeset-pc8-residency-stress: - Statuses : 8 skip(s) - Exec time: [0.0] s * igt@i915_pm_rpm@modeset-stress-extra-wait: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 73.52] s * igt@i915_pm_rpm@pc8-residency: - Statuses : 8 skip(s) - Exec time: [0.0] s * igt@i915_pm_rpm@pm-caching: - Statuses
Re: [Intel-gfx] [PATCH 03/52] drm: add managed resources tied to drm_device
Hi Greg, On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote: > >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote: > >>> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote: > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote: > > On Wed, Feb 19, 2020 at 11:20:33AM +0100, Daniel Vetter wrote: > >> We have lots of these. And the cleanup code tends to be of dubious > >> quality. The biggest wrong pattern is that developers use devm_, which > >> ties the release action to the underlying struct device, whereas > >> all the userspace visible stuff attached to a drm_device can long > >> outlive that one (e.g. after a hotunplug while userspace has open > >> files and mmap'ed buffers). Give people what they want, but with more > >> correctness. > >> > >> Mostly copied from devres.c, with types adjusted to fit drm_device and > >> a few simplifications - I didn't (yet) copy over everything. Since > >> the types don't match code sharing looked like a hopeless endeavour. > >> > >> For now it's only super simplified, no groups, you can't remove > >> actions (but kfree exists, we'll need that soon). Plus all specific to > >> drm_device ofc, including the logging. Which I didn't bother to make > >> compile-time optional, since none of the other drm logging is compile > >> time optional either. > >> > >> One tricky bit here is the chicken between allocating your > >> drm_device structure and initiliazing it with drm_dev_init. For > >> perfect onion unwinding we'd need to have the action to kfree the > >> allocation registered before drm_dev_init registers any of its own > >> release handlers. But drm_dev_init doesn't know where exactly the > >> drm_device is emebedded into the overall structure, and by the time it > >> returns it'll all be too late. And forcing drivers to be able clean up > >> everything except the one kzalloc is silly. > >> > >> Work around this by having a very special final_kfree pointer. This > >> also avoids troubles with the list head possibly disappearing from > >> underneath us when we release all resources attached to the > >> drm_device. > > > > This is all a very good idea ! Many subsystems are plagged by drivers > > using devm_k*alloc to allocate data accessible by userspace. Since the > > introduction of devm_*, we've likely reduced the number of memory leaks, > > but I'm pretty sure we've increased the risk of crashes as I've seen > > some drivers that used .release() callbacks correctly being naively > > converted to incorrect devm_* usage :-( > > > > This leads me to a question: if other subsystems have the same problem, > > could we turn this implementation into something more generic ? It > > doesn't have to be done right away and shouldn't block merging this > > series, but I think it would be very useful. > > It shouldn't be that hard to tie this into a drv_m() type of a thing > (driver_memory?) > > And yes, I think it's much better than devm_* for the obvious reasons of > this being needed here. > >>> > >>> There's two reasons I went with copypasta instead of trying to share code: > >>> - Type checking, I definitely don't want people to mix up devm_ with > >>> drmm_. But even if we do a drv_m that subsystems could embed we do > >>> have quite a few different types of component drivers (and with > >>> drm_panel and drm_bridge even standardized), and I don't want people > >>> to be able to pass the wrong kind of struct to e.g. a managed > >>> drmm_connector_init - it really needs to be the drm_device, not a > >>> panel or bridge or something else. > >> > >> Fair enough, that makes sense. > >> > >>> - We could still share the code as a kind of implementation/backend > >>> library. But it's not much, and with embedding I could use the drm > >>> device logging stuff which is kinda nice. But if there's more demand > >>> for this I can definitely see the point in sharing this, as Laurent > >>> pointed out with the tiny optimization with not allocating a NULL void > >>> * that I've done (and screwed up) it's not entirely trivial code. > >> > >> I think moving over time to having this be a backend library is good. > >> But no rush/issues here with this going in now, it solves a real need > >> and we can refactor it later on to try to make it more "bus/class" > >> generic as needed. > > > > >From a type checking point of view, it would then be nice to have a > > structure that models a device node, other than just struct device that > > is shared by all types of devices. As someone who was involve in the > > creation of the device model we have today, and thus know the history, > > what's your
