Re: [Intel-gfx] [PATCH 00/59] Add support for Keem Bay DRM driver
Hi Anitha. On Tue, Jun 30, 2020 at 02:27:12PM -0700, Anitha Chrisanthus wrote: > This is a new DRM driver for Intel's KeemBay SOC. > The SoC couples an ARM Cortex A53 CPU with an Intel > Movidius VPU. ... Nice and informative intro - thanks. The patchset looks more like a dump of current state and less like a logical set of changes - as the few I looked at changed code introduced in earlier patches. So I ended up applying all patches to a local branch. Very good to post an WIP version so you can capture some early feedback. It is never fun to think something is finished and then address a lot of feedback. Some general remarks after reading/browsing some of the code: - Embeds drm_device - good - Uses SPDX, good. But includes also a license text. Can we get rid of the redundandt license text? - Some of the inline functions in kmb_drv.h is too large (kmb_write_bits_mipi()) - There is stray code commented out using "//" here and there - shall be dropped. - Please arrange include files in blocks: #include #include #include #include "kmb_*" Within each block sort alphabetially. - Use a kmb_ prefix or similar for global variables - like under_flow - no extern in .c files - plane_status - Consider using an array for the clk's - In general use drm_info(), drm_err() for logging. Yes, you will need to pass kmb_drm_private around to do so - Do not use drm_device->dev_private, it is deprecated. Use upclassing - kmb_driver can be slimmed a lot. See what recent drivers uses. There is some nice defines so it is obvious what is not standard. DRIVER_HAVE_IRQ is not relevant btw. - Start using drmm_* support. The way kmb_drm_private is allocated is sub-optimal The above was my fist drive-by comments - but do not be discouraged. For the most part they should be easy to address. Looking forward for other feedback and for v2. Let me know if the above triggers any questions. > +--++-++---+ > |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | > +--++-++---+ Question to dri-devel people: Would the Mipi DSI be better represented outside the display driver? If yes, how? Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Correctly advertise HBR3 for GEN11+ (rev2)
== Series Details == Series: drm/i915/dp: Correctly advertise HBR3 for GEN11+ (rev2) URL : https://patchwork.freedesktop.org/series/61546/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8679_full -> Patchwork_18050_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18050_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18050_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_18050_full: ### IGT changes ### Possible regressions * igt@perf_pmu@most-busy-idle-check-all@vcs0: - shard-hsw: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-hsw1/igt@perf_pmu@most-busy-idle-check-...@vcs0.html Known issues Here are the changes found in Patchwork_18050_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-tglb: [PASS][2] -> [INCOMPLETE][3] ([i915#750]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-tglb6/igt@drm_import_exp...@prime.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-tglb5/igt@drm_import_exp...@prime.html * igt@gem_workarounds@suspend-resume: - shard-skl: [PASS][4] -> [INCOMPLETE][5] ([i915#69]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl6/igt@gem_workarou...@suspend-resume.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl1/igt@gem_workarou...@suspend-resume.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-kbl6/igt@i915_susp...@debugfs-reader.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-kbl6/igt@i915_susp...@debugfs-reader.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) +12 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl6/igt@kms_co...@pipe-c-ctm-0-25.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl2/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: - shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#93] / [i915#95]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-kbl4/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html * igt@kms_cursor_edge_walk@pipe-c-128x128-left-edge: - shard-kbl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-kbl7/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-kbl6/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#79]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#1635] / [i915#95]) +9 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-apl8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-apl8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#1188]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl7/igt@kms_...@bpc-switch-dpms.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl8/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][20] -> [FAIL][21] ([fdo#108145] / [i915#265]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_alpha_b
Re: [Intel-gfx] [PATCH v3] drm/i915/hdcp: Update CP as per the kernel internal state
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, June 30, 2020 3:30 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Cc: Shankar, Uma
> Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/hdcp: Update CP as per the kernel
> internal state
>
>
> Uma, is the R-b still valid? It's been a while.
Yeah Jani, the changes look good. Will need a rebase and fresh CI results
though.
Regards,
Uma Shankar
> BR,
> Jani.
>
>
> On Tue, 30 Jun 2020, Anshuman Gupta wrote:
> > Content Protection property should be updated as per the kernel
> > internal state. Let's say if Content protection is disabled by
> > userspace, CP property should be set to UNDESIRED so that
> > reauthentication will not happen until userspace request it again, but
> > when kernel disables the HDCP due to any DDI disabling sequences like
> > modeset/DPMS operation, kernel should set the property to DESIRED, so
> > that when opportunity arises, kernel will start the HDCP
> > authentication on its own.
> >
> > Somewhere in the line, state machine to set content protection to
> > DESIRED from kernel was broken and IGT coverage was missing for it.
> > This patch fixes it.
> >
> > v2:
> > - Fixing hdcp CP state in connector atomic check function
> > intel_hdcp_atomic_check(). [Maarten]
> > This will require to check hdcp->value in intel_hdcp_update_pipe()
> > in order to avoid enabling hdcp, if it was already enabled.
> >
> > v3:
> > - Rebased.
> >
> > Cc: Ramalingam C
> > Cc: Maarten Lankhorst
> > Reviewed-by: Uma Shankar
> > Signed-off-by: Anshuman Gupta
> > Link:
> > https://patchwork.freedesktop.org/patch/350962/?series=72664&rev=2 #v1
> > Link:
> > https://patchwork.freedesktop.org/patch/359396/?series=72251&rev=3 #v2
> > ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 27
> > +++
> > 1 file changed, 23 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 815b054bb167..0d410652e194 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2086,6 +2086,7 @@ void intel_hdcp_update_pipe(struct
> intel_atomic_state *state,
> > (conn_state->hdcp_content_type != hdcp->content_type &&
> > conn_state->content_protection !=
> > DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
> > + bool desired_and_not_enabled = false;
> >
> > /*
> > * During the HDCP encryption session if Type change is requested,
> > @@ -2108,8 +2109,15 @@ void intel_hdcp_update_pipe(struct
> intel_atomic_state *state,
> > }
> >
> > if (conn_state->content_protection ==
> > - DRM_MODE_CONTENT_PROTECTION_DESIRED ||
> > - content_protection_type_changed)
> > + DRM_MODE_CONTENT_PROTECTION_DESIRED) {
> > + mutex_lock(&hdcp->mutex);
> > + /* Avoid enabling hdcp, if it already ENABLED */
> > + desired_and_not_enabled =
> > + hdcp->value !=
> DRM_MODE_CONTENT_PROTECTION_ENABLED;
> > + mutex_unlock(&hdcp->mutex);
> > + }
> > +
> > + if (desired_and_not_enabled || content_protection_type_changed)
> > intel_hdcp_enable(connector,
> > crtc_state->cpu_transcoder,
> > (u8)conn_state->hdcp_content_type);
> > @@ -2158,6 +2166,19 @@ void intel_hdcp_atomic_check(struct
> drm_connector *connector,
> > return;
> > }
> >
> > + crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> > + new_state->crtc);
> > + /*
> > +* Fix the HDCP uapi content protection state in case of modeset.
> > +* FIXME: As per HDCP content protection property uapi doc, an uevent()
> > +* need to be sent if there is transition from ENABLED->DESIRED.
> > +*/
> > + if (drm_atomic_crtc_needs_modeset(crtc_state) &&
> > + (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > + new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> > + new_state->content_protection =
> > + DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > +
> > /*
> > * Nothing to do if the state didn't change, or HDCP was activated since
> > * the last commit. And also no change in hdcp content type.
> > @@ -2170,8 +2191,6 @@ void intel_hdcp_atomic_check(struct drm_connector
> *connector,
> > return;
> > }
> >
> > - crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> > - new_state->crtc);
> > crtc_state->mode_changed = true;
> > }
>
> --
> 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 v3] drm/i915/hdcp: Update CP as per the kernel internal state
> > -Original Message-
> > From: Jani Nikula
> > Sent: Tuesday, June 30, 2020 3:30 PM
> > To: Gupta, Anshuman ; intel-
> > g...@lists.freedesktop.org
> > Cc: Shankar, Uma
> > Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/hdcp: Update CP as per
> > the kernel internal state
> >
> >
> > Uma, is the R-b still valid? It's been a while.
>
> Yeah Jani, the changes look good. Will need a rebase and fresh CI results
> though.
Seems the CI results are already out and we are clean.
> Regards,
> Uma Shankar
>
> > BR,
> > Jani.
> >
> >
> > On Tue, 30 Jun 2020, Anshuman Gupta wrote:
> > > Content Protection property should be updated as per the kernel
> > > internal state. Let's say if Content protection is disabled by
> > > userspace, CP property should be set to UNDESIRED so that
> > > reauthentication will not happen until userspace request it again,
> > > but when kernel disables the HDCP due to any DDI disabling sequences
> > > like modeset/DPMS operation, kernel should set the property to
> > > DESIRED, so that when opportunity arises, kernel will start the HDCP
> > > authentication on its own.
> > >
> > > Somewhere in the line, state machine to set content protection to
> > > DESIRED from kernel was broken and IGT coverage was missing for it.
> > > This patch fixes it.
> > >
> > > v2:
> > > - Fixing hdcp CP state in connector atomic check function
> > > intel_hdcp_atomic_check(). [Maarten]
> > > This will require to check hdcp->value in intel_hdcp_update_pipe()
> > > in order to avoid enabling hdcp, if it was already enabled.
> > >
> > > v3:
> > > - Rebased.
> > >
> > > Cc: Ramalingam C
> > > Cc: Maarten Lankhorst
> > > Reviewed-by: Uma Shankar
> > > Signed-off-by: Anshuman Gupta
> > > Link:
> > > https://patchwork.freedesktop.org/patch/350962/?series=72664&rev=2
> > > #v1
> > > Link:
> > > https://patchwork.freedesktop.org/patch/359396/?series=72251&rev=3
> > > #v2
> > > ---
> > > drivers/gpu/drm/i915/display/intel_hdcp.c | 27
> > > +++
> > > 1 file changed, 23 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > index 815b054bb167..0d410652e194 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > @@ -2086,6 +2086,7 @@ void intel_hdcp_update_pipe(struct
> > intel_atomic_state *state,
> > > (conn_state->hdcp_content_type != hdcp->content_type &&
> > >conn_state->content_protection !=
> > >DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
> > > + bool desired_and_not_enabled = false;
> > >
> > > /*
> > >* During the HDCP encryption session if Type change is requested,
> > > @@ -2108,8 +2109,15 @@ void intel_hdcp_update_pipe(struct
> > intel_atomic_state *state,
> > > }
> > >
> > > if (conn_state->content_protection ==
> > > - DRM_MODE_CONTENT_PROTECTION_DESIRED ||
> > > - content_protection_type_changed)
> > > + DRM_MODE_CONTENT_PROTECTION_DESIRED) {
> > > + mutex_lock(&hdcp->mutex);
> > > + /* Avoid enabling hdcp, if it already ENABLED */
> > > + desired_and_not_enabled =
> > > + hdcp->value !=
> > DRM_MODE_CONTENT_PROTECTION_ENABLED;
> > > + mutex_unlock(&hdcp->mutex);
> > > + }
> > > +
> > > + if (desired_and_not_enabled || content_protection_type_changed)
> > > intel_hdcp_enable(connector,
> > > crtc_state->cpu_transcoder,
> > > (u8)conn_state->hdcp_content_type);
> > > @@ -2158,6 +2166,19 @@ void intel_hdcp_atomic_check(struct
> > drm_connector *connector,
> > > return;
> > > }
> > >
> > > + crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> > > +new_state->crtc);
> > > + /*
> > > + * Fix the HDCP uapi content protection state in case of modeset.
> > > + * FIXME: As per HDCP content protection property uapi doc, an uevent()
> > > + * need to be sent if there is transition from ENABLED->DESIRED.
> > > + */
> > > + if (drm_atomic_crtc_needs_modeset(crtc_state) &&
> > > + (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> > > + new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> > > + new_state->content_protection =
> > > + DRM_MODE_CONTENT_PROTECTION_DESIRED;
> > > +
> > > /*
> > >* Nothing to do if the state didn't change, or HDCP was activated since
> > >* the last commit. And also no change in hdcp content type.
> > > @@ -2170,8 +2191,6 @@ void intel_hdcp_atomic_check(struct
> > > drm_connector
> > *connector,
> > > return;
> > > }
> > >
> > > - crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> > > -new_state->crtc);
> > > crtc_state->mode_changed = true;
> > > }
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> __
[Intel-gfx] [PATCH 1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
If the driver get stuck holding the kernel timeline, we cannot issue a
heartbeat and so fail to discover that the driver is indeed stuck and do
not issue a GPU reset (which would hopefully unstick the driver!).
Switch to using a trylock so that we can query if the heartbeat's
timelin mutex is locked elsewhere, and then use the timer to probe if it
remains stuck at the same spot for consecutive heartbeats, indicating
that the mutex has not been released and the engine has not progressed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 --
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 8db7e93abde5..1663ab5c68a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -65,6 +65,7 @@ static void heartbeat(struct work_struct *wrk)
container_of(wrk, typeof(*engine), heartbeat.work.work);
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
+ unsigned long serial;
/* Just in case everything has gone horribly wrong, give it a kick */
intel_engine_flush_submission(engine);
@@ -122,10 +123,19 @@ static void heartbeat(struct work_struct *wrk)
goto out;
}
- if (engine->wakeref_serial == engine->serial)
+ serial = READ_ONCE(engine->serial);
+ if (engine->wakeref_serial == serial)
goto out;
- mutex_lock(&ce->timeline->mutex);
+ if (!mutex_trylock(&ce->timeline->mutex)) {
+ /* Unable to lock the kernel timeline, is the engine stuck? */
+ if (xchg(&engine->heartbeat.blocked, serial) == serial)
+ intel_gt_handle_error(engine->gt, engine->mask,
+ I915_ERROR_CAPTURE,
+ "stopped heartbeat on %s",
+ engine->name);
+ goto out;
+ }
intel_context_enter(ce);
rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 073c3769e8cc..490af81bd6f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -348,6 +348,7 @@ struct intel_engine_cs {
struct {
struct delayed_work work;
struct i915_request *systole;
+ unsigned long blocked;
} heartbeat;
unsigned long serial;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gt: Move the heartbeat into the highprio system wq
As we ensure that the heartbeat is reasonably fast (and should not block), move the heartbeat work into the system_highprio_wq to avoid having this essential task be blocked behind other slow work, such as our own retire_work_handler. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2119 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c index 1663ab5c68a5..3699fa8a79e8 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c @@ -32,7 +32,7 @@ static bool next_heartbeat(struct intel_engine_cs *engine) delay = msecs_to_jiffies_timeout(delay); if (delay >= HZ) delay = round_jiffies_up_relative(delay); - mod_delayed_work(system_wq, &engine->heartbeat.work, delay); + mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, delay); return true; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 33/33] drm/i915/gt: Enable ring scheduling for gen6/7
Switch over from FIFO global submission to the priority-sorted
topographical scheduler. At the cost of more busy work on the CPU to
keep the GPU supplied with the next packet of requests, this allows us
to reorder requests around submission stalls.
This also enables the timer based RPS, with the exception of Valleyview
who's PCU doesn't take kindly to our interference.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/gt/intel_rps.c | 6 ++
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index b81978890641..bb57687aea99 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -94,7 +94,7 @@ static int live_nop_switch(void *arg)
rq = i915_request_get(this);
i915_request_add(this);
}
- if (i915_request_wait(rq, 0, HZ / 5) < 0) {
+ if (i915_request_wait(rq, 0, HZ) < 0) {
pr_err("Failed to populated %d contexts\n", nctx);
intel_gt_set_wedged(&i915->gt);
i915_request_put(rq);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index a5e83c115b23..e60eeafbbaec 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -788,6 +788,8 @@ int intel_engines_init(struct intel_gt *gt)
if (HAS_EXECLISTS(gt->i915))
setup = intel_execlists_submission_setup;
+ else if (INTEL_GEN(gt->i915) >= 6)
+ setup = intel_ring_scheduler_setup;
else
setup = intel_ring_submission_setup;
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index ad4c31844885..17f995d4fda2 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1052,9 +1052,7 @@ static bool gen6_rps_enable(struct intel_rps *rps)
intel_uncore_write_fw(uncore, GEN6_RP_DOWN_TIMEOUT, 5);
intel_uncore_write_fw(uncore, GEN6_RP_IDLE_HYSTERSIS, 10);
- rps->pm_events = (GEN6_PM_RP_UP_THRESHOLD |
- GEN6_PM_RP_DOWN_THRESHOLD |
- GEN6_PM_RP_DOWN_TIMEOUT);
+ rps->pm_events = GEN6_PM_RP_UP_THRESHOLD | GEN6_PM_RP_DOWN_THRESHOLD;
return rps_reset(rps);
}
@@ -1361,7 +1359,7 @@ void intel_rps_enable(struct intel_rps *rps)
GEM_BUG_ON(rps->efficient_freq < rps->min_freq);
GEM_BUG_ON(rps->efficient_freq > rps->max_freq);
- if (has_busy_stats(rps))
+ if (has_busy_stats(rps) && !IS_VALLEYVIEW(i915))
intel_rps_set_timer(rps);
else if (INTEL_GEN(i915) >= 6)
intel_rps_set_interrupts(rps);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/33] drm/i915: Lift waiter/signaler iterators
Lift the list iteration defines for traversing the signaler/waiter lists
into i915_scheduler.h for reuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 10 --
drivers/gpu/drm/i915/i915_scheduler_types.h | 10 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index c0f3db52bd5a..eb25b80b4327 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1840,16 +1840,6 @@ static void virtual_xfer_breadcrumbs(struct
virtual_engine *ve)
intel_engine_transfer_stale_breadcrumbs(ve->siblings[0], &ve->context);
}
-#define for_each_waiter(p__, rq__) \
- list_for_each_entry_lockless(p__, \
-&(rq__)->sched.waiters_list, \
-wait_link)
-
-#define for_each_signaler(p__, rq__) \
- 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)
{
LIST_HEAD(list);
diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
b/drivers/gpu/drm/i915/i915_scheduler_types.h
index f72e6c397b08..343ed44d5ed4 100644
--- a/drivers/gpu/drm/i915/i915_scheduler_types.h
+++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
@@ -81,4 +81,14 @@ struct i915_dependency {
#define I915_DEPENDENCY_WEAK BIT(2)
};
+#define for_each_waiter(p__, rq__) \
+ list_for_each_entry_lockless(p__, \
+&(rq__)->sched.waiters_list, \
+wait_link)
+
+#define for_each_signaler(p__, rq__) \
+ list_for_each_entry_rcu(p__, \
+ &(rq__)->sched.signalers_list, \
+ signal_link)
+
#endif /* _I915_SCHEDULER_TYPES_H_ */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 24/33] drm/i915/gt: Specify a deadline for the heartbeat
As we know when we expect the heartbeat to be checked for completion,
pass this information along as its deadline. We still do not complain if
the deadline is missed, at least until we have tried a few times, but it
will allow for quicker hang detection on systems where deadlines are
adhered to.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index d66bfa21e0a0..3e363e75d1ff 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -54,6 +54,16 @@ static void heartbeat_commit(struct i915_request *rq,
local_bh_enable();
}
+static void set_heartbeat_deadline(struct intel_engine_cs *engine,
+ struct i915_request *rq)
+{
+ unsigned long interval;
+
+ interval = READ_ONCE(engine->props.heartbeat_interval_ms);
+ if (interval)
+ i915_request_set_deadline(rq, ktime_get() + (interval << 20));
+}
+
static void show_heartbeat(const struct i915_request *rq,
struct intel_engine_cs *engine)
{
@@ -119,6 +129,8 @@ static void heartbeat(struct work_struct *wrk)
local_bh_disable();
i915_request_set_priority(rq, attr.priority);
+ if (attr.priority == I915_PRIORITY_BARRIER)
+ i915_request_set_deadline(rq, 0);
local_bh_enable();
} else {
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -155,6 +167,7 @@ static void heartbeat(struct work_struct *wrk)
if (engine->i915->params.enable_hangcheck)
engine->heartbeat.systole = i915_request_get(rq);
+ set_heartbeat_deadline(engine, rq);
heartbeat_commit(rq, &attr);
unlock:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 26/33] drm/i915: Move saturated workload detection to the GT
When we introduced the saturated workload detection to tell us to back
off from semaphore usage [semaphores have a noticeable impact on
contended bus cycles with the CPU for some heavy workloads], we first
introduced it as a per-context tracker. This allows individual contexts
to try and optimise their own usage, but we found that with the local
tracking and the no-semaphore boosting, the first context to disable
semaphores got a massive priority boost and so would starve the rest and
all new contexts (as they started with semaphores enabled and lower
priority). Hence we moved the saturated workload detection to the
engine, and a consequence had to disable semaphores on virtual engines.
Now that we do not have semaphore priority boosting, we can move the
tracking to the GT and virtual engines can now utilise the faster
inter-engine synchronisation, while maintaining the global information
to back off on saturation.
References: 44d89409a12e ("drm/i915: Make the semaphore saturation mask global")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 --
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
drivers/gpu/drm/i915/i915_request.c | 13 -
5 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index ac9c777a6592..c9b83acaadf4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -230,7 +230,7 @@ static int __engine_park(struct intel_wakeref *wf)
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
- engine->saturated = 0;
+ clear_bit(engine->id, &engine->gt->saturated);
/*
* If one and only one request is completed between pm events,
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index a3b9da4b3721..53a1ddd43177 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -319,8 +319,6 @@ struct intel_engine_cs {
struct intel_context *kernel_context; /* pinned */
- intel_engine_mask_t saturated; /* submitting semaphores too late? */
-
struct {
struct delayed_work work;
struct i915_request *systole;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 0cc1d6b185dc..d7e139a2119b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -74,6 +74,8 @@ struct intel_gt {
*/
intel_wakeref_t awake;
+ unsigned long saturated; /* submitting semaphores too late? */
+
u32 clock_frequency;
struct intel_llc llc;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1c3afaa8f948..4208ef2d01b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5519,21 +5519,6 @@ intel_execlists_create_virtual(struct intel_engine_cs
**siblings,
ve->base.instance = I915_ENGINE_CLASS_INVALID_VIRTUAL;
ve->base.uabi_instance = I915_ENGINE_CLASS_INVALID_VIRTUAL;
- /*
-* The decision on whether to submit a request using semaphores
-* depends on the saturated state of the engine. We only compute
-* this during HW submission of the request, and we need for this
-* state to be globally applied to all requests being submitted
-* to this engine. Virtual engines encompass more than one physical
-* engine and so we cannot accurately tell in advance if one of those
-* engines is already saturated and so cannot afford to use a semaphore
-* and be pessimized in priority for doing so -- if we are the only
-* context using semaphores after all other clients have stopped, we
-* will be starved on the saturated system. Such a global switch for
-* semaphores is less than ideal, but alas is the current compromise.
-*/
- ve->base.saturated = ALL_ENGINES;
-
snprintf(ve->base.name, sizeof(ve->base.name), "virtual");
intel_engine_init_active(&ve->base, ENGINE_VIRTUAL);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a80dc5eae577..1ca93a97d20e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -551,7 +551,7 @@ bool __i915_request_submit(struct i915_request *request)
*/
if (request->sched.semaphores &&
i915_sw_fence_signaled(&request->semaphore))
- engine->saturated |= request->sched.semaphores;
+ set_bit(engine->id, &engine->gt->saturated);
engine->emit_fini_breadcrumb(request,
[Intel-gfx] [PATCH 05/33] drm/i915/gt: Replace direct submit with direct call to tasklet
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fast/immediate submissions, without requiring any
duplicated code paths.
The trickiest part here is to ensure that paired operations (such as
schedule_in/schedule_out) remain under consistent locking domains,
e.g. when pulled outside of the engine->active.lock
v2: Use bh kicking, see commit 3c53776e29f8 ("Mark HI and TASKLET
softirq synchronous").
v3: Update engine-reset to be tasklet aware
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 35 +++---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 20 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 119 ++
drivers/gpu/drm/i915/gt/intel_reset.c | 60 +
drivers/gpu/drm/i915/gt/intel_reset.h | 2 +
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 27 ++--
drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 2 +
drivers/gpu/drm/i915/selftests/i915_request.c | 6 +-
12 files changed, 149 insertions(+), 143 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5c13809dc3c8..5ca8f84d8de8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -399,12 +399,14 @@ static bool __reset_engine(struct intel_engine_cs *engine)
if (!intel_has_reset_engine(gt))
return false;
+ local_bh_disable();
if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
>->reset.flags)) {
- success = intel_engine_reset(engine, NULL) == 0;
+ success = __intel_engine_reset_bh(engine, NULL) == 0;
clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
>->reset.flags);
}
+ local_bh_enable();
return success;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c38ab51e82f0..ef425fd990c4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2355,7 +2355,9 @@ static void eb_request_add(struct i915_execbuffer *eb)
__i915_request_skip(rq);
}
+ local_bh_disable();
__i915_request_queue(rq, &attr);
+ local_bh_enable();
/* Try to clean up the client's timeline after submitting the request */
if (prev)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 7bf2f76212f0..b024ac1debc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -903,32 +903,39 @@ static unsigned long stop_timeout(const struct
intel_engine_cs *engine)
return READ_ONCE(engine->props.stop_timeout_ms);
}
-int intel_engine_stop_cs(struct intel_engine_cs *engine)
+static int __intel_engine_stop_cs(struct intel_engine_cs *engine,
+ int fast_timeout_us,
+ int slow_timeout_ms)
{
struct intel_uncore *uncore = engine->uncore;
- const u32 base = engine->mmio_base;
- const i915_reg_t mode = RING_MI_MODE(base);
+ const i915_reg_t mode = RING_MI_MODE(engine->mmio_base);
int err;
+ intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
+ err = __intel_wait_for_register_fw(engine->uncore, mode,
+ MODE_IDLE, MODE_IDLE,
+ fast_timeout_us,
+ slow_timeout_ms,
+ NULL);
+
+ /* A final mmio read to let GPU writes be hopefully flushed to memory */
+ intel_uncore_posting_read_fw(uncore, mode);
+ return err;
+}
+
+int intel_engine_stop_cs(struct intel_engine_cs *engine)
+{
+ int err = 0;
+
if (INTEL_GEN(engine->i915) < 3)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
-
- intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
-
- err = 0;
- if (__intel_wait_for_register_fw(uncore,
-mode, MODE_IDLE, MODE_IDLE,
-1000, stop_timeout(engine),
-NULL)) {
+ if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine, "ti
[Intel-gfx] [PATCH 28/33] drm/i915/gt: Couple tasklet scheduling for all CS interrupts
If any engine asks for the tasklet to be kicked from the CS interrupt,
do so. Currently, this is used by the execlists scheduler backends to
feed in the next request to the HW, and similarly could be used by a
ring scheduler, as will be seen in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 19 ++-
drivers/gpu/drm/i915/gt/intel_gt_irq.h | 3 +++
drivers/gpu/drm/i915/gt/intel_rps.c| 2 +-
drivers/gpu/drm/i915/i915_irq.c| 8
4 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0cc7dd54f4f9..a7a83137dc22 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -60,6 +60,15 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
tasklet_hi_schedule(&engine->execlists.tasklet);
}
+void gen2_engine_cs_irq(struct intel_engine_cs *engine)
+{
+ if (!list_empty(&engine->breadcrumbs.signalers))
+ intel_engine_signal_breadcrumbs(engine);
+
+ if (intel_engine_needs_breadcrumb_tasklet(engine))
+ tasklet_hi_schedule(&engine->execlists.tasklet);
+}
+
static u32
gen11_gt_engine_identity(struct intel_gt *gt,
const unsigned int bank, const unsigned int bit)
@@ -273,9 +282,9 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
void gen5_gt_irq_handler(struct intel_gt *gt, u32 gt_iir)
{
if (gt_iir & GT_RENDER_USER_INTERRUPT)
-
intel_engine_signal_breadcrumbs(gt->engine_class[RENDER_CLASS][0]);
+ gen2_engine_cs_irq(gt->engine_class[RENDER_CLASS][0]);
if (gt_iir & ILK_BSD_USER_INTERRUPT)
-
intel_engine_signal_breadcrumbs(gt->engine_class[VIDEO_DECODE_CLASS][0]);
+ gen2_engine_cs_irq(gt->engine_class[VIDEO_DECODE_CLASS][0]);
}
static void gen7_parity_error_irq_handler(struct intel_gt *gt, u32 iir)
@@ -299,11 +308,11 @@ static void gen7_parity_error_irq_handler(struct intel_gt
*gt, u32 iir)
void gen6_gt_irq_handler(struct intel_gt *gt, u32 gt_iir)
{
if (gt_iir & GT_RENDER_USER_INTERRUPT)
-
intel_engine_signal_breadcrumbs(gt->engine_class[RENDER_CLASS][0]);
+ gen2_engine_cs_irq(gt->engine_class[RENDER_CLASS][0]);
if (gt_iir & GT_BSD_USER_INTERRUPT)
-
intel_engine_signal_breadcrumbs(gt->engine_class[VIDEO_DECODE_CLASS][0]);
+ gen2_engine_cs_irq(gt->engine_class[VIDEO_DECODE_CLASS][0]);
if (gt_iir & GT_BLT_USER_INTERRUPT)
-
intel_engine_signal_breadcrumbs(gt->engine_class[COPY_ENGINE_CLASS][0]);
+ gen2_engine_cs_irq(gt->engine_class[COPY_ENGINE_CLASS][0]);
if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
GT_BSD_CS_ERROR_INTERRUPT |
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.h
b/drivers/gpu/drm/i915/gt/intel_gt_irq.h
index 886c5cf408a2..6c69cd563fe1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.h
@@ -9,6 +9,7 @@
#include
+struct intel_engine_cs;
struct intel_gt;
#define GEN8_GT_IRQS (GEN8_GT_RCS_IRQ | \
@@ -19,6 +20,8 @@ struct intel_gt;
GEN8_GT_PM_IRQ | \
GEN8_GT_GUC_IRQ)
+void gen2_engine_cs_irq(struct intel_engine_cs *engine);
+
void gen11_gt_irq_reset(struct intel_gt *gt);
void gen11_gt_irq_postinstall(struct intel_gt *gt);
void gen11_gt_irq_handler(struct intel_gt *gt, const u32 master_ctl);
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 296391deeb94..ad4c31844885 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1740,7 +1740,7 @@ void gen6_rps_irq_handler(struct intel_rps *rps, u32
pm_iir)
return;
if (pm_iir & PM_VEBOX_USER_INTERRUPT)
- intel_engine_signal_breadcrumbs(gt->engine[VECS0]);
+ gen2_engine_cs_irq(gt->engine[VECS0]);
if (pm_iir & PM_VEBOX_CS_ERROR_INTERRUPT)
DRM_DEBUG("Command parser error, pm_iir 0x%08x\n", pm_iir);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 562b43ed077f..ed34e9d0dc1c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3685,7 +3685,7 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
intel_uncore_write16(&dev_priv->uncore, GEN2_IIR, iir);
if (iir & I915_USER_INTERRUPT)
-
intel_engine_signal_breadcrumbs(dev_priv->gt.engine[RCS0]);
+ gen2_engine_cs_irq(dev_priv->gt.engine[RCS0]);
if (iir & I915_MASTER_ERROR_INTERRUPT)
i8xx_error_irq_handler(dev_priv, eir, eir_stuck);
@@ -3790,7 +3790,7 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
I915
[Intel-gfx] [PATCH 27/33] Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
This was removed in commit 478ffad6d690 ("drm/i915: drop
engine_pin/unpin_breadcrumbs_irq") as the last user had been removed,
but now there is a promise of a new user in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 22 +
drivers/gpu/drm/i915/gt/intel_engine.h | 3 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index d907d538176e..03c14ab86d95 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -220,6 +220,28 @@ static void signal_irq_work(struct irq_work *work)
}
}
+void intel_engine_pin_breadcrumbs_irq(struct intel_engine_cs *engine)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+
+ spin_lock_irq(&b->irq_lock);
+ if (!b->irq_enabled++)
+ irq_enable(engine);
+ GEM_BUG_ON(!b->irq_enabled); /* no overflow! */
+ spin_unlock_irq(&b->irq_lock);
+}
+
+void intel_engine_unpin_breadcrumbs_irq(struct intel_engine_cs *engine)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+
+ spin_lock_irq(&b->irq_lock);
+ GEM_BUG_ON(!b->irq_enabled); /* no underflow! */
+ if (!--b->irq_enabled)
+ irq_disable(engine);
+ spin_unlock_irq(&b->irq_lock);
+}
+
static bool __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
struct intel_engine_cs *engine =
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index a9249a23903a..dcc2fc22ea37 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -226,6 +226,9 @@ void intel_engine_init_execlists(struct intel_engine_cs
*engine);
void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
+void intel_engine_pin_breadcrumbs_irq(struct intel_engine_cs *engine);
+void intel_engine_unpin_breadcrumbs_irq(struct intel_engine_cs *engine);
+
void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
static inline void
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/33] drm/i915: Strip out internal priorities
Since we are not using any internal priority levels, and in the next few
patches will introduce a new index for which the optimisation is not so
lear cut, discard the small table within the priolist.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 22 ++--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 +--
drivers/gpu/drm/i915/i915_priolist_types.h| 8 +--
drivers/gpu/drm/i915/i915_scheduler.c | 51 +++
drivers/gpu/drm/i915/i915_scheduler.h | 18 ++-
7 files changed, 21 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 2a3bbf460437..30a3e3dea6e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -113,7 +113,7 @@ static void heartbeat(struct work_struct *wrk)
* low latency and no jitter] the chance to naturally
* complete before being preempted.
*/
- attr.priority = I915_PRIORITY_MASK;
+ attr.priority = 0;
if (rq->sched.attr.priority >= attr.priority)
attr.priority |=
I915_USER_PRIORITY(I915_PRIORITY_HEARTBEAT);
if (rq->sched.attr.priority >= attr.priority)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index eb25b80b4327..27cabb305317 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -435,22 +435,13 @@ static int effective_prio(const struct i915_request *rq)
static int queue_prio(const struct intel_engine_execlists *execlists)
{
- struct i915_priolist *p;
struct rb_node *rb;
rb = rb_first_cached(&execlists->queue);
if (!rb)
return INT_MIN;
- /*
-* As the priolist[] are inverted, with the highest priority in [0],
-* we have to flip the index value to become priority.
-*/
- p = to_priolist(rb);
- if (!I915_USER_PRIORITY_SHIFT)
- return p->priority;
-
- return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used);
+ return to_priolist(rb)->priority;
}
static inline bool need_preempt(const struct intel_engine_cs *engine,
@@ -2286,9 +2277,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
while ((rb = rb_first_cached(&execlists->queue))) {
struct i915_priolist *p = to_priolist(rb);
struct i915_request *rq, *rn;
- int i;
- priolist_for_each_request_consume(rq, rn, p, i) {
+ priolist_for_each_request_consume(rq, rn, p) {
bool merge = true;
/*
@@ -4251,9 +4241,8 @@ static void execlists_reset_cancel(struct intel_engine_cs
*engine)
/* Flush the queued requests to the timeline list (for retiring). */
while ((rb = rb_first_cached(&execlists->queue))) {
struct i915_priolist *p = to_priolist(rb);
- int i;
- priolist_for_each_request_consume(rq, rn, p, i) {
+ priolist_for_each_request_consume(rq, rn, p) {
mark_eio(rq);
__i915_request_submit(rq);
}
@@ -5277,7 +5266,7 @@ static int __execlists_context_alloc(struct intel_context
*ce,
static struct list_head *virtual_queue(struct virtual_engine *ve)
{
- return &ve->base.execlists.default_priolist.requests[0];
+ return &ve->base.execlists.default_priolist.requests;
}
static void virtual_context_destroy(struct kref *kref)
@@ -5836,9 +5825,8 @@ void intel_execlists_show_requests(struct intel_engine_cs
*engine,
count = 0;
for (rb = rb_first_cached(&execlists->queue); rb; rb = rb_next(rb)) {
struct i915_priolist *p = rb_entry(rb, typeof(*p), node);
- int i;
- priolist_for_each_request(rq, p, i) {
+ priolist_for_each_request(rq, p) {
if (count++ < max - 1)
show_request(m, rq, "\t\tQ ");
else
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 7476a54e8154..90391e1a1049 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1102,7 +1102,6 @@ create_rewinder(struct intel_context *ce,
intel_ring_advance(rq, cs);
- rq->sched.attr.priority = I915_PRIORITY_MASK;
err = 0;
err:
i915_request_get(rq);
@@ -5365,7 +5364,6 @@ create_timestamp(struct intel_context *ce, void *slot,
int idx)
intel_ring_advance(rq, cs);
-
[Intel-gfx] [PATCH 19/33] drm/i915/gt: Do not suspend bonded requests if one hangs
Treat the dependency between bonded requests as weak and leave the remainder of the pair on the GPU if one hangs. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_lrc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 6b3d5d3dd0d1..94fd214c91c8 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -2697,6 +2697,9 @@ static void __execlists_hold(struct i915_request *rq) struct i915_request *w = container_of(p->waiter, typeof(*w), sched); + if (p->flags & I915_DEPENDENCY_WEAK) + continue; + /* Leave semaphores spinning on the other engines */ if (w->engine != rq->engine) continue; @@ -2792,6 +2795,9 @@ static void __execlists_unhold(struct i915_request *rq) struct i915_request *w = container_of(p->waiter, typeof(*w), sched); + if (p->flags & I915_DEPENDENCY_WEAK) + continue; + /* Propagate any change in error status */ if (rq->fence.error) i915_request_set_error_once(w, rq->fence.error); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/33] drm/i915/gt: Drop atomic for engine->fw_active tracking
Since schedule-in/out is now entirely serialised by the tasklet bitlock,
we do not need to worry about concurrent in/out operations and so reduce
the atomic operations to plain instructions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index b024ac1debc7..d58e5e251ff3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1540,7 +1540,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
ktime_to_ms(intel_engine_get_busy_time(engine,
&dummy)));
drm_printf(m, "\tForcewake: %x domains, %d active\n",
- engine->fw_domain, atomic_read(&engine->fw_active));
+ engine->fw_domain, READ_ONCE(engine->fw_active));
rcu_read_lock();
rq = READ_ONCE(engine->heartbeat.systole);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 490af81bd6f3..b8d8973e6f97 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -322,7 +322,7 @@ struct intel_engine_cs {
* as possible.
*/
enum forcewake_domains fw_domain;
- atomic_t fw_active;
+ unsigned int fw_active;
unsigned long context_tag;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 07736814a9e1..61c27733debc 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1350,7 +1350,7 @@ __execlists_schedule_in(struct i915_request *rq)
ce->lrc.ccid |= engine->execlists.ccid;
__intel_gt_pm_get(engine->gt);
- if (engine->fw_domain && !atomic_fetch_inc(&engine->fw_active))
+ if (engine->fw_domain && !engine->fw_active++)
intel_uncore_forcewake_get(engine->uncore, engine->fw_domain);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
@@ -1455,7 +1455,7 @@ static inline void __execlists_schedule_out(struct
i915_request *rq)
intel_context_update_runtime(ce);
intel_engine_context_out(engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
- if (engine->fw_domain && !atomic_dec_return(&engine->fw_active))
+ if (engine->fw_domain && !--engine->fw_active)
intel_uncore_forcewake_put(engine->uncore, engine->fw_domain);
intel_gt_pm_put_async(engine->gt);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 31/33] drm/i915/gt: Infrastructure for ring scheduling
Build a bare bones scheduler to sit on top the global legacy ringbuffer
submission. This virtual execlists scheme should be applicable to all
older platforms.
A key problem we have with the legacy ring buffer submission is that it
only allows for FIFO queuing. All clients share the global request queue
and must contend for its lock when submitting. As any client may need to
wait for external events, all clients must then wait. However, if we
stage each client into their own virtual ringbuffer with their own
timelines, we can copy the client requests into the global ringbuffer
only when they are ready, reordering the submission around stalls.
Furthermore, the ability to reorder gives us rudimentarily priority
sorting -- although without preemption support, once something is on the
GPU it stays on the GPU, and so it is still possible for a hog to delay
a high priority request (such as updating the display). However, it does
means that in keeping a short submission queue, the high priority
request will be next. This design resembles the old guc submission
scheduler, for reordering requests onto a global workqueue.
The implementation uses the MI_USER_INTERRUPT at the end of every
request to track completion, so is more interrupt happy than execlists
[which has an interrupt for each context event, albeit two]. Our
interrupts on these system are relatively heavy, and in the past we have
been able to completely starve Sandybrige by the interrupt traffic. Our
interrupt handlers are being much better (in part offloading the work to
bottom halves leaving the interrupt itself only dealing with acking the
registers) but we can still see the impact of starvation in the uneven
submission latency on a saturated system.
Overall though, the short sumission queues and extra interrupts do not
appear to be affecting throughput (+-10%, some tasks even improve to the
reduced request overheads) and improve latency. [Which is a massive
improvement since the introduction of Sandybridge!]
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_engine.h| 1 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
.../gpu/drm/i915/gt/intel_ring_scheduler.c| 736 ++
.../gpu/drm/i915/gt/intel_ring_submission.c | 13 +-
.../gpu/drm/i915/gt/intel_ring_submission.h | 16 +
6 files changed, 762 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_ring_submission.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 41a27fd5dbc7..6d98a74da41e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -109,6 +109,7 @@ gt-y += \
gt/intel_renderstate.o \
gt/intel_reset.o \
gt/intel_ring.o \
+ gt/intel_ring_scheduler.o \
gt/intel_ring_submission.o \
gt/intel_rps.o \
gt/intel_sseu.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index dcc2fc22ea37..b816581b95d3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -209,6 +209,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine);
int intel_engine_resume(struct intel_engine_cs *engine);
int intel_ring_submission_setup(struct intel_engine_cs *engine);
+int intel_ring_scheduler_setup(struct intel_engine_cs *engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 53a1ddd43177..e0e1ab419760 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -334,6 +334,7 @@ struct intel_engine_cs {
struct {
struct intel_ring *ring;
struct intel_timeline *timeline;
+ struct intel_context *context;
} legacy;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
new file mode 100644
index ..6b3c50e63bd9
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
@@ -0,0 +1,736 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+
+#include
+
+#include "i915_drv.h"
+#include "intel_context.h"
+#include "intel_engine_stats.h"
+#include "intel_gt.h"
+#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
+#include "intel_reset.h"
+#include "intel_ring.h"
+#include "intel_ring_submission.h"
+#include "shmem_utils.h"
+
+/*
+ * Rough estimate of the typical request size, performing a flush,
+ * set-context and then emitting the batch.
+ */
+#define LEGACY_REQUEST_SIZE 200
+
+static inline int rq_prio(const struct i915_request *rq)
+{
+ return rq->sched.attr.priorit
[Intel-gfx] [PATCH 17/33] drm/i915: Remove I915_USER_PRIORITY_SHIFT
As we do not have any internal priority levels, the priority can be set
directed from the user values.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +--
.../i915/gem/selftests/i915_gem_object_blt.c | 4 +-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 6 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 44 +++
drivers/gpu/drm/i915/i915_priolist_types.h| 3 --
drivers/gpu/drm/i915/i915_scheduler.c | 1 -
7 files changed, 23 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 84e2a17b5ecb..59536eb1ee50 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15908,9 +15908,7 @@ static void intel_plane_unpin_fb(struct
intel_plane_state *old_plane_state)
static void fb_obj_bump_render_priority(struct drm_i915_gem_object *obj)
{
- struct i915_sched_attr attr = {
- .priority = I915_USER_PRIORITY(I915_PRIORITY_DISPLAY),
- };
+ struct i915_sched_attr attr = { .priority = I915_PRIORITY_DISPLAY };
i915_gem_object_wait_priority(obj, 0, &attr);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5ca8f84d8de8..d4fce5cb3eb4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -714,7 +714,7 @@ __create_context(struct drm_i915_private *i915)
kref_init(&ctx->ref);
ctx->i915 = i915;
- ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
+ ctx->sched.priority = I915_PRIORITY_NORMAL;
mutex_init(&ctx->mutex);
spin_lock_init(&ctx->stale.lock);
@@ -1996,7 +1996,7 @@ static int set_priority(struct i915_gem_context *ctx,
!capable(CAP_SYS_NICE))
return -EPERM;
- ctx->sched.priority = I915_USER_PRIORITY(priority);
+ ctx->sched.priority = priority;
context_apply_all(ctx, __apply_priority, ctx);
return 0;
@@ -2499,7 +2499,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
case I915_CONTEXT_PARAM_PRIORITY:
args->size = 0;
- args->value = ctx->sched.priority >> I915_USER_PRIORITY_SHIFT;
+ args->value = ctx->sched.priority;
break;
case I915_CONTEXT_PARAM_SSEU:
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
index 23b6e11bbc3e..c4c04fb97d14 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
@@ -220,7 +220,7 @@ static int igt_fill_blt_thread(void *arg)
return PTR_ERR(ctx);
prio = i915_prandom_u32_max_state(I915_PRIORITY_MAX, prng);
- ctx->sched.priority = I915_USER_PRIORITY(prio);
+ ctx->sched.priority = prio;
}
ce = i915_gem_context_get_engine(ctx, 0);
@@ -338,7 +338,7 @@ static int igt_copy_blt_thread(void *arg)
return PTR_ERR(ctx);
prio = i915_prandom_u32_max_state(I915_PRIORITY_MAX, prng);
- ctx->sched.priority = I915_USER_PRIORITY(prio);
+ ctx->sched.priority = prio;
}
ce = i915_gem_context_get_engine(ctx, 0);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 30a3e3dea6e1..8e1abd037a94 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -69,9 +69,7 @@ static void show_heartbeat(const struct i915_request *rq,
static void heartbeat(struct work_struct *wrk)
{
- struct i915_sched_attr attr = {
- .priority = I915_USER_PRIORITY(I915_PRIORITY_MIN),
- };
+ struct i915_sched_attr attr = { .priority = I915_PRIORITY_MIN };
struct intel_engine_cs *engine =
container_of(wrk, typeof(*engine), heartbeat.work.work);
struct intel_context *ce = engine->kernel_context;
@@ -115,7 +113,7 @@ static void heartbeat(struct work_struct *wrk)
*/
attr.priority = 0;
if (rq->sched.attr.priority >= attr.priority)
- attr.priority |=
I915_USER_PRIORITY(I915_PRIORITY_HEARTBEAT);
+ attr.priority = I915_PRIORITY_HEARTBEAT;
if (rq->sched.attr.priority >= attr.priority)
attr.priority = I915_PRIORITY_BARRIER;
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 90391e1a1049..46d400640188 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++
[Intel-gfx] [PATCH 30/33] drm/i915/gt: Use client timeline address for seqno writes
If we allow for per-client timelines, even with legacy ring submission,
we open the door to a world full of possiblities [scheduling and
semaphores].
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen6_engine_cs.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
index ce38d1bcaba3..fa11174bb13b 100644
--- a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
@@ -373,11 +373,10 @@ u32 *gen7_emit_breadcrumb_rcs(struct i915_request *rq,
u32 *cs)
u32 *gen6_emit_breadcrumb_xcs(struct i915_request *rq, u32 *cs)
{
- GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt !=
rq->engine->status_page.vma);
-
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) !=
I915_GEM_HWS_SEQNO_ADDR);
+ u32 addr = i915_request_active_timeline(rq)->hwsp_offset;
- *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
- *cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
+ *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW;
+ *cs++ = addr | MI_FLUSH_DW_USE_GTT;
*cs++ = rq->fence.seqno;
*cs++ = MI_USER_INTERRUPT;
@@ -391,19 +390,17 @@ u32 *gen6_emit_breadcrumb_xcs(struct i915_request *rq,
u32 *cs)
#define GEN7_XCS_WA 32
u32 *gen7_emit_breadcrumb_xcs(struct i915_request *rq, u32 *cs)
{
+ u32 addr = i915_request_active_timeline(rq)->hwsp_offset;
int i;
- GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt !=
rq->engine->status_page.vma);
-
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) !=
I915_GEM_HWS_SEQNO_ADDR);
-
- *cs++ = MI_FLUSH_DW | MI_INVALIDATE_TLB |
- MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
- *cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
+ *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW;
+ *cs++ = addr | MI_FLUSH_DW_USE_GTT;
*cs++ = rq->fence.seqno;
for (i = 0; i < GEN7_XCS_WA; i++) {
- *cs++ = MI_STORE_DWORD_INDEX;
- *cs++ = I915_GEM_HWS_SEQNO_ADDR;
+ *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
+ *cs++ = 0;
+ *cs++ = addr;
*cs++ = rq->fence.seqno;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/33] drm/i915/gt: Decouple inflight virtual engines
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the context is inflight, only kick the bound sibling while it
inflight and upon scheduling out the kick the rest (so that we can swap
engines on timeslicing if the previously bound engine becomes
oversubscribed).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 30 +
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e0b9a1f9eedf..e7eec78a2e55 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1410,9 +1410,8 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
static void kick_siblings(struct i915_request *rq, struct intel_context *ce)
{
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
- struct i915_request *next = READ_ONCE(ve->request);
- if (next == rq || (next && next->execution_mask & ~rq->execution_mask))
+ if (READ_ONCE(ve->request))
tasklet_hi_schedule(&ve->base.execlists.tasklet);
}
@@ -1828,18 +1827,14 @@ first_virtual_engine(struct intel_engine_cs *engine)
rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
struct i915_request *rq = READ_ONCE(ve->request);
- if (!rq) { /* lazily cleanup after another engine handled rq */
+ /* lazily cleanup after another engine handled rq */
+ if (!rq || !virtual_matches(ve, rq, engine)) {
rb_erase_cached(rb, &el->virtual);
RB_CLEAR_NODE(rb);
rb = rb_first_cached(&el->virtual);
continue;
}
- if (!virtual_matches(ve, rq, engine)) {
- rb = rb_next(rb);
- continue;
- }
-
return ve;
}
@@ -5448,7 +5443,6 @@ static void virtual_submission_tasklet(unsigned long data)
if (unlikely(!mask))
return;
- local_irq_disable();
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = READ_ONCE(ve->siblings[n]);
struct ve_node * const node = &ve->nodes[sibling->id];
@@ -5458,20 +5452,19 @@ static void virtual_submission_tasklet(unsigned long
data)
if (!READ_ONCE(ve->request))
break; /* already handled by a sibling's tasklet */
+ spin_lock_irq(&sibling->active.lock);
+
if (unlikely(!(mask & sibling->mask))) {
if (!RB_EMPTY_NODE(&node->rb)) {
- spin_lock(&sibling->active.lock);
rb_erase_cached(&node->rb,
&sibling->execlists.virtual);
RB_CLEAR_NODE(&node->rb);
- spin_unlock(&sibling->active.lock);
}
- continue;
- }
- spin_lock(&sibling->active.lock);
+ goto unlock_engine;
+ }
- if (!RB_EMPTY_NODE(&node->rb)) {
+ if (unlikely(!RB_EMPTY_NODE(&node->rb))) {
/*
* Cheat and avoid rebalancing the tree if we can
* reuse this node in situ.
@@ -5511,9 +5504,12 @@ static void virtual_submission_tasklet(unsigned long
data)
if (first && prio > sibling->execlists.queue_priority_hint)
tasklet_hi_schedule(&sibling->execlists.tasklet);
- spin_unlock(&sibling->active.lock);
+unlock_engine:
+ spin_unlock_irq(&sibling->active.lock);
+
+ if (intel_context_inflight(&ve->context))
+ break;
}
- local_irq_enable();
}
static void virtual_submit_request(struct i915_request *rq)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/33] drm/i915/gt: ce->inflight updates are now serialised
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 44 +
1 file changed, 19 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e8f85f31..07736814a9e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1341,7 +1341,7 @@ __execlists_schedule_in(struct i915_request *rq)
unsigned int tag = ffs(READ_ONCE(engine->context_tag));
GEM_BUG_ON(tag == 0 || tag >= BITS_PER_LONG);
- clear_bit(tag - 1, &engine->context_tag);
+ __clear_bit(tag - 1, &engine->context_tag);
ce->lrc.ccid = tag << (GEN11_SW_CTX_ID_SHIFT - 32);
BUILD_BUG_ON(BITS_PER_LONG > GEN12_MAX_CONTEXT_HW_ID);
@@ -1368,13 +1368,10 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
GEM_BUG_ON(!intel_engine_pm_is_awake(rq->engine));
trace_i915_request_in(rq, idx);
- old = READ_ONCE(ce->inflight);
- do {
- if (!old) {
- WRITE_ONCE(ce->inflight, __execlists_schedule_in(rq));
- break;
- }
- } while (!try_cmpxchg(&ce->inflight, &old, ptr_inc(old)));
+ old = ce->inflight;
+ if (!old)
+ old = __execlists_schedule_in(rq);
+ WRITE_ONCE(ce->inflight, ptr_inc(old));
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
}
@@ -1424,12 +1421,11 @@ static void kick_siblings(struct i915_request *rq,
struct intel_context *ce)
resubmit_virtual_request(rq, ve);
}
-static inline void
-__execlists_schedule_out(struct i915_request *rq,
-struct intel_engine_cs * const engine,
-unsigned int ccid)
+static inline void __execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
+ struct intel_engine_cs * const engine = rq->engine;
+ unsigned int ccid;
/*
* NB process_csb() is not under the engine->active.lock and hence
@@ -1437,7 +1433,7 @@ __execlists_schedule_out(struct i915_request *rq,
* refrain from doing non-trivial work here.
*/
- CE_TRACE(ce, "schedule-out, ccid:%x\n", ccid);
+ CE_TRACE(ce, "schedule-out, ccid:%x\n", ce->lrc.ccid);
/*
* If we have just completed this context, the engine may now be
@@ -1447,12 +1443,13 @@ __execlists_schedule_out(struct i915_request *rq,
i915_request_completed(rq))
intel_engine_add_retire(engine, ce->timeline);
+ ccid = ce->lrc.ccid;
ccid >>= GEN11_SW_CTX_ID_SHIFT - 32;
ccid &= GEN12_MAX_CONTEXT_HW_ID;
if (ccid < BITS_PER_LONG) {
GEM_BUG_ON(ccid == 0);
GEM_BUG_ON(test_bit(ccid - 1, &engine->context_tag));
- set_bit(ccid - 1, &engine->context_tag);
+ __set_bit(ccid - 1, &engine->context_tag);
}
intel_context_update_runtime(ce);
@@ -1473,26 +1470,23 @@ __execlists_schedule_out(struct i915_request *rq,
*/
if (ce->engine != engine)
kick_siblings(rq, ce);
-
- intel_context_put(ce);
}
static inline void
execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
- struct intel_engine_cs *cur, *old;
- u32 ccid;
trace_i915_request_out(rq);
- ccid = rq->context->lrc.ccid;
- old = READ_ONCE(ce->inflight);
- do
- cur = ptr_unmask_bits(old, 2) ? ptr_dec(old) : NULL;
- while (!try_cmpxchg(&ce->inflight, &old, cur));
- if (!cur)
- __execlists_schedule_out(rq, old, ccid);
+ GEM_BUG_ON(!ce->inflight);
+ ce->inflight = ptr_dec(ce->inflight);
+ if (!intel_context_inflight_count(ce)) {
+ GEM_BUG_ON(ce->inflight != rq->engine);
+ __execlists_schedule_out(rq);
+ WRITE_ONCE(ce->inflight, NULL);
+ intel_context_put(ce);
+ }
i915_request_put(rq);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 25/33] drm/i915: Replace the priority boosting for the display with a deadline
For a modeset/pageflip, there is a very precise deadline by which the
frame must be completed in order to hit the vblank and be shown. While
we don't pass along that exact information, we can at least inform the
scheduler that this request-chain needs to be completed asap.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 ++-
drivers/gpu/drm/i915/i915_priolist_types.h | 3 ---
4 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6ad91f8649fd..920e9d64a53f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15982,7 +15982,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
if (ret)
return ret;
- i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
+ i915_gem_object_wait_deadline(obj, 0, ktime_get() /* next vblank? */);
i915_gem_object_flush_frontbuffer(obj, ORIGIN_DIRTYFB);
if (!new_plane_state->uapi.fence) { /* implicit fencing */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 876c34982555..7bcd2661de4c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -474,9 +474,9 @@ static inline void __start_cpu_write(struct
drm_i915_gem_object *obj)
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
unsigned int flags,
long timeout);
-int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+int i915_gem_object_wait_deadline(struct drm_i915_gem_object *obj,
unsigned int flags,
- int prio);
+ ktime_t deadline);
void __i915_gem_object_flush_frontbuffer(struct drm_i915_gem_object *obj,
enum fb_op_origin origin);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index cefbbb3d9b52..3334817183f6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -93,17 +93,18 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
return timeout;
}
-static void __fence_set_priority(struct dma_fence *fence, int prio)
+static void __fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
{
if (dma_fence_is_signaled(fence) || !dma_fence_is_i915(fence))
return;
local_bh_disable();
- i915_request_set_priority(to_request(fence), prio);
+ i915_request_set_deadline(to_request(fence),
+ i915_sched_to_ticks(deadline));
local_bh_enable(); /* kick the tasklets if queues were reprioritised */
}
-static void fence_set_priority(struct dma_fence *fence, int prio)
+static void fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
{
/* Recurse once into a fence-array */
if (dma_fence_is_array(fence)) {
@@ -111,16 +112,16 @@ static void fence_set_priority(struct dma_fence *fence,
int prio)
int i;
for (i = 0; i < array->num_fences; i++)
- __fence_set_priority(array->fences[i], prio);
+ __fence_set_deadline(array->fences[i], deadline);
} else {
- __fence_set_priority(fence, prio);
+ __fence_set_deadline(fence, deadline);
}
}
int
-i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+i915_gem_object_wait_deadline(struct drm_i915_gem_object *obj,
unsigned int flags,
- int prio)
+ ktime_t deadline)
{
struct dma_fence *excl;
@@ -135,7 +136,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object
*obj,
return ret;
for (i = 0; i < count; i++) {
- fence_set_priority(shared[i], prio);
+ fence_set_deadline(shared[i], deadline);
dma_fence_put(shared[i]);
}
@@ -145,7 +146,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object
*obj,
}
if (excl) {
- fence_set_priority(excl, prio);
+ fence_set_deadline(excl, deadline);
dma_fence_put(excl);
}
return 0;
diff --git a/drivers/gpu/drm/i915/i915_priolist_types.h
b/drivers/gpu/drm/i915/i915_priolist_types.h
index 43a0ac45295f..ac6d9614ea23 100644
--- a/drivers/gpu/drm/i915/i915_priolist_types.h
+++ b/drivers/gpu/drm/i915/i915_priolist_types.h
@@ -20,9 +20,6 @@ enum {
/* A preemptive pulse used to monitor the health of each en
[Intel-gfx] [PATCH 21/33] drm/i915: Restructure priority inheritance
In anticipation of wanting to be able to call pi from underneath an
engine's active.lock, rework the priority inheritance to primarily work
along an engine's priority queue, delegating any other engine that the
chain may traverse to a worker. This reduces the global spinlock from
governing the entire priority inheritance depth-first search, to a small
lock around a single list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.c | 246 ++--
drivers/gpu/drm/i915/i915_scheduler_types.h | 6 +-
2 files changed, 130 insertions(+), 122 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 2e4d512e61d8..6500f04c5f39 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -17,7 +17,66 @@ static struct i915_global_scheduler {
struct kmem_cache *slab_priorities;
} global;
-static DEFINE_SPINLOCK(schedule_lock);
+static DEFINE_SPINLOCK(ipi_lock);
+static LIST_HEAD(ipi_list);
+
+static inline int rq_prio(const struct i915_request *rq)
+{
+ return READ_ONCE(rq->sched.attr.priority);
+}
+
+static void ipi_schedule(struct irq_work *wrk)
+{
+ rcu_read_lock();
+ do {
+ struct i915_dependency *p;
+ struct i915_request *rq;
+ unsigned long flags;
+ int prio;
+
+ spin_lock_irqsave(&ipi_lock, flags);
+ p = list_first_entry_or_null(&ipi_list, typeof(*p), ipi_link);
+ if (p) {
+ rq = container_of(p->signaler, typeof(*rq), sched);
+ list_del_init(&p->ipi_link);
+
+ prio = p->ipi_priority;
+ p->ipi_priority = I915_PRIORITY_INVALID;
+ }
+ spin_unlock_irqrestore(&ipi_lock, flags);
+ if (!p)
+ break;
+
+ if (i915_request_completed(rq))
+ continue;
+
+ if (prio > rq_prio(rq))
+ i915_request_set_priority(rq, prio);
+ } while (1);
+ rcu_read_unlock();
+}
+
+static DEFINE_IRQ_WORK(ipi_work, ipi_schedule);
+
+/*
+ * Virtual engines complicate acquiring the engine timeline lock,
+ * as their rq->engine pointer is not stable until under that
+ * engine lock. The simple ploy we use is to take the lock then
+ * check that the rq still belongs to the newly locked engine.
+ */
+#define lock_engine_irqsave(rq, flags) ({ \
+ struct i915_request * const rq__ = (rq); \
+ struct intel_engine_cs *engine__ = READ_ONCE(rq__->engine); \
+\
+ spin_lock_irqsave(&engine__->active.lock, (flags)); \
+ while (engine__ != READ_ONCE((rq__)->engine)) { \
+ spin_unlock(&engine__->active.lock); \
+ engine__ = READ_ONCE(rq__->engine); \
+ spin_lock(&engine__->active.lock); \
+ } \
+\
+ engine__; \
+})
static const struct i915_request *
node_to_request(const struct i915_sched_node *node)
@@ -126,42 +185,6 @@ void __i915_priolist_free(struct i915_priolist *p)
kmem_cache_free(global.slab_priorities, p);
}
-struct sched_cache {
- struct list_head *priolist;
-};
-
-static struct intel_engine_cs *
-sched_lock_engine(const struct i915_sched_node *node,
- struct intel_engine_cs *locked,
- struct sched_cache *cache)
-{
- const struct i915_request *rq = node_to_request(node);
- struct intel_engine_cs *engine;
-
- GEM_BUG_ON(!locked);
-
- /*
-* Virtual engines complicate acquiring the engine timeline lock,
-* as their rq->engine pointer is not stable until under that
-* engine lock. The simple ploy we use is to take the lock then
-* check that the rq still belongs to the newly locked engine.
-*/
- while (locked != (engine = READ_ONCE(rq->engine))) {
- spin_unlock(&locked->active.lock);
- memset(cache, 0, sizeof(*cache));
- spin_lock(&engine->active.lock);
- locked = engine;
- }
-
- GEM_BUG_ON(locked != engine);
- return locked;
-}
-
-static inline int rq_prio(const struct i915_request *rq)
-{
- return rq->sched.attr.priority;
-}
-
static inline bool need_preempt(int prio, int active)
{
/*
@@ -216,25 +239,15 @@ static void kick_submission(struct intel_engine_cs
*engine,
rcu_read_unlock();
}
-static void __i915_schedule(struct i915_sched_node *node, int prio)
+static void __i915_request_set_priority(struct i915_request *rq, int prio)
{
- struct intel_engine_cs *engine;
- struct i915_dependency *dep, *p;
- struct i915_dependency stack;
- struct sched_cache cache;
+ struct intel_engine_cs *engine = rq->engine;
+ struct i915_request *rn;
+ struct list_head *plist;
LIST_HEAD(dfs);
- /* Needed in order to use the temporary link
[Intel-gfx] [PATCH 03/33] drm/i915/gt: Decouple completed requests on unwind
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any. However, if the request is completed we currently leave it
on the list [until retirement], but we could just as simply remove it
and stop treating it as active. We would only have to then traverse it
once while unwinding in quick succession.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e866b8d721ed..4eb397b0e14d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1114,8 +1114,10 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
list_for_each_entry_safe_reverse(rq, rn,
&engine->active.requests,
sched.link) {
- if (i915_request_completed(rq))
- continue; /* XXX */
+ if (i915_request_completed(rq)) {
+ list_del_init(&rq->sched.link);
+ continue;
+ }
__i915_request_unsubmit(rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 29/33] drm/i915/gt: Support creation of 'internal' rings
To support legacy ring buffer scheduling, we want a virtual ringbuffer
for each client. These rings are purely for holding the requests as they
are being constructed on the CPU and never accessed by the GPU, so they
should not be bound into the GGTT, and we can use plain old WB mapped
pages.
As they are not bound, we need to nerf a few assumptions that a rq->ring
is in the GGTT.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 17 ++
drivers/gpu/drm/i915/gt/intel_ring.c | 63 ++
drivers/gpu/drm/i915/gt/intel_ring.h | 12 -
drivers/gpu/drm/i915/gt/intel_ring_types.h | 2 +
5 files changed, 57 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index e4aece20bc80..fd71977c010a 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -127,7 +127,7 @@ int __intel_context_do_pin(struct intel_context *ce)
goto err_active;
CE_TRACE(ce, "pin ring:{start:%08x, head:%04x, tail:%04x}\n",
-i915_ggtt_offset(ce->ring->vma),
+intel_ring_address(ce->ring),
ce->ring->head, ce->ring->tail);
smp_mb__before_atomic(); /* flush pin before it is visible */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 413d8393b989..a5e83c115b23 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1267,7 +1267,7 @@ static int print_ring(char *buf, int sz, struct
i915_request *rq)
len = scnprintf(buf, sz,
"ring:{start:%08x, hwsp:%08x, seqno:%08x,
runtime:%llums}, ",
- i915_ggtt_offset(rq->ring->vma),
+ intel_ring_address(rq->ring),
tl ? tl->hwsp_offset : 0,
hwsp_seqno(rq),
DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
@@ -1559,7 +1559,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
print_request(m, rq, "\t\tactive ");
drm_printf(m, "\t\tring->start: 0x%08x\n",
- i915_ggtt_offset(rq->ring->vma));
+ intel_ring_address(rq->ring));
drm_printf(m, "\t\tring->head: 0x%08x\n",
rq->ring->head);
drm_printf(m, "\t\tring->tail: 0x%08x\n",
@@ -1640,13 +1640,6 @@ ktime_t intel_engine_get_busy_time(struct
intel_engine_cs *engine, ktime_t *now)
return total;
}
-static bool match_ring(struct i915_request *rq)
-{
- u32 ring = ENGINE_READ(rq->engine, RING_START);
-
- return ring == i915_ggtt_offset(rq->ring->vma);
-}
-
struct i915_request *
intel_engine_find_active_request(struct intel_engine_cs *engine)
{
@@ -1686,11 +1679,7 @@ intel_engine_find_active_request(struct intel_engine_cs
*engine)
continue;
if (!i915_request_started(request))
- continue;
-
- /* More than one preemptible request may match! */
- if (!match_ring(request))
- continue;
+ break;
active = request;
break;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index bdb324167ef3..c17cb9f24962 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -24,33 +24,42 @@ unsigned int intel_ring_update_space(struct intel_ring
*ring)
int intel_ring_pin(struct intel_ring *ring)
{
struct i915_vma *vma = ring->vma;
- unsigned int flags;
void *addr;
int ret;
if (atomic_fetch_inc(&ring->pin_count))
return 0;
- /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
- flags = PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
+ if (!(ring->flags & INTEL_RING_CREATE_INTERNAL)) {
+ unsigned int pin;
- if (vma->obj->stolen)
- flags |= PIN_MAPPABLE;
- else
- flags |= PIN_HIGH;
+ /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
+ pin |= PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
- ret = i915_ggtt_pin(vma, 0, flags);
- if (unlikely(ret))
- goto err_unpin;
+ if (vma->obj->stolen)
+ pin |= PIN_MAPPABLE;
+ else
+ pin |= PIN_HIGH;
- if (i915_vma_is_map_and_fenceable(vma))
- addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
[Intel-gfx] [PATCH 18/33] drm/i915: Replace engine->schedule() with a known request operation
Looking to the future, we want to set the scheduling attributes
explicitly and so replace the generic engine->schedule() with the more
direct i915_request_set_priority()
What it loses in removing the 'schedule' name from the function, it
gains in having an explicit entry point with a stated goal.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_display.c | 9 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 27 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 --
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 29
drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 11 +++
drivers/gpu/drm/i915/gt/selftest_lrc.c| 33 +--
drivers/gpu/drm/i915/i915_request.c | 11 ---
drivers/gpu/drm/i915/i915_scheduler.c | 15 +
drivers/gpu/drm/i915/i915_scheduler.h | 3 +-
13 files changed, 57 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 59536eb1ee50..6ad91f8649fd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15906,13 +15906,6 @@ static void intel_plane_unpin_fb(struct
intel_plane_state *old_plane_state)
intel_unpin_fb_vma(vma, old_plane_state->flags);
}
-static void fb_obj_bump_render_priority(struct drm_i915_gem_object *obj)
-{
- struct i915_sched_attr attr = { .priority = I915_PRIORITY_DISPLAY };
-
- i915_gem_object_wait_priority(obj, 0, &attr);
-}
-
/**
* intel_prepare_plane_fb - Prepare fb for usage on plane
* @_plane: drm plane to prepare for
@@ -15989,7 +15982,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
if (ret)
return ret;
- fb_obj_bump_render_priority(obj);
+ i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
i915_gem_object_flush_frontbuffer(obj, ORIGIN_DIRTYFB);
if (!new_plane_state->uapi.fence) { /* implicit fencing */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 2faa481cc18f..876c34982555 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -476,7 +476,7 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
long timeout);
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
- const struct i915_sched_attr *attr);
+ int prio);
void __i915_gem_object_flush_frontbuffer(struct drm_i915_gem_object *obj,
enum fb_op_origin origin);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 8af55cd3e690..cefbbb3d9b52 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -93,28 +93,17 @@ i915_gem_object_wait_reservation(struct dma_resv *resv,
return timeout;
}
-static void __fence_set_priority(struct dma_fence *fence,
-const struct i915_sched_attr *attr)
+static void __fence_set_priority(struct dma_fence *fence, int prio)
{
- struct i915_request *rq;
- struct intel_engine_cs *engine;
-
if (dma_fence_is_signaled(fence) || !dma_fence_is_i915(fence))
return;
- rq = to_request(fence);
- engine = rq->engine;
-
local_bh_disable();
- rcu_read_lock(); /* RCU serialisation for set-wedged protection */
- if (engine->schedule)
- engine->schedule(rq, attr);
- rcu_read_unlock();
+ i915_request_set_priority(to_request(fence), prio);
local_bh_enable(); /* kick the tasklets if queues were reprioritised */
}
-static void fence_set_priority(struct dma_fence *fence,
- const struct i915_sched_attr *attr)
+static void fence_set_priority(struct dma_fence *fence, int prio)
{
/* Recurse once into a fence-array */
if (dma_fence_is_array(fence)) {
@@ -122,16 +111,16 @@ static void fence_set_priority(struct dma_fence *fence,
int i;
for (i = 0; i < array->num_fences; i++)
- __fence_set_priority(array->fences[i], attr);
+ __fence_set_priority(array->fences[i], prio);
} else {
- __fence_set_priority(fence, attr);
+ __fence_set_priority(fence, prio);
}
}
int
i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
- const
[Intel-gfx] [PATCH 10/33] drm/i915/gt: Simplify virtual engine handling for execlists_hold()
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue until it is scheduled; after which point it will become
eligible for transfer to a sibling. Instead, we could opt to resubmit the
request along the virtual engine on unhold, making it eligible for load
balancing immediately -- but that seems like a pointless optimisation
for a hanging context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f4323d407a9f..e8f85f31 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2785,35 +2785,6 @@ static bool execlists_hold(struct intel_engine_cs
*engine,
goto unlock;
}
- if (rq->engine != engine) { /* preempted virtual engine */
- struct virtual_engine *ve = to_virtual_engine(rq->engine);
-
- /*
-* intel_context_inflight() is only protected by virtue
-* of process_csb() being called only by the tasklet (or
-* directly from inside reset while the tasklet is suspended).
-* Assert that neither of those are allowed to run while we
-* poke at the request queues.
-*/
- GEM_BUG_ON(!reset_in_progress(&engine->execlists));
-
- /*
-* An unsubmitted request along a virtual engine will
-* remain on the active (this) engine until we are able
-* to process the context switch away (and so mark the
-* context as no longer in flight). That cannot have happened
-* yet, otherwise we would not be hanging!
-*/
- spin_lock(&ve->base.active.lock);
- GEM_BUG_ON(intel_context_inflight(rq->context) != engine);
- GEM_BUG_ON(ve->request != rq);
- ve->request = NULL;
- spin_unlock(&ve->base.active.lock);
- i915_request_put(rq);
-
- rq->engine = engine;
- }
-
/*
* Transfer this request onto the hold queue to prevent it
* being resumbitted to HW (and potentially completed) before we have
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/33] drm/i915/gt: Harden the heartbeat against a stuck driver
If the driver get stuck holding the kernel timeline, we cannot issue a
heartbeat and so fail to discover that the driver is indeed stuck and do
not issue a GPU reset (which would hopefully unstick the driver!).
Switch to using a trylock so that we can query if the heartbeat's
timelin mutex is locked elsewhere, and then use the timer to probe if it
remains stuck at the same spot for consecutive heartbeats, indicating
that the mutex has not been released and the engine has not progressed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 --
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 8db7e93abde5..1663ab5c68a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -65,6 +65,7 @@ static void heartbeat(struct work_struct *wrk)
container_of(wrk, typeof(*engine), heartbeat.work.work);
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
+ unsigned long serial;
/* Just in case everything has gone horribly wrong, give it a kick */
intel_engine_flush_submission(engine);
@@ -122,10 +123,19 @@ static void heartbeat(struct work_struct *wrk)
goto out;
}
- if (engine->wakeref_serial == engine->serial)
+ serial = READ_ONCE(engine->serial);
+ if (engine->wakeref_serial == serial)
goto out;
- mutex_lock(&ce->timeline->mutex);
+ if (!mutex_trylock(&ce->timeline->mutex)) {
+ /* Unable to lock the kernel timeline, is the engine stuck? */
+ if (xchg(&engine->heartbeat.blocked, serial) == serial)
+ intel_gt_handle_error(engine->gt, engine->mask,
+ I915_ERROR_CAPTURE,
+ "stopped heartbeat on %s",
+ engine->name);
+ goto out;
+ }
intel_context_enter(ce);
rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 073c3769e8cc..490af81bd6f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -348,6 +348,7 @@ struct intel_engine_cs {
struct {
struct delayed_work work;
struct i915_request *systole;
+ unsigned long blocked;
} heartbeat;
unsigned long serial;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/33] drm/i915/gt: Check for a completed last request once
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 4eb397b0e14d..7bdbfac26d7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2137,12 +2137,11 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*/
if ((last = *active)) {
- if (need_preempt(engine, last, rb)) {
- if (i915_request_completed(last)) {
- tasklet_hi_schedule(&execlists->tasklet);
- return;
- }
+ if (i915_request_completed(last) &&
+ !list_is_last(&last->sched.link, &engine->active.requests))
+ return;
+ if (need_preempt(engine, last, rb)) {
ENGINE_TRACE(engine,
"preempting last=%llx:%lld, prio=%d,
hint=%d\n",
last->fence.context,
@@ -2170,11 +2169,6 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
last = NULL;
} else if (need_timeslice(engine, last, rb) &&
timeslice_expired(execlists, last)) {
- if (i915_request_completed(last)) {
- tasklet_hi_schedule(&execlists->tasklet);
- return;
- }
-
ENGINE_TRACE(engine,
"expired last=%llx:%lld, prio=%d, hint=%d,
yield?=%s\n",
last->fence.context,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/33] drm/i915/gt: Defer schedule_out until after the next dequeue
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it back in during dequeue. This is just extra work
that we can avoid if we keep the context marked as inflight across the
dequeue. This becomes more significant later on for minimising virtual
engine misses.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 111 --
2 files changed, 78 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 4954b0df4864..b63db45bab7b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -45,8 +45,8 @@ struct intel_context {
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
-#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 2)
-#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 2)
+#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 3)
+#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 3)
struct i915_address_space *vm;
struct i915_gem_context __rcu *gem_context;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e7eec78a2e55..1f4483c0bbdd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1385,6 +1385,8 @@ __execlists_schedule_in(struct i915_request *rq)
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
+ CE_TRACE(ce, "schedule-in, ccid:%x\n", ce->lrc.ccid);
+
return engine;
}
@@ -1428,6 +1430,8 @@ __execlists_schedule_out(struct i915_request *rq,
* refrain from doing non-trivial work here.
*/
+ CE_TRACE(ce, "schedule-out, ccid:%x\n", ccid);
+
/*
* If we have just completed this context, the engine may now be
* idle and we want to re-enter powersaving.
@@ -2075,11 +2079,6 @@ static void set_preempt_timeout(struct intel_engine_cs
*engine,
active_preempt_timeout(engine, rq));
}
-static inline void clear_ports(struct i915_request **ports, int count)
-{
- memset_p((void **)ports, NULL, count);
-}
-
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
@@ -2430,26 +2429,36 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
start_timeslice(engine, execlists->queue_priority_hint);
skip_submit:
ring_set_paused(engine, 0);
+ while (port-- != execlists->pending)
+ i915_request_put(*port);
*execlists->pending = NULL;
}
}
-static void
-cancel_port_requests(struct intel_engine_execlists * const execlists)
+static inline void clear_ports(struct i915_request **ports, int count)
+{
+ memset_p((void **)ports, NULL, count);
+}
+
+static struct i915_request **
+cancel_port_requests(struct intel_engine_execlists * const execlists,
+struct i915_request **inactive)
{
struct i915_request * const *port;
for (port = execlists->pending; *port; port++)
- execlists_schedule_out(*port);
+ *inactive++ = *port;
clear_ports(execlists->pending, ARRAY_SIZE(execlists->pending));
/* Mark the end of active before we overwrite *active */
for (port = xchg(&execlists->active, execlists->pending); *port; port++)
- execlists_schedule_out(*port);
+ *inactive++ = *port;
clear_ports(execlists->inflight, ARRAY_SIZE(execlists->inflight));
smp_wmb(); /* complete the seqlock for execlists_active() */
WRITE_ONCE(execlists->active, execlists->inflight);
+
+ return inactive;
}
static inline void
@@ -2521,7 +2530,8 @@ gen8_csb_parse(const struct intel_engine_execlists
*execlists, const u32 *csb)
return *csb & (GEN8_CTX_STATUS_IDLE_ACTIVE | GEN8_CTX_STATUS_PREEMPTED);
}
-static void process_csb(struct intel_engine_cs *engine)
+static struct i915_request **
+process_csb(struct intel_engine_cs *engine, struct i915_request **inactive)
{
struct intel_engine_execlists * const execlists = &engine->execlists;
const u32 * const buf = execlists->csb_status;
@@ -2550,7 +2560,7 @@ static void process_csb(struct intel_engine_cs *engine)
head = execlists->csb_head;
tail = READ_ONCE(*execlists->csb_write);
if (unlikely(head == tail))
- return;
+ return
[Intel-gfx] [PATCH 32/33] drm/i915/gt: Implement ring scheduler for gen6/7
A key prolem with legacy ring buffer submission is that it is an inheret
FIFO queue across all clients; if one blocks, they all block. A
scheduler allows us to avoid that limitation, and ensures that all
clients can submit in parallel, removing the resource contention of the
global ringbuffer.
Having built the ring scheduler infrastructure over top of the global
ringbuffer submission, we now need to provide the HW knowledge required
to build command packets and implement context switching.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_ring_scheduler.c| 423 +-
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 421 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
index 6b3c50e63bd9..1e4821109570 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
@@ -7,6 +7,10 @@
#include
+#include "gen2_engine_cs.h"
+#include "gen6_engine_cs.h"
+#include "gen6_ppgtt.h"
+#include "gen7_renderclear.h"
#include "i915_drv.h"
#include "intel_context.h"
#include "intel_engine_stats.h"
@@ -139,8 +143,258 @@ static void ring_copy(struct intel_ring *dst,
memcpy(out, src->vaddr + start, end - start);
}
+static void mi_set_context(struct intel_ring *ring,
+ struct intel_engine_cs *engine,
+ struct intel_context *ce,
+ u32 flags)
+{
+ struct drm_i915_private *i915 = engine->i915;
+ enum intel_engine_id id;
+ const int num_engines =
+ IS_HASWELL(i915) ? RUNTIME_INFO(i915)->num_engines - 1 : 0;
+ int len;
+ u32 *cs;
+
+ len = 4;
+ if (IS_GEN(i915, 7))
+ len += 2 + (num_engines ? 4 * num_engines + 6 : 0);
+ else if (IS_GEN(i915, 5))
+ len += 2;
+
+ cs = ring_map_dw(ring, len);
+
+ /* WaProgramMiArbOnOffAroundMiSetContext:ivb,vlv,hsw,bdw,chv */
+ if (IS_GEN(i915, 7)) {
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+ if (num_engines) {
+ struct intel_engine_cs *signaller;
+
+ *cs++ = MI_LOAD_REGISTER_IMM(num_engines);
+ for_each_engine(signaller, engine->gt, id) {
+ if (signaller == engine)
+ continue;
+
+ *cs++ = i915_mmio_reg_offset(
+ RING_PSMI_CTL(signaller->mmio_base));
+ *cs++ = _MASKED_BIT_ENABLE(
+ GEN6_PSMI_SLEEP_MSG_DISABLE);
+ }
+ }
+ } else if (IS_GEN(i915, 5)) {
+ /*
+* This w/a is only listed for pre-production ilk a/b steppings,
+* but is also mentioned for programming the powerctx. To be
+* safe, just apply the workaround; we do not use SyncFlush so
+* this should never take effect and so be a no-op!
+*/
+ *cs++ = MI_SUSPEND_FLUSH | MI_SUSPEND_FLUSH_EN;
+ }
+
+ *cs++ = MI_NOOP;
+ *cs++ = MI_SET_CONTEXT;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
+ /*
+* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
+* WaMiSetContext_Hang:snb,ivb,vlv
+*/
+ *cs++ = MI_NOOP;
+
+ if (IS_GEN(i915, 7)) {
+ if (num_engines) {
+ struct intel_engine_cs *signaller;
+ i915_reg_t last_reg = {}; /* keep gcc quiet */
+
+ *cs++ = MI_LOAD_REGISTER_IMM(num_engines);
+ for_each_engine(signaller, engine->gt, id) {
+ if (signaller == engine)
+ continue;
+
+ last_reg = RING_PSMI_CTL(signaller->mmio_base);
+ *cs++ = i915_mmio_reg_offset(last_reg);
+ *cs++ = _MASKED_BIT_DISABLE(
+ GEN6_PSMI_SLEEP_MSG_DISABLE);
+ }
+
+ /* Insert a delay before the next switch! */
+ *cs++ = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
+ *cs++ = i915_mmio_reg_offset(last_reg);
+ *cs++ = intel_gt_scratch_offset(engine->gt,
+
INTEL_GT_SCRATCH_FIELD_DEFAULT);
+ *cs++ = MI_NOOP;
+ }
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+ } else if (IS_GEN(i915, 5)) {
+ *cs++ = MI_SUSPEND_FLUSH;
+ }
+}
+
+static struct i915_address_space *vm_alias(struct i915_address_space *vm)
+{
+ if (i915_is_ggtt(vm))
+ vm = &i
[Intel-gfx] [PATCH 20/33] drm/i915: Teach the i915_dependency to use a double-lock
Currently, we construct and teardown the i915_dependency chains using a
global spinlock. As the lists are entirely local, it should be possible
to use an double-lock with an explicit nesting [signaler -> waiter,
always] and so avoid the costly convenience of a global spinlock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +--
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/i915_scheduler.c | 44 +
drivers/gpu/drm/i915/i915_scheduler.h | 2 +-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 94fd214c91c8..4bfbfafa94c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1852,7 +1852,7 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
- if (p->flags & I915_DEPENDENCY_WEAK)
+ if (!p->waiter || p->flags & I915_DEPENDENCY_WEAK)
continue;
/* Leave semaphores spinning on the other engines */
@@ -2697,7 +2697,7 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
- if (p->flags & I915_DEPENDENCY_WEAK)
+ if (!p->waiter || p->flags & I915_DEPENDENCY_WEAK)
continue;
/* Leave semaphores spinning on the other engines */
@@ -2795,7 +2795,7 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
- if (p->flags & I915_DEPENDENCY_WEAK)
+ if (!p->waiter || p->flags & I915_DEPENDENCY_WEAK)
continue;
/* Propagate any change in error status */
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 295c0c63039e..8a9399608cf2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -337,7 +337,7 @@ bool i915_request_retire(struct i915_request *rq)
intel_context_unpin(rq->context);
free_capture_list(rq);
- i915_sched_node_fini(&rq->sched);
+ i915_sched_node_retire(&rq->sched);
i915_request_put(rq);
return true;
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 9f744f470556..2e4d512e61d8 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -353,6 +353,8 @@ void i915_request_set_priority(struct i915_request *rq, int
prio)
void i915_sched_node_init(struct i915_sched_node *node)
{
+ spin_lock_init(&node->lock);
+
INIT_LIST_HEAD(&node->signalers_list);
INIT_LIST_HEAD(&node->waiters_list);
INIT_LIST_HEAD(&node->link);
@@ -390,7 +392,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
{
bool ret = false;
- spin_lock_irq(&schedule_lock);
+ /* The signal->lock is always the outer lock in this double-lock. */
+ spin_lock_irq(&signal->lock);
if (!node_signaled(signal)) {
INIT_LIST_HEAD(&dep->dfs_link);
@@ -399,15 +402,17 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
dep->flags = flags;
/* All set, now publish. Beware the lockless walkers. */
+ spin_lock_nested(&node->lock, SINGLE_DEPTH_NESTING);
list_add_rcu(&dep->signal_link, &node->signalers_list);
list_add_rcu(&dep->wait_link, &signal->waiters_list);
+ spin_unlock(&node->lock);
/* Propagate the chains */
node->flags |= signal->flags;
ret = true;
}
- spin_unlock_irq(&schedule_lock);
+ spin_unlock_irq(&signal->lock);
return ret;
}
@@ -433,39 +438,46 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
return 0;
}
-void i915_sched_node_fini(struct i915_sched_node *node)
+void i915_sched_node_retire(struct i915_sched_node *node)
{
struct i915_dependency *dep, *tmp;
- spin_lock_irq(&schedule_lock);
+ spin_lock_irq(&node->lock);
/*
* Everyone we depended upon (the fences we wait to be signaled)
* should retire before us and remove themselves from our list.
* However, retirement is run independently on each timeline and
-* so we may be called out-of-order.
+* so we may be ca
[Intel-gfx] [PATCH 13/33] drm/i915/gt: Extract busy-stats for ring-scheduler
Lift the busy-stats context-in/out implementation out of intel_lrc, so
that we can reuse it for other scheduler implementations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 49
drivers/gpu/drm/i915/gt/intel_lrc.c | 34 +-
2 files changed, 50 insertions(+), 33 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_stats.h
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
new file mode 100644
index ..58491eae3482
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __INTEL_ENGINE_STATS_H__
+#define __INTEL_ENGINE_STATS_H__
+
+#include
+#include
+#include
+
+#include "i915_gem.h" /* GEM_BUG_ON */
+#include "intel_engine.h"
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ if (atomic_add_unless(&engine->stats.active, 1, 0))
+ return;
+
+ write_seqlock_irqsave(&engine->stats.lock, flags);
+ if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
+ engine->stats.start = ktime_get();
+ atomic_inc(&engine->stats.active);
+ }
+ write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+ unsigned long flags;
+
+ GEM_BUG_ON(!atomic_read(&engine->stats.active));
+
+ if (atomic_add_unless(&engine->stats.active, -1, 1))
+ return;
+
+ write_seqlock_irqsave(&engine->stats.lock, flags);
+ if (atomic_dec_and_test(&engine->stats.active)) {
+ engine->stats.total =
+ ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+ }
+ write_sequnlock_irqrestore(&engine->stats.lock, flags);
+}
+
+#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 61c27733debc..c0f3db52bd5a 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -139,6 +139,7 @@
#include "i915_vgpu.h"
#include "intel_context.h"
#include "intel_engine_pm.h"
+#include "intel_engine_stats.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -1164,39 +1165,6 @@ execlists_context_status_change(struct i915_request *rq,
unsigned long status)
status, rq);
}
-static void intel_engine_context_in(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- if (atomic_add_unless(&engine->stats.active, 1, 0))
- return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
- engine->stats.start = ktime_get();
- atomic_inc(&engine->stats.active);
- }
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
-static void intel_engine_context_out(struct intel_engine_cs *engine)
-{
- unsigned long flags;
-
- GEM_BUG_ON(!atomic_read(&engine->stats.active));
-
- if (atomic_add_unless(&engine->stats.active, -1, 1))
- return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (atomic_dec_and_test(&engine->stats.active)) {
- engine->stats.total =
- ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
- }
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
-}
-
static void
execlists_check_context(const struct intel_context *ce,
const struct intel_engine_cs *engine)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/33] drm/i915/gt: Move the heartbeat into the highprio system wq
As we ensure that the heartbeat is reasonably fast (and should not block), move the heartbeat work into the system_highprio_wq to avoid having this essential task be blocked behind other slow work, such as our own retire_work_handler. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2119 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c index 1663ab5c68a5..3699fa8a79e8 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c @@ -32,7 +32,7 @@ static bool next_heartbeat(struct intel_engine_cs *engine) delay = msecs_to_jiffies_timeout(delay); if (delay >= HZ) delay = round_jiffies_up_relative(delay); - mod_delayed_work(system_wq, &engine->heartbeat.work, delay); + mod_delayed_work(system_highpri_wq, &engine->heartbeat.work, delay); return true; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/33] drm/i915/gt: Remove timeslice suppression
In the next patch, we remove the strict priority system and continuously
re-evaluate the relative priority of tasks. As such we need to enable
the timeslice whenever there is more than one context in the pipeline.
This simplifies the decision and removes some of the tweaks to suppress
timeslicing, allowing us to lift the timeslice enabling to a common spot
at the end of running the submission tasklet.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 161 ++-
2 files changed, 53 insertions(+), 118 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index c371961d09e0..756e4e13a1b5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -231,16 +231,6 @@ struct intel_engine_execlists {
*/
unsigned int port_mask;
- /**
-* @switch_priority_hint: Second context priority.
-*
-* We submit multiple contexts to the HW simultaneously and would
-* like to occasionally switch between them to emulate timeslicing.
-* To know when timeslicing is suitable, we track the priority of
-* the context submitted second.
-*/
- int switch_priority_hint;
-
/**
* @queue_priority_hint: Highest pending priority.
*
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 4bfbfafa94c7..43fafaf27cf6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1890,40 +1890,6 @@ static void defer_active(struct intel_engine_cs *engine)
defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
}
-static bool
-need_timeslice(const struct intel_engine_cs *engine,
- const struct i915_request *rq,
- const struct virtual_engine *ve)
-{
- int hint;
-
- if (!intel_engine_has_timeslices(engine))
- return false;
-
- hint = engine->execlists.queue_priority_hint;
-
- if (ve) {
- const struct intel_engine_cs *inflight =
- intel_context_inflight(&ve->context);
-
- if (!inflight || inflight == engine) {
- struct i915_request *next;
-
- rcu_read_lock();
- next = READ_ONCE(ve->request);
- if (next)
- hint = max(hint, rq_prio(next));
- rcu_read_unlock();
- }
- }
-
- if (!list_is_last(&rq->sched.link, &engine->active.requests))
- hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
-
- GEM_BUG_ON(hint >= I915_PRIORITY_UNPREEMPTABLE);
- return hint >= effective_prio(rq);
-}
-
static bool
timeslice_yield(const struct intel_engine_execlists *el,
const struct i915_request *rq)
@@ -1943,76 +1909,64 @@ timeslice_yield(const struct intel_engine_execlists *el,
return rq->context->lrc.ccid == READ_ONCE(el->yield);
}
-static bool
-timeslice_expired(const struct intel_engine_execlists *el,
- const struct i915_request *rq)
+static bool needs_timeslice(const struct intel_engine_cs *engine,
+ const struct i915_request *rq)
{
- return timer_expired(&el->timer) || timeslice_yield(el, rq);
-}
+ /* If not currently active, or about to switch, wait for next event */
+ if (!rq || i915_request_completed(rq))
+ return false;
-static int
-switch_prio(struct intel_engine_cs *engine, const struct i915_request *rq)
-{
- if (list_is_last(&rq->sched.link, &engine->active.requests))
- return engine->execlists.queue_priority_hint;
+ /* We do not need to start the timeslice until after the ACK */
+ if (READ_ONCE(engine->execlists.pending[0]))
+ return false;
- return rq_prio(list_next_entry(rq, sched.link));
-}
+ /* If ELSP[1] is occupied, always check to see if worth slicing */
+ if (!list_is_last(&rq->sched.link, &engine->active.requests))
+ return true;
-static inline unsigned long
-timeslice(const struct intel_engine_cs *engine)
-{
- return READ_ONCE(engine->props.timeslice_duration_ms);
+ /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
+ if (rb_first_cached(&engine->execlists.queue))
+ return true;
+
+ return rb_first_cached(&engine->execlists.virtual);
}
-static unsigned long active_timeslice(const struct intel_engine_cs *engine)
+static bool
+timeslice_expired(struct intel_engine_cs *engine, const struct i915_request
*rq)
{
- const struct intel_engine_execlists *execlists = &engine->execlists;
- const struct i915_request *rq = *execlists->active;
+ const struct intel_engine_execlists
[Intel-gfx] [PATCH 09/33] drm/i915/gt: Resubmit the virtual engine on schedule-out
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
By keeping the unwind order intact on the local engine, we can preserve
data dependency ordering while doing a preempt-to-busy pass until we
have determined the new ELSP. This means that if we try to timeslice
between a virtual engine and a data-dependent ordinary request, the pair
will maintain their relative ordering and we will avoid the
resubmission, cancelling the timeslicing until further change.
The dilemma though is that we then may end up in a situation where the
'demotion' of the virtual request to an ordinary request in the engine
queue results in filling the ELSP[] with virtual requests instead of
spreading the load across the engines. To compensate for this, we mark
each virtual request and refuse to resubmit a virtual request in the
secondary ELSP slots, thus forcing subsequent virtual requests to be
scheduled out after timeslicing. By delaying the decision until we
schedule out, we will avoid unnecessary resubmission.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 118 -
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
2 files changed, 75 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1f4483c0bbdd..f4323d407a9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1119,53 +1119,23 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
__i915_request_unsubmit(rq);
- /*
-* Push the request back into the queue for later resubmission.
-* If this request is not native to this physical engine (i.e.
-* it came from a virtual source), push it back onto the virtual
-* engine so that it can be moved across onto another physical
-* engine as load dictates.
-*/
- if (likely(rq->execution_mask == engine->mask)) {
- GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
- if (rq_prio(rq) != prio) {
- prio = rq_prio(rq);
- pl = i915_sched_lookup_priolist(engine, prio);
- }
-
GEM_BUG_ON(RB_EMPTY_ROOT(&engine->execlists.queue.rb_root));
-
- list_move(&rq->sched.link, pl);
- set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
+ GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
+ if (rq_prio(rq) != prio) {
+ prio = rq_prio(rq);
+ pl = i915_sched_lookup_priolist(engine, prio);
+ }
+ GEM_BUG_ON(RB_EMPTY_ROOT(&engine->execlists.queue.rb_root));
- /* Check in case we rollback so far we wrap [size/2] */
- if (intel_ring_direction(rq->ring,
-intel_ring_wrap(rq->ring,
-rq->tail),
-rq->ring->tail) > 0)
- rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
+ list_move(&rq->sched.link, pl);
+ set_bit(I915_FENCE_FLAG_PQUEUE, &rq->fence.flags);
- active = rq;
- } else {
- struct intel_engine_cs *owner = rq->context->engine;
+ /* Check in case we rollback so far we wrap [size/2] */
+ if (intel_ring_direction(rq->ring,
+intel_ring_wrap(rq->ring, rq->tail),
+rq->ring->tail) > 0)
+ rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
- /*
-* Decouple the virtual breadcrumb before moving it
-* back to the virtual engine -- we don't want the
-* request to complete in the background and try
-* and cancel the breadcrumb on the virtual engine
-* (instead of the old engine where it is linked)!
-*/
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
-&rq->fence.flags)) {
- spin_lock_nested(&rq->lock,
-SINGLE_DEPTH_NESTING);
- i915_request_cancel_breadcrumb(rq);
- spin_unlock(&rq->lock);
- }
- WRITE_ONCE(rq->engine, owner);
- owner->submit_re
[Intel-gfx] [PATCH 06/33] drm/i915/gt: Use virtual_engine during execlists_dequeue
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtual engine lookup, for typical use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 209 ++--
1 file changed, 101 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 358b0b801d7c..e0b9a1f9eedf 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -454,7 +454,7 @@ static int queue_prio(const struct intel_engine_execlists
*execlists)
static inline bool need_preempt(const struct intel_engine_cs *engine,
const struct i915_request *rq,
- struct rb_node *rb)
+ const struct virtual_engine *ve)
{
int last_prio;
@@ -491,9 +491,7 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
rq_prio(list_next_entry(rq, sched.link)) > last_prio)
return true;
- if (rb) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ if (ve) {
bool preempt = false;
if (engine == ve->siblings[0]) { /* only preempt one sibling */
@@ -1819,6 +1817,35 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
+static struct virtual_engine *
+first_virtual_engine(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *el = &engine->execlists;
+ struct rb_node *rb = rb_first_cached(&el->virtual);
+
+ while (rb) {
+ struct virtual_engine *ve =
+ rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ struct i915_request *rq = READ_ONCE(ve->request);
+
+ if (!rq) { /* lazily cleanup after another engine handled rq */
+ rb_erase_cached(rb, &el->virtual);
+ RB_CLEAR_NODE(rb);
+ rb = rb_first_cached(&el->virtual);
+ continue;
+ }
+
+ if (!virtual_matches(ve, rq, engine)) {
+ rb = rb_next(rb);
+ continue;
+ }
+
+ return ve;
+ }
+
+ return NULL;
+}
+
static void virtual_xfer_breadcrumbs(struct virtual_engine *ve)
{
/*
@@ -1903,7 +1930,7 @@ static void defer_active(struct intel_engine_cs *engine)
static bool
need_timeslice(const struct intel_engine_cs *engine,
const struct i915_request *rq,
- const struct rb_node *rb)
+ const struct virtual_engine *ve)
{
int hint;
@@ -1912,9 +1939,7 @@ need_timeslice(const struct intel_engine_cs *engine,
hint = engine->execlists.queue_priority_hint;
- if (rb) {
- const struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ if (ve) {
const struct intel_engine_cs *inflight =
intel_context_inflight(&ve->context);
@@ -2066,6 +2091,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
struct i915_request **port = execlists->pending;
struct i915_request ** const last_port = port + execlists->port_mask;
struct i915_request * const *active = execlists->active;
+ struct virtual_engine *ve;
struct i915_request *last;
unsigned long flags;
struct rb_node *rb;
@@ -2093,26 +2119,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* and context switches) submission.
*/
spin_lock_irqsave(&engine->active.lock, flags);
-
- for (rb = rb_first_cached(&execlists->virtual); rb; ) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
- struct i915_request *rq = READ_ONCE(ve->request);
-
- if (!rq) { /* lazily cleanup after another engine handled rq */
- rb_erase_cached(rb, &execlists->virtual);
- RB_CLEAR_NODE(rb);
- rb = rb_first_cached(&execlists->virtual);
- continue;
- }
-
- if (!virtual_matches(ve, rq, engine)) {
- rb = rb_next(rb);
- continue;
- }
-
- break;
- }
+ ve = first_virtual_engine(engine);
/*
* If the queue is higher priority than the last
@@ -2140,7 +2147,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
return;
}
-
[Intel-gfx] [PATCH 14/33] drm/i915/gt: Convert stats.active to plain unsigned int
As context-in/out is now always serialised, we do not have to worry
about concurrent enabling/disable of the busy-stats and can reduce the
atomic_t active to a plain unsigned int, and the seqlock to a seqcount.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8 ++--
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 45
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 +-
3 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d58e5e251ff3..06a65b280111 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -338,7 +338,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->schedule = NULL;
ewma__engine_latency_init(&engine->latency);
- seqlock_init(&engine->stats.lock);
+ seqcount_init(&engine->stats.lock);
ATOMIC_INIT_NOTIFIER_HEAD(&engine->context_status_notifier);
@@ -1617,7 +1617,7 @@ static ktime_t __intel_engine_get_busy_time(struct
intel_engine_cs *engine,
* add it to the total.
*/
*now = ktime_get();
- if (atomic_read(&engine->stats.active))
+ if (READ_ONCE(engine->stats.active))
total = ktime_add(total, ktime_sub(*now, engine->stats.start));
return total;
@@ -1636,9 +1636,9 @@ ktime_t intel_engine_get_busy_time(struct intel_engine_cs
*engine, ktime_t *now)
ktime_t total;
do {
- seq = read_seqbegin(&engine->stats.lock);
+ seq = read_seqcount_begin(&engine->stats.lock);
total = __intel_engine_get_busy_time(engine, now);
- } while (read_seqretry(&engine->stats.lock, seq));
+ } while (read_seqcount_retry(&engine->stats.lock, seq));
return total;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
index 58491eae3482..24fbdd94351a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_stats.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_stats.h
@@ -17,33 +17,44 @@ static inline void intel_engine_context_in(struct
intel_engine_cs *engine)
{
unsigned long flags;
- if (atomic_add_unless(&engine->stats.active, 1, 0))
+ if (engine->stats.active) {
+ engine->stats.active++;
return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (!atomic_add_unless(&engine->stats.active, 1, 0)) {
- engine->stats.start = ktime_get();
- atomic_inc(&engine->stats.active);
}
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
+
+ /* The writer is serialised; but the pmu reader may be from hardirq */
+ local_irq_save(flags);
+ write_seqcount_begin(&engine->stats.lock);
+
+ engine->stats.start = ktime_get();
+ engine->stats.active++;
+
+ write_seqcount_end(&engine->stats.lock);
+ local_irq_restore(flags);
+
+ GEM_BUG_ON(!engine->stats.active);
}
static inline void intel_engine_context_out(struct intel_engine_cs *engine)
{
unsigned long flags;
- GEM_BUG_ON(!atomic_read(&engine->stats.active));
-
- if (atomic_add_unless(&engine->stats.active, -1, 1))
+ GEM_BUG_ON(!engine->stats.active);
+ if (engine->stats.active > 1) {
+ engine->stats.active--;
return;
-
- write_seqlock_irqsave(&engine->stats.lock, flags);
- if (atomic_dec_and_test(&engine->stats.active)) {
- engine->stats.total =
- ktime_add(engine->stats.total,
- ktime_sub(ktime_get(), engine->stats.start));
}
- write_sequnlock_irqrestore(&engine->stats.lock, flags);
+
+ local_irq_save(flags);
+ write_seqcount_begin(&engine->stats.lock);
+
+ engine->stats.active--;
+ engine->stats.total =
+ ktime_add(engine->stats.total,
+ ktime_sub(ktime_get(), engine->stats.start));
+
+ write_seqcount_end(&engine->stats.lock);
+ local_irq_restore(flags);
}
#endif /* __INTEL_ENGINE_STATS_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index b8d8973e6f97..242b6bbd7fe3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -545,12 +545,12 @@ struct intel_engine_cs {
/**
* @active: Number of contexts currently scheduled in.
*/
- atomic_t active;
+ unsigned int active;
/**
* @lock: Lock protecting the below fields.
*/
- seqlock_t lock;
+ seqcount_t lock;
/**
* @total: Total time this engine was busy.
--
2.20.1
[Intel-gfx] [PATCH 23/33] drm/i915: Fair low-latency scheduling
The first "scheduler" was a topographical sorting of requests into priority order. The execution order was deterministic, the earliest submitted, highest priority request would be executed first. Priority inherited ensured that inversions were kept at bay, and allowed us to dynamically boost priorities (e.g. for interactive pageflips). The minimalistic timeslicing scheme was an attempt to introduce fairness between long running requests, by evicting the active request at the end of a timeslice and moving it to the back of its priority queue (while ensuring that dependencies were kept in order). For short running requests from many clients of equal priority, the scheme is still very much FIFO submission ordering, and as unfair as before. To impose fairness, we need an external metric that ensures that clients are interpersed, we don't execute one long chain from client A before executing any of client B. This could be imposed by the clients by using a fences based on an external clock, that is they only submit work for a "frame" at frame-interval, instead of submitting as much work as they are able to. The standard SwapBuffers approach is akin to double bufferring, where as one frame is being executed, the next is being submitted, such that there is always a maximum of two frames per client in the pipeline. Even this scheme exhibits unfairness under load as a single client will execute two frames back to back before the next, and with enough clients, deadlines will be missed. The idea introduced by BFS/MuQSS is that fairness is introduced by metering with an external clock. Every request, when it becomes ready to execute is assigned a virtual deadline, and execution order is then determined by earliest deadline. Priority is used as a hint, rather than strict ordering, where high priority requests have earlier deadlines, but not necessarily earlier than outstanding work. Thus work is executed in order of 'readiness', with timeslicing to demote long running work. The Achille's heel of this scheduler is its strong preference for low-latency and favouring of new queues. Whereas it was easy to dominate the old scheduler by flooding it with many requests over a short period of time, the new scheduler can be dominated by a 'synchronous' client that waits for each of its requests to complete before submitting the next. As such a client has no history, it is always considered ready-to-run and receives an earlier deadline than the long running requests. To check the impact on throughput (often the downfall of latency sensitive schedulers), we used gem_wsim to simulate various transcode workloads with different load balancers, and varying the number of competing [heterogenous] clients. +mB+ | a | | cda | | c.a | | ..aa | | ..---. | | -.--+-.| |.c.-.-+++. b | | bbb.d-c-+--+++.aab aab b | |b b b b b. b ..---+++-+a. b. b b b bb b| 1 A| | 2 |___AM| | 3|A__| | 4|MA_| | +--+ Clients Min Max Median AvgStddev 1 -8.20 5.4 -0.045 -0.02375 0.094722134 2 -15.96 19.28 -0.64 -1.05 2.2428076 4 -5.11 2.95 -1.15-1.0680.72382651 8 -5.63 1.85 -0.905 -0.871224490.73390971 The impact was on average 1% under contention due to the change in context execution order and number of context switches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 - drivers/gpu/drm/i915/gt/intel_lrc.c | 204 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 5 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 41 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 +- drivers/gpu/drm/i915/i915_priolist_types.h| 7 +- drivers/gpu/drm/i915/i915_request.c | 1 + drivers/gpu/drm/i915/i915_scheduler.c | 349 +- drivers/gpu/drm/i915/i915_scheduler.h | 24 +- drivers/
[Intel-gfx] [CI] drm/i915/gem: Move obj->lut_list under its own lock
The obj->lut_list is traversed when the object is closed as the file
table is destroyed during process termination. As this occurs before we
kill any outstanding context if, due to some bug or another, the closure
is blocked, then we fail to shootdown any inflight operations
potentially leaving the GPU spinning forever. As we only need to guard
the list against concurrent closures and insertions, the hold is short
and merits being treated as a simple spinlock.
Signed-off-by: Chris Wilson
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_object.c| 21 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
4 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5c13809dc3c8..6675447a47b9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -112,8 +112,7 @@ static void lut_close(struct i915_gem_context *ctx)
if (!kref_get_unless_zero(&obj->base.refcount))
continue;
- rcu_read_unlock();
- i915_gem_object_lock(obj);
+ spin_lock(&obj->lut_lock);
list_for_each_entry(lut, &obj->lut_list, obj_link) {
if (lut->ctx != ctx)
continue;
@@ -124,8 +123,7 @@ static void lut_close(struct i915_gem_context *ctx)
list_del(&lut->obj_link);
break;
}
- i915_gem_object_unlock(obj);
- rcu_read_lock();
+ spin_unlock(&obj->lut_lock);
if (&lut->obj_link != &obj->lut_list) {
i915_lut_handle_free(lut);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c38ab51e82f0..b4862afaaf28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -789,14 +789,14 @@ static int __eb_add_lut(struct i915_execbuffer *eb,
if (err == 0) { /* And nor has this handle */
struct drm_i915_gem_object *obj = vma->obj;
- i915_gem_object_lock(obj);
+ spin_lock(&obj->lut_lock);
if (idr_find(&eb->file->object_idr, handle) == obj) {
list_add(&lut->obj_link, &obj->lut_list);
} else {
radix_tree_delete(&ctx->handles_vma, handle);
err = -ENOENT;
}
- i915_gem_object_unlock(obj);
+ spin_unlock(&obj->lut_lock);
}
mutex_unlock(&ctx->mutex);
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index b6ec5b50d93b..6b69191c5543 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -61,6 +61,7 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
INIT_LIST_HEAD(&obj->mm.link);
INIT_LIST_HEAD(&obj->lut_list);
+ spin_lock_init(&obj->lut_lock);
spin_lock_init(&obj->mmo.lock);
obj->mmo.offsets = RB_ROOT;
@@ -104,21 +105,29 @@ void i915_gem_close_object(struct drm_gem_object *gem,
struct drm_file *file)
{
struct drm_i915_gem_object *obj = to_intel_bo(gem);
struct drm_i915_file_private *fpriv = file->driver_priv;
+ struct i915_lut_handle bookmark = {};
struct i915_mmap_offset *mmo, *mn;
struct i915_lut_handle *lut, *ln;
LIST_HEAD(close);
- i915_gem_object_lock(obj);
+ spin_lock(&obj->lut_lock);
list_for_each_entry_safe(lut, ln, &obj->lut_list, obj_link) {
struct i915_gem_context *ctx = lut->ctx;
- if (ctx->file_priv != fpriv)
- continue;
+ if (ctx && ctx->file_priv == fpriv) {
+ i915_gem_context_get(ctx);
+ list_move(&lut->obj_link, &close);
+ }
- i915_gem_context_get(ctx);
- list_move(&lut->obj_link, &close);
+ /* Break long locks, and carefully continue on from this spot */
+ if (&ln->obj_link != &obj->lut_list) {
+ list_add_tail(&bookmark.obj_link, &ln->obj_link);
+ if (cond_resched_lock(&obj->lut_lock))
+ list_safe_reset_next(&bookmark, ln, obj_link);
+ __list_del_entry(&bookmark.obj_link);
+ }
}
- i915_gem_object_unlock(obj);
+ spin_unlock(&obj->lut_lock);
spin_lock(&obj->
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [1/2] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/78986/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2185948b6b7c drm/i915/gt: Harden the heartbeat against a stuck driver -:43: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using 'heartbeat', this function's name, in a string #43: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:135: + "stopped heartbeat on %s", total: 0 errors, 1 warnings, 0 checks, 35 lines checked 3bc799bb6c5d drm/i915/gt: Move the heartbeat into the highprio system wq ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [1/2] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/78986/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2269:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2270:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2273:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux
[Intel-gfx] [PATCH] drm/i915/gt: Harden the heartbeat against a stuck driver
If the driver gets stuck holding the kernel timeline, we cannot issue a
heartbeat and so fail to discover that the driver is indeed stuck and do
not issue a GPU reset (which would hopefully unstick the driver!).
Switch to using a trylock so that we can query if the heartbeat's
timeline mutex is locked elsewhere, and then use the timer to probe if it
remains stuck at the same spot for consecutive heartbeats, indicating
that the mutex has not been released and the engine has not progressed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 --
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 8db7e93abde5..1c6c6692dd17 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -65,6 +65,7 @@ static void heartbeat(struct work_struct *wrk)
container_of(wrk, typeof(*engine), heartbeat.work.work);
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
+ unsigned long serial;
/* Just in case everything has gone horribly wrong, give it a kick */
intel_engine_flush_submission(engine);
@@ -122,10 +123,19 @@ static void heartbeat(struct work_struct *wrk)
goto out;
}
- if (engine->wakeref_serial == engine->serial)
+ serial = READ_ONCE(engine->serial);
+ if (engine->wakeref_serial == serial)
goto out;
- mutex_lock(&ce->timeline->mutex);
+ if (!mutex_trylock(&ce->timeline->mutex)) {
+ /* Unable to lock the kernel timeline, is the engine stuck? */
+ if (xchg(&engine->heartbeat.blocked, serial) == serial)
+ intel_gt_handle_error(engine->gt, engine->mask,
+ I915_ERROR_CAPTURE,
+ "no heartbeat on %s",
+ engine->name);
+ goto out;
+ }
intel_context_enter(ce);
rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 073c3769e8cc..490af81bd6f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -348,6 +348,7 @@ struct intel_engine_cs {
struct {
struct delayed_work work;
struct i915_request *systole;
+ unsigned long blocked;
} heartbeat;
unsigned long serial;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Harden the heartbeat against a
stuck driver
URL : https://patchwork.freedesktop.org/series/78986/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8682 -> Patchwork_18053
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/index.html
Known issues
Here are the changes found in Patchwork_18053 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@i915_module_load@reload:
- fi-tgl-u2: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-tgl-u2/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-bsw-kefka/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-bsw-kefka/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][11] ([i915#402]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#1982] / [i915#62] / [i915#92]
/ [i915#95]) -> [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [FAIL][17] ([i915#579]) -> [SKIP][18] ([fdo#109271])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62]) -> [SKIP][20]
([fdo#109271])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8682/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18053/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freed
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/33] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details ==
Series: series starting with [01/33] drm/i915/gt: Harden the heartbeat against
a stuck driver
URL : https://patchwork.freedesktop.org/series/78987/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d499941ea4dc drm/i915/gt: Harden the heartbeat against a stuck driver
-:43: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using
'heartbeat', this function's name, in a string
#43: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:135:
+ "stopped heartbeat on %s",
total: 0 errors, 1 warnings, 0 checks, 35 lines checked
6005d22404ee drm/i915/gt: Move the heartbeat into the highprio system wq
a88b1324c0e4 drm/i915/gt: Decouple completed requests on unwind
6df6651ce794 drm/i915/gt: Check for a completed last request once
8a484e67419b drm/i915/gt: Replace direct submit with direct call to tasklet
b807a1aa2cc6 drm/i915/gt: Use virtual_engine during execlists_dequeue
e0d8e53384b4 drm/i915/gt: Decouple inflight virtual engines
07c202c5b553 drm/i915/gt: Defer schedule_out until after the next dequeue
77abad2cc860 drm/i915/gt: Resubmit the virtual engine on schedule-out
c20604000873 drm/i915/gt: Simplify virtual engine handling for execlists_hold()
1d3df5a15c70 drm/i915/gt: ce->inflight updates are now serialised
9a511c705c10 drm/i915/gt: Drop atomic for engine->fw_active tracking
7d0425bc6864 drm/i915/gt: Extract busy-stats for ring-scheduler
-:12: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#12:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 95 lines checked
851c723d19be drm/i915/gt: Convert stats.active to plain unsigned int
ac29cc857205 drm/i915: Lift waiter/signaler iterators
796fb1aa036a drm/i915: Strip out internal priorities
284c4ee82fb5 drm/i915: Remove I915_USER_PRIORITY_SHIFT
67f4f4fadb82 drm/i915: Replace engine->schedule() with a known request operation
5f0a0dc1333b drm/i915/gt: Do not suspend bonded requests if one hangs
7d61bb0dd5d2 drm/i915: Teach the i915_dependency to use a double-lock
a1a69cab81f5 drm/i915: Restructure priority inheritance
d7403349647f drm/i915/gt: Remove timeslice suppression
2569e0b593e7 drm/i915: Fair low-latency scheduling
-:1548: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#1548:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 1371 lines checked
675054b4e9d9 drm/i915/gt: Specify a deadline for the heartbeat
cf6941683a97 drm/i915: Replace the priority boosting for the display with a
deadline
5af3de0375a1 drm/i915: Move saturated workload detection to the GT
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#22:
References: 44d89409a12e ("drm/i915: Make the semaphore saturation mask global")
-:22: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 44d89409a12e ("drm/i915: Make
the semaphore saturation mask global")'
#22:
References: 44d89409a12e ("drm/i915: Make the semaphore saturation mask global")
total: 1 errors, 1 warnings, 0 checks, 82 lines checked
5021faa7f115 Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq"
7bfc5312e63e drm/i915/gt: Couple tasklet scheduling for all CS interrupts
2dca796d3efe drm/i915/gt: Support creation of 'internal' rings
988103172126 drm/i915/gt: Use client timeline address for seqno writes
8071d6c00487 drm/i915/gt: Infrastructure for ring scheduling
-:79: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#79:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 818 lines checked
86f134b795e6 drm/i915/gt: Implement ring scheduler for gen6/7
-:68: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#68: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:177:
+ *cs++ = i915_mmio_reg_offset(
-:70: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#70: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:179:
+ *cs++ = _MASKED_BIT_ENABLE(
-:105: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#105: FILE: drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:214:
+ *cs++ = _MASKED_BIT_DISABLE(
total: 0 errors, 0 warnings, 3 checks, 536 lines checked
06d3b687d37c drm/i915/gt: Enable ring scheduling for gen6/7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/33] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [01/33] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/78987/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gt/intel_reset.c:1326:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: co
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/33] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details ==
Series: series starting with [01/33] drm/i915/gt: Harden the heartbeat against
a stuck driver
URL : https://patchwork.freedesktop.org/series/78987/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8683 -> Patchwork_18054
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/index.html
Known issues
Here are the changes found in Patchwork_18054 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][1] -> [DMESG-WARN][2] ([i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-icl-y: [PASS][5] -> [DMESG-FAIL][6] ([i915#656])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-icl-y/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-icl-y/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] /
[i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][11] ([i915#1888]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [SKIP][15] ([fdo#109271]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][21] ([i915#402]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#1982] / [i915#62] / [i915#92]
/ [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/tgl: Implement WA 18011464164
== Series Details == Series: series starting with [v2,1/2] drm/i915/tgl: Implement WA 18011464164 URL : https://patchwork.freedesktop.org/series/78965/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8680_full -> Patchwork_18051_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18051_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18051_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_18051_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-iclb3/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-iclb1/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_18051_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-kbl2/igt@gem_ctx_isolation@preservation...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-kbl1/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-glk9/igt@gem_exec_whis...@basic-contexts-forked.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-glk4/igt@gem_exec_whis...@basic-contexts-forked.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-tglb3/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-tglb6/igt@i915_module_l...@reload.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +11 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-skl2/igt@kms_co...@pipe-c-ctm-0-25.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-skl5/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#95]) +15 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#72]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_flip@2x-plain-flip-ts-check@ab-vga1-hdmi-a1: - shard-hsw: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-hsw1/igt@kms_flip@2x-plain-flip-ts-ch...@ab-vga1-hdmi-a1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-hsw6/igt@kms_flip@2x-plain-flip-ts-ch...@ab-vga1-hdmi-a1.html * igt@kms_flip@flip-vs-expired-vblank@c-edp1: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/shard-skl4/igt@kms_flip@flip-vs-expired-vbl...@c-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@b-hdmi-a1: - shard-hsw: [PASS][21] -> [INCOMPLETE][22] ([i915#2055]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8680/shard-hsw7/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18051/s
[Intel-gfx] [PATCH] drm/i915/dmc: Use firmware v2.02 for RKL
The latest firmware contains fix for PSR2 power saving. Cc: Matt Roper Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_csr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_csr.c b/drivers/gpu/drm/i915/display/intel_csr.c index f22a7645c249..7e8b11aa6a8a 100644 --- a/drivers/gpu/drm/i915/display/intel_csr.c +++ b/drivers/gpu/drm/i915/display/intel_csr.c @@ -40,8 +40,8 @@ #define GEN12_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE -#define RKL_CSR_PATH "i915/rkl_dmc_ver2_01.bin" -#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 1) +#define RKL_CSR_PATH "i915/rkl_dmc_ver2_02.bin" +#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 2) MODULE_FIRMWARE(RKL_CSR_PATH); #define TGL_CSR_PATH "i915/tgl_dmc_ver2_06.bin" -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Move obj->lut_list under its own lock
== Series Details == Series: drm/i915/gem: Move obj->lut_list under its own lock URL : https://patchwork.freedesktop.org/series/78988/ State : success == Summary == CI Bug Log - changes from CI_DRM_8684 -> Patchwork_18055 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/index.html Known issues Here are the changes found in Patchwork_18055 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-byt-n2820: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-byt-n2820/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-byt-n2820/igt@i915_module_l...@reload.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-tgl-u2: [INCOMPLETE][7] -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-tgl-u2/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-tgl-u2/igt@i915_selftest@l...@execlists.html - fi-icl-y: [INCOMPLETE][9] ([i915#1684]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-icl-y/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][14] ([i915#62] / [i915#92]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) -> [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/fi-kbl-x1275/igt@kms_pipe_crc_ba...@read-crc-pipe-a.html [i915#1684]: https://gitlab.freedesktop.org/drm/intel/issues/1684 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (44 -> 38) -- Additional (1): fi-tgl-y Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8684 -> Patchwork_18055 CI-20190529: 20190529 CI_DRM_8684: 68dfde01d77a76e98108fd0d00325c9340e475d9 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5718: af1ef32bfae90bcdbaf1b5d84c61ff4e04368505 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18055: a4e38133ec25b9067178ffe98d2d856599290a62 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a4e38133ec25 drm/i915/gem: Move obj->lut_list under its own lock == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/i915/gt: Harden the heartbeat against a stuck driver (rev2)
== Series Details == Series: series starting with drm/i915/gt: Harden the heartbeat against a stuck driver (rev2) URL : https://patchwork.freedesktop.org/series/78986/ State : warning == Summary == $ dim checkpatch origin/drm-tip 812b34bfde95 drm/i915/gt: Harden the heartbeat against a stuck driver -:43: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using 'heartbeat', this function's name, in a string #43: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:135: + "no heartbeat on %s", total: 0 errors, 1 warnings, 0 checks, 35 lines checked ef8ecc7428fe drm/i915/gt: Move the heartbeat into the highprio system wq ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with drm/i915/gt: Harden the heartbeat against a stuck driver (rev2)
== Series Details == Series: series starting with drm/i915/gt: Harden the heartbeat against a stuck driver (rev2) URL : https://patchwork.freedesktop.org/series/78986/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2269:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2270:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2271:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2272:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2273:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_lrc.c:2785:17: error: too long token expansion +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linu
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: prefer dig_port to reference intel_digital_port
== Series Details == Series: drm/i915/display: prefer dig_port to reference intel_digital_port URL : https://patchwork.freedesktop.org/series/78971/ State : success == Summary == CI Bug Log - changes from CI_DRM_8681_full -> Patchwork_18052_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18052_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-kbl4/igt@gem_ctx_isolation@preservation...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-kbl4/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_exec_nop@basic-parallel: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] / [i915#95]) +9 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-apl4/igt@gem_exec_...@basic-parallel.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-apl8/igt@gem_exec_...@basic-parallel.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-glk3/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1436] / [i915#716]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-glk5/igt@kms_big...@x-tiled-64bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_color@pipe-b-ctm-negative: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +14 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-skl1/igt@kms_co...@pipe-b-ctm-negative.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-skl3/igt@kms_co...@pipe-b-ctm-negative.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-kbl7/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#79]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html * igt@kms_flip@modeset-vs-vblank-race-interruptible@a-dp1: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-kbl2/igt@kms_flip@modeset-vs-vblank-race-interrupti...@a-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-kbl3/igt@kms_flip@modeset-vs-vblank-race-interrupti...@a-dp1.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt: - shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8681/shard-iclb5/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18052/shard-iclb7/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) +1 similar issue [23]: https://i
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915/gt: Harden the heartbeat against a stuck driver (rev2)
== Series Details ==
Series: series starting with drm/i915/gt: Harden the heartbeat against a stuck
driver (rev2)
URL : https://patchwork.freedesktop.org/series/78986/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8684 -> Patchwork_18056
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/index.html
Known issues
Here are the changes found in Patchwork_18056 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_backlight@basic-brightness:
- fi-whl-u: [PASS][1] -> [DMESG-WARN][2] ([i915#95])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#402])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-tgl-u2: [INCOMPLETE][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-tgl-u2/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-kbl-7560u}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.o
Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Correctly advertise HBR3 for GEN11+
On Tue, Jun 30, 2020 at 04:33:10PM -0700, Matt Atwood wrote:
> intel_dp_set_source_rates() calls intel_dp_is_edp(), which is unsafe to
> use before encoder_type is set. This caused GEN11+ to incorrectly strip
> HBR3 from source rates for edp. Move intel_dp_set_source_rates() to
> after encoder_type is set. Add comment to intel_dp_is_edp() describing
> unsafe usages.
>
> v2: Alter intel_dp_set_source_rates final position (Ville/Manasi).
> Remove outdated comment (Ville).
> Slight optimization of control flow in intel_dp_init_connector.
> Slight rewording in commit message.
>
> Signed-off-by: Matt Atwood
lgtm
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 ++---
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 3df5d901dd9d..c9b93c5706af 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -137,6 +137,8 @@ static const u8 valid_dsc_slicecount[] = {1, 2, 4};
> *
> * If a CPU or PCH DP output is attached to an eDP panel, this function
> * will return true, and false otherwise.
> + *
> + * This function is not safe to use prior to encoder type being set.
> */
> bool intel_dp_is_edp(struct intel_dp *intel_dp)
> {
> @@ -8157,8 +8159,6 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
>intel_encoder->base.name))
> return false;
>
> - intel_dp_set_source_rates(intel_dp);
> -
> intel_dp->reset_link_params = true;
> intel_dp->pps_pipe = INVALID_PIPE;
> intel_dp->active_pipe = INVALID_PIPE;
> @@ -8174,28 +8174,22 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
>*/
> drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
> type = DRM_MODE_CONNECTOR_eDP;
> + intel_encoder->type = INTEL_OUTPUT_EDP;
> +
> + /* eDP only on port B and/or C on vlv/chv */
> + if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> + IS_CHERRYVIEW(dev_priv)) &&
> + port != PORT_B && port != PORT_C))
> + return false;
> } else {
> type = DRM_MODE_CONNECTOR_DisplayPort;
> }
>
> + intel_dp_set_source_rates(intel_dp);
> +
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> intel_dp->active_pipe = vlv_active_pipe(intel_dp);
>
> - /*
> - * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but
> - * for DP the encoder type can be set by the caller to
> - * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it.
> - */
> - if (type == DRM_MODE_CONNECTOR_eDP)
> - intel_encoder->type = INTEL_OUTPUT_EDP;
> -
> - /* eDP only on port B and/or C on vlv/chv */
> - if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
> - IS_CHERRYVIEW(dev_priv)) &&
> - intel_dp_is_edp(intel_dp) &&
> - port != PORT_B && port != PORT_C))
> - return false;
> -
> drm_dbg_kms(&dev_priv->drm,
> "Adding %s connector on [ENCODER:%d:%s]\n",
> type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> --
> 2.21.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/tgl: Implement WA 18011464164
On Tue, Jun 30, 2020 at 06:06:54PM -0700, José Roberto de Souza wrote:
> This fix some possible corruptions.
>
> v2:
> Renamed SLICE_UNIT_LEVEL_CLOCK_GATING_CTL to
> SLICE_UNIT_LEVEL_CLKGATE_CTL_94D8
Spec people are getting creative with the naming :/
>
> BSpec: 52755
> BSpec: 52890
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 8 +++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9d6536afc94b..76bc70d214b6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4174,6 +4174,9 @@ enum {
> #define INF_UNIT_LEVEL_CLKGATE _MMIO(0x9560)
> #define CGPSF_CLKGATE_DIS (1 << 3)
>
> +#define SLICE_UNIT_LEVEL_CLKGATE_CTL_94D8_MMIO(0x94D8)
> +#define GS_UNIT_CLOCK_GATING_DIS REG_BIT(24)
> +
> /*
> * Display engine regs
> */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2a32d6230795..80293e3e48ad 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7113,7 +7113,7 @@ static void tgl_init_clock_gating(struct
> drm_i915_private *dev_priv)
> I915_WRITE(POWERGATE_ENABLE,
> I915_READ(POWERGATE_ENABLE) | vd_pg_enable);
>
> - /* Wa_1409825376:tgl (pre-prod)*/
> + /* Wa_1409825376:tgl (pre-prod) */
> if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
> I915_WRITE(GEN9_CLKGATE_DIS_3, I915_READ(GEN9_CLKGATE_DIS_3) |
> TGL_VRH_GATING_DIS);
> @@ -7121,6 +7121,12 @@ static void tgl_init_clock_gating(struct
> drm_i915_private *dev_priv)
> /* Wa_14011059788:tgl */
> intel_uncore_rmw(&dev_priv->uncore, GEN10_DFR_RATIO_EN_AND_CHICKEN,
>0, DFR_DISABLE);
> +
> + /* Wa_18011464164:tgl */
> + if (IS_TGL_REVID(dev_priv, TGL_REVID_B0, TGL_REVID_B0))
> + intel_uncore_rmw(&dev_priv->uncore,
> + SLICE_UNIT_LEVEL_CLKGATE_CTL_94D8, 0,
> + GS_UNIT_CLOCK_GATING_DIS);
Still looks like the wrong place for gt w/as though.
> }
>
> static void cnp_init_clock_gating(struct drm_i915_private *dev_priv)
> --
> 2.27.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 1/2] drm/i915/tgl: Implement WA 18011464164
On Wed, Jul 01, 2020 at 02:57:22PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 30, 2020 at 06:06:54PM -0700, José Roberto de Souza wrote:
> > This fix some possible corruptions.
> >
> > v2:
> > Renamed SLICE_UNIT_LEVEL_CLOCK_GATING_CTL to
> > SLICE_UNIT_LEVEL_CLKGATE_CTL_94D8
>
> Spec people are getting creative with the naming :/
>
> >
> > BSpec: 52755
> > BSpec: 52890
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 3 +++
> > drivers/gpu/drm/i915/intel_pm.c | 8 +++-
> > 2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 9d6536afc94b..76bc70d214b6 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4174,6 +4174,9 @@ enum {
> > #define INF_UNIT_LEVEL_CLKGATE _MMIO(0x9560)
> > #define CGPSF_CLKGATE_DIS(1 << 3)
> >
> > +#define SLICE_UNIT_LEVEL_CLKGATE_CTL_94D8 _MMIO(0x94D8)
> > +#define GS_UNIT_CLOCK_GATING_DIS REG_BIT(24)
> > +
Oh, and that should probably live next to its cousin.
> > /*
> > * Display engine regs
> > */
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 2a32d6230795..80293e3e48ad 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7113,7 +7113,7 @@ static void tgl_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> > I915_WRITE(POWERGATE_ENABLE,
> >I915_READ(POWERGATE_ENABLE) | vd_pg_enable);
> >
> > - /* Wa_1409825376:tgl (pre-prod)*/
> > + /* Wa_1409825376:tgl (pre-prod) */
> > if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
> > I915_WRITE(GEN9_CLKGATE_DIS_3, I915_READ(GEN9_CLKGATE_DIS_3) |
> >TGL_VRH_GATING_DIS);
> > @@ -7121,6 +7121,12 @@ static void tgl_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> > /* Wa_14011059788:tgl */
> > intel_uncore_rmw(&dev_priv->uncore, GEN10_DFR_RATIO_EN_AND_CHICKEN,
> > 0, DFR_DISABLE);
> > +
> > + /* Wa_18011464164:tgl */
> > + if (IS_TGL_REVID(dev_priv, TGL_REVID_B0, TGL_REVID_B0))
> > + intel_uncore_rmw(&dev_priv->uncore,
> > +SLICE_UNIT_LEVEL_CLKGATE_CTL_94D8, 0,
> > +GS_UNIT_CLOCK_GATING_DIS);
>
> Still looks like the wrong place for gt w/as though.
>
> > }
> >
> > static void cnp_init_clock_gating(struct drm_i915_private *dev_priv)
> > --
> > 2.27.0
>
> --
> Ville Syrjälä
> Intel
--
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 drm/i915/dmc: Use firmware v2.02 for RKL
== Series Details ==
Series: drm/i915/dmc: Use firmware v2.02 for RKL
URL : https://patchwork.freedesktop.org/series/78989/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8685 -> Patchwork_18057
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/index.html
Known issues
Here are the changes found in Patchwork_18057 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][3] -> [DMESG-WARN][4] ([i915#62] / [i915#92] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-apl-guc: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/fi-apl-guc/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/fi-apl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Warnings
* igt@kms_flip@basic-plain-flip@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/fi-kbl-x1275/igt@kms_flip@basic-plain-f...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (43 -> 37)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8685 -> Patchwork_18057
CI-20190529: 20190529
CI_DRM_8685: 2bd7cba2c0c0aca2d054ba7fb07df21705c60c68 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5718: af1ef32bfae90bcdbaf1b5d84c61ff4e04368505 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18057: 2ba4535234d0ce1bc0966310769b7c62eb4476ff @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2ba4535234d0 drm/i915/dmc: Use firmware v2.02 for RKL
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K
Op 30-06-2020 om 13:26 schreef Stanislav Lisovskiy:
> We still need "Bump up CDCLK" workaround otherwise getting
> underruns - however currently it blocks 8K as CDCLK = Pixel rate,
> in 8K case would require CDCLK to be around 1 Ghz which is not
> possible.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 45f7f33d1144..01a5bc6b08c4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2080,9 +2080,21 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
>* Explicitly stating here that this seems to be currently
>* rather a Hack, than final solution.
>*/
> - if (IS_TIGERLAKE(dev_priv))
> + if (IS_TIGERLAKE(dev_priv)) {
> min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
>
> + /*
> + * Clamp to max_cdclk_freq in order not to break an 8K,
> + * but still leave W/A at place.
> + */
> + min_cdclk = min(min_cdclk, (int)dev_priv->max_cdclk_freq);
> +
> + /*
> + * max_cdclk_freq check obviously not needed - just return.
> + */
> + return min_cdclk;
> + }
> +
> if (min_cdclk > dev_priv->max_cdclk_freq) {
> drm_dbg_kms(&dev_priv->drm,
> "required cdclk (%d kHz) exceeds max (%d kHz)\n",
Wouldn't you just have to halve pixel_rate if bigjoiner flag is set?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_close_race: Mix in a contexts and a small delay to closure
>-Original Message-
>From: Chris Wilson
>Sent: Tuesday, June 30, 2020 5:25 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: igt-...@lists.freedesktop.org; Chris Wilson ;
>Ruhl, Michael J
>Subject: [PATCH i-g-t] i915/gem_close_race: Mix in a contexts and a small
>delay to closure
>
>Keep the old handles in a small ring so that we build up a small amount
>of pressure for i915_gem_close_object() and throw in a few concurrent
>contexts so we have to process an obj->lut_list containing more than one
>element. And to make sure the list is truly long enough to schedule,
>start leaking the contexts.
>
>Note that the only correctness check is that the selfcopy doesn't
>explode; the challenge would be to prove that the old handles are no
>longer accessible via the execbuf lut. However, this is sufficient to
>make sure we at least hit the interruptible spinlock used by
>close-objects.
>
>Signed-off-by: Chris Wilson
>Cc: Michael J. Ruhl
>---
> tests/i915/gem_close_race.c | 68 +---
>-
> 1 file changed, 53 insertions(+), 15 deletions(-)
>
>diff --git a/tests/i915/gem_close_race.c b/tests/i915/gem_close_race.c
>index db570e8fd..4b72d353c 100644
>--- a/tests/i915/gem_close_race.c
>+++ b/tests/i915/gem_close_race.c
>@@ -55,7 +55,7 @@ static bool has_64bit_relocations;
>
> #define sigev_notify_thread_id _sigev_un._tid
>
>-static void selfcopy(int fd, uint32_t handle, int loops)
>+static void selfcopy(int fd, uint32_t ctx, uint32_t handle, int loops)
> {
> struct drm_i915_gem_relocation_entry reloc[2];
> struct drm_i915_gem_exec_object2 gem_exec[2];
>@@ -113,6 +113,7 @@ static void selfcopy(int fd, uint32_t handle, int loops)
> execbuf.batch_len = (b - buf) * sizeof(*b);
> if (HAS_BLT_RING(devid))
> execbuf.flags |= I915_EXEC_BLT;
>+ execbuf.rsvd1 = ctx;
>
> memset(&gem_pwrite, 0, sizeof(gem_pwrite));
> gem_pwrite.handle = create.handle;
>@@ -135,7 +136,7 @@ static uint32_t load(int fd)
> if (handle == 0)
> return 0;
>
>- selfcopy(fd, handle, 100);
>+ selfcopy(fd, 0, handle, 100);
> return handle;
> }
>
>@@ -165,14 +166,19 @@ static void crashme_now(int sig)
> #define usec(x) (1000*(x))
> #define msec(x) usec(1000*(x))
>
>-static void threads(int timeout)
>+static void thread(int fd, struct drm_gem_open name,
>+ int timeout, unsigned int flags)
>+#define CONTEXTS 0x1
> {
> struct sigevent sev;
> struct sigaction act;
>- struct drm_gem_open name;
> struct itimerspec its;
>+ uint32_t *history;
>+#define N_HISTORY (256)
> timer_t timer;
>- int fd;
>+
>+ history = malloc(sizeof(*history) * N_HISTORY);
>+ igt_assert(history);
>
> memset(&act, 0, sizeof(act));
> act.sa_handler = crashme_now;
>@@ -184,28 +190,57 @@ static void threads(int timeout)
> sev.sigev_signo = SIGRTMIN;
> igt_assert(timer_create(CLOCK_MONOTONIC, &sev, &timer) == 0);
>
>- fd = drm_open_driver(DRIVER_INTEL);
>- name.name = gem_flink(fd, gem_create(fd, OBJECT_SIZE));
>-
> igt_until_timeout(timeout) {
>- crashme.fd = drm_open_driver(DRIVER_INTEL);
>+ unsigned int n = 0;
>+
>+ memset(history, 0, sizeof(*history) * N_HISTORY);
>+
>+ crashme.fd = gem_reopen_driver(fd);
>
> memset(&its, 0, sizeof(its));
>- its.it_value.tv_nsec = msec(1) + (rand() % msec(10));
>+ its.it_value.tv_nsec = msec(1) + (rand() % msec(150));
> igt_assert(timer_settime(timer, 0, &its, NULL) == 0);
>
> do {
>- if (drmIoctl(crashme.fd, DRM_IOCTL_GEM_OPEN,
>&name))
>+ uint32_t ctx = 0;
>+
>+ if (drmIoctl(crashme.fd,
>+ DRM_IOCTL_GEM_OPEN,
>+ &name))
> break;
>
>- selfcopy(crashme.fd, name.handle, 100);
>- drmIoctl(crashme.fd, DRM_IOCTL_GEM_CLOSE,
>&name.handle);
>+ if (flags & CONTEXTS)
>+ __gem_context_create(crashme.fd, &ctx);
>+
>+ selfcopy(crashme.fd, ctx, name.handle, 1);
>+
>+ ctx = history[n % N_HISTORY];
Ahh this 'ctx' isn't really a context, it an unclosed handle.
So the difference is that you keep around N_HISTORY open handles and
the associated contexts (if requested) until the test is done.
And 256 is enough history? Any concerns with faster CPU/GPUs?
Looks like a good way to stress things.
Reviewed-by: Michael J. Ruhl
M
>+ if (ctx)
>+ drmIoctl(crashme.fd,
>+ DRM_IOCTL_GEM_CLOSE,
>+ &ctx);
>+ history[n % N_HISTORY] = name.handle;
>+ n++;
> } while (1);
>
>
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/tgl+: Fix TBT DPLL fractional divider for 38.4MHz ref clock
On Tue, Jun 30, 2020 at 02:25:30PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915/tgl+: Fix TBT DPLL fractional > divider for 38.4MHz ref clock > URL : https://patchwork.freedesktop.org/series/78909/ > State : success Thanks for the reviews pushed the patchset to -dinq. While applying patch 1, I fixed the TBT dock type in the commit log and added the BSpec WA code comment. > > == Summary == > > CI Bug Log - changes from CI_DRM_8676_full -> Patchwork_18037_full > > > Summary > --- > > **WARNING** > > Minor unknown changes coming with Patchwork_18037_full need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_18037_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_18037_full: > > ### IGT changes ### > > Warnings > > * igt@kms_atomic@plane-primary-overlay-mutable-zpos: > - shard-iclb: [SKIP][1] ([i915#404]) -> [TIMEOUT][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-iclb5/igt@kms_ato...@plane-primary-overlay-mutable-zpos.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-iclb4/igt@kms_ato...@plane-primary-overlay-mutable-zpos.html > > > Known issues > > > Here are the changes found in Patchwork_18037_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_balancer@sliced: > - shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#1958]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-iclb5/igt@gem_exec_balan...@sliced.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-iclb4/igt@gem_exec_balan...@sliced.html > > * igt@gem_mmap_gtt@ptrace: > - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / > [i915#95]) +15 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-apl4/igt@gem_mmap_...@ptrace.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-apl8/igt@gem_mmap_...@ptrace.html > > * igt@i915_selftest@mock@requests: > - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([i915#2110] / > [i915#58] / [k.org#198133]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-glk7/igt@i915_selftest@m...@requests.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-glk3/igt@i915_selftest@m...@requests.html > > * igt@kms_big_fb@y-tiled-64bpp-rotate-180: > - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / > [i915#95]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-glk6/igt@kms_big...@y-tiled-64bpp-rotate-180.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html > > * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: > - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] / > [i915#95]) +2 similar issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html > > * igt@kms_flip@basic-plain-flip@a-edp1: > - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +7 > similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-skl4/igt@kms_flip@basic-plain-f...@a-edp1.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-skl9/igt@kms_flip@basic-plain-f...@a-edp1.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1: > - shard-apl: [PASS][15] -> [FAIL][16] ([i915#79]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-apl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-apl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: > - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8676/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18037/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a2: > - shard-glk: [PASS][19] -> [FAIL][20] ([i915#79]) >[19]: > https://intel-gfx-ci.01.org/tr
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_close_race: Mix in a contexts and a small delay to closure
Quoting Ruhl, Michael J (2020-07-01 13:39:22)
> > do {
> >- if (drmIoctl(crashme.fd, DRM_IOCTL_GEM_OPEN,
> >&name))
> >+ uint32_t ctx = 0;
> >+
> >+ if (drmIoctl(crashme.fd,
> >+ DRM_IOCTL_GEM_OPEN,
> >+ &name))
> > break;
> >
> >- selfcopy(crashme.fd, name.handle, 100);
> >- drmIoctl(crashme.fd, DRM_IOCTL_GEM_CLOSE,
> >&name.handle);
> >+ if (flags & CONTEXTS)
> >+ __gem_context_create(crashme.fd, &ctx);
> >+
> >+ selfcopy(crashme.fd, ctx, name.handle, 1);
> >+
> >+ ctx = history[n % N_HISTORY];
>
> Ahh this 'ctx' isn't really a context, it an unclosed handle.
Welcome to my world of laziness.
> So the difference is that you keep around N_HISTORY open handles and
> the associated contexts (if requested) until the test is done.
>
> And 256 is enough history? Any concerns with faster CPU/GPUs?
It's a balancing between trying to keep the original test where we are
closing handles as go along and keeping some around. On the slow atom
with debug enabled, it would complete a few hundred cycles in the 100ms
loop. So I picked 256 so that it would start evicting some old handles
on some passes.
For the purpose of hitting the bookmark, we just need to hit one case
with more than one element. And I manually verified that the test case
was seeing contention at that point, i.e. we released the spinlock so
that another close_object was seeing the other bookmarks in its
obj->lut_list walk. So I'm confident this will hit the path in question
in CI, I'm not happy that it can't prove it did :|
[At the extreme, we could look at the fairness of close_object!]
> Looks like a good way to stress things.
>
> Reviewed-by: Michael J. Ruhl
Ta,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/26] Revert "drm/i915/gem: Async GPU relocations only" (rev2)
== Series Details == Series: series starting with [01/26] Revert "drm/i915/gem: Async GPU relocations only" (rev2) URL : https://patchwork.freedesktop.org/series/78744/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8661_full -> Patchwork_18018_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18018_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18018_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_18018_full: ### IGT changes ### Possible regressions * igt@gem_close@many-handles-one-vma: - shard-glk: [PASS][1] -> ([FAIL][2], [FAIL][3]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-glk9/igt@gem_cl...@many-handles-one-vma.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-glk1/igt@gem_cl...@many-handles-one-vma.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-glk6/igt@gem_cl...@many-handles-one-vma.html - shard-apl: [PASS][4] -> ([FAIL][5], [FAIL][6]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-apl1/igt@gem_cl...@many-handles-one-vma.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-apl4/igt@gem_cl...@many-handles-one-vma.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-apl3/igt@gem_cl...@many-handles-one-vma.html - shard-skl: [PASS][7] -> ([FAIL][8], [FAIL][9]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-skl1/igt@gem_cl...@many-handles-one-vma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-skl9/igt@gem_cl...@many-handles-one-vma.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-skl2/igt@gem_cl...@many-handles-one-vma.html - shard-kbl: [PASS][10] -> ([FAIL][11], [FAIL][12]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl7/igt@gem_cl...@many-handles-one-vma.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-kbl4/igt@gem_cl...@many-handles-one-vma.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-kbl6/igt@gem_cl...@many-handles-one-vma.html - shard-hsw: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-hsw5/igt@gem_cl...@many-handles-one-vma.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-hsw1/igt@gem_cl...@many-handles-one-vma.html - shard-snb: [PASS][15] -> ([FAIL][16], [FAIL][17]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-snb5/igt@gem_cl...@many-handles-one-vma.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-snb6/igt@gem_cl...@many-handles-one-vma.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-snb5/igt@gem_cl...@many-handles-one-vma.html - shard-iclb: [PASS][18] -> ([FAIL][19], [FAIL][20]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-iclb8/igt@gem_cl...@many-handles-one-vma.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-iclb2/igt@gem_cl...@many-handles-one-vma.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-iclb5/igt@gem_cl...@many-handles-one-vma.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-tglb: [PASS][21] -> ([FAIL][22], [FAIL][23]) ([i915#1815]) +6 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-tglb3/igt@gem_exec_reloc@basic-many-act...@rcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-tglb1/igt@gem_exec_reloc@basic-many-act...@rcs0.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-tglb5/igt@gem_exec_reloc@basic-many-act...@rcs0.html - shard-glk: [PASS][24] -> ([FAIL][25], [FAIL][26]) ([i915#1815]) +7 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-glk7/igt@gem_exec_reloc@basic-many-act...@rcs0.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-glk4/igt@gem_exec_reloc@basic-many-act...@rcs0.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18018/shard-glk6/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-kbl: [PASS][27] -> ([FAIL][28], [FAIL][29]) ([i915#1815]) +9 similar issues [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8661/shard-kbl6/igt@gem_exec_reloc@basic-many-act...@vcs0.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1801
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel -
Pretty quiet in the i915 front.
drm-intel-fixes-2020-07-01:
drm/i915 fixes for v5.8-rc4:
- GVT fixes
- Include asm sources for render cache clear batches
BR,
Jani.
The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68:
Linux 5.8-rc3 (2020-06-28 15:00:24 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-07-01
for you to fetch changes up to 55fd7e0222ea01246ef3e6aae28b5721fdfb790f:
drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c (2020-06-29
11:29:12 +0300)
drm/i915 fixes for v5.8-rc4:
- GVT fixes
- Include asm sources for render cache clear batches
Colin Xu (4):
drm/i915/gvt: Add one missing MMIO handler for D_SKL_PLUS
drm/i915/gvt: Fix two CFL MMIO handling caused by regression.
drm/i915/gvt: Fix incorrect check of enabled bits in mask registers
drm/i915/gvt: Use GFP_ATOMIC instead of GFP_KERNEL in atomic context
Jani Nikula (1):
Merge tag 'gvt-fixes-2020-06-17' of https://github.com/intel/gvt-linux
into drm-intel-fixes
Rodrigo Vivi (1):
drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
drivers/gpu/drm/i915/gt/shaders/README | 46
.../gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm | 119 +
.../gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm | 117
drivers/gpu/drm/i915/gvt/debugfs.c | 2 +-
drivers/gpu/drm/i915/gvt/handlers.c| 24 +++--
drivers/gpu/drm/i915/gvt/mmio_context.h| 6 +-
drivers/gpu/drm/i915/gvt/reg.h | 5 +
7 files changed, 304 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/shaders/README
create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm
create mode 100644 drivers/gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm
--
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 v2 3/6] drm/i915/display: start description-based ddi initialization
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
> Start adding per-platform relevant data into a table that we use for
> initialization. Intention is to keep the different indexes we need (e.g.
> phy, vbt, ddi, etc) and any other differences for each platform in these
> tables so we don't have to keep converting back and forth between them.
>
> For now, just add the naked table with name. Subsequent patches will
> start piping this in via intel_ddi_init().
>
> v2: do not try to generalize the checks for port presence nor dsi
> initialization. Instead focus on getting the ddi table created for all
> platforms using DDI and keep their differences in the original function
I like this.
> drm/i915/display: description-based initialization for remaining ddi
> platforms
Stray line?
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 141 --
> .../drm/i915/display/intel_display_types.h| 5 +
> 2 files changed, 99 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index effd6b65f270..c234b50212b0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16805,6 +16805,83 @@ static void intel_pps_init(struct drm_i915_private
> *dev_priv)
> intel_pps_unlock_regs_wa(dev_priv);
> }
>
> +static const struct intel_ddi_port_info rkl_ports[] = {
> + { .name = "DDI A", .port = PORT_A },
> + { .name = "DDI B", .port = PORT_B },
> + { .name = "DDI TC1", .port = PORT_D },
> + { .name = "DDI TC2", .port = PORT_E },
> + { .port = PORT_NONE }
> +};
> +
> +static const struct intel_ddi_port_info tgl_ports[] = {
> + { .name = "DDI A", .port = PORT_A },
> + { .name = "DDI B", .port = PORT_B },
> + { .name = "DDI TC1", .port = PORT_D },
> + { .name = "DDI TC2", .port = PORT_E },
> + { .name = "DDI TC3", .port = PORT_F },
> + { .name = "DDI TC4", .port = PORT_G },
> + { .name = "DDI TC5", .port = PORT_H },
> + { .name = "DDI TC6", .port = PORT_I },
> + { .port = PORT_NONE }
> +};
> +
> +static const struct intel_ddi_port_info ehl_ports[] = {
> + { .name = "DDI A", .port = PORT_A },
> + { .name = "DDI B", .port = PORT_B },
> + { .name = "DDI C", .port = PORT_C },
> + { .name = "DDI D", .port = PORT_D },
> + { .port = PORT_NONE }
> +};
> +
> +static const struct intel_ddi_port_info icl_ports[] = {
> + { .name = "DDI A", .port = PORT_A },
> + { .name = "DDI B", .port = PORT_B },
> + { .name = "DDI TC1", .port = PORT_C },
> + { .name = "DDI TC2", .port = PORT_D },
> + { .name = "DDI TC3", .port = PORT_E },
> + { .name = "DDI TC4", .port = PORT_F },
> + { .port = PORT_NONE }
> +};
> +
> +static const struct intel_ddi_port_info gen9lp_ports[] = {
> + { .name = "DDI A", .port = PORT_A },
> + { .name = "DDI B", .port = PORT_B },
> + { .name = "DDI C", .port = PORT_C },
> + { .port = PORT_NONE }
> +};
> +
> +static const struct intel_ddi_port_info ddi_ports[] = {
> + { .name = "DDI A", .port = PORT_A },
> + { .name = "DDI B", .port = PORT_B },
> + { .name = "DDI C", .port = PORT_C },
> + { .name = "DDI D", .port = PORT_D },
> + { .name = "DDI E", .port = PORT_E },
> + { .name = "DDI F", .port = PORT_F },
> + { .port = PORT_NONE }
> +};
These make me wonder about a potential future restructuring of moving
the output setup stuff to a separate file. No need to do that here, just
throwing ideas around.
> +
> +/*
> + * Use a description-based approach for platforms that can be supported with
> a
> + * static table
> + *
> + * @disable_mask: any port that should not be enabled due to being disabled
> by
> + * any reason
> + */
> +static void setup_ddi_outputs_desc(struct drm_i915_private *i915,
> +const struct intel_ddi_port_info *ports,
> +unsigned long disable_mask)
> +{
> + const struct intel_ddi_port_info *port_info;
> +
> + for (port_info = ports;
> + port_info->port != PORT_NONE; port_info++) {
> + if (test_bit(port_info->port, &disable_mask))
> + continue;
> +
> + intel_ddi_init(i915, port_info->port);
> + }
> +}
> +
> static void intel_setup_outputs(struct drm_i915_private *dev_priv)
> {
> struct intel_encoder *encoder;
> @@ -16816,46 +16893,21 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> return;
>
> if (IS_ROCKETLAKE(dev_priv)) {
> - intel_ddi_init(dev_priv, PORT_A);
> - intel_ddi_init(dev_priv, PORT_B);
> - intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
> - intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
> + setup_ddi_outputs_desc(dev_priv, rkl_ports, 0);
> } else if (INTEL_GEN(dev_priv) >= 12
[Intel-gfx] [PATCH] drm/i915/guc: Expand guc_info debugfs with more information
From: Michał Winiarski
The information about platform/driver/user view of GuC firmware usage
currently requires user to either go through kernel log or parse the
combination of "enable_guc" modparam and various debugfs entries.
Let's keep things simple and add a "supported/used/wanted" matrix
(already used internally by i915) in guc_info debugfs.
Signed-off-by: Michał Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Lukasz Fiedorowicz
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 861657897c0f..446a41946f56 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -733,19 +733,28 @@ int intel_guc_allocate_and_map_vma(struct intel_guc *guc,
u32 size,
*/
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p)
{
+ struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
struct intel_gt *gt = guc_to_gt(guc);
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- if (!intel_guc_is_supported(guc)) {
- drm_printf(p, "GuC not supported\n");
+ drm_printf(p, "[guc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc(uc)),
+ yesno(intel_uc_wants_guc(uc)),
+ yesno(intel_uc_uses_guc(uc)));
+ drm_printf(p, "[huc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_huc(uc)),
+ yesno(intel_uc_wants_huc(uc)),
+ yesno(intel_uc_uses_huc(uc)));
+ drm_printf(p, "[submission] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc_submission(uc)),
+ yesno(intel_uc_wants_guc_submission(uc)),
+ yesno(intel_uc_uses_guc_submission(uc)));
+
+ if (!intel_guc_is_supported(guc) || !intel_guc_is_wanted(guc))
return;
- }
- if (!intel_guc_is_wanted(guc)) {
- drm_printf(p, "GuC disabled\n");
- return;
- }
+ drm_puts(p, "\n");
intel_uc_fw_dump(&guc->fw, p);
--
2.27.0
___
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 [01/33] drm/i915/gt: Harden the heartbeat against a stuck driver
== Series Details == Series: series starting with [01/33] drm/i915/gt: Harden the heartbeat against a stuck driver URL : https://patchwork.freedesktop.org/series/78987/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8683_full -> Patchwork_18054_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18054_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18054_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_18054_full: ### IGT changes ### Possible regressions * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglb: [PASS][1] -> [FAIL][2] +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-tglb1/igt@gem_ctx_e...@basic-nohangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-tglb8/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_exec_schedule@reorder-wide@bcs0: - shard-skl: [PASS][3] -> [FAIL][4] +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-skl10/igt@gem_exec_schedule@reorder-w...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-skl5/igt@gem_exec_schedule@reorder-w...@bcs0.html * igt@gem_exec_schedule@reorder-wide@rcs0: - shard-hsw: NOTRUN -> [FAIL][5] +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-hsw4/igt@gem_exec_schedule@reorder-w...@rcs0.html - shard-apl: [PASS][6] -> [FAIL][7] +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-apl8/igt@gem_exec_schedule@reorder-w...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-apl2/igt@gem_exec_schedule@reorder-w...@rcs0.html - shard-glk: [PASS][8] -> [FAIL][9] +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-glk9/igt@gem_exec_schedule@reorder-w...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-glk3/igt@gem_exec_schedule@reorder-w...@rcs0.html - shard-snb: NOTRUN -> [FAIL][10] +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-snb1/igt@gem_exec_schedule@reorder-w...@rcs0.html * igt@gem_exec_schedule@reorder-wide@vcs0: - shard-iclb: [PASS][11] -> [FAIL][12] +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-iclb7/igt@gem_exec_schedule@reorder-w...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-iclb4/igt@gem_exec_schedule@reorder-w...@vcs0.html * igt@gem_exec_schedule@reorder-wide@vcs1: - shard-kbl: [PASS][13] -> [FAIL][14] +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-kbl6/igt@gem_exec_schedule@reorder-w...@vcs1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-kbl2/igt@gem_exec_schedule@reorder-w...@vcs1.html - shard-iclb: NOTRUN -> [FAIL][15] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-iclb4/igt@gem_exec_schedule@reorder-w...@vcs1.html New tests - New tests have been introduced between CI_DRM_8683_full and Patchwork_18054_full: ### New IGT tests (1) ### * igt@i915_selftest@mock@scheduler: - Statuses : 2 pass(s) - Exec time: [0.21, 1.04] s Known issues Here are the changes found in Patchwork_18054_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@set-priority-not-supported: - shard-snb: [PASS][16] -> [SKIP][17] ([fdo#109271]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-snb6/igt@gem_ctx_pa...@set-priority-not-supported.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-snb6/igt@gem_ctx_pa...@set-priority-not-supported.html - shard-hsw: [PASS][18] -> [SKIP][19] ([fdo#109271]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-hsw7/igt@gem_ctx_pa...@set-priority-not-supported.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-hsw7/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_exec_balancer@smoke: - shard-kbl: [PASS][20] -> [TIMEOUT][21] ([i915#2119]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8683/shard-kbl2/igt@gem_exec_balan...@smoke.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18054/shard-kbl6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-engines@bcs0: - shard-kbl: [PASS][22] ->
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/display: add phy, vbt and ddi indexes
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
> Identify 3 possible cases in which the index numbers can be different
> from the "port" and add them to the description-based ddi initialization
> table. This can be used in place of additional functions mapping from
> one to the other. Right now we already cover part of this by creating kind of
> virtual phy numbering, but that comes with downsides:
>
> a) there's not really a "phy numbering" in the spec, this is purely a
> software thing; hardware uses whatever they want thinking mapping from
> one to the other arbitrarily is easy in software.
>
> b) currently the mapping occurs on "leaf" functions, making the decision
> based on the platform for each of those functions
>
> With this new table the approach will be: the port, as defined by the
> enum port, is merely a driver convention and won't be used anymore to
> define the register offset or register bits. For that we have the other
> 3 indexes, identified as being possibly different from the current usage
> of register bits: ddi, vbt and phy. The phy type is also added here,
> meant to replace the checks for combo vs tc.
>
> v2: Rebase and add RKL
>
I guess I'd like to see where the *_idx fields will lead before
advocating for this.
With them removed,
Acked-by: Jani Nikula
But I'm also not saying you can't have them - until I see where this
leads. ;)
One comment inline below.
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 64 ++-
> drivers/gpu/drm/i915/display/intel_display.h | 8 +++
> .../drm/i915/display/intel_display_types.h| 4 ++
> 3 files changed, 45 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c234b50212b0..d591063502c5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16806,57 +16806,59 @@ static void intel_pps_init(struct drm_i915_private
> *dev_priv)
> }
>
> static const struct intel_ddi_port_info rkl_ports[] = {
> - { .name = "DDI A", .port = PORT_A },
> - { .name = "DDI B", .port = PORT_B },
> - { .name = "DDI TC1", .port = PORT_D },
> - { .name = "DDI TC2", .port = PORT_E },
> + { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
> + { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
> + /* TODO: use continguous namespace for port once driver is converted */
> + { .name = "DDI C", .port = PORT_D, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x3, .phy_idx = 0x2, .vbt_idx = 0x2, },
> + { .name = "DDI D", .port = PORT_E, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x4, .phy_idx = 0x3, .vbt_idx = 0x3, },
> { .port = PORT_NONE }
> };
>
> static const struct intel_ddi_port_info tgl_ports[] = {
> - { .name = "DDI A", .port = PORT_A },
> - { .name = "DDI B", .port = PORT_B },
> - { .name = "DDI TC1", .port = PORT_D },
> - { .name = "DDI TC2", .port = PORT_E },
> - { .name = "DDI TC3", .port = PORT_F },
> - { .name = "DDI TC4", .port = PORT_G },
> - { .name = "DDI TC5", .port = PORT_H },
> - { .name = "DDI TC6", .port = PORT_I },
> + { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO,
> .ddi_idx = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
> + { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO,
> .ddi_idx = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
> + /* TODO: use continguous namespace for port once driver is converted */
> + { .name = "DDI TC1", .port = PORT_D, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x3, .phy_idx = 0x0, .vbt_idx = 0x2, },
> + { .name = "DDI TC2", .port = PORT_E, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x4, .phy_idx = 0x1, .vbt_idx = 0x3, },
> + { .name = "DDI TC3", .port = PORT_F, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x5, .phy_idx = 0x2, .vbt_idx = 0x4, },
> + { .name = "DDI TC4", .port = PORT_G, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x6, .phy_idx = 0x3, .vbt_idx = 0x5, },
> + { .name = "DDI TC5", .port = PORT_H, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x7, .phy_idx = 0x4, .vbt_idx = 0x6, },
> + { .name = "DDI TC6", .port = PORT_I, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x8, .phy_idx = 0x5, .vbt_idx = 0x7, },
> { .port = PORT_NONE }
> };
>
> static const struct intel_ddi_port_info ehl_ports[] = {
> - { .name = "DDI A", .port = PORT_A },
> - { .name = "DDI B", .port = PORT_B },
> - { .name = "DDI C", .port = PORT_C },
> - { .name = "DDI D", .port = PORT_D },
> + { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
> + { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
> + { .name =
[Intel-gfx] [PATCH] drm/i915: Reboot CI if we get wedged during driver init
From: Michał Winiarski Getting wedged device on driver init is pretty much unrecoverable. Since we're running verious scenarios that may potentially hit this in CI (module reload / selftests / hotunplug), and if it happens, it means that we can't trust any subsequent CI results, we should just apply the taint to let the CI know that it should reboot (CI checks taint between test runs). Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Petri Latvala --- drivers/gpu/drm/i915/gt/intel_reset.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c index 0156f1f5c736..d27e8bb7d550 100644 --- a/drivers/gpu/drm/i915/gt/intel_reset.c +++ b/drivers/gpu/drm/i915/gt/intel_reset.c @@ -1360,6 +1360,8 @@ void intel_gt_set_wedged_on_init(struct intel_gt *gt) I915_WEDGED_ON_INIT); intel_gt_set_wedged(gt); set_bit(I915_WEDGED_ON_INIT, >->reset.flags); + + add_taint_for_CI(TAINT_WARN); } void intel_gt_init_reset(struct intel_gt *gt) -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Expand guc_info debugfs with more information
== Series Details == Series: drm/i915/guc: Expand guc_info debugfs with more information URL : https://patchwork.freedesktop.org/series/78997/ State : success == Summary == CI Bug Log - changes from CI_DRM_8686 -> Patchwork_18058 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/index.html Known issues Here are the changes found in Patchwork_18058 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_backlight@basic-brightness: - fi-whl-u: [PASS][1] -> [DMESG-WARN][2] ([i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-whl-u/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-glk-dsi: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-glk-dsi/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-glk-dsi/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-kbl-x1275/igt@kms_busy@ba...@flip.html Warnings * igt@debugfs_test@read_all_entries: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) -> [DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][13] ([i915#62]) -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1: - fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][16] ([i915#62] / [i915#92]) +7 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8686/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (42 -> 37) -- Additional (2): fi-cml-u2 fi-tgl-u2 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8686 -> Patchwork_18058 CI-20190529: 20190529 CI_DRM_8686: 7ac6088487e9ffebed115a6447371087b07b784c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5718: af1ef32bfae90bcdbaf1b5d84c61ff4e04368505 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18058: 3bdb63a31053743687af9e08ad0432835b7bbeb7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3bdb63a31053 drm/i915/guc: Expand guc_info debugfs with more information == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18058/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reboot CI if we get wedged during driver init
Quoting Michał Winiarski (2020-07-01 16:07:21) > From: Michał Winiarski > > Getting wedged device on driver init is pretty much unrecoverable. > Since we're running verious scenarios that may potentially hit this in > CI (module reload / selftests / hotunplug), and if it happens, it means > that we can't trust any subsequent CI results, we should just apply the > taint to let the CI know that it should reboot (CI checks taint between > test runs). Ok, we treat WEDGED_ON_INIT as non-recoverable [as opposed to the less wedged WEDGED]. > Signed-off-by: Michał Winiarski > Cc: Chris Wilson > Cc: Petri Latvala 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 v2 6/6] drm/i915/display: replace port to phy conversions in intel_ddi.c
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
> This is the first level conversion to use port_info directly from
> intel_digital_port, rather than derive the phy or tc_port from the port.
> This touches only the functions which have the encoder or dig_port
> directly available.
Overall I like it, some nitpicks and notes inline.
Eventually we'll probably want to convert the "tc_port" in register
macros to "phy" or something, but no rush.
With the issues fixed,
Reviewed-by: Jani Nikula
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 158 +++
> 1 file changed, 77 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 27e2f29f47a2..aa0b478ab54a 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1061,11 +1061,11 @@ tgl_get_dkl_buf_trans(struct drm_i915_private
> *dev_priv, int type, int rate,
> static int intel_ddi_hdmi_level(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> int n_entries, level, default_entry;
> - enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
>
> if (INTEL_GEN(dev_priv) >= 12) {
> - if (intel_phy_is_combo(dev_priv, phy))
> + if (intel_ddi_has_combo_phy(dig_port))
Btw why the "is" -> "has" in the function name?
> tgl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
> 0, &n_entries);
> else
> @@ -1073,7 +1073,7 @@ static int intel_ddi_hdmi_level(struct intel_encoder
> *encoder)
> &n_entries);
> default_entry = n_entries - 1;
> } else if (INTEL_GEN(dev_priv) == 11) {
> - if (intel_phy_is_combo(dev_priv, phy))
> + if (intel_ddi_has_combo_phy(dig_port))
> icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
> 0, &n_entries);
> else
> @@ -1453,9 +1453,9 @@ static void intel_ddi_clock_get(struct intel_encoder
> *encoder,
> struct intel_crtc_state *pipe_config)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
>
> - if (intel_phy_is_tc(dev_priv, phy) &&
> + if (intel_ddi_has_tc_phy(dig_port) &&
> intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll) ==
> DPLL_ID_ICL_TBTPLL)
> pipe_config->port_clock = icl_calc_tbt_pll_link(dev_priv,
> @@ -1983,7 +1983,6 @@ static void intel_ddi_get_power_domains(struct
> intel_encoder *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_digital_port *dig_port;
> - enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
>
> /*
>* TODO: Add support for MST encoders. Atm, the following should never
> @@ -1996,7 +1995,7 @@ static void intel_ddi_get_power_domains(struct
> intel_encoder *encoder,
>
> dig_port = enc_to_dig_port(encoder);
>
> - if (!intel_phy_is_tc(dev_priv, phy) ||
> + if (!intel_ddi_has_tc_phy(dig_port) ||
> dig_port->tc_mode != TC_PORT_TBT_ALT)
> intel_display_power_get(dev_priv,
> dig_port->ddi_io_power_domain);
> @@ -2006,7 +2005,7 @@ static void intel_ddi_get_power_domains(struct
> intel_encoder *encoder,
>* ports.
>*/
> if (intel_crtc_has_dp_encoder(crtc_state) ||
> - intel_phy_is_tc(dev_priv, phy))
> + intel_ddi_has_tc_phy(dig_port))
> intel_display_power_get(dev_priv,
>
> intel_ddi_main_link_aux_domain(dig_port));
>
> @@ -2142,14 +2141,14 @@ static void bxt_ddi_vswing_sequence(struct
> intel_encoder *encoder,
>
> static u8 intel_ddi_dp_voltage_max(struct intel_dp *intel_dp)
> {
> - struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct intel_encoder *encoder = &dig_port->base;
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = encoder->port;
> - enum phy phy = intel_port_to_phy(dev_priv, port);
> int n_entries;
>
> if (INTEL_GEN(dev_priv) >= 12) {
> - if (intel_phy_is_combo(dev_priv, phy))
> + if (intel_ddi_has_tc_phy(dig_port))
Mixup with combo and tc.
> tgl_get_combo_buf_trans(dev_priv, encoder->type,
> intel_dp->link_rate,
> &n_entries);
>
Re: [Intel-gfx] [PATCH] drm/i915: Reboot CI if we get wedged during driver init
Quoting Michał Winiarski (2020-07-01 16:07:21) > From: Michał Winiarski > > Getting wedged device on driver init is pretty much unrecoverable. > Since we're running verious scenarios that may potentially hit this in > CI (module reload / selftests / hotunplug), and if it happens, it means > that we can't trust any subsequent CI results, we should just apply the > taint to let the CI know that it should reboot (CI checks taint between > test runs). > > Signed-off-by: Michał Winiarski > Cc: Chris Wilson > Cc: Petri Latvala > --- > drivers/gpu/drm/i915/gt/intel_reset.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c > b/drivers/gpu/drm/i915/gt/intel_reset.c > index 0156f1f5c736..d27e8bb7d550 100644 > --- a/drivers/gpu/drm/i915/gt/intel_reset.c > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > @@ -1360,6 +1360,8 @@ void intel_gt_set_wedged_on_init(struct intel_gt *gt) > I915_WEDGED_ON_INIT); > intel_gt_set_wedged(gt); > set_bit(I915_WEDGED_ON_INIT, >->reset.flags); > + Ah, we don't say around here that this WEDGED_ON_INIT is non-recoverable, could you please add a comment to that effect? > + add_taint_for_CI(TAINT_WARN); > } > > void intel_gt_init_reset(struct intel_gt *gt) > -- > 2.27.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/display: add phy, vbt and ddi indexes
On Wed, 01 Jul 2020, Jani Nikula wrote:
> On Wed, 24 Jun 2020, Lucas De Marchi wrote:
>> Identify 3 possible cases in which the index numbers can be different
>> from the "port" and add them to the description-based ddi initialization
>> table. This can be used in place of additional functions mapping from
>> one to the other. Right now we already cover part of this by creating kind
>> of
>> virtual phy numbering, but that comes with downsides:
>>
>> a) there's not really a "phy numbering" in the spec, this is purely a
>> software thing; hardware uses whatever they want thinking mapping from
>> one to the other arbitrarily is easy in software.
>>
>> b) currently the mapping occurs on "leaf" functions, making the decision
>> based on the platform for each of those functions
>>
>> With this new table the approach will be: the port, as defined by the
>> enum port, is merely a driver convention and won't be used anymore to
>> define the register offset or register bits. For that we have the other
>> 3 indexes, identified as being possibly different from the current usage
>> of register bits: ddi, vbt and phy. The phy type is also added here,
>> meant to replace the checks for combo vs tc.
>>
>> v2: Rebase and add RKL
>>
>
> I guess I'd like to see where the *_idx fields will lead before
> advocating for this.
>
> With them removed,
Ahem, ddi_idx and vbt_idx - obviously phy_idx is used, and I approve of
the use.
Another comment inline below.
>
> Acked-by: Jani Nikula
>
> But I'm also not saying you can't have them - until I see where this
> leads. ;)
>
> One comment inline below.
>
>> Signed-off-by: Lucas De Marchi
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 64 ++-
>> drivers/gpu/drm/i915/display/intel_display.h | 8 +++
>> .../drm/i915/display/intel_display_types.h| 4 ++
>> 3 files changed, 45 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index c234b50212b0..d591063502c5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -16806,57 +16806,59 @@ static void intel_pps_init(struct drm_i915_private
>> *dev_priv)
>> }
>>
>> static const struct intel_ddi_port_info rkl_ports[] = {
>> -{ .name = "DDI A", .port = PORT_A },
>> -{ .name = "DDI B", .port = PORT_B },
>> -{ .name = "DDI TC1", .port = PORT_D },
>> -{ .name = "DDI TC2", .port = PORT_E },
>> +{ .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
>> = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
>> +{ .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
>> = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
>> +/* TODO: use continguous namespace for port once driver is converted */
>> +{ .name = "DDI C", .port = PORT_D, .phy_type = PHY_TYPE_COMBO, .ddi_idx
>> = 0x3, .phy_idx = 0x2, .vbt_idx = 0x2, },
>> +{ .name = "DDI D", .port = PORT_E, .phy_type = PHY_TYPE_COMBO, .ddi_idx
>> = 0x4, .phy_idx = 0x3, .vbt_idx = 0x3, },
>> { .port = PORT_NONE }
>> };
>>
>> static const struct intel_ddi_port_info tgl_ports[] = {
>> -{ .name = "DDI A", .port = PORT_A },
>> -{ .name = "DDI B", .port = PORT_B },
>> -{ .name = "DDI TC1", .port = PORT_D },
>> -{ .name = "DDI TC2", .port = PORT_E },
>> -{ .name = "DDI TC3", .port = PORT_F },
>> -{ .name = "DDI TC4", .port = PORT_G },
>> -{ .name = "DDI TC5", .port = PORT_H },
>> -{ .name = "DDI TC6", .port = PORT_I },
>> +{ .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO,
>> .ddi_idx = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
>> +{ .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO,
>> .ddi_idx = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
>> +/* TODO: use continguous namespace for port once driver is converted */
>> +{ .name = "DDI TC1", .port = PORT_D, .phy_type = PHY_TYPE_DKL,
>> .ddi_idx = 0x3, .phy_idx = 0x0, .vbt_idx = 0x2, },
>> +{ .name = "DDI TC2", .port = PORT_E, .phy_type = PHY_TYPE_DKL,
>> .ddi_idx = 0x4, .phy_idx = 0x1, .vbt_idx = 0x3, },
>> +{ .name = "DDI TC3", .port = PORT_F, .phy_type = PHY_TYPE_DKL,
>> .ddi_idx = 0x5, .phy_idx = 0x2, .vbt_idx = 0x4, },
>> +{ .name = "DDI TC4", .port = PORT_G, .phy_type = PHY_TYPE_DKL,
>> .ddi_idx = 0x6, .phy_idx = 0x3, .vbt_idx = 0x5, },
>> +{ .name = "DDI TC5", .port = PORT_H, .phy_type = PHY_TYPE_DKL,
>> .ddi_idx = 0x7, .phy_idx = 0x4, .vbt_idx = 0x6, },
>> +{ .name = "DDI TC6", .port = PORT_I, .phy_type = PHY_TYPE_DKL,
>> .ddi_idx = 0x8, .phy_idx = 0x5, .vbt_idx = 0x7, },
>> { .port = PORT_NONE }
>> };
>>
>> static const struct intel_ddi_port_info ehl_ports[] = {
>> -{ .name = "DDI A", .port = PORT_A },
>> -{ .name = "DDI B", .port = PORT_B },
>> -{ .name = "DDI C", .port = PORT_C },
>> -{ .name = "DDI D", .port = PORT_D },
>> +{ .name = "DDI A", .p
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/display: use port_info in intel_ddi_init
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
> Now that we have tables for all platforms using ddi, keep the port_info
> around so we can use it for decisions like "what phy does it have?"
> instead of keep checking the platform/gen everywhere.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 39 ---
> drivers/gpu/drm/i915/display/intel_ddi.h | 8 +++-
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> .../drm/i915/display/intel_display_types.h| 3 ++
> 4 files changed, 37 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ca7bb2294d2b..27e2f29f47a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4844,12 +4844,24 @@ intel_ddi_max_lanes(struct intel_digital_port
> *intel_dport)
> return max_lanes;
> }
>
> -void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
> +bool intel_ddi_has_tc_phy(const struct intel_digital_port *dig_port)
> {
> + return dig_port->port_info->phy_type == PHY_TYPE_MG ||
> + dig_port->port_info->phy_type == PHY_TYPE_DKL;
> +}
> +
> +bool intel_ddi_has_combo_phy(const struct intel_digital_port *dig_port)
> +{
> + return dig_port->port_info->phy_type == PHY_TYPE_COMBO;
> +}
> +
> +void intel_ddi_init(struct drm_i915_private *dev_priv,
> + const struct intel_ddi_port_info *port_info)
> +{
> + enum port port = port_info->port;
> struct intel_digital_port *intel_dig_port;
> struct intel_encoder *encoder;
> bool init_hdmi, init_dp, init_lspcon = false;
> - enum phy phy = intel_port_to_phy(dev_priv, port);
>
> init_hdmi = intel_bios_port_supports_dvi(dev_priv, port) ||
> intel_bios_port_supports_hdmi(dev_priv, port);
> @@ -4864,14 +4876,14 @@ void intel_ddi_init(struct drm_i915_private
> *dev_priv, enum port port)
> init_dp = true;
> init_lspcon = true;
> init_hdmi = false;
> - drm_dbg_kms(&dev_priv->drm, "VBT says port %c has lspcon\n",
> - port_name(port));
> + drm_dbg_kms(&dev_priv->drm, "VBT says port %s has lspcon\n",
> + port_info->name);
> }
>
> if (!init_dp && !init_hdmi) {
> drm_dbg_kms(&dev_priv->drm,
> - "VBT says port %c is not DVI/HDMI/DP compatible,
> respect it\n",
> - port_name(port));
> + "VBT says port %s is not DVI/HDMI/DP compatible,
> respect it\n",
> + port_info->name);
> return;
> }
>
> @@ -4882,7 +4894,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> encoder = &intel_dig_port->base;
>
> drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
> - DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
> + DRM_MODE_ENCODER_TMDS, port_info->name);
>
> encoder->hotplug = intel_ddi_hotplug;
> encoder->compute_output_type = intel_ddi_compute_output_type;
> @@ -4917,8 +4929,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
> intel_dig_port->max_lanes = intel_ddi_max_lanes(intel_dig_port);
> intel_dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
> + intel_dig_port->port_info = port_info;
>
> - if (intel_phy_is_tc(dev_priv, phy)) {
> + if (intel_ddi_has_tc_phy(intel_dig_port)) {
> bool is_legacy =
> !intel_bios_port_supports_typec_usb(dev_priv, port) &&
> !intel_bios_port_supports_tbt(dev_priv, port);
> @@ -4951,20 +4964,20 @@ void intel_ddi_init(struct drm_i915_private
> *dev_priv, enum port port)
> if (lspcon_init(intel_dig_port))
> /* TODO: handle hdmi info frame part */
> drm_dbg_kms(&dev_priv->drm,
> - "LSPCON init success on port %c\n",
> - port_name(port));
> + "LSPCON init success on port %s\n",
> + port_info->name);
> else
> /*
>* LSPCON init faied, but DP init was success, so
>* lets try to drive as DP++ port.
>*/
> drm_err(&dev_priv->drm,
> - "LSPCON init failed on port %c\n",
> - port_name(port));
> + "LSPCON init failed on port %s\n",
> + port_info->name);
> }
>
> if (INTEL_GEN(dev_priv) >= 11) {
> - if (intel_p
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/display: start description-based ddi initialization
On Wed, Jul 01, 2020 at 05:20:17PM +0300, Jani Nikula wrote:
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
Start adding per-platform relevant data into a table that we use for
initialization. Intention is to keep the different indexes we need (e.g.
phy, vbt, ddi, etc) and any other differences for each platform in these
tables so we don't have to keep converting back and forth between them.
For now, just add the naked table with name. Subsequent patches will
start piping this in via intel_ddi_init().
v2: do not try to generalize the checks for port presence nor dsi
initialization. Instead focus on getting the ddi table created for all
platforms using DDI and keep their differences in the original function
I like this.
drm/i915/display: description-based initialization for remaining ddi
platforms
Stray line?
yep, happens a lot to me when squashing changes
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 141 --
.../drm/i915/display/intel_display_types.h| 5 +
2 files changed, 99 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index effd6b65f270..c234b50212b0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16805,6 +16805,83 @@ static void intel_pps_init(struct drm_i915_private
*dev_priv)
intel_pps_unlock_regs_wa(dev_priv);
}
+static const struct intel_ddi_port_info rkl_ports[] = {
+ { .name = "DDI A", .port = PORT_A },
+ { .name = "DDI B", .port = PORT_B },
+ { .name = "DDI TC1", .port = PORT_D },
+ { .name = "DDI TC2", .port = PORT_E },
+ { .port = PORT_NONE }
+};
+
+static const struct intel_ddi_port_info tgl_ports[] = {
+ { .name = "DDI A", .port = PORT_A },
+ { .name = "DDI B", .port = PORT_B },
+ { .name = "DDI TC1", .port = PORT_D },
+ { .name = "DDI TC2", .port = PORT_E },
+ { .name = "DDI TC3", .port = PORT_F },
+ { .name = "DDI TC4", .port = PORT_G },
+ { .name = "DDI TC5", .port = PORT_H },
+ { .name = "DDI TC6", .port = PORT_I },
+ { .port = PORT_NONE }
+};
+
+static const struct intel_ddi_port_info ehl_ports[] = {
+ { .name = "DDI A", .port = PORT_A },
+ { .name = "DDI B", .port = PORT_B },
+ { .name = "DDI C", .port = PORT_C },
+ { .name = "DDI D", .port = PORT_D },
+ { .port = PORT_NONE }
+};
+
+static const struct intel_ddi_port_info icl_ports[] = {
+ { .name = "DDI A", .port = PORT_A },
+ { .name = "DDI B", .port = PORT_B },
+ { .name = "DDI TC1", .port = PORT_C },
+ { .name = "DDI TC2", .port = PORT_D },
+ { .name = "DDI TC3", .port = PORT_E },
+ { .name = "DDI TC4", .port = PORT_F },
+ { .port = PORT_NONE }
+};
+
+static const struct intel_ddi_port_info gen9lp_ports[] = {
+ { .name = "DDI A", .port = PORT_A },
+ { .name = "DDI B", .port = PORT_B },
+ { .name = "DDI C", .port = PORT_C },
+ { .port = PORT_NONE }
+};
+
+static const struct intel_ddi_port_info ddi_ports[] = {
+ { .name = "DDI A", .port = PORT_A },
+ { .name = "DDI B", .port = PORT_B },
+ { .name = "DDI C", .port = PORT_C },
+ { .name = "DDI D", .port = PORT_D },
+ { .name = "DDI E", .port = PORT_E },
+ { .name = "DDI F", .port = PORT_F },
+ { .port = PORT_NONE }
+};
These make me wonder about a potential future restructuring of moving
the output setup stuff to a separate file. No need to do that here, just
throwing ideas around.
yeah, I think it would make sense to later let the tables live alone in
a single .c file. Another possibility that reduces conflicts is to have
each platform in its own .c file and either #include the .c or declare
the table as extern.
+
+/*
+ * Use a description-based approach for platforms that can be supported with a
+ * static table
+ *
+ * @disable_mask: any port that should not be enabled due to being disabled by
+ * any reason
+ */
+static void setup_ddi_outputs_desc(struct drm_i915_private *i915,
+ const struct intel_ddi_port_info *ports,
+ unsigned long disable_mask)
+{
+ const struct intel_ddi_port_info *port_info;
+
+ for (port_info = ports;
+port_info->port != PORT_NONE; port_info++) {
+ if (test_bit(port_info->port, &disable_mask))
+ continue;
+
+ intel_ddi_init(i915, port_info->port);
+ }
+}
+
static void intel_setup_outputs(struct drm_i915_private *dev_priv)
{
struct intel_encoder *encoder;
@@ -16816,46 +16893,21 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
return;
if (IS_ROCKETLAKE(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- i
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/display: fix comment on skl straps
On Tue, Jun 30, 2020 at 06:55:38PM +0300, Jani Nikula wrote: On Wed, 24 Jun 2020, Lucas De Marchi wrote: We are not checking for specific SKUs and feedback from HW team is that it may not work since it was supposed to be fixed by the same time straps stopped to be used. So, just update comment. v2: Instead of removing the check, just update the comment since feedback from HW team was that it actually may not work Signed-off-by: Lucas De Marchi Acked-by: Jani Nikula is an ack sufficient for merging a comment-only change? Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 49772c82a299..effd6b65f270 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -16863,8 +16863,9 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv) /* * Haswell uses DDI functions to detect digital outputs. -* On SKL pre-D0 the strap isn't connected, so we assume -* it's there. +* On SKL pre-D0 the strap isn't connected. Later SKUs may or +* may not have it - it was supposed to be fixed by the same +* time we stopped using straps. Assume it's there. */ found = intel_de_read(dev_priv, DDI_BUF_CTL(PORT_A)) & DDI_INIT_DISPLAY_DETECTED; /* WaIgnoreDDIAStrap: skl */ -- 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 v2 3/6] drm/i915/display: start description-based ddi initialization
On Wed, Jul 01, 2020 at 06:35:55PM +0300, Jani Nikula wrote:
On Wed, 01 Jul 2020, Jani Nikula wrote:
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
+struct intel_ddi_port_info {
Just thinking out loud, should we have a "struct port" or "struct
intel_port" instead. Maybe, maybe not. *shrug*
After reading the whole series, I might lean even more towards
introducing a struct intel_port.
Not insisting you'd have to do that as part of this series, but
something to consider. How would things look like?
I think it will be the natural next conversion, but I'd like to get the
ddi changes applied first, because the conversions will take some
time... This patch series only scratches the surface.
Lucas De Marchi
BR,
Jani.
Anyway the patch is
Reviewed-by: Jani Nikula
+ const char *name;
+ enum port port;
+};
+
static inline enum dpio_channel
vlv_dport_to_channel(struct intel_digital_port *dport)
{
--
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 v2 3/6] drm/i915/display: start description-based ddi initialization
On Wed, 01 Jul 2020, Jani Nikula wrote:
> On Wed, 24 Jun 2020, Lucas De Marchi wrote:
>>
>> +struct intel_ddi_port_info {
>
> Just thinking out loud, should we have a "struct port" or "struct
> intel_port" instead. Maybe, maybe not. *shrug*
After reading the whole series, I might lean even more towards
introducing a struct intel_port.
Not insisting you'd have to do that as part of this series, but
something to consider. How would things look like?
BR,
Jani.
>
> Anyway the patch is
>
> Reviewed-by: Jani Nikula
>
>> +const char *name;
>> +enum port port;
>> +};
>> +
>> static inline enum dpio_channel
>> vlv_dport_to_channel(struct intel_digital_port *dport)
>> {
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Move obj->lut_list under its own lock
== Series Details == Series: drm/i915/gem: Move obj->lut_list under its own lock URL : https://patchwork.freedesktop.org/series/78988/ State : success == Summary == CI Bug Log - changes from CI_DRM_8684_full -> Patchwork_18055_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18055_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-tglb2/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-tglb7/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@fences-dpms: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-kbl2/igt@i915_pm_...@fences-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-kbl6/igt@i915_pm_...@fences-dpms.html * igt@i915_pm_rpm@modeset-non-lpsp: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#95]) +16 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-apl8/igt@i915_pm_...@modeset-non-lpsp.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-apl6/igt@i915_pm_...@modeset-non-lpsp.html * igt@i915_selftest@live@blt: - shard-snb: [PASS][7] -> [DMESG-FAIL][8] ([i915#1669]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-snb5/igt@i915_selftest@l...@blt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-snb5/igt@i915_selftest@l...@blt.html * igt@kms_color@pipe-b-ctm-negative: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +16 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-skl5/igt@kms_co...@pipe-b-ctm-negative.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-skl9/igt@kms_co...@pipe-b-ctm-negative.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118] / [i915#95]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-glk4/igt@kms_cursor_...@pipe-a-cursor-128x128-rapid-movement.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-glk6/igt@kms_cursor_...@pipe-a-cursor-128x128-rapid-movement.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1: - shard-apl: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-apl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-apl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-iclb4/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-iclb8/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@b-hdmi-a1: - shard-hsw: [PASS][19] -> [INCOMPLETE][20] ([i915#2055]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-hsw7/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-hsw4/igt@kms_flip@flip-vs-suspend-interrupti...@b-hdmi-a1.html * igt@kms_flip@modeset-vs-vblank-race-interruptible@a-dp1: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-kbl2/igt@kms_flip@modeset-vs-vblank-race-interrupti...@a-dp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-kbl4/igt@kms_flip@modeset-vs-vblank-race-interrupti...@a-dp1.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt: - shard-iclb: [PASS][23] -> [DMESG-WARN][24] ([i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-iclb2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18055/shard-iclb8/igt@kms_frontbuffer_track...@fbc-rgb565-draw-blt.html
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/display: add phy, vbt and ddi indexes
On Wed, Jul 01, 2020 at 06:23:05PM +0300, Jani Nikula wrote:
On Wed, 01 Jul 2020, Jani Nikula wrote:
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
Identify 3 possible cases in which the index numbers can be different
from the "port" and add them to the description-based ddi initialization
table. This can be used in place of additional functions mapping from
one to the other. Right now we already cover part of this by creating kind of
virtual phy numbering, but that comes with downsides:
a) there's not really a "phy numbering" in the spec, this is purely a
software thing; hardware uses whatever they want thinking mapping from
one to the other arbitrarily is easy in software.
b) currently the mapping occurs on "leaf" functions, making the decision
based on the platform for each of those functions
With this new table the approach will be: the port, as defined by the
enum port, is merely a driver convention and won't be used anymore to
define the register offset or register bits. For that we have the other
3 indexes, identified as being possibly different from the current usage
of register bits: ddi, vbt and phy. The phy type is also added here,
meant to replace the checks for combo vs tc.
v2: Rebase and add RKL
I guess I'd like to see where the *_idx fields will lead before
advocating for this.
With them removed,
Ahem, ddi_idx and vbt_idx - obviously phy_idx is used, and I approve of
the use.
Another comment inline below.
Acked-by: Jani Nikula
But I'm also not saying you can't have them - until I see where this
leads. ;)
One comment inline below.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 64 ++-
drivers/gpu/drm/i915/display/intel_display.h | 8 +++
.../drm/i915/display/intel_display_types.h| 4 ++
3 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c234b50212b0..d591063502c5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16806,57 +16806,59 @@ static void intel_pps_init(struct drm_i915_private
*dev_priv)
}
static const struct intel_ddi_port_info rkl_ports[] = {
- { .name = "DDI A", .port = PORT_A },
- { .name = "DDI B", .port = PORT_B },
- { .name = "DDI TC1", .port = PORT_D },
- { .name = "DDI TC2", .port = PORT_E },
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
+ { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
+ /* TODO: use continguous namespace for port once driver is converted */
+ { .name = "DDI C", .port = PORT_D, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x3, .phy_idx = 0x2, .vbt_idx = 0x2, },
+ { .name = "DDI D", .port = PORT_E, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x4, .phy_idx = 0x3, .vbt_idx = 0x3, },
{ .port = PORT_NONE }
};
static const struct intel_ddi_port_info tgl_ports[] = {
- { .name = "DDI A", .port = PORT_A },
- { .name = "DDI B", .port = PORT_B },
- { .name = "DDI TC1", .port = PORT_D },
- { .name = "DDI TC2", .port = PORT_E },
- { .name = "DDI TC3", .port = PORT_F },
- { .name = "DDI TC4", .port = PORT_G },
- { .name = "DDI TC5", .port = PORT_H },
- { .name = "DDI TC6", .port = PORT_I },
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO,
.ddi_idx = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
+ { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO,
.ddi_idx = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
+ /* TODO: use continguous namespace for port once driver is converted */
+ { .name = "DDI TC1", .port = PORT_D, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x3, .phy_idx = 0x0, .vbt_idx = 0x2, },
+ { .name = "DDI TC2", .port = PORT_E, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x4, .phy_idx = 0x1, .vbt_idx = 0x3, },
+ { .name = "DDI TC3", .port = PORT_F, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x5, .phy_idx = 0x2, .vbt_idx = 0x4, },
+ { .name = "DDI TC4", .port = PORT_G, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x6, .phy_idx = 0x3, .vbt_idx = 0x5, },
+ { .name = "DDI TC5", .port = PORT_H, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x7, .phy_idx = 0x4, .vbt_idx = 0x6, },
+ { .name = "DDI TC6", .port = PORT_I, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x8, .phy_idx = 0x5, .vbt_idx = 0x7, },
{ .port = PORT_NONE }
};
static const struct intel_ddi_port_info ehl_ports[] = {
- { .name = "DDI A", .port = PORT_A },
- { .name = "DDI B", .port = PORT_B },
- { .name = "DDI C", .port = PORT_C },
- { .name = "DDI D", .port = PORT_D },
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
+ { .name = "DDI B", .por
Re: [Intel-gfx] [PATCH] drm/i915/guc: Expand guc_info debugfs with more information
On 7/1/2020 7:27 AM, Michał Winiarski wrote:
From: Michał Winiarski
The information about platform/driver/user view of GuC firmware usage
currently requires user to either go through kernel log or parse the
combination of "enable_guc" modparam and various debugfs entries.
Let's keep things simple and add a "supported/used/wanted" matrix
(already used internally by i915) in guc_info debugfs.
Signed-off-by: Michał Winiarski
Cc: Daniele Ceraolo Spurio
Cc: Lukasz Fiedorowicz
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 861657897c0f..446a41946f56 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -733,19 +733,28 @@ int intel_guc_allocate_and_map_vma(struct intel_guc *guc,
u32 size,
*/
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p)
{
+ struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
struct intel_gt *gt = guc_to_gt(guc);
struct intel_uncore *uncore = gt->uncore;
intel_wakeref_t wakeref;
- if (!intel_guc_is_supported(guc)) {
- drm_printf(p, "GuC not supported\n");
+ drm_printf(p, "[guc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc(uc)),
+ yesno(intel_uc_wants_guc(uc)),
+ yesno(intel_uc_uses_guc(uc)));
There are intel_guc equivalents for there uc functions, so we can use
those and avoid the intel_uc var if we ditch the HuC (see comment below):
intel_guc_is_supported
intel_guc_is_wanted
intel_guc_is_used
Same for the others.
+ drm_printf(p, "[huc] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_huc(uc)),
+ yesno(intel_uc_wants_huc(uc)),
+ yesno(intel_uc_uses_huc(uc)));
The HuC view should go to the huc_info debugfs
+ drm_printf(p, "[submission] supported:%s wanted:%s used:%s\n",
+ yesno(intel_uc_supports_guc_submission(uc)),
+ yesno(intel_uc_wants_guc_submission(uc)),
+ yesno(intel_uc_uses_guc_submission(uc)));
+
+ if (!intel_guc_is_supported(guc) || !intel_guc_is_wanted(guc))
intel_guc_is_wanted implies intel_guc_is_supported so you can
potentially test only that, but I agree that having both is clearer to read.
Daniele
return;
- }
- if (!intel_guc_is_wanted(guc)) {
- drm_printf(p, "GuC disabled\n");
- return;
- }
+ drm_puts(p, "\n");
intel_uc_fw_dump(&guc->fw, p);
___
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 drm/i915/gt: Harden the heartbeat against a stuck driver (rev2)
== Series Details == Series: series starting with drm/i915/gt: Harden the heartbeat against a stuck driver (rev2) URL : https://patchwork.freedesktop.org/series/78986/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8684_full -> Patchwork_18056_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18056_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18056_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_18056_full: ### IGT changes ### Possible regressions * igt@kms_cursor_crc@pipe-a-cursor-256x85-random: - shard-hsw: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-hsw7/igt@kms_cursor_...@pipe-a-cursor-256x85-random.html Known issues Here are the changes found in Patchwork_18056_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - shard-tglb: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-tglb2/igt@i915_module_l...@reload.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-tglb2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@modeset-non-lpsp: - shard-apl: [PASS][4] -> [DMESG-WARN][5] ([i915#1635] / [i915#95]) +25 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-apl8/igt@i915_pm_...@modeset-non-lpsp.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-apl6/igt@i915_pm_...@modeset-non-lpsp.html * igt@i915_selftest@mock@requests: - shard-glk: [PASS][6] -> [INCOMPLETE][7] ([i915#2110] / [i915#58] / [k.org#198133]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-glk1/igt@i915_selftest@m...@requests.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-glk4/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@x-tiled-64bpp-rotate-180: - shard-glk: [PASS][8] -> [DMESG-FAIL][9] ([i915#118] / [i915#95]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-glk1/igt@kms_big...@x-tiled-64bpp-rotate-180.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: - shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#93] / [i915#95]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html * igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge: - shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-skl6/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-skl7/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#46]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html * igt@kms_frontbuffer_tracking@psr-farfromfence: - shard-tglb: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-tglb3/igt@kms_frontbuffer_track...@psr-farfromfence.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-tglb5/igt@kms_frontbuffer_track...@psr-farfromfence.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#1188]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-skl4/igt@kms_...@bpc-switch.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-skl5/igt@kms_...@bpc-switch.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) +4 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8684/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18056/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-rea
Re: [Intel-gfx] [PATCH] drm/i915/guc: Expand guc_info debugfs with more information
On Wed, 2020-07-01 at 16:27 +0200, Michał Winiarski wrote:
> From: Michał Winiarski
>
> The information about platform/driver/user view of GuC firmware usage
> currently requires user to either go through kernel log or parse the
> combination of "enable_guc" modparam and various debugfs entries.
> Let's keep things simple and add a "supported/used/wanted" matrix
> (already used internally by i915) in guc_info debugfs.
>
> Signed-off-by: Michał Winiarski
LGTM
Reviewed-by: Lukasz Fiedorowicz
> Cc: Daniele Ceraolo Spurio
> Cc: Lukasz Fiedorowicz
> Cc: Michal Wajdeczko
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index 861657897c0f..446a41946f56 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -733,19 +733,28 @@ int intel_guc_allocate_and_map_vma(struct
> intel_guc *guc, u32 size,
> */
> void intel_guc_load_status(struct intel_guc *guc, struct drm_printer
> *p)
> {
> + struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
> struct intel_gt *gt = guc_to_gt(guc);
> struct intel_uncore *uncore = gt->uncore;
> intel_wakeref_t wakeref;
>
> - if (!intel_guc_is_supported(guc)) {
> - drm_printf(p, "GuC not supported\n");
> + drm_printf(p, "[guc] supported:%s wanted:%s used:%s\n",
> +yesno(intel_uc_supports_guc(uc)),
> +yesno(intel_uc_wants_guc(uc)),
> +yesno(intel_uc_uses_guc(uc)));
> + drm_printf(p, "[huc] supported:%s wanted:%s used:%s\n",
> +yesno(intel_uc_supports_huc(uc)),
> +yesno(intel_uc_wants_huc(uc)),
> +yesno(intel_uc_uses_huc(uc)));
> + drm_printf(p, "[submission] supported:%s wanted:%s used:%s\n",
> +yesno(intel_uc_supports_guc_submission(uc)),
> +yesno(intel_uc_wants_guc_submission(uc)),
> +yesno(intel_uc_uses_guc_submission(uc)));
> +
> + if (!intel_guc_is_supported(guc) || !intel_guc_is_wanted(guc))
> return;
> - }
>
> - if (!intel_guc_is_wanted(guc)) {
> - drm_printf(p, "GuC disabled\n");
> - return;
> - }
> + drm_puts(p, "\n");
>
> intel_uc_fw_dump(&guc->fw, p);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/display: replace port to phy conversions in intel_ddi.c
On Wed, Jul 01, 2020 at 06:17:09PM +0300, Jani Nikula wrote:
On Wed, 24 Jun 2020, Lucas De Marchi wrote:
This is the first level conversion to use port_info directly from
intel_digital_port, rather than derive the phy or tc_port from the port.
This touches only the functions which have the encoder or dig_port
directly available.
Overall I like it, some nitpicks and notes inline.
Eventually we'll probably want to convert the "tc_port" in register
macros to "phy" or something, but no rush.
yes, that's the plan... eventually get rid of tc_port.
With the issues fixed,
Reviewed-by: Jani Nikula
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_ddi.c | 158 +++
1 file changed, 77 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 27e2f29f47a2..aa0b478ab54a 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1061,11 +1061,11 @@ tgl_get_dkl_buf_trans(struct drm_i915_private
*dev_priv, int type, int rate,
static int intel_ddi_hdmi_level(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
int n_entries, level, default_entry;
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
if (INTEL_GEN(dev_priv) >= 12) {
- if (intel_phy_is_combo(dev_priv, phy))
+ if (intel_ddi_has_combo_phy(dig_port))
Btw why the "is" -> "has" in the function name?
because I wanted it in the intel_ddi_ "namespace". Reading on how the HW
is architected, I think it's more correct to say a DDI has combo phy or
"is attached to" a combo phy than "it *is* a combo phy" since the phy is
a separate entity.
previously it was intel_phy_, so the "is" was a natural choice.
tgl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
0, &n_entries);
else
@@ -1073,7 +1073,7 @@ static int intel_ddi_hdmi_level(struct intel_encoder
*encoder)
&n_entries);
default_entry = n_entries - 1;
} else if (INTEL_GEN(dev_priv) == 11) {
- if (intel_phy_is_combo(dev_priv, phy))
+ if (intel_ddi_has_combo_phy(dig_port))
icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
0, &n_entries);
else
@@ -1453,9 +1453,9 @@ static void intel_ddi_clock_get(struct intel_encoder
*encoder,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
- if (intel_phy_is_tc(dev_priv, phy) &&
+ if (intel_ddi_has_tc_phy(dig_port) &&
intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll) ==
DPLL_ID_ICL_TBTPLL)
pipe_config->port_clock = icl_calc_tbt_pll_link(dev_priv,
@@ -1983,7 +1983,6 @@ static void intel_ddi_get_power_domains(struct
intel_encoder *encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port;
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
/*
* TODO: Add support for MST encoders. Atm, the following should never
@@ -1996,7 +1995,7 @@ static void intel_ddi_get_power_domains(struct
intel_encoder *encoder,
dig_port = enc_to_dig_port(encoder);
- if (!intel_phy_is_tc(dev_priv, phy) ||
+ if (!intel_ddi_has_tc_phy(dig_port) ||
dig_port->tc_mode != TC_PORT_TBT_ALT)
intel_display_power_get(dev_priv,
dig_port->ddi_io_power_domain);
@@ -2006,7 +2005,7 @@ static void intel_ddi_get_power_domains(struct
intel_encoder *encoder,
* ports.
*/
if (intel_crtc_has_dp_encoder(crtc_state) ||
- intel_phy_is_tc(dev_priv, phy))
+ intel_ddi_has_tc_phy(dig_port))
intel_display_power_get(dev_priv,
intel_ddi_main_link_aux_domain(dig_port));
@@ -2142,14 +2141,14 @@ static void bxt_ddi_vswing_sequence(struct
intel_encoder *encoder,
static u8 intel_ddi_dp_voltage_max(struct intel_dp *intel_dp)
{
- struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = &dig_port->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
- enum phy phy = intel_port_to_phy(dev_priv, port);
int n_entries;
Re: [Intel-gfx] [PATCH] drm/i915: Reboot CI if we get wedged during driver init
On 01.07.2020 17:17, Chris Wilson wrote: > Quoting Michał Winiarski (2020-07-01 16:07:21) >> From: Michał Winiarski >> >> Getting wedged device on driver init is pretty much unrecoverable. >> Since we're running verious scenarios that may potentially hit this in typo >> CI (module reload / selftests / hotunplug), and if it happens, it means >> that we can't trust any subsequent CI results, we should just apply the >> taint to let the CI know that it should reboot (CI checks taint between >> test runs). >> >> Signed-off-by: Michał Winiarski >> Cc: Chris Wilson >> Cc: Petri Latvala >> --- >> drivers/gpu/drm/i915/gt/intel_reset.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c >> b/drivers/gpu/drm/i915/gt/intel_reset.c >> index 0156f1f5c736..d27e8bb7d550 100644 >> --- a/drivers/gpu/drm/i915/gt/intel_reset.c >> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c >> @@ -1360,6 +1360,8 @@ void intel_gt_set_wedged_on_init(struct intel_gt *gt) >> I915_WEDGED_ON_INIT); >> intel_gt_set_wedged(gt); >> set_bit(I915_WEDGED_ON_INIT, >->reset.flags); >> + > > Ah, we don't say around here that this WEDGED_ON_INIT is non-recoverable, > could you please add a comment to that effect? > Such comment is already in WEDGED_ON_INIT description, but repeating it will definitely help >> + add_taint_for_CI(TAINT_WARN); btw, today we are tainting kernel for CI silently and from different places, so maybe it is worth to add there some debug log with __builtin_return_address() for better diagnose why we stopped CI? with typo/comment fixed, Reviewed-by: Michal Wajdeczko >> } >> >> void intel_gt_init_reset(struct intel_gt *gt) >> -- >> 2.27.0 >> > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/display: add phy, vbt and ddi indexes
On Wed, Jun 24, 2020 at 05:11:18PM -0700, Lucas De Marchi wrote:
> Identify 3 possible cases in which the index numbers can be different
> from the "port" and add them to the description-based ddi initialization
> table. This can be used in place of additional functions mapping from
> one to the other. Right now we already cover part of this by creating kind of
> virtual phy numbering, but that comes with downsides:
>
> a) there's not really a "phy numbering" in the spec, this is purely a
> software thing; hardware uses whatever they want thinking mapping from
> one to the other arbitrarily is easy in software.
>
> b) currently the mapping occurs on "leaf" functions, making the decision
> based on the platform for each of those functions
>
> With this new table the approach will be: the port, as defined by the
> enum port, is merely a driver convention and won't be used anymore to
> define the register offset or register bits. For that we have the other
> 3 indexes, identified as being possibly different from the current usage
> of register bits: ddi, vbt and phy. The phy type is also added here,
> meant to replace the checks for combo vs tc.
>
> v2: Rebase and add RKL
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 64 ++-
> drivers/gpu/drm/i915/display/intel_display.h | 8 +++
> .../drm/i915/display/intel_display_types.h| 4 ++
> 3 files changed, 45 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c234b50212b0..d591063502c5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16806,57 +16806,59 @@ static void intel_pps_init(struct drm_i915_private
> *dev_priv)
> }
>
> static const struct intel_ddi_port_info rkl_ports[] = {
> - { .name = "DDI A", .port = PORT_A },
> - { .name = "DDI B", .port = PORT_B },
> - { .name = "DDI TC1", .port = PORT_D },
> - { .name = "DDI TC2", .port = PORT_E },
> + { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
I'm thinking we won't need ddi_idx and instead 'port' should suffice.
We can add the aliases with the TC names for tgl+ to unconfuse the
current mess. In fact I already tried that in a local branch (while
doing the hpd_pin cleanup) and it looks mostly fine to me. There are
a few annoying parts, like power domains, where we still end up with
port G-I names that don't exist anywhere in bspec (excetp in VBT).
Not really sure about the other bare numbers you're using here either.
Migth just make things less confusing if we don't have names for many
things. So I think enums would be better.
And I think this stuff should probably go into intel_ddi.c instead
of intel_display.c.
> + { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
> + /* TODO: use continguous namespace for port once driver is converted */
> + { .name = "DDI C", .port = PORT_D, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x3, .phy_idx = 0x2, .vbt_idx = 0x2, },
> + { .name = "DDI D", .port = PORT_E, .phy_type = PHY_TYPE_COMBO, .ddi_idx
> = 0x4, .phy_idx = 0x3, .vbt_idx = 0x3, },
> { .port = PORT_NONE }
> };
>
> static const struct intel_ddi_port_info tgl_ports[] = {
> - { .name = "DDI A", .port = PORT_A },
> - { .name = "DDI B", .port = PORT_B },
> - { .name = "DDI TC1", .port = PORT_D },
> - { .name = "DDI TC2", .port = PORT_E },
> - { .name = "DDI TC3", .port = PORT_F },
> - { .name = "DDI TC4", .port = PORT_G },
> - { .name = "DDI TC5", .port = PORT_H },
> - { .name = "DDI TC6", .port = PORT_I },
> + { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO,
> .ddi_idx = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
> + { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO,
> .ddi_idx = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
> + /* TODO: use continguous namespace for port once driver is converted */
> + { .name = "DDI TC1", .port = PORT_D, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x3, .phy_idx = 0x0, .vbt_idx = 0x2, },
> + { .name = "DDI TC2", .port = PORT_E, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x4, .phy_idx = 0x1, .vbt_idx = 0x3, },
> + { .name = "DDI TC3", .port = PORT_F, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x5, .phy_idx = 0x2, .vbt_idx = 0x4, },
> + { .name = "DDI TC4", .port = PORT_G, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x6, .phy_idx = 0x3, .vbt_idx = 0x5, },
> + { .name = "DDI TC5", .port = PORT_H, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x7, .phy_idx = 0x4, .vbt_idx = 0x6, },
> + { .name = "DDI TC6", .port = PORT_I, .phy_type = PHY_TYPE_DKL,
> .ddi_idx = 0x8, .phy_idx = 0x5, .vbt_idx = 0x7, },
> { .port = PORT_NONE }
> };
>
> static const struct intel_ddi_
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/display: add phy, vbt and ddi indexes
On Wed, Jul 01, 2020 at 08:04:30PM +0300, Ville Syrjälä wrote:
On Wed, Jun 24, 2020 at 05:11:18PM -0700, Lucas De Marchi wrote:
Identify 3 possible cases in which the index numbers can be different
from the "port" and add them to the description-based ddi initialization
table. This can be used in place of additional functions mapping from
one to the other. Right now we already cover part of this by creating kind of
virtual phy numbering, but that comes with downsides:
a) there's not really a "phy numbering" in the spec, this is purely a
software thing; hardware uses whatever they want thinking mapping from
one to the other arbitrarily is easy in software.
b) currently the mapping occurs on "leaf" functions, making the decision
based on the platform for each of those functions
With this new table the approach will be: the port, as defined by the
enum port, is merely a driver convention and won't be used anymore to
define the register offset or register bits. For that we have the other
3 indexes, identified as being possibly different from the current usage
of register bits: ddi, vbt and phy. The phy type is also added here,
meant to replace the checks for combo vs tc.
v2: Rebase and add RKL
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 64 ++-
drivers/gpu/drm/i915/display/intel_display.h | 8 +++
.../drm/i915/display/intel_display_types.h| 4 ++
3 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c234b50212b0..d591063502c5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16806,57 +16806,59 @@ static void intel_pps_init(struct drm_i915_private
*dev_priv)
}
static const struct intel_ddi_port_info rkl_ports[] = {
- { .name = "DDI A", .port = PORT_A },
- { .name = "DDI B", .port = PORT_B },
- { .name = "DDI TC1", .port = PORT_D },
- { .name = "DDI TC2", .port = PORT_E },
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
I'm thinking we won't need ddi_idx and instead 'port' should suffice.
We can add the aliases with the TC names for tgl+ to unconfuse the
current mess. In fact I already tried that in a local branch (while
doing the hpd_pin cleanup) and it looks mostly fine to me. There are
a few annoying parts, like power domains, where we still end up with
port G-I names that don't exist anywhere in bspec (excetp in VBT).
I think we should stop trying that because it leads to the current mess
we put ourselves into. Hence my idea of "port should be just a software
thing, don't try to make it match the hardware". HW indexes (for register
address, bitfields and whatnot) are provided by the correspondent _idx.
Which index you use depends on what part of the hw you are talking to.
See the TODO below of one case this would be true. Once the conversions
are finished we change them and then for every ddi+ platform, port is
just a number we can use to identify the entry in the table.
Lucas De Marchi
Not really sure about the other bare numbers you're using here either.
Migth just make things less confusing if we don't have names for many
things. So I think enums would be better.
And I think this stuff should probably go into intel_ddi.c instead
of intel_display.c.
+ { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
+ /* TODO: use continguous namespace for port once driver is converted */
+ { .name = "DDI C", .port = PORT_D, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x3, .phy_idx = 0x2, .vbt_idx = 0x2, },
+ { .name = "DDI D", .port = PORT_E, .phy_type = PHY_TYPE_COMBO, .ddi_idx
= 0x4, .phy_idx = 0x3, .vbt_idx = 0x3, },
{ .port = PORT_NONE }
};
static const struct intel_ddi_port_info tgl_ports[] = {
- { .name = "DDI A", .port = PORT_A },
- { .name = "DDI B", .port = PORT_B },
- { .name = "DDI TC1", .port = PORT_D },
- { .name = "DDI TC2", .port = PORT_E },
- { .name = "DDI TC3", .port = PORT_F },
- { .name = "DDI TC4", .port = PORT_G },
- { .name = "DDI TC5", .port = PORT_H },
- { .name = "DDI TC6", .port = PORT_I },
+ { .name = "DDI A", .port = PORT_A, .phy_type = PHY_TYPE_COMBO,
.ddi_idx = 0x0, .phy_idx = 0x0, .vbt_idx = 0x0, },
+ { .name = "DDI B", .port = PORT_B, .phy_type = PHY_TYPE_COMBO,
.ddi_idx = 0x1, .phy_idx = 0x1, .vbt_idx = 0x1, },
+ /* TODO: use continguous namespace for port once driver is converted */
+ { .name = "DDI TC1", .port = PORT_D, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x3, .phy_idx = 0x0, .vbt_idx = 0x2, },
+ { .name = "DDI TC2", .port = PORT_E, .phy_type = PHY_TYPE_DKL,
.ddi_idx = 0x4, .phy_idx = 0x1, .vbt_idx = 0x3, },
+ { .name = "DDI TC3"
[Intel-gfx] [PATCH] drm/i915: Fix the old vs. new epoch counter check during hotplug detect
The old epoch counter was left uninited, so the function returned a
changed state always.
While at it debug print the old epoch counter as well.
Fixes: 35205ee9ba46 ("drm/i915: Send hotplug event if edid had changed")
Cc: Kunal Joshi
Cc: Stanislav Lisovskiy
Cc: Maarten Lankhorst
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 80bcfff032e9..3f1d7b804a66 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -288,6 +288,7 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
old_status = connector->base.status;
+ old_epoch_counter = connector->base.epoch_counter;
connector->base.status =
drm_helper_probe_detect(&connector->base, NULL, false);
@@ -296,11 +297,12 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
ret = true;
if (ret) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s(epoch counter %llu)\n",
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to %s
(epoch counter %llu->%llu)\n",
connector->base.base.id,
connector->base.name,
drm_get_connector_status_name(old_status),
drm_get_connector_status_name(connector->base.status),
+ old_epoch_counter,
connector->base.epoch_counter);
return INTEL_HOTPLUG_CHANGED;
}
--
2.23.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmc: Use firmware v2.02 for RKL
== Series Details == Series: drm/i915/dmc: Use firmware v2.02 for RKL URL : https://patchwork.freedesktop.org/series/78989/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8685_full -> Patchwork_18057_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18057_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18057_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_18057_full: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s4-devices: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-iclb6/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-iclb6/igt@gem_exec_susp...@basic-s4-devices.html Known issues Here are the changes found in Patchwork_18057_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-fds-priority-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-glk3/igt@gem_exec_whis...@basic-fds-priority-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-glk8/igt@gem_exec_whis...@basic-fds-priority-all.html * igt@gem_mmap_gtt@ptrace: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#95]) +20 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-apl1/igt@gem_mmap_...@ptrace.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-apl3/igt@gem_mmap_...@ptrace.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-tglb1/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-tglb8/igt@i915_module_l...@reload.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#454]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-iclb1/igt@i915_pm...@dc6-psr.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-iclb8/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] / [i915#95]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html * igt@kms_cursor_edge_walk@pipe-a-256x256-right-edge: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +7 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-skl6/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-skl2/igt@kms_cursor_edge_w...@pipe-a-256x256-right-edge.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-kbl2/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-kbl1/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-suspend-interruptible@c-edp1: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#198]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-skl1/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-skl5/igt@kms_flip@flip-vs-suspend-interrupti...@c-edp1.html * igt@kms_flip@modeset-vs-vblank-race-interruptible@a-edp1: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-tglb3/igt@kms_flip@modeset-vs-vblank-race-interrupti...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18057/shard-tglb7/igt@kms_flip@modeset-vs-vblank-race-interrupti...@a-edp1.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8685/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [22]: https
[Intel-gfx] [PATCH] drm/i915: do not read swizzle info if unavailable
Since gen8 we don't use swizzle anymore. Don't dump registers related to
it: registers may or may not be there.
Cc: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8594a8ef08ce..d9e56eee0453 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1138,13 +1138,17 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
struct intel_uncore *uncore = &dev_priv->uncore;
intel_wakeref_t wakeref;
- wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
-
seq_printf(m, "bit6 swizzle for X-tiling = %s\n",
swizzle_string(dev_priv->ggtt.bit_6_swizzle_x));
seq_printf(m, "bit6 swizzle for Y-tiling = %s\n",
swizzle_string(dev_priv->ggtt.bit_6_swizzle_y));
+ /* On BDW+, swizzling is not used. See detect_bit_6_swizzle() */
+ if (INTEL_GEN(dev_priv) >= 8 || IS_VALLEYVIEW(dev_priv))
+ return 0;
+
+ wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
+
if (IS_GEN_RANGE(dev_priv, 3, 4)) {
seq_printf(m, "DDC = 0x%08x\n",
intel_uncore_read(uncore, DCC));
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix the old vs. new epoch counter check during hotplug detect
== Series Details ==
Series: drm/i915: Fix the old vs. new epoch counter check during hotplug detect
URL : https://patchwork.freedesktop.org/series/79006/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8688 -> Patchwork_18060
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/index.html
Known issues
Here are the changes found in Patchwork_18060 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#402])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-tgl-u2/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-kbl-7560u}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_force_connector_basic@force-connector-state:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18060/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (44 -> 37)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8688 -> Patchwork_18060
CI-20190529: 20190529
CI_DRM_8688: e732088e2eb2bbb1c
Re: [Intel-gfx] [PATCH v1] drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K
On Wed, Jul 01, 2020 at 02:20:28PM +0200, Maarten Lankhorst wrote:
> Op 30-06-2020 om 13:26 schreef Stanislav Lisovskiy:
> > We still need "Bump up CDCLK" workaround otherwise getting
> > underruns - however currently it blocks 8K as CDCLK = Pixel rate,
> > in 8K case would require CDCLK to be around 1 Ghz which is not
> > possible.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 45f7f33d1144..01a5bc6b08c4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2080,9 +2080,21 @@ int intel_crtc_compute_min_cdclk(const struct
> > intel_crtc_state *crtc_state)
> > * Explicitly stating here that this seems to be currently
> > * rather a Hack, than final solution.
> > */
> > - if (IS_TIGERLAKE(dev_priv))
> > + if (IS_TIGERLAKE(dev_priv)) {
> > min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> >
> > + /*
> > +* Clamp to max_cdclk_freq in order not to break an 8K,
> > +* but still leave W/A at place.
> > +*/
> > + min_cdclk = min(min_cdclk, (int)dev_priv->max_cdclk_freq);
> > +
> > + /*
> > +* max_cdclk_freq check obviously not needed - just return.
> > +*/
> > + return min_cdclk;
> > + }
> > +
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > drm_dbg_kms(&dev_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>
> Wouldn't you just have to halve pixel_rate if bigjoiner flag is set?
We dont have big joiner patches pulled in yet, this is just for the 2p2p
configuration
Manasi
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: do not read swizzle info if unavailable
== Series Details ==
Series: drm/i915: do not read swizzle info if unavailable
URL : https://patchwork.freedesktop.org/series/79007/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8688 -> Patchwork_18061
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/index.html
Known issues
Here are the changes found in Patchwork_18061 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#402])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-tgl-u2/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-tgl-u2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
* igt@kms_force_connector_basic@force-connector-state:
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-tgl-dsi/igt@kms_force_connector_ba...@force-connector-state.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +5 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8688/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18061/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (44 -> 37)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8688 -> Patchwork_18061
CI-20190529: 20190529
CI_DRM_8688: e732088e2eb2bbb1ca72c1f68d0405f17477d446 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5719: 54731f017df8660f29cc8f5db0b570239729e808 @
git://a
Re: [Intel-gfx] [PATCH] drm/i915: Fix the old vs. new epoch counter check during hotplug detect
On Wed, Jul 01, 2020 at 09:00:01PM +0300, Imre Deak wrote:
> The old epoch counter was left uninited, so the function returned a
> changed state always.
>
> While at it debug print the old epoch counter as well.
>
> Fixes: 35205ee9ba46 ("drm/i915: Send hotplug event if edid had changed")
> Cc: Kunal Joshi
> Cc: Stanislav Lisovskiy
> Cc: Maarten Lankhorst
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_hotplug.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index 80bcfff032e9..3f1d7b804a66 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -288,6 +288,7 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
>
> drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
> old_status = connector->base.status;
> + old_epoch_counter = connector->base.epoch_counter;
Yep..did it in drm_helper_hpd_irq_event but forgot here..
Thank you very much for spotting!
Reviewed-by: Stanislav Lisovskiy
>
> connector->base.status =
> drm_helper_probe_detect(&connector->base, NULL, false);
> @@ -296,11 +297,12 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> ret = true;
>
> if (ret) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
> %s(epoch counter %llu)\n",
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to %s
> (epoch counter %llu->%llu)\n",
> connector->base.base.id,
> connector->base.name,
> drm_get_connector_status_name(old_status),
>
> drm_get_connector_status_name(connector->base.status),
> + old_epoch_counter,
> connector->base.epoch_counter);
> return INTEL_HOTPLUG_CHANGED;
> }
> --
> 2.23.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K
On Wed, Jul 01, 2020 at 11:44:04AM -0700, Manasi Navare wrote:
> On Wed, Jul 01, 2020 at 02:20:28PM +0200, Maarten Lankhorst wrote:
> > Op 30-06-2020 om 13:26 schreef Stanislav Lisovskiy:
> > > We still need "Bump up CDCLK" workaround otherwise getting
> > > underruns - however currently it blocks 8K as CDCLK = Pixel rate,
> > > in 8K case would require CDCLK to be around 1 Ghz which is not
> > > possible.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 14 +-
> > > 1 file changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 45f7f33d1144..01a5bc6b08c4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2080,9 +2080,21 @@ int intel_crtc_compute_min_cdclk(const struct
> > > intel_crtc_state *crtc_state)
> > >* Explicitly stating here that this seems to be currently
> > >* rather a Hack, than final solution.
> > >*/
> > > - if (IS_TIGERLAKE(dev_priv))
> > > + if (IS_TIGERLAKE(dev_priv)) {
> > > min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> > >
> > > + /*
> > > + * Clamp to max_cdclk_freq in order not to break an 8K,
> > > + * but still leave W/A at place.
> > > + */
> > > + min_cdclk = min(min_cdclk, (int)dev_priv->max_cdclk_freq);
> > > +
> > > + /*
> > > + * max_cdclk_freq check obviously not needed - just return.
> > > + */
> > > + return min_cdclk;
> > > + }
> > > +
> > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > drm_dbg_kms(&dev_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
> > Wouldn't you just have to halve pixel_rate if bigjoiner flag is set?
>
> We dont have big joiner patches pulled in yet, this is just for the 2p2p
> configuration
>
> Manasi
Also it would make more sense if we wanted this to stay here, however I still
want
to believe that some day(R) we figure out proper solution. Otherwise yep, we
would
need some logic to check if the pixel rate should be divided and etc..
Stan
>
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: do not read swizzle info if unavailable
Quoting Lucas De Marchi (2020-07-01 19:36:26) > Since gen8 we don't use swizzle anymore. Don't dump registers related to > it: registers may or may not be there. > > Cc: Matt Roper > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/i915_debugfs.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 8594a8ef08ce..d9e56eee0453 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -1138,13 +1138,17 @@ static int i915_swizzle_info(struct seq_file *m, void > *data) > struct intel_uncore *uncore = &dev_priv->uncore; > intel_wakeref_t wakeref; > > - wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm); > - > seq_printf(m, "bit6 swizzle for X-tiling = %s\n", >swizzle_string(dev_priv->ggtt.bit_6_swizzle_x)); > seq_printf(m, "bit6 swizzle for Y-tiling = %s\n", >swizzle_string(dev_priv->ggtt.bit_6_swizzle_y)); I'm really tempted to say kill this, it's past the point of usefulness. There's one user in igt, who can just use the information provided via the get_tiling_ioctl. However, if you pull the if (dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) seq_puts(m, "L-shaped memory detected\n"); here to before the register read out as well (as that is also plain driver state), you have a deal. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/33] drm/i915/gt: Infrastructure for ring scheduling
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip]
[cannot apply to v5.8-rc3 next-20200701]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Harden-the-heartbeat-against-a-stuck-driver/20200701-164638
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
c8f1d442d0858f66fd4128fde6f67eb5202fa2b1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:44:42: warning: implicit
>> conversion from 'u64' (aka 'unsigned long long') to 'int' changes value from
>> 18446744073709551615 to -1 [-Wconstant-conversion]
return rb ? to_priolist(rb)->deadline : I915_DEADLINE_NEVER;
~~ ^~~
drivers/gpu/drm/i915/i915_scheduler_types.h:87:29: note: expanded from macro
'I915_DEADLINE_NEVER'
#define I915_DEADLINE_NEVER U64_MAX
^~~
include/linux/limits.h:22:19: note: expanded from macro 'U64_MAX'
#define U64_MAX ((u64)~0ULL)
^~
drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:42:19: warning: unused
function 'queue_deadline' [-Wunused-function]
static inline int queue_deadline(struct rb_node *rb)
^
>> drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:47:20: warning: function
>> 'reset_in_progress' is not needed and will not be emitted
>> [-Wunneeded-internal-declaration]
static inline bool reset_in_progress(const struct intel_engine_execlists *el)
^
drivers/gpu/drm/i915/gt/intel_ring_scheduler.c:115:20: warning: unused
function 'ring_map_dw' [-Wunused-function]
static inline u32 *ring_map_dw(struct intel_ring *ring, u32 len)
^
4 warnings generated.
vim +44 drivers/gpu/drm/i915/gt/intel_ring_scheduler.c
41
> 42 static inline int queue_deadline(struct rb_node *rb)
43 {
> 44 return rb ? to_priolist(rb)->deadline : I915_DEADLINE_NEVER;
45 }
46
> 47 static inline bool reset_in_progress(const struct
intel_engine_execlists *el)
48 {
49 return unlikely(!__tasklet_is_enabled(&el->tasklet));
50 }
51
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
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/dp: Correctly advertise HBR3 for GEN11+ (rev2)
== Series Details == Series: drm/i915/dp: Correctly advertise HBR3 for GEN11+ (rev2) URL : https://patchwork.freedesktop.org/series/61546/ State : success == Summary == CI Bug Log - changes from CI_DRM_8679_full -> Patchwork_18050_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18050_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@prime: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#750]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-tglb6/igt@drm_import_exp...@prime.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-tglb5/igt@drm_import_exp...@prime.html * igt@gem_workarounds@suspend-resume: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#69]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl6/igt@gem_workarou...@suspend-resume.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl1/igt@gem_workarou...@suspend-resume.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-kbl6/igt@i915_susp...@debugfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-kbl6/igt@i915_susp...@debugfs-reader.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +12 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl6/igt@kms_co...@pipe-c-ctm-0-25.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl2/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-kbl4/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html * igt@kms_cursor_edge_walk@pipe-c-128x128-left-edge: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-kbl7/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-kbl6/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1635] / [i915#95]) +9 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-apl8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-apl8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-pwrite.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl7/igt@kms_...@bpc-switch-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl8/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][21] -> [DMESG-FAIL][22] ([fdo#108145] / [i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_prime@basic-crc@second-to-first: - shard-kbl: [PASS][23] -> [DMESG-FAIL][24] ([i915#95]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8679/shard-kbl1/igt@kms_prime@basic-...@second-to-first.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18050/shard-kbl1/igt@kms_prime@basic-...@second-to-first.ht
Re: [Intel-gfx] [PATCH 00/59] Add support for Keem Bay DRM driver
Thanks much Sam for reviewing the code so quickly. I'll address your reviews in v2. Anitha > -Original Message- > From: Sam Ravnborg > Sent: Wednesday, July 1, 2020 12:01 AM > To: Chrisanthus, Anitha > Cc: dri-de...@lists.freedesktop.org; Paauwe, Bob J ; > Dea, Edmund J ; Vetter, Daniel > ; intel-gfx@lists.freedesktop.org; Vivi, Rodrigo > > Subject: Re: [PATCH 00/59] Add support for Keem Bay DRM driver > > Hi Anitha. > > On Tue, Jun 30, 2020 at 02:27:12PM -0700, Anitha Chrisanthus wrote: > > This is a new DRM driver for Intel's KeemBay SOC. > > The SoC couples an ARM Cortex A53 CPU with an Intel > > Movidius VPU. > ... > Nice and informative intro - thanks. > > The patchset looks more like a dump of current state and less like a > logical set of changes - as the few I looked at changed code introduced > in earlier patches. > So I ended up applying all patches to a local branch. > Very good to post an WIP version so you can capture some early > feedback. > It is never fun to think something is finished and then address a lot of > feedback. > > > Some general remarks after reading/browsing some of the code: > - Embeds drm_device - good > - Uses SPDX, good. But includes also a license text. Can we > get rid of the redundandt license text? > - Some of the inline functions in kmb_drv.h is too large > (kmb_write_bits_mipi()) > - There is stray code commented out using "//" here and there - shall be > dropped. > - Please arrange include files in blocks: > #include > > #include > > #include > > #include "kmb_*" > > Within each block sort alphabetially. > > - Use a kmb_ prefix or similar for global variables - like under_flow > - no extern in .c files - plane_status > - Consider using an array for the clk's > - In general use drm_info(), drm_err() for logging. > Yes, you will need to pass kmb_drm_private around to do so > - Do not use drm_device->dev_private, it is deprecated. Use upclassing > - kmb_driver can be slimmed a lot. See what recent drivers uses. There is > some nice defines so it is obvious what is not standard. > DRIVER_HAVE_IRQ is not relevant btw. > - Start using drmm_* support. The way kmb_drm_private is allocated > is sub-optimal > > The above was my fist drive-by comments - but do not be discouraged. > For the most part they should be easy to address. > Looking forward for other feedback and for v2. > > Let me know if the above triggers any questions. > > > +--++-++---+ > > |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter | > > +--++-++---+ > > Question to dri-devel people: > Would the Mipi DSI be better represented outside the display driver? > If yes, how? > > Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
