[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/gt: Protect signaler walk with RCU
== Series Details ==
Series: series starting with [1/6] drm/i915/gt: Protect signaler walk with RCU
URL : https://patchwork.freedesktop.org/series/73691/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7970 -> Patchwork_16642
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16642 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16642, 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_16642/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16642:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-byt-j1900: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16642/fi-byt-j1900/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_16642 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-byt-j1900: [PASS][2] -> [INCOMPLETE][3] ([i915#45])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16642/fi-byt-j1900/igt@gem_ctx_cre...@basic-files.html
* igt@i915_selftest@live_sanitycheck:
- fi-icl-u3: [PASS][4] -> [DMESG-WARN][5] ([i915#585])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16642/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bwr-2160:[PASS][6] -> [FAIL][7] ([i915#34])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16642/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [TIMEOUT][8] ([fdo#112271] / [i915#1084]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16642/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_execlists:
- {fi-tgl-dsi}: [INCOMPLETE][10] ([i915#529] / [i915#647]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16642/fi-tgl-dsi/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gtt:
- fi-kbl-7500u: [TIMEOUT][12] ([fdo#112271]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7970/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16642/fi-kbl-7500u/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).
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#529]: https://gitlab.freedesktop.org/drm/intel/issues/529
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#647]: https://gitlab.freedesktop.org/drm/intel/issues/647
Participating hosts (48 -> 40)
--
Additional (3): fi-gdg-551 fi-bsw-nick fi-snb-2600
Missing(11): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-cfl-8109u fi-bsw-kefka fi-skl-lmem fi-kbl-7560u fi-byt-n2820 fi-byt-clapper
fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7970 -> Patchwork_16642
CI-20190529: 20190529
CI_DRM_7970: 6b8b833350142345f4b1a6af9486db7d316a7ff1 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5452: c05dc6cd816feb1cc518ce777ab3fd6c81893113 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16642: 81c48211d4f0171849b2fe323a5c6bf3bdfcfae6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
81c48211d4f0 drm/i915/gt: Yield the timeslice if caught waiting on a user
semaphore
3a98210715c5 drm/i915/gt: Declare when we enabled timeslicing
c0b4866e2c12 drm/i915/gem: Check that the context wasn't closed during setup
4af18a639c91 drm/i915/gt: Prevent allocation on a banned context
1677db7d6e97 drm/i915/gem: Consolidate
Re: [Intel-gfx] [CI v3 1/3] drm/i915: Introduce encoder->compute_config_late()
> -Original Message-
> From: Intel-gfx On Behalf Of Manasi
> Navare
> Sent: Friday, February 14, 2020 5:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v3 1/3] drm/i915: Introduce
> encoder->compute_config_late()
>
> From: Ville Syrjälä
>
> Add an optional secondary encoder state compute hook. This gets called after
> the
> normak .compute_config() has been called for all the encoders in the state.
> Thus in
> the new hook we can rely on all derived state populated by .compute_config()
> to be
> already set up. Should be useful for MST and port sync master/slave transcoder
> selection.
Pushed the series to dinq. Thanks for the patches and review.
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 39 +++
> .../drm/i915/display/intel_display_types.h| 3 ++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e09d3c93c52b..ce72551ba16a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13549,6 +13549,35 @@ intel_modeset_pipe_config(struct intel_crtc_state
> *pipe_config)
> return 0;
> }
>
> +static int
> +intel_modeset_pipe_config_late(struct intel_crtc_state *crtc_state) {
> + struct intel_atomic_state *state =
> + to_intel_atomic_state(crtc_state->uapi.state);
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_connector_state *conn_state;
> + struct drm_connector *connector;
> + int i;
> +
> + for_each_new_connector_in_state(&state->base, connector,
> + conn_state, i) {
> + struct intel_encoder *encoder =
> + to_intel_encoder(conn_state->best_encoder);
> + int ret;
> +
> + if (conn_state->crtc != &crtc->base ||
> + !encoder->compute_config_late)
> + continue;
> +
> + ret = encoder->compute_config_late(encoder, crtc_state,
> +conn_state);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> bool intel_fuzzy_clock_check(int clock1, int clock2) {
> int diff;
> @@ -14954,6 +14983,16 @@ static int intel_atomic_check(struct drm_device *dev,
> ret = intel_modeset_pipe_config(new_crtc_state);
> if (ret)
> goto fail;
> + }
> +
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (!needs_modeset(new_crtc_state))
> + continue;
> +
> + ret = intel_modeset_pipe_config_late(new_crtc_state);
> + if (ret)
> + goto fail;
>
> intel_crtc_check_fastset(old_crtc_state, new_crtc_state);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 283c622f8ba1..0d8a64305464 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -141,6 +141,9 @@ struct intel_encoder {
> int (*compute_config)(struct intel_encoder *,
> struct intel_crtc_state *,
> struct drm_connector_state *);
> + int (*compute_config_late)(struct intel_encoder *,
> +struct intel_crtc_state *,
> +struct drm_connector_state *);
> void (*update_prepare)(struct intel_atomic_state *,
> struct intel_encoder *,
> struct intel_crtc *);
> --
> 2.19.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 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
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 - &attach.move_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(&bo->tbo, &placement, &ctx);
+ 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 transaction would automatically end up waiting on the contended
lock, provid
[Intel-gfx] [PATCH i-g-t 1/3] igt/kms_frontbuffer_tracking: Skip over IGT_DRAW_BLT when there's no BLT
If the blitter is not available, we cannot use it as a source for dirty
rectangles. We shall have to rely on the other engines to create GPU
dirty instead.
v2: Try using lots of subgroup+fixtures
Signed-off-by: Chris Wilson
---
tests/kms_frontbuffer_tracking.c | 57 ++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c4b4af43a..9e00fa2e1 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -3043,6 +3043,8 @@ static void basic_subtest(const struct test_mode *t)
fb1 = params->primary.fb;
for (r = 0, method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
+ if (method == IGT_DRAW_BLT && !gem_has_blitter(drm.fd))
+ continue;
if (method == IGT_DRAW_MMAP_GTT &&
!gem_has_mappable_ggtt(drm.fd))
continue;
@@ -3275,10 +3277,11 @@ static const char *flip_str(enum flip_type flip)
continue; \
if (!opt.show_hidden && t.fbs == FBS_SHARED && \
(t.plane == PLANE_CUR || t.plane == PLANE_SPR))\
- continue;
+ continue; \
+ igt_subtest_group {
-#define TEST_MODE_ITER_END } } } } } }
+#define TEST_MODE_ITER_END } } } } } } }
struct option long_options[] = {
{ "no-status-check", 0, 0, 's'},
@@ -3324,6 +3327,10 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
}
TEST_MODE_ITER_BEGIN(t)
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
igt_subtest_f("%s-%s-%s-%s-%s-draw-%s",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3340,6 +3347,11 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
(!opt.show_hidden && t.method != IGT_DRAW_BLT))
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
for (t.flip = 0; t.flip < FLIP_COUNT; t.flip++)
igt_subtest_f("%s-%s-%s-%s-%sflip-%s",
feature_str(t.feature),
@@ -3358,6 +3370,11 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
(t.feature & FEATURE_FBC) == 0)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-fliptrack",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3371,6 +3388,11 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
t.plane == PLANE_PRI)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-%s-%s-move",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3394,6 +3416,11 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
t.plane != PLANE_SPR)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-%s-%s-fullscreen",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3410,6 +3437,11 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
(!opt.show_hidden && t.fbs != FBS_INDIVIDUAL))
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-%s-multidraw",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3426,6 +3458,11 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
t.method != IGT_DRAW_MMAP_GTT)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-farfromfence", feature_str(t.feature))
[Intel-gfx] [PATCH i-g-t 2/3] igt/kms_flip_tiling: Check GEM availability before use
We use the GPU to convert between tiling formats, indirectly via the
call to igt_create_pattern_fb. So before we try and execute commands on
the GPU, we should check that the GPU is available.
Signed-off-by: Chris Wilson
---
tests/kms_flip_tiling.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/kms_flip_tiling.c b/tests/kms_flip_tiling.c
index 17cf816de..1465e73a1 100644
--- a/tests/kms_flip_tiling.c
+++ b/tests/kms_flip_tiling.c
@@ -154,6 +154,7 @@ igt_main
igt_fixture {
data.drm_fd = drm_open_driver_master(DRIVER_INTEL);
data.gen = intel_gen(intel_get_drm_devid(data.drm_fd));
+ igt_require_gem(data.drm_fd);
data.testformat = DRM_FORMAT_XRGB;
--
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 3/3] igt/kms_draw_crc: Test for a working GPU first
The draw-method-blt subtests require a working GPU, so create a subtest
group for the draw-methods, and skip the BLT group using
igt_require_gem() in its fixture.
Signed-off-by: Chris Wilson
---
tests/kms_draw_crc.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index fa7433ab2..917a55432 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -331,14 +331,24 @@ igt_main
for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
- for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
- igt_subtest_f("draw-method-%s-%s-%s",
- format_str(format_idx),
- igt_draw_get_method_name(method),
- tiling_str(tiling_idx))
- draw_method_subtest(method, format_idx,
- tilings[tiling_idx]);
- } } }
+ igt_subtest_group {
+ igt_fixture {
+ if (method == IGT_DRAW_BLT)
+ igt_require_gem(drm_fd);
+ }
+
+ for (tiling_idx = 0;
+tiling_idx < N_TILING_METHODS;
+tiling_idx++) {
+ igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+ draw_method_subtest(method,
+ format_idx,
+ tilings[tiling_idx]);
+ }
+ }}}
igt_subtest("fill-fb")
fill_fb_subtest();
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI v3 3/3] drm/i915/dp: Add all tiled and port sync conns to modeset
> -Original Message-
> From: Intel-gfx On Behalf Of Manasi
> Navare
> Sent: Friday, February 14, 2020 5:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v3 3/3] drm/i915/dp: Add all tiled and port sync
> conns to
> modeset
>
> If one of the synced crtcs needs a full modeset, we need to make sure all the
> synced
> crtcs are forced a full modeset.
>
> v3:
> * Remove ~BIT(cpu_trans) which is a nop (Ville)
> * use get_new_crtc_state and remove error check (Ville)
>
> v2:
> * Add tiles based on cpu_trans check (Ville)
Pushed the changes to dinq, there was some conflict in this patch.
@Manasi/Ville: Can you check if the conflict resolution was ok.
Thanks Jonas for helping in getting this resolved and help on handling the
merge conflicts
Regards,
Uma Shankar
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Signed-off-by: Manasi Navare
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 85
> drivers/gpu/drm/i915/display/intel_dp.c | 136 ++-
> 2 files changed, 135 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c8615f212e8f..8693585d8d88 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14694,76 +14694,6 @@ static bool
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
> return false;
> }
>
> -static int
> -intel_modeset_all_tiles(struct intel_atomic_state *state, int tile_grp_id) -{
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct drm_connector *connector;
> - struct drm_connector_list_iter conn_iter;
> - int ret = 0;
> -
> - drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> - drm_for_each_connector_iter(connector, &conn_iter) {
> - struct drm_connector_state *conn_state;
> - struct drm_crtc_state *crtc_state;
> -
> - if (!connector->has_tile ||
> - connector->tile_group->id != tile_grp_id)
> - continue;
> - conn_state = drm_atomic_get_connector_state(&state->base,
> - connector);
> - if (IS_ERR(conn_state)) {
> - ret = PTR_ERR(conn_state);
> - break;
> - }
> -
> - if (!conn_state->crtc)
> - continue;
> -
> - crtc_state = drm_atomic_get_crtc_state(&state->base,
> -conn_state->crtc);
> - if (IS_ERR(crtc_state)) {
> - ret = PTR_ERR(crtc_state);
> - break;
> - }
> - crtc_state->mode_changed = true;
> - ret = drm_atomic_add_affected_connectors(&state->base,
> - conn_state->crtc);
> - if (ret)
> - break;
> - }
> - drm_connector_list_iter_end(&conn_iter);
> -
> - return ret;
> -}
> -
> -static int
> -intel_atomic_check_tiled_conns(struct intel_atomic_state *state) -{
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct drm_connector *connector;
> - struct drm_connector_state *old_conn_state, *new_conn_state;
> - int i, ret;
> -
> - if (INTEL_GEN(dev_priv) < 11)
> - return 0;
> -
> - /* Is tiled, mark all other tiled CRTCs as needing a modeset */
> - for_each_oldnew_connector_in_state(&state->base, connector,
> -old_conn_state, new_conn_state, i) {
> - if (!connector->has_tile)
> - continue;
> - if (!intel_connector_needs_modeset(state, connector))
> - continue;
> -
> - ret = intel_modeset_all_tiles(state, connector->tile_group->id);
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> /**
> * intel_atomic_check - validate state object
> * @dev: drm device
> @@ -14792,21 +14722,6 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - /**
> - * This check adds all the connectors in current state that belong to
> - * the same tile group to a full modeset.
> - * This function directly sets the mode_changed to true and we also call
> - * drm_atomic_add_affected_connectors(). Hence we are not explicitly
> - * calling drm_atomic_helper_check_modeset() after this.
> - *
> - * Fixme: Handle some corner cases where one of the
> - * tiled connectors gets disconnected and tile info is lost but since it
> - * was previously synced to other conn, we need to add that to the
> modeset.
> - */
> - ret = intel_atomic_check_tiled_conns(state);
[Intel-gfx] [PULL] drm-misc-fixes
I see I missed some commits in the actual tag, but I fixed this below. drm-misc-fixes-2020-02-20: drm-misc-fixes for v5.6-rc3: - Fix dt binding for sunxi. - Allow only 1 rotation argument, and allow 0 rotation in video cmdline. - Small compiler warning fix for panfrost. - Fix when using performance counters in panfrost when using per fd address space. - Fix tc358767 poll timeouts. - Fix ti-tfp410 error message. The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9: Linux 5.6-rc1 (2020-02-09 16:08:48 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-02-20 for you to fetch changes up to dde2bb2da01e96c17f0a44b4a3cf72a30e66e3ef: drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context (2020-02-12 14:27:29 -0600) drm-misc-fixes for v5.6-rc3: - Fix dt binding for sunxi. - Allow only 1 rotation argument, and allow 0 rotation in video cmdline. - Small compiler warning fix for panfrost. - Fix when using performance counters in panfrost when using per fd address space. Boris Brezillon (1): drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context Geert Uytterhoeven (1): drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error message Maarten Lankhorst (1): Merge v5.6-rc1 into drm-misc-fixes Maxime Ripard (1): dt-bindings: display: sunxi: Fix compatible Stephan Gerhold (2): drm/modes: Make sure to parse valid rotation value from cmdline drm/modes: Allow DRM_MODE_ROTATE_0 when applying video mode parameters Tomi Valkeinen (1): drm/bridge: tc358767: fix poll timeouts YueHaibing (1): drm/panfrost: Remove set but not used variable 'bo' .../bindings/display/allwinner,sun4i-a10-tcon.yaml| 6 +- drivers/gpu/drm/bridge/tc358767.c | 8 drivers/gpu/drm/bridge/ti-tfp410.c| 3 ++- drivers/gpu/drm/drm_client_modeset.c | 3 ++- drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++- drivers/gpu/drm/drm_modes.c | 7 +++ drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + drivers/gpu/drm/panfrost/panfrost_gem.h | 6 ++ drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 3 +++ drivers/gpu/drm/panfrost/panfrost_job.c | 13 +++-- drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 ++- drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 11 --- drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_cmdline_parser.c | 15 +-- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 - 15 files changed, 63 insertions(+), 25 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Distribute switch variables for initialization
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
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?
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 = &crtc_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 =
> &crtc_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(&uncore->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);
>
--
Jani Nikula, Intel Open Sourc
Re: [Intel-gfx] [PATCH v5] drm/i915/gt: make a gt sysfs group and move power management files
On Wed, 19 Feb 2020, Andi Shyti wrote:
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create the 'gt/' directory in sysfs and move the power management
> related files.
>
> The new interfaces are:
>
> gt/gt_act_freq_mhz
> gt/gt_boost_freq_mhz
> gt/gt_cur_freq_mhz
> gt/gt_info
> gt/gt_max_freq_mhz
> gt/gt_min_freq_mhz
> gt/gt_RP0_freq_mhz
> gt/gt_RP1_freq_mhz
> gt/gt_RPn_freq_mhz
> gt/rc6_enable
> gt/rc6_residency_ms
>
> The once in the root directory will be marked as deprecated, if
> accessed a warning message is printed.
>
> Signed-off-by: Andi Shyti
> ---
> v4 -> v5:
> - removed spurious ghost 'vvv' file that was never meant to be
> there... sorry for spamming.
> v3 -> v4:
> - fixed Tvrtko's comments:
> - some renaming
> - some clumsy unbalanced kobject_put/get
> - the warning print is more descriptive and printed with
> limited rate
> - TODO: drm_print doesn't have a drm_warn_unlimited, to
> be added
> v2 -> v3:
> - fix some cleanups that I forgot in the previous patch
> - fix reference pointers to the gt structure
> - and many other small changes here and there.
> v1 -> v2:
> - keep the existing files as they are
> - use "intel_gt_*" as prefix instead of "sysfs_*"
>
> drivers/gpu/drm/i915/Makefile| 4 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 3 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
> drivers/gpu/drm/i915/gt/sysfs_gt.c | 79 +
> drivers/gpu/drm/i915/gt/sysfs_gt.h | 22 ++
> drivers/gpu/drm/i915/gt/sysfs_gt_pm.c| 432 +++
> drivers/gpu/drm/i915/gt/sysfs_gt_pm.h| 17 +
> drivers/gpu/drm/i915/i915_sysfs.c| 375 +---
> drivers/gpu/drm/i915/i915_sysfs.h| 3 +
> 9 files changed, 561 insertions(+), 375 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c
> create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h
> create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
> create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b314d44ded5e..ff9e17c97dc2 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -107,7 +107,9 @@ gt-y += \
> gt/intel_rps.o \
> gt/intel_sseu.o \
> gt/intel_timeline.o \
> - gt/intel_workarounds.o
> + gt/intel_workarounds.o \
> + gt/sysfs_gt.o \
> + gt/sysfs_gt_pm.o
> # autogenerated null render state
> gt-y += \
> gt/gen6_renderstate.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index f1f1b306e0af..e794d05d69a1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -15,6 +15,7 @@
> #include "intel_rps.h"
> #include "intel_uncore.h"
> #include "intel_pm.h"
> +#include "sysfs_gt.h"
>
> void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
> {
> @@ -321,6 +322,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
> intel_rps_driver_register(>->rps);
>
> debugfs_gt_register(gt);
> + intel_gt_sysfs_register(gt);
> }
>
> static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
> @@ -641,6 +643,7 @@ void intel_gt_driver_remove(struct intel_gt *gt)
>
> void intel_gt_driver_unregister(struct intel_gt *gt)
> {
> + intel_gt_sysfs_unregister(gt);
> intel_rps_driver_unregister(>->rps);
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index 96890dd12b5f..7f0b4f8d9e28 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -32,6 +32,7 @@ struct intel_gt {
> struct drm_i915_private *i915;
> struct intel_uncore *uncore;
> struct i915_ggtt *ggtt;
> + struct kobject sysfs_root;
>
> struct intel_uc uc;
>
> diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c
> b/drivers/gpu/drm/i915/gt/sysfs_gt.c
> new file mode 100644
> index ..9335a92d5248
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/sysfs_gt.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: MIT
> +
Superfluous newline.
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
It's 2020 now. ;)
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../i915_drv.h"
No need for "../", it's in include path.
> +#include "intel_gt.h"
> +#include "intel_gt_types.h"
> +#include "intel_rc6.h"
> +
> +#include "sysfs_gt.h"
> +#include "sysfs_gt_pm.h"
> +
> +static inline struct kobject *gt_get_parent_obj(struct intel_gt *gt)
In .c files just drop the inline keyword and let the compiler do what's
best.
> +{
> + return >->i915->drm.primary->kdev->kobj;
> +}
> +
> +static ssize_t gt_info_show(struct device *dev,
> + struct device_attribute *attr,
> +
Re: [Intel-gfx] [PATCH 01/12] drm: Nuke mode->hsync
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Let's just calculate the hsync rate on demand. No point in wasting
> space storing it and risking the cached value getting out of sync
> with reality.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_modes.c | 14 ++
> drivers/gpu/drm/i915/display/intel_display.c | 1 -
> include/drm/drm_modes.h | 10 --
> 3 files changed, 2 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index d4d64518e11b..fe7e872a6239 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -752,24 +752,14 @@ EXPORT_SYMBOL(drm_mode_set_name);
> * @mode: mode
> *
> * Returns:
> - * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
> - * value first if it is not yet set.
> + * @modes's hsync rate in kHz, rounded to the nearest integer
> */
> int drm_mode_hsync(const struct drm_display_mode *mode)
> {
> - unsigned int calc_val;
> -
> - if (mode->hsync)
> - return mode->hsync;
> -
> if (mode->htotal <= 0)
> return 0;
>
> - calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
> - calc_val += 500;/* round to 1000Hz */
> - calc_val /= 1000; /* truncate to kHz */
> -
> - return calc_val;
> + return DIV_ROUND_CLOSEST(mode->clock, mode->htotal);
> }
> EXPORT_SYMBOL(drm_mode_hsync);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ee7d54ccd3e6..fab914819489 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8867,7 +8867,6 @@ void intel_mode_from_pipe_config(struct
> drm_display_mode *mode,
>
> mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
>
> - mode->hsync = drm_mode_hsync(mode);
With this gone, we could make drm_mode_hsync() internal and move it to
drm_foo_internal.h.
Making it obvious that drivers, should be copy/pasting it.
Regardless, the patch is:
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala wrote: > > From: Ville Syrjälä > > htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it. > > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Signed-off-by: Ville Syrjälä Reviewed-by: Emil Velikov -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove the other slab_dependencies
The real one can be found in i915_scheduler.c.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 6daf18dbb3d4..dbd882fe22ef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -51,7 +51,6 @@ struct execute_cb {
static struct i915_global_request {
struct i915_global base;
struct kmem_cache *slab_requests;
- struct kmem_cache *slab_dependencies;
struct kmem_cache *slab_execute_cbs;
} global;
@@ -1614,14 +1613,12 @@ long i915_request_wait(struct i915_request *rq,
static void i915_global_request_shrink(void)
{
- kmem_cache_shrink(global.slab_dependencies);
kmem_cache_shrink(global.slab_execute_cbs);
kmem_cache_shrink(global.slab_requests);
}
static void i915_global_request_exit(void)
{
- kmem_cache_destroy(global.slab_dependencies);
kmem_cache_destroy(global.slab_execute_cbs);
kmem_cache_destroy(global.slab_requests);
}
@@ -1651,16 +1648,9 @@ int __init i915_global_request_init(void)
if (!global.slab_execute_cbs)
goto err_requests;
- global.slab_dependencies = KMEM_CACHE(i915_dependency,
- SLAB_HWCACHE_ALIGN |
- SLAB_RECLAIM_ACCOUNT);
- if (!global.slab_dependencies)
- goto err_execute_cbs;
-
i915_global_register(&global.base);
return 0;
-err_execute_cbs:
kmem_cache_destroy(global.slab_execute_cbs);
err_requests:
kmem_cache_destroy(global.slab_requests);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove the other slab_dependencies
Quoting Matthew Auld (2020-02-20 10:57:07) > The real one can be found in i915_scheduler.c. > > Signed-off-by: Matthew Auld > Cc: Chris Wilson You're not a fan of redundancy, I see :) Oops, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Introduce some local intel_dp variables
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala wrote: > > From: Ville Syrjälä > > The drrs code dereferences mode->vrefresh via some really long chain > of structures/pointers. Couldn't get coccinelle to see through all > that so let's add some local variables to help it. > There's a limit to the madness that coccinelle can take :-P Other drrs functions already use intel_dp, so might as well be consistent. Reviewed-by: Emil Velikov -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel -
Due to issues in s2idle in v5.6-rc2, I've gotten CI results on these
with two hack reverts on top, and I threw them out just before making
the pull request. I had to revert:
fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the
system")
e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE")
I've been told the issues have been reported, hopefully we'll get the
fixes in Linus' upstream soon too.
drm-intel-fixes-2020-02-20:
drm/i915 fixes for v5.6-rc3:
- Workaround missing Display Stream Compression (DSC) state readout by
forcing modeset when its enabled at probe
- Fix EHL port clock voltage level requirements
- Fix queuing retire workers on the virtual engine
- Fix use of partially initialized waiters
- Stop using drm_pci_alloc/drm_pci/free
- Fix rewind of RING_TAIL by forcing a context reload
- Fix locking on resetting ring->head
- Propagate our bug filing URL change to stable kernels
BR,
Jani.
The following changes since commit 11a48a5a18c63fd7621bb050228cebf13566e4d8:
Linux 5.6-rc2 (2020-02-16 13:16:59 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-02-20
for you to fetch changes up to 15de9cb5c9c83a23be92b8f7a1178cead1486587:
drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex
(2020-02-18 09:53:18 +0200)
drm/i915 fixes for v5.6-rc3:
- Workaround missing Display Stream Compression (DSC) state readout by
forcing modeset when its enabled at probe
- Fix EHL port clock voltage level requirements
- Fix queuing retire workers on the virtual engine
- Fix use of partially initialized waiters
- Stop using drm_pci_alloc/drm_pci/free
- Fix rewind of RING_TAIL by forcing a context reload
- Fix locking on resetting ring->head
- Propagate our bug filing URL change to stable kernels
Chris Wilson (7):
drm/i915/gem: Require per-engine reset support for non-persistent contexts
drm/i915: Initialise basic fence before acquiring seqno
drm/i915/gt: Prevent queuing retire workers on the virtual engine
drm/i915/gt: Protect defer_request() from new waiters
drm/i915: Wean off drm_pci_alloc/drm_pci_free
drm/i915/execlists: Always force a context reload when rewinding RING_TAIL
drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex
Jani Nikula (3):
MAINTAINERS: Update drm/i915 bug filing URL
drm/i915: Update drm/i915 bug filing URL
drm/i915/dsc: force full modeset whenever DSC is enabled at probe
Matt Roper (1):
drm/i915/ehl: Update port clock voltage level requirements
MAINTAINERS | 2 +-
drivers/gpu/drm/i915/Kconfig | 5 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_display.c | 20 -
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 -
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 98
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +++
drivers/gpu/drm/i915/gt/intel_ring.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring.h | 8 ++
drivers/gpu/drm/i915/gt/intel_ring_types.h | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 8 +-
drivers/gpu/drm/i915/i915_gpu_error.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 21 +++--
drivers/gpu/drm/i915/i915_scheduler.c| 6 +-
drivers/gpu/drm/i915/i915_utils.c| 5 +-
19 files changed, 168 insertions(+), 108 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915: Add i9xx_lut_8()
On Thu, 7 Nov 2019 at 15:17, Ville Syrjala wrote: > > From: Ville Syrjälä > > We have a nice little helper to compute a single LUT entry > for everything except the 8bpc legacy gamma mode. Let's > complete the set. > At a later stage one could rename this & the 10bit one, moving them to include/drm/. There are other drivers doing the same thing... not sure if that's worth it though. Reviewed-by: Emil Velikov -Emil ___ 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 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 ? Otherwise: Reviewed-by: Emil Velikov -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
== Series Details == Series: series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14 URL : https://patchwork.freedesktop.org/series/73586/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16603_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16603_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16603_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_16603_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_16603/shard-tglb5/igt@gem_exec_balan...@hang.html Known issues Here are the changes found in Patchwork_16603_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_b...@busy-vcs1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb6/igt@gem_b...@busy-vcs1.html * igt@gem_exec_schedule@pi-shared-iova-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-iclb8/igt@gem_exec_sched...@pi-shared-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +5 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_16603/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl4/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl4/igt@gem_exec_susp...@basic-s3.html * igt@gem_partial_pwrite_pread@reads-uncached: - shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@gem_partial_pwrite_pr...@reads-uncached.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-hsw2/igt@gem_partial_pwrite_pr...@reads-uncached.html * igt@i915_selftest@live_gt_heartbeat: - shard-skl: [PASS][13] -> [DMESG-FAIL][14] ([fdo#112406]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl7/igt@i915_selftest@live_gt_heartbeat.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl8/igt@i915_selftest@live_gt_heartbeat.html * igt@i915_selftest@live_gt_lrc: - shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#1233]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@live_gt_lrc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb2/igt@i915_selftest@live_gt_lrc.html * igt@kms_cursor_legacy@flip-vs-cursor-legacy: - shard-skl: [PASS][17] -> [FAIL][18] ([IGT#5]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html * igt@kms_flip@flip-vs-absolute-wf_vblank: - shard-tglb: [PASS][19] -> [FAIL][20] ([i915#488]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html * igt@kms_flip@flip-vs-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@kms_f...@flip-vs-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl1/igt@kms_f...@flip-vs-suspend.html - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl4/igt@kms_f...@flip-vs-suspend.htm
Re: [Intel-gfx] [PATCH 04/12] drm: Nuke mode->vrefresh
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala wrote: > > From: Ville Syrjälä > > Get rid of mode->vrefresh and just calculate it on demand. Saves > a bit of space and avoids the cached value getting out of sync > with reality. > > Mostly done with cocci, with the following manual fixups: > - Remove the now empty loop in drm_helper_probe_single_connector_modes() > - Fix __MODE() macro in ch7006_mode.c Speaking of ch7006_mode.c, it has its own "fixed vrefresh", which doesn't seem to be used anywhere. One could potentially nuke it, although it can be a completely separate patch. This patch is: Reviewed-by: Emil Velikov -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: remove the other slab_dependencies
== Series Details ==
Series: drm/i915: remove the other slab_dependencies
URL : https://patchwork.freedesktop.org/series/73701/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7972 -> Patchwork_16643
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16643 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16643, 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_16643/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16643:
### IGT changes ###
Possible regressions
* igt@prime_busy@basic-wait-before-default:
- fi-skl-6770hq: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-skl-6770hq/igt@prime_b...@basic-wait-before-default.html
Known issues
Here are the changes found in Patchwork_16643 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][2] -> [INCOMPLETE][3] ([i915#694] / [i915#816])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][4] -> [DMESG-FAIL][5] ([i915#877])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- fi-bxt-dsi: [PASS][6] -> [TIMEOUT][7] ([fdo#112271])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
- fi-bdw-5557u: [PASS][8] -> [TIMEOUT][9] ([fdo#112271])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][10] -> [FAIL][11] ([i915#262])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][12] ([i915#585]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-icl-u3/igt@i915_module_l...@reload.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_execlists:
- fi-icl-y: [DMESG-FAIL][14] ([fdo#108569]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-icl-y/igt@i915_selftest@live_execlists.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-icl-y/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [DMESG-FAIL][16] ([i915#730]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gtt:
- fi-kbl-7500u: [TIMEOUT][18] ([fdo#112271]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-kbl-7500u/igt@i915_selftest@live_gtt.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u3: [INCOMPLETE][20] ([fdo#108569]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7972/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16643/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[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#
[Intel-gfx] [PATCH v17 5/7] drm/i915: Added required new PCode commands
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_sideband.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b09c1d6dc0aa..b3924e9d25bc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8997,6 +8997,7 @@ enum {
#define GEN7_PCODE_ILLEGAL_DATA0x3
#define GEN11_PCODE_ILLEGAL_SUBCOMMAND 0x4
#define GEN11_PCODE_LOCKED 0x6
+#define GEN11_PCODE_REJECTED 0x11
#define GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE 0x10
#define GEN6_PCODE_WRITE_RC6VIDS 0x4
#define GEN6_PCODE_READ_RC6VIDS 0x5
@@ -9018,6 +9019,7 @@ enum {
#define ICL_PCODE_MEM_SUBSYSYSTEM_INFO 0xd
#define ICL_PCODE_MEM_SS_READ_GLOBAL_INFO (0x0 << 8)
#define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)(((point) <<
16) | (0x1 << 8))
+#define ICL_PCODE_SAGV_DE_MEM_SS_CONFIG 0xe
#define GEN6_PCODE_READ_D_COMP 0x10
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
@@ -9030,6 +9032,8 @@ enum {
#define GEN9_SAGV_IS_DISABLED 0x1
#define GEN9_SAGV_ENABLE 0x3
#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
+#define GEN11_PCODE_POINTS_RESTRICTED 0x0
+#define GEN11_PCODE_POINTS_RESTRICTED_MASK 0x1
#define GEN6_PCODE_DATA_MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 1447e7516cb7..1e7dd6b6f103 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -370,6 +370,8 @@ static inline int gen7_check_mailbox_status(u32 mbox)
return -ENXIO;
case GEN11_PCODE_LOCKED:
return -EBUSY;
+ case GEN11_PCODE_REJECTED:
+ return -EACCES;
case GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE:
return -EOVERFLOW;
default:
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 4/7] drm/i915: Refactor intel_can_enable_sagv
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with added sagv block time latency and
check if it fits in DBuf in order to
determine if SAGV can be enabled already
at this stage, just as BSpec 49325 states.
if that fails rollback to usual Level 0
latency and disable SAGV.
- Remove unneeded tabs(James Ausmus)
v3: Rebased the patch
v4: - Added back interlaced check for Gen12 and
added separate function for TGL SAGV check
(thanks to James Ausmus for spotting)
- Removed unneeded gen check
- Extracted Gen12 SAGV decision making code
to a separate function from skl_compute_wm
v5: - Added SAGV global state to dev_priv, because
we need to track all pipes, not only those
in atomic state. Each pipe has now correspondent
bit mask reflecting, whether it can tolerate
SAGV or not(thanks to Ville Syrjala for suggestions).
- Now using active flag instead of enable in crc
usage check.
v6: - Fixed rebase conflicts
v7: - kms_cursor_legacy seems to get broken because of multiple memcpy
calls when copying level 0 water marks for enabled SAGV, to
fix this now simply using that field right away, without copying,
for that introduced a new wm_level accessor which decides which
wm_level to return based on SAGV state.
v8: - Protect crtc_sagv_mask same way as we do for other global state
changes: i.e check if changes are needed, then grab all crtc locks
to serialize the changes(Ville Syrjälä)
- Add crtc_sagv_mask caching in order to avoid needless recalculations
(Matthew Roper)
- Put back Gen12 SAGV switch in order to get it enabled in separate
patch(Matthew Roper)
- Rename *_set_sagv_mask to *_compute_sagv_mask(Matthew Roper)
- Check if there are no active pipes in intel_can_enable_sagv
instead of platform specific functions(Matthew Roper), same
for intel_has_sagv check.
v9 - Switched to u8 for crtc_sagv_mask(Ville Syrjälä)
- crtc_sagv_mask now is pipe_sagv_mask(Ville Syrjälä)
- Extracted sagv checking logic from skl/icl/tgl_compute_sagv_mask
- Extracted skl_plane_wm_level function and passing latency to
separate patches(Ville Syrjälä)
- Removed part of unneeded copy-paste from tgl_check_pipe_fits_sagv_wm
(Ville Syrjälä)
- Now using simple assignment for sagv_wm0 as it contains only
pod types and no pointers(Ville Syrjälä)
- Fixed intel_can_enable_sagv not to do double duty, now it only
check SAGV bits by ANDing those between local and global state.
The SAGV masks are now computed after watermarks are available,
in order to be able to figure out if ddb ranges are fitting nicely.
(Ville Syrjälä)
- Now having uv_sagv_wm0 and sagv_wm0, otherwise we have wrong logic
when using skl_plane_wm_level accessor, as we had previously for Gen11+
color plane and regular wm levels, so probably both has to be recalculated
with additional SAGV block time for Level 0.
v10: - Starting to use new global state for storing pipe_sagv_mask
v11: - Fixed rebase conflict with recent drm-tip
- Check if we really need to recalculate SAGV mask, otherwise
bail out without making any changes.
- Use cached SAGV result, instead of recalculating it everytime,
if bw_state hasn't changed.
Signed-off-by: Stanislav Lisovskiy
Cc: Ville Syrjälä
Cc: James Ausmus
---
drivers/gpu/drm/i915/display/intel_bw.h | 18 +
drivers/gpu/drm/i915/display/intel_display.c | 22 +-
.../drm/i915/display/intel_display_types.h| 2 +
.../gpu/drm/i915/display/intel_global_state.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 449 --
drivers/gpu/drm/i915/intel_pm.h | 4 +-
6 files changed, 454 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index ac004d6f4276..fb1760125f9d 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -18,6 +18,24 @@ struct intel_crtc_state;
struct intel_bw_state {
struct intel_global_state base;
+ /*
+* Contains a bit mask, used to determine, whether correspondent
+* pipe allows SAGV or not.
+*/
+ u8 pipe_sagv_mask;
+
+ /*
+* Used to determine if we already had calculated
+* SAGV mask for this state once.
+*/
+ bool sagv_calculated;
+
+ /*
+* Contains final SAGV decision based on current mask,
+* to prevent doing the same job over and over again.
+*/
+ bool can_sagv;
+
unsigned int data_rate[I915_MAX_PIPES];
u8 num_active_p
[Intel-gfx] [PATCH v17 2/7] drm/i915: Introduce skl_plane_wm_level accessor.
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be changed
in next coming patches from this series.
v2: - plane_id -> plane->id(Ville Syrjälä)
- Moved wm_level var to have more local scope
(Ville Syrjälä)
- Renamed yuv to color_plane(Ville Syrjälä) in
skl_plane_wm_level
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 120 +---
1 file changed, 81 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d6933e382657..e1d167429489 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4548,6 +4548,18 @@ icl_get_total_relative_data_rate(struct intel_crtc_state
*crtc_state,
return total_data_rate;
}
+static const struct skl_wm_level *
+skl_plane_wm_level(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ int level,
+ int color_plane)
+{
+ const struct skl_plane_wm *wm =
+ &crtc_state->wm.skl.optimal.planes[plane->id];
+
+ return color_plane ? &wm->uv_wm[level] : &wm->wm[level];
+}
+
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
{
@@ -4560,7 +4572,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *crtc_state)
u16 total[I915_MAX_PLANES] = {};
u16 uv_total[I915_MAX_PLANES] = {};
u64 total_data_rate;
- enum plane_id plane_id;
+ struct intel_plane *plane;
int num_active;
u64 plane_data_rate[I915_MAX_PLANES] = {};
u64 uv_plane_data_rate[I915_MAX_PLANES] = {};
@@ -4612,22 +4624,28 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
*crtc_state)
*/
for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
blocks = 0;
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
- const struct skl_plane_wm *wm =
- &crtc_state->wm.skl.optimal.planes[plane_id];
- if (plane_id == PLANE_CURSOR) {
- if (wm->wm[level].min_ddb_alloc >
total[PLANE_CURSOR]) {
+ for_each_intel_plane_on_crtc(&dev_priv->drm, intel_crtc, plane)
{
+ const struct skl_wm_level *wm_level;
+ const struct skl_wm_level *wm_uv_level;
+
+ wm_level = skl_plane_wm_level(plane, crtc_state,
+ level, false);
+ wm_uv_level = skl_plane_wm_level(plane, crtc_state,
+level, true);
+
+ if (plane->id == PLANE_CURSOR) {
+ if (wm_level->min_ddb_alloc >
total[PLANE_CURSOR]) {
drm_WARN_ON(&dev_priv->drm,
- wm->wm[level].min_ddb_alloc
!= U16_MAX);
+ wm_level->min_ddb_alloc !=
U16_MAX);
blocks = U32_MAX;
break;
}
continue;
}
- blocks += wm->wm[level].min_ddb_alloc;
- blocks += wm->uv_wm[level].min_ddb_alloc;
+ blocks += wm_level->min_ddb_alloc;
+ blocks += wm_uv_level->min_ddb_alloc;
}
if (blocks <= alloc_size) {
@@ -4649,13 +4667,18 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
*crtc_state)
* watermark level, plus an extra share of the leftover blocks
* proportional to its relative data rate.
*/
- for_each_plane_id_on_crtc(intel_crtc, plane_id) {
- const struct skl_plane_wm *wm =
- &crtc_state->wm.skl.optimal.planes[plane_id];
+ for_each_intel_plane_on_crtc(&dev_priv->drm, intel_crtc, plane) {
+ const struct skl_wm_level *wm_level;
+ const struct skl_wm_level *wm_uv_level;
u64 rate;
u16 extra;
- if (plane_id == PLANE_CURSOR)
+ wm_level = skl_plane_wm_level(plane, crtc_state,
+ level, false);
+ wm_uv_level = skl_plane_wm_level(plane, crtc_state,
+level, true);
+
+ if (plane->id == PLANE_CURSOR)
continue;
/*
@@ -4665,22 +4688,22 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
*crtc_state)
if (total_d
[Intel-gfx] [PATCH v17 3/7] drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
We might be willing to call intel_atomic_get_old_global_obj_state
and intel_atomic_get_new_global_obj_state right away, however
those are not initializing global obj state as
intel_atomic_get_global_obj_state does.
Extracted initializing part to separate function and now using this
also in intel_atomic_get_old_global_obj_state and
intel_atomic_get_new_global_obj_state
v2: - Fixed typo in function call
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.c | 28 -
drivers/gpu/drm/i915/display/intel_bw.h | 9
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 58b264bc318d..ff57277e8880 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -374,7 +374,33 @@ static unsigned int intel_bw_data_rate(struct
drm_i915_private *dev_priv,
return data_rate;
}
-static struct intel_bw_state *
+struct intel_bw_state *
+intel_atomic_get_old_bw_state(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_global_state *bw_state;
+
+ bw_state = intel_atomic_get_old_global_obj_state(state,
&dev_priv->bw_obj);
+ if (IS_ERR(bw_state))
+ return ERR_CAST(bw_state);
+
+ return to_intel_bw_state(bw_state);
+}
+
+struct intel_bw_state *
+intel_atomic_get_new_bw_state(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_global_state *bw_state;
+ bw_state = intel_atomic_get_new_global_obj_state(state,
&dev_priv->bw_obj);
+
+ if (IS_ERR(bw_state))
+ return ERR_CAST(bw_state);
+
+ return to_intel_bw_state(bw_state);
+}
+
+struct intel_bw_state *
intel_atomic_get_bw_state(struct intel_atomic_state *state)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index a8aa7624c5aa..ac004d6f4276 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -24,6 +24,15 @@ struct intel_bw_state {
#define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
+struct intel_bw_state *
+intel_atomic_get_old_bw_state(struct intel_atomic_state *state);
+
+struct intel_bw_state *
+intel_atomic_get_new_bw_state(struct intel_atomic_state *state);
+
+struct intel_bw_state *
+intel_atomic_get_bw_state(struct intel_atomic_state *state);
+
void intel_bw_init_hw(struct drm_i915_private *dev_priv);
int intel_bw_init(struct drm_i915_private *dev_priv);
int intel_bw_atomic_check(struct intel_atomic_state *state);
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 6/7] drm/i915: Restrict qgv points which don't have enough bandwidth.
According to BSpec 53998, we should try to restrict qgv points, which can't provide enough bandwidth for desired display configuration. Currently we are just comparing against all of those and take minimum(worst case). v2: Fixed wrong PCode reply mask, removed hardcoded values. v3: Forbid simultaneous legacy SAGV PCode requests and restricting qgv points. Put the actual restriction to commit function, added serialization(thanks to Ville) to prevent commit being applied out of order in case of nonblocking and/or nomodeset commits. v4: - Minor code refactoring, fixed few typos(thanks to James Ausmus) - Change the naming of qgv point masking/unmasking functions(James Ausmus). - Simplify the masking/unmasking operation itself, as we don't need to mask only single point per request(James Ausmus) - Reject and stick to highest bandwidth point if SAGV can't be enabled(BSpec) v5: - Add new mailbox reply codes, which seems to happen during boot time for TGL and indicate that QGV setting is not yet available. v6: - Increase number of supported QGV points to be in sync with BSpec. v7: - Rebased and resolved conflict to fix build failure. - Fix NUM_QGV_POINTS to 8 and moved that to header file(James Ausmus) v8: - Don't report an error if we can't restrict qgv points, as SAGV can be disabled by BIOS, which is completely legal. So don't make CI panic. Instead if we detect that there is only 1 QGV point accessible just analyze if we can fit the required bandwidth requirements, but no need in restricting. v9: - Fix wrong QGV transition if we have 0 planes and no SAGV simultaneously. v10: - Fix CDCLK corruption, because of global state getting serialized without modeset, which caused copying of non-calculated cdclk to be copied to dev_priv(thanks to Ville for the hint). v11: - Remove unneeded headers and spaces(Matthew Roper) - Remove unneeded intel_qgv_info qi struct from bw check and zero out the needed one(Matthew Roper) - Changed QGV error message to have more clear meaning(Matthew Roper) - Use state->modeset_set instead of any_ms(Matthew Roper) - Moved NUM_SAGV_POINTS from i915_reg.h to i915_drv.h where it's used - Keep using crtc_state->hw.active instead of .enable(Matthew Roper) - Moved unrelated changes to other patch(using latency as parameter for plane wm calculation, moved to SAGV refactoring patch) v12: - Fix rebase conflict with own temporary SAGV/QGV fix. - Remove unnecessary mask being zero check when unmasking qgv points as this is completely legal(Matt Roper) - Check if we are setting the same mask as already being set in hardware to prevent error from PCode. - Fix error message when restricting/unrestricting qgv points to "mask/unmask" which sounds more accurate(Matt Roper) - Move sagv status setting to icl_get_bw_info from atomic check as this should be calculated only once.(Matt Roper) - Edited comments for the case when we can't enable SAGV and use only 1 QGV point with highest bandwidth to be more understandable.(Matt Roper) v13: - Moved max_data_rate in bw check to closer scope(Ville Syrjälä) - Changed comment for zero new_mask in qgv points masking function to better reflect reality(Ville Syrjälä) - Simplified bit mask operation in qgv points masking function (Ville Syrjälä) - Moved intel_qgv_points_mask closer to gen11 SAGV disabling, however this still can't be under modeset condition(Ville Syrjälä) - Packed qgv_points_mask as u8 and moved closer to pipe_sagv_mask (Ville Syrjälä) - Extracted PCode changes to separate patch.(Ville Syrjälä) - Now treat num_planes 0 same as 1 to avoid confusion and returning max_bw as 0, which would prevent choosing QGV point having max bandwidth in case if SAGV is not allowed, as per BSpec(Ville Syrjälä) - Do the actual qgv_points_mask swap in the same place as all other global state parts like cdclk are swapped. In the next patch, this all will be moved to bw state as global state, once new global state patch series from Ville lands v14: - Now using global state to serialize access to qgv points - Added global state locking back, otherwise we seem to read bw state in a wrong way. v15: - Added TODO comment for near atomic global state locking in bw code. Signed-off-by: Stanislav Lisovskiy Cc: Ville Syrjälä Cc: James Ausmus --- drivers/gpu/drm/i915/display/intel_bw.c | 177 ++- drivers/gpu/drm/i915/display/intel_bw.h | 9 + drivers/gpu/drm/i915/display/intel_display.c | 109 drivers/gpu/drm/i915/i915_drv.h | 3 + 4 files changed, 249 insertions(+), 49 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bw.c b/drivers/gpu/drm/i915/d
[Intel-gfx] [PATCH v17 7/7] drm/i915: Enable SAGV support for Gen12
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2aafd2b07e4a..6d4240f260a9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3624,10 +3624,6 @@ static bool skl_needs_memory_bw_wa(struct
drm_i915_private *dev_priv)
bool
intel_has_sagv(struct drm_i915_private *dev_priv)
{
- /* HACK! */
- if (IS_GEN(dev_priv, 12))
- return false;
-
return (IS_GEN9_BC(dev_priv) || INTEL_GEN(dev_priv) >= 10) &&
dev_priv->sagv_status != I915_SAGV_NOT_CONTROLLED;
}
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 0/7] Refactor Gen11+ SAGV support
For Gen11+ platforms BSpec suggests disabling specific QGV points separately, depending on bandwidth limitations and current display configuration. Thus it required adding a new PCode request for disabling QGV points and some refactoring of already existing SAGV code. Also had to refactor intel_can_enable_sagv function, as current seems to be outdated and using skl specific workarounds, also not following BSpec for Gen11+. v17: Had to rebase the whole series. Stanislav Lisovskiy (7): drm/i915: Start passing latency as parameter drm/i915: Introduce skl_plane_wm_level accessor. drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state drm/i915: Refactor intel_can_enable_sagv drm/i915: Added required new PCode commands drm/i915: Restrict qgv points which don't have enough bandwidth. drm/i915: Enable SAGV support for Gen12 drivers/gpu/drm/i915/display/intel_bw.c | 205 -- drivers/gpu/drm/i915/display/intel_bw.h | 36 ++ drivers/gpu/drm/i915/display/intel_display.c | 131 +++- .../drm/i915/display/intel_display_types.h| 2 + .../gpu/drm/i915/display/intel_global_state.h | 1 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_pm.c | 585 +++--- drivers/gpu/drm/i915/intel_pm.h | 4 +- drivers/gpu/drm/i915/intel_sideband.c | 2 + 10 files changed, 834 insertions(+), 139 deletions(-) -- 2.24.1.485.gad05a3d8e5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v17 1/7] drm/i915: Start passing latency as parameter
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ffac0b862ca5..d6933e382657 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4002,6 +4002,7 @@ static int skl_compute_wm_params(const struct
intel_crtc_state *crtc_state,
int color_plane);
static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
int level,
+u32 latency,
const struct skl_wm_params *wp,
const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */);
@@ -4024,7 +4025,9 @@ skl_cursor_allocation(const struct intel_crtc_state
*crtc_state,
drm_WARN_ON(&dev_priv->drm, ret);
for (level = 0; level <= max_level; level++) {
- skl_compute_plane_wm(crtc_state, level, &wp, &wm, &wm);
+ u32 latency = dev_priv->wm.skl_latency[level];
+
+ skl_compute_plane_wm(crtc_state, level, latency, &wp, &wm, &wm);
if (wm.min_ddb_alloc == U16_MAX)
break;
@@ -4978,12 +4981,12 @@ static bool skl_wm_has_lines(struct drm_i915_private
*dev_priv, int level)
static void skl_compute_plane_wm(const struct intel_crtc_state *crtc_state,
int level,
+u32 latency,
const struct skl_wm_params *wp,
const struct skl_wm_level *result_prev,
struct skl_wm_level *result /* out */)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
- u32 latency = dev_priv->wm.skl_latency[level];
uint_fixed_16_16_t method1, method2;
uint_fixed_16_16_t selected_result;
u32 res_blocks, res_lines, min_ddb_alloc = 0;
@@ -5112,9 +5115,10 @@ skl_compute_wm_levels(const struct intel_crtc_state
*crtc_state,
for (level = 0; level <= max_level; level++) {
struct skl_wm_level *result = &levels[level];
+ u32 latency = dev_priv->wm.skl_latency[level];
- skl_compute_plane_wm(crtc_state, level, wm_params,
-result_prev, result);
+ skl_compute_plane_wm(crtc_state, level, latency,
+wm_params, result_prev, result);
result_prev = result;
}
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Double check bumping after the spinlock
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 59f70b674665..be770f2419b1 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -363,6 +363,9 @@ static void __bump_priority(struct i915_sched_node *node,
unsigned int bump)
{
struct i915_sched_attr attr = node->attr;
+ if (attr.priority & bump)
+ return;
+
attr.priority |= bump;
__i915_schedule(node, &attr);
}
--
2.25.1
___
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 v2] tests/gem_userptr_blits: Enhance invalid mapping exercise
Hi Chris,
On Tuesday, February 11, 2020 5:44:59 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> > @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler,
NULL)
> > igt_subtest("invalid-null-pointer")
> > test_invalid_null_pointer(fd);
> >
> > - igt_subtest("invalid-gtt-mapping")
> > - test_invalid_gtt_mapping(fd);
> > + igt_describe("Verify userptr on top of GTT mapping to GEM
object will fail");
> > + igt_subtest("invalid-gtt-mapping") {
> > + gem_require_mappable_ggtt(fd);
> > + test_invalid_mapping(fd, I915_MMAP_OFFSET_GTT);
> > + }
>
> #include "i915/gem_mman.h"
> igt_subtest_with_dynamic("invalid-mmap-offset") {
> for_each_mmap_offset_type(t) {
> igt_dynamic_f("%s", t->name)
> test_invalid_mapping(fd, t);
>
> In test_invalid_mapping, instead of do_ioctl(MMAP_OFFSET) use
> igt_require(igt_ioctl(MMAP_OFFSET, &arg) == 0);
Inspired by Michał, I've revisited this construct and now I think a confusing
side effect of it may be expected. When run on a driver with no mmap-offset
support, igt_ioctl(MMAP_OFFSET, &arg) would succeed for each t->type and the
test would claim success for every mapping type.
Something like this should help:
if (t->type != I915_MMAP_OFFSET_GTT)
igt_require(gem_has_mmap_offset(fd);
If my finding occurs correct, I'll update my patches and resubmit.
Thanks,
Janusz
>
> (Or igt_require_f if you like to keep the spiel.)
>
> }
> }
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Protect i915_request_await_start from early waits
We need to be extremely careful inside i915_request_await_start() as it
needs to walk the list of requests in the foreign timeline with very
little protection. As we hold our own timeline mutex, we can not nest
inside the signaler's timeline mutex, so all that remains is our RCU
protection. However, to be safe we need to tell the compiler that we may
be traversing the list only under RCU protection, and furthermore we
need to start declaring requests as elements of the timeline from their
construction.
Fixes: 9ddc8ec027a3 ("drm/i915: Eliminate the trylock for awaiting an earlier
request")
Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 43 -
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d53af93b919b..28f135ebeaa0 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -290,7 +290,7 @@ bool i915_request_retire(struct i915_request *rq)
spin_unlock_irq(&rq->lock);
remove_from_client(rq);
- list_del(&rq->link);
+ list_del_rcu(&rq->link);
intel_context_exit(rq->context);
intel_context_unpin(rq->context);
@@ -736,6 +736,8 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->infix = rq->ring->emit; /* end of header; start of user payload */
intel_context_mark_active(ce);
+ list_add_tail_rcu(&rq->link, &tl->requests);
+
return rq;
err_unwind:
@@ -792,13 +794,21 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
GEM_BUG_ON(i915_request_timeline(rq) ==
rcu_access_pointer(signal->timeline));
+ if (i915_request_started(signal))
+ return 0;
+
fence = NULL;
rcu_read_lock();
spin_lock_irq(&signal->lock);
- if (!i915_request_started(signal) &&
- !list_is_first(&signal->link,
- &rcu_dereference(signal->timeline)->requests)) {
- struct i915_request *prev = list_prev_entry(signal, link);
+ do {
+ struct list_head *pos = READ_ONCE(signal->link.prev);
+ struct i915_request *prev;
+
+ if (i915_request_started(signal))
+ break;
+
+ if (pos == &rcu_dereference(signal->timeline)->requests)
+ break;
/*
* Peek at the request before us in the timeline. That
@@ -806,13 +816,22 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
* after acquiring a reference to it, confirm that it is
* still part of the signaler's timeline.
*/
- if (i915_request_get_rcu(prev)) {
- if (list_next_entry(prev, link) == signal)
- fence = &prev->fence;
- else
- i915_request_put(prev);
+ prev = list_entry(pos, typeof(*prev), link);
+ if (!i915_request_get_rcu(prev))
+ break;
+
+ if (i915_request_completed(prev)) {
+ i915_request_put(prev);
+ break;
}
- }
+
+ if (READ_ONCE(prev->link.next) != &signal->link) {
+ i915_request_put(prev);
+ break;
+ }
+
+ fence = &prev->fence;
+ } while (0);
spin_unlock_irq(&signal->lock);
rcu_read_unlock();
if (!fence)
@@ -1253,8 +1272,6 @@ __i915_request_add_to_timeline(struct i915_request *rq)
0);
}
- list_add_tail(&rq->link, &timeline->requests);
-
/*
* Make sure that no request gazumped us - if it was allocated after
* our i915_request_alloc() and called __i915_request_add() before
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Force PSR probe only after full initialization
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.
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()?
> if (!crtc_state->has_psr)
> return;
>
> @@ -1096,6 +1098,8 @@ void intel_psr_update(struct intel_dp
> *intel_dp,
> struct i915_psr *psr = &dev_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.
> +{
> + 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 a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index f7a1c33697b7..83791c197611 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"
>
> @@ -1256,6 +1257,8 @@ static void i915_driver_register(struct
> drm_i915_private *dev_priv)
>
> intel_audio_init(dev_priv);
>
> + intel_psr_force_mod
Re: [Intel-gfx] [PATCH v17 3/7] drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
On Thu, 20 Feb 2020, Stanislav Lisovskiy wrote:
> We might be willing to call intel_atomic_get_old_global_obj_state
> and intel_atomic_get_new_global_obj_state right away, however
> those are not initializing global obj state as
> intel_atomic_get_global_obj_state does.
> Extracted initializing part to separate function and now using this
> also in intel_atomic_get_old_global_obj_state and
> intel_atomic_get_new_global_obj_state
>
> v2: - Fixed typo in function call
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 28 -
> drivers/gpu/drm/i915/display/intel_bw.h | 9
> 2 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 58b264bc318d..ff57277e8880 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -374,7 +374,33 @@ static unsigned int intel_bw_data_rate(struct
> drm_i915_private *dev_priv,
> return data_rate;
> }
>
> -static struct intel_bw_state *
> +struct intel_bw_state *
> +intel_atomic_get_old_bw_state(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_global_state *bw_state;
> +
> + bw_state = intel_atomic_get_old_global_obj_state(state,
> &dev_priv->bw_obj);
> + if (IS_ERR(bw_state))
> + return ERR_CAST(bw_state);
> +
> + return to_intel_bw_state(bw_state);
> +}
> +
> +struct intel_bw_state *
> +intel_atomic_get_new_bw_state(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_global_state *bw_state;
> + bw_state = intel_atomic_get_new_global_obj_state(state,
> &dev_priv->bw_obj);
> +
> + if (IS_ERR(bw_state))
> + return ERR_CAST(bw_state);
> +
> + return to_intel_bw_state(bw_state);
> +}
> +
> +struct intel_bw_state *
> intel_atomic_get_bw_state(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index a8aa7624c5aa..ac004d6f4276 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -24,6 +24,15 @@ struct intel_bw_state {
>
> #define to_intel_bw_state(x) container_of((x), struct intel_bw_state, base)
>
> +struct intel_bw_state *
> +intel_atomic_get_old_bw_state(struct intel_atomic_state *state);
> +
> +struct intel_bw_state *
> +intel_atomic_get_new_bw_state(struct intel_atomic_state *state);
> +
> +struct intel_bw_state *
> +intel_atomic_get_bw_state(struct intel_atomic_state *state);
> +
I'm trying to promote a convention that a module foo_bar.[ch] would
export functions prefixed foo_bar_. Here, intel_bw_* like below.
BR,
Jani.
> void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> int intel_bw_init(struct drm_i915_private *dev_priv);
> int intel_bw_atomic_check(struct intel_atomic_state *state);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915/hdcp: Return 0 on config_stream_type() +ve return
As DP shim's config_stream_type returns size of message to be written in case of success therefore on config_stream_type success return a zero success value in order to succeed the HDCP auth. CC: Ramalingam C Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index 75f60ca282fc..464ef7ba4db4 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -1538,7 +1538,9 @@ static int hdcp2_authenticate_sink(struct intel_connector *connector) ret = shim->config_stream_type(intel_dig_port, hdcp->is_repeater, hdcp->content_type); - if (ret < 0) + if (ret >= 0) + ret = 0; + else return ret; } -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg
HDCP Repeater initializes seq_num_V to 0 at the beginning of
hdcp Session i.e. after AKE_init received, refer
HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20.
HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT
considers failure of authentication if the repeater provides a
non-zero value in seq_num_V in the first,
RepeaterAuth_Send_ReceiverID_List message.
Make sure that HDCP repeater initializes seq_num_V to zero at
beginning of session i.e. after AKE_Init, fail the Auth if
there is non zero seq_num_V.
v2:
- Used existing hdcp2_encrypted flag instead of
declaring new flag. [Ram]
Cc: Ramalingam C
Reviewed-by: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 30e0a3aa9d57..75f60ca282fc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1462,6 +1462,12 @@ int hdcp2_authenticate_repeater_topology(struct
intel_connector *connector)
seq_num_v =
drm_hdcp_be24_to_cpu((const u8 *)msgs.recvid_list.seq_num_v);
+ if (!hdcp->hdcp2_encrypted && seq_num_v) {
+ drm_dbg_kms(&dev_priv->drm,
+ "Non zero Seq_num_v at first RecvId_List msg\n");
+ return -EINVAL;
+ }
+
if (seq_num_v < hdcp->seq_num_v) {
/* Roll over of the seq_num_v from repeater. Reauthenticate. */
DRM_DEBUG_KMS("Seq_num_v roll over.\n");
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/2] HDCP 2.2 Comp fixes
Adding ram's RB on patch1 and a new patch to fix DP HDCP Auth. Anshuman Gupta (2): drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg drm/i915/hdcp: Return 0 on config_stream_type() +ve return drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Protect signaler walk with RCU
On 20/02/2020 07:50, Chris Wilson wrote:
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the list_del_rcu.
v2: Mark the deps as safe-for-rcu
Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new
waiters")
Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
requests")
Signed-off-by: Chris Wilson
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 7 ---
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ba31cbe8c68e..47561dc29304 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1668,9 +1668,9 @@ last_active(const struct intel_engine_execlists
*execlists)
wait_link)
#define for_each_signaler(p__, rq__) \
- list_for_each_entry_lockless(p__, \
-&(rq__)->sched.signalers_list, \
-signal_link)
+ list_for_each_entry_rcu(p__, \
+ &(rq__)->sched.signalers_list, \
+ signal_link)
static void defer_request(struct i915_request *rq, struct list_head * const pl)
{
@@ -2533,11 +2533,13 @@ static bool execlists_hold(struct intel_engine_cs
*engine,
static bool hold_request(const struct i915_request *rq)
{
struct i915_dependency *p;
+ bool result = false;
/*
* If one of our ancestors is on hold, we must also be on hold,
* otherwise we will bypass it and execute before it.
*/
+ rcu_read_lock();
for_each_signaler(p, rq) {
const struct i915_request *s =
container_of(p->signaler, typeof(*s), sched);
@@ -2545,11 +2547,13 @@ static bool hold_request(const struct i915_request *rq)
if (s->engine != rq->engine)
continue;
- if (i915_request_on_hold(s))
- return true;
+ result = i915_request_on_hold(s);
+ if (result)
+ break;
}
+ rcu_read_unlock();
- return false;
+ return result;
}
static void __execlists_unhold(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index e19a37a83397..59f70b674665 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -486,7 +486,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
list_for_each_entry_safe(dep, tmp, &node->signalers_list, signal_link) {
GEM_BUG_ON(!list_empty(&dep->dfs_link));
- list_del(&dep->wait_link);
+ list_del_rcu(&dep->wait_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
GEM_BUG_ON(dep->signaler != node);
GEM_BUG_ON(!list_empty(&dep->dfs_link));
- list_del(&dep->signal_link);
+ list_del_rcu(&dep->signal_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -526,7 +526,8 @@ static struct i915_global_scheduler global = { {
int __init i915_global_scheduler_init(void)
{
global.slab_dependencies = KMEM_CACHE(i915_dependency,
- SLAB_HWCACHE_ALIGN);
+ SLAB_HWCACHE_ALIGN |
+ SLAB_TYPESAFE_BY_RCU);
So, the claim is that we should be fine if the node is re-used and then
initialised, even though there might exist a minuscule window where
hold_request might still be able to see it, somehow?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/12] drm: Shrink {width,height}_mm to u16
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Instead of supporting ~2000km wide displayes let's limit ourselves
> to ~65m. That seems plenty big enough to me.
>
> Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
> 10*0xfff which fits into the 16 bits.
>
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_modes.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 52e8ca613e4b..2bb2b1a8592a 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -330,7 +330,7 @@ struct drm_display_mode {
> * Addressable size of the output in mm, projectors should set this to
> * 0.
> */
> - int width_mm;
> + u16 width_mm;
>
> /**
> * @height_mm:
> @@ -338,7 +338,7 @@ struct drm_display_mode {
> * Addressable size of the output in mm, projectors should set this to
> * 0.
> */
> - int height_mm;
> + u16 height_mm;
>
Fwiw we could do the same for struct drm_display_info, although we
should be carefull since that info sets passed to userspace.
Regardless, this patch is:
Reviewed-by: Emil Velikov
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 01/14] drm/i915: Fix sha_text population code
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104.
v5.5.4: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging
macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
v5.4.20: Failed to apply! Possible dependencies:
65833c463886 ("drm/i915/hdcp: conversion to struct drm_device based logging
macros.")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
692059318c0f ("drm/i915/hdcp: Enable HDCP 1.4 and 2.2 on Gen12+")
v4.19.104: Failed to apply! Possible dependencies:
04707f971636 ("drm/i915: Initialize HDCP2.2")
09d56393c1d8 ("drm/i915: hdcp1.4 CP_IRQ handling and SW encryption
tracking")
2f80d7bd8d93 ("drm/i915: drop all drmP.h includes")
33b7f3ee6e00 ("drm/i915: Add CRTC output format YCBCR 4:2:0")
340a44bef234 ("drm/i915/icl: program MG_DP_MODE")
342ac601df64 ("drm/i915: hdcp_check_link only on CP_IRQ")
47658556da85 ("drm/i915/dp: Do not grab crtc modeset lock in
intel_dp_detect()")
667944ad77f1 ("drm/i915/hdcp: use intel_de_*() functions for register
access")
668b6c176c33 ("drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON")
7b610f1fbed2 ("drm/i915/dp: Add DSC params and DSC config to
intel_crtc_state")
9055aac76589 ("drm/i915: MEI interface implementation")
9844bc87cb7a ("drm/i915/dp: Fix duplication of DEVICE_SERVICE_IRQ handling")
bdc93fe0eb82 ("drm/i915/debugfs: hdcp capability of a sink")
cbfa8ac835cb ("drm/i915/dp: Kill intel_dp->detect_done flag")
d3dacc70797b ("drm/i915: wrapping all hdcp var into intel_hdcp")
d5acd97f5571 ("drm/i915/dp: Use a local variable for intel_encoder *")
d78aa650670d ("drm: Add drm/drm_util.h header file")
de25eb7f3075 ("drm/i915: introduce dp_to_i915() helper")
f106d1005ac7 ("drm/i915: Pullout the bksv read and validation")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Protect signaler walk with RCU
Quoting Matthew Auld (2020-02-20 12:47:28)
> On 20/02/2020 07:50, Chris Wilson wrote:
> > While we know that the waiters cannot disappear as we walk our list
> > (only that they might be added), the same cannot be said for our
> > signalers as they may be completed by the HW and retired as we process
> > this request. Ergo we need to use rcu to protect the list iteration and
> > remember to mark up the list_del_rcu.
> >
> > v2: Mark the deps as safe-for-rcu
> >
> > Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new
> > waiters")
> > Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
> > requests")
> > Signed-off-by: Chris Wilson
> > Cc: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Mika Kuoppala
> > Cc: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
> > drivers/gpu/drm/i915/i915_scheduler.c | 7 ---
> > 2 files changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index ba31cbe8c68e..47561dc29304 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1668,9 +1668,9 @@ last_active(const struct intel_engine_execlists
> > *execlists)
> >wait_link)
> >
> > #define for_each_signaler(p__, rq__) \
> > - list_for_each_entry_lockless(p__, \
> > - &(rq__)->sched.signalers_list, \
> > - signal_link)
> > + list_for_each_entry_rcu(p__, \
> > + &(rq__)->sched.signalers_list, \
> > + signal_link)
> >
> > static void defer_request(struct i915_request *rq, struct list_head *
> > const pl)
> > {
> > @@ -2533,11 +2533,13 @@ static bool execlists_hold(struct intel_engine_cs
> > *engine,
> > static bool hold_request(const struct i915_request *rq)
> > {
> > struct i915_dependency *p;
> > + bool result = false;
> >
> > /*
> >* If one of our ancestors is on hold, we must also be on hold,
> >* otherwise we will bypass it and execute before it.
> >*/
> > + rcu_read_lock();
> > for_each_signaler(p, rq) {
> > const struct i915_request *s =
> > container_of(p->signaler, typeof(*s), sched);
> > @@ -2545,11 +2547,13 @@ static bool hold_request(const struct i915_request
> > *rq)
> > if (s->engine != rq->engine)
> > continue;
> >
> > - if (i915_request_on_hold(s))
> > - return true;
> > + result = i915_request_on_hold(s);
> > + if (result)
> > + break;
> > }
> > + rcu_read_unlock();
> >
> > - return false;
> > + return result;
> > }
> >
> > static void __execlists_unhold(struct i915_request *rq)
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index e19a37a83397..59f70b674665 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -486,7 +486,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
> > list_for_each_entry_safe(dep, tmp, &node->signalers_list,
> > signal_link) {
> > GEM_BUG_ON(!list_empty(&dep->dfs_link));
> >
> > - list_del(&dep->wait_link);
> > + list_del_rcu(&dep->wait_link);
> > if (dep->flags & I915_DEPENDENCY_ALLOC)
> > i915_dependency_free(dep);
> > }
> > @@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
> > GEM_BUG_ON(dep->signaler != node);
> > GEM_BUG_ON(!list_empty(&dep->dfs_link));
> >
> > - list_del(&dep->signal_link);
> > + list_del_rcu(&dep->signal_link);
> > if (dep->flags & I915_DEPENDENCY_ALLOC)
> > i915_dependency_free(dep);
> > }
> > @@ -526,7 +526,8 @@ static struct i915_global_scheduler global = { {
> > int __init i915_global_scheduler_init(void)
> > {
> > global.slab_dependencies = KMEM_CACHE(i915_dependency,
> > - SLAB_HWCACHE_ALIGN);
> > + SLAB_HWCACHE_ALIGN |
> > + SLAB_TYPESAFE_BY_RCU);
>
> So, the claim is that we should be fine if the node is re-used and then
> initialised, even though there might exist a minuscule window where
> hold_request might still be able to see it, somehow?
Yes. That is my claim. The saving grace here is that for the on-hold
transitions we must go through the engine->active.lock which we are
holding. Ergo hold_request() is safe.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop
Re: [Intel-gfx] [PATCH 12/12] drm: pahole struct drm_display_mode
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala wrote: > > From: Ville Syrjälä > > Reorganize drm_display_mode to eliminate all the holes. > We'll put all the actual timings to the start of the > struct and all the extra junk to the end. > > Gets the size down to 136 bytes on 64bit and 120 bytes on > 32bit. With a bit more work we should be able to get this > below the two cacheline mark even on 64bit. > > Signed-off-by: Ville Syrjälä Patches 07-12 are: Reviewed-by: Emil Velikov -Emil ___ 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: Double check bumping after the spinlock
On 20/02/2020 12:36, Chris Wilson wrote:
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 01/10] capabilities: introduce CAP_PERFMON to kernel and user space
On 07.02.2020 16:39, Alexey Budankov wrote: > > On 07.02.2020 14:38, Thomas Gleixner wrote: >> Alexey Budankov writes: >>> On 22.01.2020 17:25, Alexey Budankov wrote: On 22.01.2020 17:07, Stephen Smalley wrote: >> It keeps the implementation simple and readable. The implementation is >> more >> performant in the sense of calling the API - one capable() call for >> CAP_PERFMON >> privileged process. >> >> Yes, it bloats audit log for CAP_SYS_ADMIN privileged and unprivileged >> processes, >> but this bloating also advertises and leverages using more secure >> CAP_PERFMON >> based approach to use perf_event_open system call. > > I can live with that. We just need to document that when you see > both a CAP_PERFMON and a CAP_SYS_ADMIN audit message for a process, > try only allowing CAP_PERFMON first and see if that resolves the > issue. We have a similar issue with CAP_DAC_READ_SEARCH versus > CAP_DAC_OVERRIDE. perf security [1] document can be updated, at least, to align and document this audit logging specifics. >>> >>> And I plan to update the document right after this patch set is accepted. >>> Feel free to let me know of the places in the kernel docs that also >>> require update w.r.t CAP_PERFMON extension. >> >> The documentation update wants be part of the patch set and not planned >> to be done _after_ the patch set is merged. > > Well, accepted. It is going to make patches #11 and beyond. Patches #11 and #12 of v7 [1] contain information on CAP_PERFMON intention and usage. Patch for man-pages [2] extends perf_event_open.2 documentation. Thanks, Alexey --- [1] https://lore.kernel.org/lkml/c8de937a-0b3a-7147-f5ef-69f467e87...@linux.intel.com/ [2] https://lore.kernel.org/lkml/18d1083d-efe5-f5f8-c531-d142c0e5c...@linux.intel.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v17 3/7] drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > We might be willing to call intel_atomic_get_old_global_obj_state
> > and intel_atomic_get_new_global_obj_state right away, however
> > those are not initializing global obj state as
> > intel_atomic_get_global_obj_state does.
> > Extracted initializing part to separate function and now using this
> > also in intel_atomic_get_old_global_obj_state and
> > intel_atomic_get_new_global_obj_state
> >
> > v2: - Fixed typo in function call
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 28
> > -
> > drivers/gpu/drm/i915/display/intel_bw.h | 9
> > 2 files changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 58b264bc318d..ff57277e8880 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -374,7 +374,33 @@ static unsigned int intel_bw_data_rate(struct
> > drm_i915_private *dev_priv,
> > return data_rate;
> > }
> >
> > -static struct intel_bw_state *
> > +struct intel_bw_state *
> > +intel_atomic_get_old_bw_state(struct intel_atomic_state *state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + struct intel_global_state *bw_state;
> > +
> > + bw_state = intel_atomic_get_old_global_obj_state(state,
> > &dev_priv->bw_obj);
> > + if (IS_ERR(bw_state))
> > + return ERR_CAST(bw_state);
> > +
> > + return to_intel_bw_state(bw_state);
> > +}
> > +
> > +struct intel_bw_state *
> > +intel_atomic_get_new_bw_state(struct intel_atomic_state *state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + struct intel_global_state *bw_state;
> > + bw_state = intel_atomic_get_new_global_obj_state(state,
> > &dev_priv->bw_obj);
> > +
> > + if (IS_ERR(bw_state))
> > + return ERR_CAST(bw_state);
> > +
> > + return to_intel_bw_state(bw_state);
> > +}
> > +
> > +struct intel_bw_state *
> > intel_atomic_get_bw_state(struct intel_atomic_state *state)
> > {
> > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > b/drivers/gpu/drm/i915/display/intel_bw.h
> > index a8aa7624c5aa..ac004d6f4276 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > @@ -24,6 +24,15 @@ struct intel_bw_state {
> >
> > #define to_intel_bw_state(x) container_of((x), struct
> > intel_bw_state, base)
> >
> > +struct intel_bw_state *
> > +intel_atomic_get_old_bw_state(struct intel_atomic_state *state);
> > +
> > +struct intel_bw_state *
> > +intel_atomic_get_new_bw_state(struct intel_atomic_state *state);
> > +
> > +struct intel_bw_state *
> > +intel_atomic_get_bw_state(struct intel_atomic_state *state);
> > +
>
> I'm trying to promote a convention that a module foo_bar.[ch] would
> export functions prefixed foo_bar_. Here, intel_bw_* like below.
I'm fine with that. However most of the functions in this file have
intel_atomic_* prefix, so if I now follow this convention it won't be
consistent with current naming in the file.
Anyway if this is now mandatory, will change it. Just will wait now
first if CI doesn't blow up with this series, as I haven't rebased it
for a while..
Stan
>
> BR,
> Jani.
>
>
> > void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> > int intel_bw_init(struct drm_i915_private *dev_priv);
> > int intel_bw_atomic_check(struct intel_atomic_state *state);
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Protect signaler walk with RCU
On 20/02/2020 12:52, Chris Wilson wrote:
Quoting Matthew Auld (2020-02-20 12:47:28)
On 20/02/2020 07:50, Chris Wilson wrote:
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the list_del_rcu.
v2: Mark the deps as safe-for-rcu
Fixes: 793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new
waiters")
Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
requests")
Signed-off-by: Chris Wilson
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 7 ---
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ba31cbe8c68e..47561dc29304 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1668,9 +1668,9 @@ last_active(const struct intel_engine_execlists
*execlists)
wait_link)
#define for_each_signaler(p__, rq__) \
- list_for_each_entry_lockless(p__, \
- &(rq__)->sched.signalers_list, \
- signal_link)
+ list_for_each_entry_rcu(p__, \
+ &(rq__)->sched.signalers_list, \
+ signal_link)
static void defer_request(struct i915_request *rq, struct list_head * const pl)
{
@@ -2533,11 +2533,13 @@ static bool execlists_hold(struct intel_engine_cs
*engine,
static bool hold_request(const struct i915_request *rq)
{
struct i915_dependency *p;
+ bool result = false;
/*
* If one of our ancestors is on hold, we must also be on hold,
* otherwise we will bypass it and execute before it.
*/
+ rcu_read_lock();
for_each_signaler(p, rq) {
const struct i915_request *s =
container_of(p->signaler, typeof(*s), sched);
@@ -2545,11 +2547,13 @@ static bool hold_request(const struct i915_request *rq)
if (s->engine != rq->engine)
continue;
- if (i915_request_on_hold(s))
- return true;
+ result = i915_request_on_hold(s);
+ if (result)
+ break;
}
+ rcu_read_unlock();
- return false;
+ return result;
}
static void __execlists_unhold(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index e19a37a83397..59f70b674665 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -486,7 +486,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
list_for_each_entry_safe(dep, tmp, &node->signalers_list, signal_link) {
GEM_BUG_ON(!list_empty(&dep->dfs_link));
- list_del(&dep->wait_link);
+ list_del_rcu(&dep->wait_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -497,7 +497,7 @@ void i915_sched_node_fini(struct i915_sched_node *node)
GEM_BUG_ON(dep->signaler != node);
GEM_BUG_ON(!list_empty(&dep->dfs_link));
- list_del(&dep->signal_link);
+ list_del_rcu(&dep->signal_link);
if (dep->flags & I915_DEPENDENCY_ALLOC)
i915_dependency_free(dep);
}
@@ -526,7 +526,8 @@ static struct i915_global_scheduler global = { {
int __init i915_global_scheduler_init(void)
{
global.slab_dependencies = KMEM_CACHE(i915_dependency,
- SLAB_HWCACHE_ALIGN);
+ SLAB_HWCACHE_ALIGN |
+ SLAB_TYPESAFE_BY_RCU);
So, the claim is that we should be fine if the node is re-used and then
initialised, even though there might exist a minuscule window where
hold_request might still be able to see it, somehow?
Yes. That is my claim. The saving grace here is that for the on-hold
transitions we must go through the engine->active.lock which we are
holding. Ergo hold_request() is safe.
Reviewed-by: Matthew Auld
-Chris
___
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 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. From drm_mode_set_name(): snprintf(mode->name, DRM_DISPLAY_MODE_LEN, "%dx%d%s", mode->hdisplay, mode->vdisplay, interlaced ? "i" : ""); We change the h/v display from (10^15)-1 to (10^11)-1 which seems reasonable. Note: haven't checked if name includes the terminating \0, so take numbers with a grain of salt. -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v17 3/7] drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
On Thu, 2020-02-20 at 15:11 +0200, stanislav.lisovs...@intel.com wrote:
> On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> > On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> > stanislav.lisovs...@intel.com> wrote:
> > > We might be willing to call intel_atomic_get_old_global_obj_state
> > > and intel_atomic_get_new_global_obj_state right away, however
> > > those are not initializing global obj state as
> > > intel_atomic_get_global_obj_state does.
> > > Extracted initializing part to separate function and now using
> > > this
> > > also in intel_atomic_get_old_global_obj_state and
> > > intel_atomic_get_new_global_obj_state
> > >
> > > v2: - Fixed typo in function call
> > >
> > > Signed-off-by: Stanislav Lisovskiy > > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.c | 28
> > > -
> > > drivers/gpu/drm/i915/display/intel_bw.h | 9
> > > 2 files changed, 36 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > > b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index 58b264bc318d..ff57277e8880 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -374,7 +374,33 @@ static unsigned int
> > > intel_bw_data_rate(struct
> > > drm_i915_private *dev_priv,
> > > return data_rate;
> > > }
> > >
> > > -static struct intel_bw_state *
> > > +struct intel_bw_state *
> > > +intel_atomic_get_old_bw_state(struct intel_atomic_state *state)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + struct intel_global_state *bw_state;
> > > +
> > > + bw_state = intel_atomic_get_old_global_obj_state(state,
> > > &dev_priv->bw_obj);
> > > + if (IS_ERR(bw_state))
> > > + return ERR_CAST(bw_state);
> > > +
> > > + return to_intel_bw_state(bw_state);
> > > +}
> > > +
> > > +struct intel_bw_state *
> > > +intel_atomic_get_new_bw_state(struct intel_atomic_state *state)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + struct intel_global_state *bw_state;
> > > + bw_state = intel_atomic_get_new_global_obj_state(state,
> > > &dev_priv->bw_obj);
> > > +
> > > + if (IS_ERR(bw_state))
> > > + return ERR_CAST(bw_state);
> > > +
> > > + return to_intel_bw_state(bw_state);
> > > +}
> > > +
> > > +struct intel_bw_state *
> > > intel_atomic_get_bw_state(struct intel_atomic_state *state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index a8aa7624c5aa..ac004d6f4276 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -24,6 +24,15 @@ struct intel_bw_state {
> > >
> > > #define to_intel_bw_state(x) container_of((x), struct
> > > intel_bw_state, base)
> > >
> > > +struct intel_bw_state *
> > > +intel_atomic_get_old_bw_state(struct intel_atomic_state *state);
> > > +
> > > +struct intel_bw_state *
> > > +intel_atomic_get_new_bw_state(struct intel_atomic_state *state);
> > > +
> > > +struct intel_bw_state *
> > > +intel_atomic_get_bw_state(struct intel_atomic_state *state);
> > > +
> >
> > I'm trying to promote a convention that a module foo_bar.[ch] would
> > export functions prefixed foo_bar_. Here, intel_bw_* like below.
>
> I'm fine with that. However most of the functions in this file have
> intel_atomic_* prefix, so if I now follow this convention it won't be
> consistent with current naming in the file.
Actually, I was wrong. Was looking into intel_global_state.c instead of
intel_bw.c. Yes, that totally makes sense.
Stan
>
> Anyway if this is now mandatory, will change it. Just will wait now
> first if CI doesn't blow up with this series, as I haven't rebased it
> for a while..
>
> Stan
>
> >
> > BR,
> > Jani.
> >
> >
> > > void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> > > int intel_bw_init(struct drm_i915_private *dev_priv);
> > > int intel_bw_atomic_check(struct intel_atomic_state *state);
> >
> >
___
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: make i915_debugfs_register return void.
== Series Details ==
Series: drm/i915: make i915_debugfs_register return void.
URL : https://patchwork.freedesktop.org/series/73587/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16604_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_16604_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_whisper@basic-fds-all}:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb7/igt@gem_exec_whis...@basic-fds-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-tglb1/igt@gem_exec_whis...@basic-fds-all.html
Known issues
Here are the changes found in Patchwork_16604_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +14 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_b...@busy-vcs1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-iclb8/igt@gem_b...@busy-vcs1.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
* igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@gem_exec_sched...@pi-shared-iova-bsd.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html
* igt@gem_exec_schedule@wide-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_sched...@wide-bsd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#644])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@gem_pp...@flink-and-close-vma-leak.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-kbl4/igt@gem_pp...@flink-and-close-vma-leak.html
* igt@gem_workarounds@suspend-resume-context:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#69])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl4/igt@gem_workarou...@suspend-resume-context.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-skl7/igt@gem_workarou...@suspend-resume-context.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#454])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@i915_pm...@dc6-psr.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-iclb6/igt@i915_pm...@dc6-psr.html
* igt@i915_selftest@live_gt_lrc:
- shard-tglb: [PASS][17] -> [INCOMPLETE][18] ([i915#1233])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@live_gt_lrc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-tglb2/igt@i915_selftest@live_gt_lrc.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_cursor_legacy@2x-flip-vs-cursor-legacy:
- shard-glk: [PASS][23] -> [FAIL][24] ([i915#72])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk1/igt@kms_cursor_leg...@2x-flip-vs-cursor-legacy.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16604/shard-glk1/igt@kms_cursor_leg...@2x-flip-vs-cursor-legacy.html
* igt@kms_flip
Re: [Intel-gfx] [PATCH] drm/i915: Distribute switch variables for initialization
On Wed, Feb 19, 2020 at 10:22:58PM -0800, 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].
Silly compilers.
> 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
> ---
> 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;
This one I'd just remove and s/port_mask/BIT(encoder->port)/
everywhere. Otherwise lgtm.
> +
> 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 = &crtc_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 =
> &crtc_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(&uncore->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);
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915: Add i9xx_lut_8()
On Thu, Feb 20, 2020 at 11:20:05AM +, Emil Velikov wrote: > On Thu, 7 Nov 2019 at 15:17, Ville Syrjala > wrote: > > > > From: Ville Syrjälä > > > > We have a nice little helper to compute a single LUT entry > > for everything except the 8bpc legacy gamma mode. Let's > > complete the set. > > > At a later stage one could rename this & the 10bit one, moving them to > include/drm/. > There are other drivers doing the same thing... not sure if that's > worth it though. I'd say no. These are specifically about formatting the LUT entry for the hw register. I don't really see much benefit from sharing code to compute hw register values across totally different hardware, even if the bits happen to match by accident. The only good exception I can think of are cases where said register value comes more or less straight from some cross vendor spec. -- 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 39/52] drm/stm: Drop explicit drm_mode_config_cleanup call
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. Philippe :-) ___ 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, 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 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Force PSR probe only after full initialization (rev5)
== Series Details == Series: drm/i915/psr: Force PSR probe only after full initialization (rev5) URL : https://patchwork.freedesktop.org/series/73436/ State : success == Summary == CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16607_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_7963_full and Patchwork_16607_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.24] 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, 4.54] 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.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 : 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.02] s * igt@i915_pm_rpm@basic-rte: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [1.30, 11.45] s * igt@i915_pm_rpm@cursor: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 41.78] s * igt@i915_pm_rpm@cursor-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 41.22] s * igt@i915_pm_rpm@debugfs-forcewake-user: - Statuses : 7 pass(s) - Exec time: [10.44, 14.38] 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.82] s * igt@i915_pm_rpm@dpms-mode-unset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 13.27] s * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 4.14] 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) - Exec time: [0.79, 9.69] s * igt@i915_pm_rpm@fences: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 16.91] s * igt@i915_pm_rpm@fences-dpms: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 12.80] 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.56] s * igt@i915_pm_rpm@gem-execbuf-stress: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 42.66] 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.26] s * igt@i915_pm_rpm@gem-pread: - Statuses : 7 pass(s) 1 skip(s) - Exec time: [0.0, 6.15] s * igt@i915_pm_rpm@i2c: - Statuses : 7 pass(s) - Exec time: [0.94, 11.24] 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.54] s * igt@i915_pm_rpm@modeset-lpsp: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 4.76] s * igt@i915_pm_rpm@modeset-lpsp-stress: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 53.13] s * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - Statuses : 3 pass(s) 5 skip(s) - Exec time: [0.0, 16.77] s * igt@i915_pm_rpm@modeset-non-lpsp: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 4.00] s * igt@i915_pm_rpm@modeset-non-lpsp-stress: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 9.55] s * igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait: - Statuses : 4 pass(s) 4 skip(s) - Exec time: [0.0, 6.65] 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, 72.05] 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: [0
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&egg 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 yo
[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 :
[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(&plane_state->uapi.src) >> 16;
+ src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
+ dst_w = drm_rect_width(&plane_state->uapi.dst);
+ dst_h = drm_rect_height(&plane_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_pri
[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 basic
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
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 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(&plane_state->uapi.src) >> 16;
> + src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> + dst_w = drm_rect_width(&plane_state->uapi.dst);
> + dst_h = drm_rect_height(&plane_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;
> +
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(&plane_state->uapi.src) >> 16;
> > + src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> > + dst_w = drm_rect_width(&plane_state->uapi.dst);
> > + dst_h = drm_rect_height(&plane_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 preve
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, &p) == 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, &p);
> > > + 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] [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] [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] [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
[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(&plane_state->uapi.src) >> 16;
+ src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
+ dst_w = drm_rect_width(&plane_state->uapi.dst);
+ dst_h = drm_rect_height(&plane_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] [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] ✓ 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: [0.0
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
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 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 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 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
[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,
&dev_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:
+
&new_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
[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.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 compu
[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] [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] [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
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 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
[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(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->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, &n_entries);
default_entry = 6;
} else {
- WARN(1, "ddi translation table missing\n");
+ drm_WARN(&dev_priv->drm, 1, "ddi translation table missing\n");
return 0;
}
- if (WARN_ON_ONCE(n_entries == 0))
+ if (drm_WARN_ON_ONCE(&dev_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(&dev_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, &n_entries);
- if (WARN_ON_ONCE(!ddi_translations))
+ if (drm_WARN_ON_ONCE(&dev_priv->drm, !ddi_translations))
return;
- if (WARN_ON_ONCE(level >= n_entries))
+ if (drm_WARN_ON_ONCE(&dev_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(&dev_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(&dev_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(&dev_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,
e
[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(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_priv->drm,
+ cdclk != dev_priv->cdclk.hw.bypass);
+
[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(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->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(&dev_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(&dev_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(&dev_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(&dev_priv->drm,
+ port_sel != PANEL_PORT_SELECT_LVDS);
intel_lvds_port_enabled(dev_priv, LVDS, &panel_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(&dev_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-
[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(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_priv->power_domains));
- WARN_ON(refs > power_well->count);
+ drm_WARN_ON(&dev_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(&dev_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(&dev_priv->drm, !dig_port))
return;
- WARN_ON(!intel_tc_port_ref_held(dig_port));
+ drm_WARN_ON(&dev_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_d
[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(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_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(&dev_priv->pps_mutex);
/* We should never land here with regular DP ports */
- WARN_ON(!intel_dp_is_edp(intel_dp));
+ drm_WARN_ON(&dev_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(&dev_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
[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(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->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(&dev_priv->runtime_pm);
- if (WARN_ON(fence >= vgpu_fence_sz(vgpu)))
+ if (drm_WARN_ON(&dev_priv->drm, fence >= vgpu_fence_sz(vgpu)))
return;
reg = vgpu->fence.regs[fence];
- if (WARN_ON(!reg))
+ if (drm_WARN_ON(&dev_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(&dev_priv->drm, !vgpu_fence_sz(vgpu)))
return;
intel_runtime_pm_get(&dev_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(&dev_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(&dev_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(&dev_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(&dev_priv->drm, !fb_info))
return -ENODEV;
vgpu = fb_info->obj->vgpu;
- if (WARN_ON(!vgpu))
+ if (drm_WARN_ON(&dev_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_
[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(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->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(&dev_priv->drm,
+ !intel_hdcp_in_use(dev_priv, cpu_transcoder, port))) {
drm_err(&dev_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(&dev_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(&dev_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(&dev_priv->drm,
+ !intel_hdcp2_in_use(dev_priv, cpu_transcoder, port))) {
drm_err(&dev_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(&dev_priv->hdcp_comp_mutex);
- WARN_ON(dev_priv->hdcp_comp_added);
+ drm_WARN_ON(&dev_priv->drm, dev_priv->hdcp_comp_added);
dev_priv->hdcp_comp_added = true;
mutex_unlock(&dev_priv->hdcp_comp_mutex);
@@ -1990,7 +1993,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
return -ENOENT;
mutex_lock(&hdcp->mutex);
- WARN_ON(hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
+ drm_WARN_ON(&dev_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 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(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->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(&i915->drm, bytes > 4))
return -EINVAL;
- if (WARN_ON(offset + bytes > vgpu->gvt->device_info.cfg_space_size))
+ if (drm_WARN_ON(&i915->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(&i915->drm, bytes > 4))
return -EINVAL;
- if (WARN_ON(offset + bytes > vgpu->gvt->device_info.cfg_space_size))
+ if (drm_WARN_ON(&i915->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(&i915->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(&i915->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(&i915->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(&i915->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(&i915->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
[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, old_si
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;
>
> igt_debug("Mappin
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(&crtc->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(&crtc->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(&crtc->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(&crtc->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(&crtc->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(&dev_priv->drm, pipe);
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> +
> + drm_crtc_wait_one_vblank(&crtc->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(&crtc->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(&dev_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_eac
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
[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 @ git:/
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(&dev_priv->drm, plane) {
> + struct intel_crtc *crtc;
> +
> + crtc = intel_get_crtc_for_pipe(dev_priv, plane->pipe);
> + plane->base.possible_crtcs = drm_crtc_mask(&crtc->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(&dev_priv->drm, &plane->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 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(&new_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(&new_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(&new_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
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(&dev_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 as
[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);
[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
