[Intel-gfx] ✓ Fi.CI.IGT: success for Add gamma/degamma LUT validation helper
== Series Details == Series: Add gamma/degamma LUT validation helper URL : https://patchwork.freedesktop.org/series/54023/ State : success == Summary == CI Bug Log - changes from CI_DRM_5315_full -> Patchwork_11092_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11092_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11092_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_11092_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-snb: SKIP -> PASS Known issues Here are the changes found in Patchwork_11092_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-blt: - shard-skl: NOTRUN -> FAIL [fdo#103158] * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +3 * igt@kms_busy@extended-modeset-hang-newfb-render-b: - shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#107882] * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-skl: NOTRUN -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move: - shard-glk: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: PASS -> FAIL [fdo#103167] +6 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-move: - shard-iclb: NOTRUN -> FAIL [fdo#103167] * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] +1 - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_rmfb@rmfb-ioctl: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +1 * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-glk: PASS -> DMESG-WARN [fdo#105763] / [fdo#106538] * igt@kms_setmode@basic: - shard-skl: NOTRUN -> FAIL [fdo#99912] * igt@kms_sysfs_edid_timing: - shard-skl: NOTRUN -> FAIL [fdo#100047] * igt@kms_universal_plane@cursor-fb-leak-pipe-c: - shard-skl: PASS -> DMESG-WARN [fdo#105541] * igt@perf_pmu@semaphore-wait-bcs0: - shard-apl: PASS -> INCOMPLETE [fdo#103927] Possible fixes * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-kbl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_busy@extended-pageflip-hang-newfb-render-a: - shard-glk: DMESG-WARN [fdo#107956] -> PASS * igt@kms_cursor_crc@cursor-64x21-random: - shard-apl: FAIL [fdo#103232] -> PASS +2 * igt@kms_fbcon_fbt@fbc-suspend: - shard-snb: DMESG-WARN [fdo#102365] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-iclb: FAIL [fdo#103167] -> PASS +3 - shard-apl: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-render: - shard-glk: FAIL [fdo#103167] -> PASS * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-iclb: INCOMPLETE [fdo#107713] -> PASS * igt@kms_plane@plane-position-covered-pipe-a-planes: - shard-glk: FAIL [fdo#103166] -> PASS - shard-iclb: FAIL [fdo#103166] -> PASS * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: - shard-glk: FAIL [fdo#108145] -> PASS * igt@kms_plane_multiple@atomic-pipe-b-tiling-y: - shard-apl: FAIL [fdo#103166] -> PASS * igt@perf_pmu@rc6-runtime-pm: - shard-kbl: FAIL [fdo#105010] -> PASS * igt@pm_rpm@cursor-dpms: - shard-iclb: INCOMPLETE [fdo#108840] -> PASS * igt@pm_rpm@dpms-mode-unset-non-lpsp: - shard-skl: INCOMPLETE [fdo#107807] -> SKIP [fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047 [fdo#102365]: https://bugs.freedesktop.org/show_bug.cgi?id=102365 [fdo#103158]: https://bugs.freedesktop.org/show_bug.cgi?id=103158 [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103167]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for MST refcounting/atomic helpers cleanup
== Series Details ==
Series: MST refcounting/atomic helpers cleanup
URL : https://patchwork.freedesktop.org/series/54030/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5316 -> Patchwork_11093
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11093 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11093, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54030/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11093:
### IGT changes ###
Possible regressions
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: PASS -> FAIL
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: PASS -> SKIP
- fi-bsw-kefka: SKIP -> PASS
Known issues
Here are the changes found in Patchwork_11093 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_hangcheck:
- fi-kbl-7560u: INCOMPLETE [fdo#108044] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: FAIL -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
Participating hosts (52 -> 47)
--
Additional (1): fi-icl-y
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5316 -> Patchwork_11093
CI_DRM_5316: caa765e4d3924701c07164819f47e9c7ee6565e5 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11093: 36339baac207cf4f6aae4c6c99f6d7aa4d3f8943 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
36339baac207 drm/nouveau: Use atomic VCPI helpers for MST
6f6ba4dab707 drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
ccded9c0a4ba drm/dp_mst: Start tracking per-port VCPI allocations
38ced18302b4 drm/dp_mst: Add some atomic state iterator macros
da2150a45314 drm/nouveau: Grab payload lock in nv50_msto_payload()
47a8052bcd5e drm/nouveau: Stop unsetting mstc->port, use malloc refs
106eea116ce9 drm/nouveau: Fix potential use-after-frees for MSTCs
13984c5ea301 drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
cf8a68c1efd5 drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
f7fb04a02f7c drm/i915: Keep malloc references to MST ports
bb69acc1a685 drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
45508c149b9e drm/dp_mst: Stop releasing VCPI when removing ports from topology
e2f94fce005b drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
6b4005731a4b drm/dp_mst: Refactor drm_dp_update_payload_part1()
69cf74524440 drm/dp_mst: Remove bogus conditional in
drm_dp_update_payload_part1()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11093/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for MST refcounting/atomic helpers cleanup
== Series Details == Series: MST refcounting/atomic helpers cleanup URL : https://patchwork.freedesktop.org/series/54030/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1() Okay! Commit: drm/dp_mst: Refactor drm_dp_update_payload_part1() Okay! Commit: drm/dp_mst: Introduce new refcounting scheme for mstbs and ports Okay! Commit: drm/dp_mst: Stop releasing VCPI when removing ports from topology Okay! Commit: drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs Okay! Commit: drm/i915: Keep malloc references to MST ports Okay! Commit: drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() Okay! Commit: drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() Okay! Commit: drm/nouveau: Fix potential use-after-frees for MSTCs Okay! Commit: drm/nouveau: Stop unsetting mstc->port, use malloc refs Okay! Commit: drm/nouveau: Grab payload lock in nv50_msto_payload() Okay! Commit: drm/dp_mst: Add some atomic state iterator macros Okay! Commit: drm/dp_mst: Start tracking per-port VCPI allocations +./include/linux/slab.h:332:43: warning: dubious: x & !y Commit: drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() Okay! Commit: drm/nouveau: Use atomic VCPI helpers for MST Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for MST refcounting/atomic helpers cleanup
== Series Details ==
Series: MST refcounting/atomic helpers cleanup
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
69cf74524440 drm/dp_mst: Remove bogus conditional in
drm_dp_update_payload_part1()
6b4005731a4b drm/dp_mst: Refactor drm_dp_update_payload_part1()
e2f94fce005b drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
-:22: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 91a25e463130 ("drm/dp/mst:
deallocate payload on port destruction")'
#22:
91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#27:
263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
-:27: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 263efde31f97 ("drm/dp/mst: Get
validated port ref in drm_dp_update_payload_part1()")'
#27:
263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
-:46: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit c54c7374ff44 ("drm/dp_mst: Skip
validating ports during destruction, just ref")'
#46:
c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref")
-:51: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 9765635b3075 ("Revert
"drm/dp_mst: Skip validating ports during destruction, just ref"")'
#51:
9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during destruction,
just ref"")
-:101: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#101:
new file mode 100644
-:428: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#428: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:894:
+ DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(&mstb->malloc_kref)-1);
^
-:471: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#471: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:937:
+ DRM_DEBUG("port %p (%d)\n", port, kref_read(&port->malloc_kref)-1);
^
-:605: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#605: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1058:
+ DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(&mstb->topology_kref)-1);
^
-:714: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#714: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1181:
+ DRM_DEBUG("port %p (%d)\n", port, kref_read(&port->topology_kref)-1);
^
-:734: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#734: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1197:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:754: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#754: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1214:
+ rmstb = drm_dp_mst_topology_get_mstb_validated_locked(
-:780: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#780: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1235:
+ mport = drm_dp_mst_topology_get_port_validated_locked(
-:800: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#800: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1252:
+ rport = drm_dp_mst_topology_get_port_validated_locked(
total: 4 errors, 2 warnings, 8 checks, 1258 lines checked
45508c149b9e drm/dp_mst: Stop releasing VCPI when removing ports from topology
bb69acc1a685 drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
-:92: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#92: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2155:
+ port = drm_dp_mst_topology_get_port_validated(
total: 0 errors, 0 warnings, 1 checks, 124 lines checked
f7fb04a02f7c drm/i915: Keep malloc references to MST ports
cf8a68c1efd5 drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
13984c5ea301 drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
106eea116ce9 drm/nouveau: Fix potential use-after-frees for MSTCs
47a8052bcd5e drm/nouveau: Stop unsetting mstc->port, use malloc refs
da2150a45314 drm/nouveau: Grab payload lock in nv50_msto_payload()
38ced18302b4 drm/dp_mst: Add some atomic state iterator macros
-:106: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__state' - possible
side-effects?
#106: FILE: include/drm/drm_dp_mst_helper.h:697:
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)
[Intel-gfx] [WIP PATCH 15/15] drm/nouveau: Use atomic VCPI helpers for MST
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI tokens required.
So, drop usage of the old helpers and move entirely over to the atomic
helpers.
Changes since v5:
- Update nv50_msto_atomic_check() and nv50_mstc_atomic_check() to the
new requirements for drm_dp_atomic_find_vcpi_slots() and
drm_dp_atomic_release_vcpi_slots()
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 52 ++---
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 67f7bf97e5d9..df696008d205 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -762,16 +762,22 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
- struct nv50_mstc *mstc = nv50_mstc(conn_state->connector);
+ struct drm_atomic_state *state = crtc_state->state;
+ struct drm_connector *connector = conn_state->connector;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
- int bpp = conn_state->connector->display_info.bpc * 3;
+ int bpp = connector->display_info.bpc * 3;
int slots;
- mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, bpp);
+ mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+bpp);
- slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
- if (slots < 0)
- return slots;
+ if (crtc_state->connectors_changed || crtc_state->mode_changed) {
+ slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
+ mstc->port, mstc->pbn);
+ if (slots < 0)
+ return slots;
+ }
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
mstc->native);
@@ -934,12 +940,42 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
}
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct drm_dp_mst_topology_mgr *mgr = &mstc->mstm->mgr;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_crtc_state *old_crtc_state;
+ struct drm_crtc *new_crtc = new_conn_state->crtc,
+ *old_crtc = old_conn_state->crtc;
+
+ if (!old_crtc)
+ return 0;
+
+ old_crtc_state = drm_atomic_get_old_crtc_state(state, old_crtc);
+ if (!old_crtc_state || !old_crtc_state->enable)
+ return 0;
+
+ if (new_crtc)
+ return 0;
+
+ /* This connector will be left without an enabled CRTC, so its VCPI
+* must be released here
+*/
+ return drm_dp_atomic_release_vcpi_slots(state, mgr, mstc->port);
+}
+
static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
+ .atomic_check = nv50_mstc_atomic_check,
};
static enum drm_connector_status
@@ -2121,6 +2157,10 @@ nv50_disp_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
return ret;
}
+ ret = drm_dp_mst_atomic_check(state);
+ if (ret)
+ return ret;
+
return 0;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 10/15] drm/nouveau: Stop unsetting mstc->port, use malloc refs
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 982054bbcc8b..157d208d37b5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -709,8 +709,7 @@ nv50_msto_cleanup(struct nv50_msto *msto)
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port)
- drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
+ drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
msto->mstc = NULL;
msto->head = NULL;
@@ -735,7 +734,7 @@ nv50_msto_prepare(struct nv50_msto *msto)
};
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0) {
+ if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
if (payload) {
args.vcpi.start_slot = payload->start_slot;
@@ -832,8 +831,7 @@ nv50_msto_disable(struct drm_encoder *encoder)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
- if (mstc->port)
- drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
+ drm_dp_mst_reset_vcpi_slots(&mstm->mgr, mstc->port);
mstm->outp->update(mstm->outp, msto->head->base.index, NULL, 0, 0);
mstm->modified = true;
@@ -945,7 +943,7 @@ nv50_mstc_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status conn_status;
int ret;
- if (!mstc->port)
+ if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
ret = pm_runtime_get_sync(connector->dev->dev);
@@ -966,8 +964,7 @@ nv50_mstc_destroy(struct drm_connector *connector)
struct nv50_mstc *mstc = nv50_mstc(connector);
drm_connector_cleanup(&mstc->connector);
- if (mstc->port)
- drm_dp_mst_put_port_malloc(mstc->port);
+ drm_dp_mst_put_port_malloc(mstc->port);
kfree(mstc);
}
@@ -1081,11 +1078,6 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
- drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
- drm_dp_mst_put_port_malloc(mstc->port);
- mstc->port = NULL;
- drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
-
drm_connector_put(&mstc->connector);
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 12/15] drm/dp_mst: Add some atomic state iterator macros
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 +-
include/drm/drm_dp_mst_helper.h | 96 +++
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 93f08bfd2ab3..8d94c8943ac7 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3415,10 +3415,11 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
kfree(mst_state);
}
-static const struct drm_private_state_funcs mst_state_funcs = {
+const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs = {
.atomic_duplicate_state = drm_dp_mst_duplicate_state,
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
/**
* drm_atomic_get_mst_topology_state: get MST topology state
@@ -3502,7 +3503,7 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
drm_atomic_private_obj_init(dev, &mgr->base,
&mst_state->base,
- &mst_state_funcs);
+ &drm_dp_mst_topology_state_funcs);
return 0;
}
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 50643a39765d..b8a8d75410d0 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -637,4 +637,100 @@ int drm_dp_send_power_updown_phy(struct
drm_dp_mst_topology_mgr *mgr,
void drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port);
void drm_dp_mst_put_port_malloc(struct drm_dp_mst_port *port);
+extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
+
+/**
+ * __drm_dp_mst_state_iter_get - private atomic state iterator function for
+ * macro-internal use
+ * @state: &struct drm_atomic_state pointer
+ * @mgr: pointer to the &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: optional pointer to the old &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @new_state: optional pointer to the new &struct drm_dp_mst_topology_state
+ * iteration cursor
+ * @i: int iteration cursor, for macro-internal use
+ *
+ * Used by for_each_oldnew_mst_mgr_in_state(),
+ * for_each_old_mst_mgr_in_state(), and for_each_new_mst_mgr_in_state(). Don't
+ * call this directly.
+ *
+ * Returns:
+ * True if the current &struct drm_private_obj is a &struct
+ * drm_dp_mst_topology_mgr, false otherwise.
+ */
+static inline bool
+__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr **mgr,
+ struct drm_dp_mst_topology_state **old_state,
+ struct drm_dp_mst_topology_state **new_state,
+ int i)
+{
+ struct __drm_private_objs_state *objs_state = &state->private_objs[i];
+
+ if (objs_state->ptr->funcs != &drm_dp_mst_topology_state_funcs)
+ return false;
+
+ *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
+ if (old_state)
+ *old_state = to_dp_mst_topology_state(objs_state->old_state);
+ if (new_state)
+ *new_state = to_dp_mst_topology_state(objs_state->new_state);
+
+ return true;
+}
+
+/**
+ * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
+ * managers in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @new_state: &struct drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking both old and new state. This is useful in places where the state
+ * delta needs to be considered, for example in atomic check functions.
+ */
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
__i) \
+ for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+ for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
&(old_state), &(new_state), (__i)))
+
+/**
+ * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state: &struct drm_atomic_state pointer
+ * @mgr: &struct drm_dp_mst_topology_mgr iteration cursor
+ * @old_state: &struct drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking only the old state. This is useful i
[Intel-gfx] [WIP PATCH 09/15] drm/nouveau: Fix potential use-after-frees for MSTCs
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is allocated for
as long as we keep mstc around we can remove the connector registration
checks for codepaths which release payloads, allowing us to release
payloads on active topologies properly. These registration checks were
only required before in order to avoid situations where mstc->port could
technically be pointing at freed memory.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0f7d72518604..982054bbcc8b 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -964,7 +964,11 @@ static void
nv50_mstc_destroy(struct drm_connector *connector)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
+
drm_connector_cleanup(&mstc->connector);
+ if (mstc->port)
+ drm_dp_mst_put_port_malloc(mstc->port);
+
kfree(mstc);
}
@@ -1012,6 +1016,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.path_property, 0);
drm_object_attach_property(&mstc->connector.base,
dev->mode_config.tile_property, 0);
drm_connector_set_path_property(&mstc->connector, path);
+ drm_dp_mst_get_port_malloc(port);
return 0;
}
@@ -1077,6 +1082,7 @@ nv50_mstm_destroy_connector(struct
drm_dp_mst_topology_mgr *mgr,
drm_fb_helper_remove_one_connector(&drm->fbcon->helper,
&mstc->connector);
drm_modeset_lock(&drm->dev->mode_config.connection_mutex, NULL);
+ drm_dp_mst_put_port_malloc(mstc->port);
mstc->port = NULL;
drm_modeset_unlock(&drm->dev->mode_config.connection_mutex);
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 04/15] drm/dp_mst: Stop releasing VCPI when removing ports from topology
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c196fb580beb..ae9d019af9f2 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1084,8 +1084,6 @@ static void drm_dp_destroy_port(struct kref *kref)
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
if (!port->input) {
- port->vcpi.num_slots = 0;
-
kfree(port->cached_edid);
/*
@@ -3381,12 +3379,6 @@ static void drm_dp_destroy_connector_work(struct
work_struct *work)
drm_dp_port_teardown_pdt(port, port->pdt);
port->pdt = DP_PEER_DEVICE_NONE;
- if (!port->input && port->vcpi.vcpi > 0) {
- drm_dp_mst_reset_vcpi_slots(mgr, port);
- drm_dp_update_payload_part1(mgr);
- drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi);
- }
-
drm_dp_mst_put_port_malloc(port);
send_hotplug = true;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 05/15] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed will never be a valid part of the topology after
they've been removed.
Since we've introduced malloc refs, we can replace all of the validation
logic in payload helpers which are used for deallocation with some
well-placed malloc krefs. This ensures that regardless of whether or not
the ports are still valid and in the topology, any port which has an
allocated payload will remain allocated in memory until it's payloads
have been removed - finally allowing us to actually release said
payloads correctly.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 54 +++
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ae9d019af9f2..93f08bfd2ab3 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1989,10 +1989,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
u8 sinks[DRM_DP_MAX_SDP_STREAMS];
int i;
- port = drm_dp_mst_topology_get_port_validated(mgr, port);
- if (!port)
- return -EINVAL;
-
port_num = port->port_num;
mstb = drm_dp_mst_topology_get_mstb_validated(mgr, port->parent);
if (!mstb) {
@@ -2000,10 +1996,8 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
port->parent,
&port_num);
- if (!mstb) {
- drm_dp_mst_topology_put_port(port);
+ if (!mstb)
return -EINVAL;
- }
}
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
@@ -2032,7 +2026,6 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
kfree(txmsg);
fail_put:
drm_dp_mst_topology_put_mstb(mstb);
- drm_dp_mst_topology_put_port(port);
return ret;
}
@@ -2137,15 +2130,16 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
*/
int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
{
- int i, j;
- int cur_slots = 1;
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
+ int i, j;
+ int cur_slots = 1;
mutex_lock(&mgr->payload_lock);
for (i = 0; i < mgr->max_payloads; i++) {
struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
struct drm_dp_payload *payload = &mgr->payloads[i];
+ bool put_port = false;
/* solve the current payloads - compare to the hw ones
- update the hw view */
@@ -2153,12 +2147,20 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
if (vcpi) {
port = container_of(vcpi, struct drm_dp_mst_port,
vcpi);
- port = drm_dp_mst_topology_get_port_validated(mgr,
- port);
- if (!port) {
- mutex_unlock(&mgr->payload_lock);
- return -EINVAL;
+
+ /* Validated ports don't matter if we're releasing
+* VCPI
+*/
+ if (vcpi->num_slots) {
+ port = drm_dp_mst_topology_get_port_validated(
+ mgr, port);
+ if (!port) {
+ mutex_unlock(&mgr->payload_lock);
+ return -EINVAL;
+ }
+ put_port = true;
}
+
req_payload.num_slots = vcpi->num_slots;
req_payload.vcpi = vcpi->vcpi;
} else {
@@ -2190,7 +2192,7 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
}
cur_slots += req_payload.num_slots;
- if (port)
+ if (put_port)
drm_dp_mst_topology_put_port(port);
}
@@ -3005,6 +3007,8 @@ bool drm_dp_mst_allocate_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
pbn, port->vcpi.num_slots);
+ /* Keep port allocated until it's payload has been removed */
+ drm_dp_mst_get_port_malloc(port);
drm_dp_mst_topology_put_port(port);
[Intel-gfx] [WIP PATCH 11/15] drm/nouveau: Grab payload lock in nv50_msto_payload()
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 157d208d37b5..67f7bf97e5d9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -680,6 +680,8 @@ nv50_msto_payload(struct nv50_msto *msto)
struct nv50_mstm *mstm = mstc->mstm;
int vcpi = mstc->port->vcpi.vcpi, i;
+ WARN_ON(!mutex_is_locked(&mstm->mgr.payload_lock));
+
NV_ATOMIC(drm, "%s: vcpi %d\n", msto->encoder.name, vcpi);
for (i = 0; i < mstm->mgr.max_payloads; i++) {
struct drm_dp_payload *payload = &mstm->mgr.payloads[i];
@@ -733,6 +735,8 @@ nv50_msto_prepare(struct nv50_msto *msto)
(0x0100 << msto->head->base.index),
};
+ mutex_lock(&mstm->mgr.payload_lock);
+
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
if (mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
@@ -748,7 +752,9 @@ nv50_msto_prepare(struct nv50_msto *msto)
msto->encoder.name, msto->head->base.base.name,
args.vcpi.start_slot, args.vcpi.num_slots,
args.vcpi.pbn, args.vcpi.aligned_pbn);
+
nvif_mthd(&drm->display->disp.object, 0, &args, sizeof(args));
+ mutex_unlock(&mstm->mgr.payload_lock);
}
static int
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 14/15] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b9374c981a5b..ebffb834f5d6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3538,7 +3538,7 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63, ret;
+ int avail_slots = 63, payload_count = 0, ret;
/* There's no possible scenario where releasing VCPI or keeping it the
* same would make the state invalid
@@ -3575,6 +3575,13 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
goto port_fail;
}
+ if (++payload_count > mgr->max_payloads) {
+ DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many
payloads (max=%d)\n",
+mgr, mst_state, mgr->max_payloads);
+ ret = -EINVAL;
+ goto port_fail;
+ }
+
drm_dp_mst_topology_put_port(vcpi->port);
}
DRM_DEBUG_ATOMIC("[MST MGR:%p] mst state %p VCPI avail=%d used=%d\n",
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 13/15] drm/dp_mst: Start tracking per-port VCPI allocations
There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking * per-port slot allocation in drm_dp_mst_topology_state instead of * depending on the caller to tell us how many slots to release. */ That's not the only reason we should fix this: forcing the driver to track the VCPI allocations throughout a state's atomic check is error prone, because it means that extra care has to be taken with the order that drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() are called in in order to ensure idempotency. Currently the only driver actually using these helpers, i915, doesn't even do this correctly: multiple ->best_encoder() checks with i915's current implementation would not be idempotent and would over-allocate VCPI slots, something I learned trying to implement fallback retraining in MST. So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for each port. This allows us to ensure idempotency without having to rely on the driver as much. Additionally: the driver doesn't need to do any kind of VCPI slot tracking anymore if it doesn't need it for it's own internal state. Additionally; this adds a new drm_dp_mst_atomic_check() helper which must be used by atomic drivers to perform validity checks for the new VCPI allocations incurred by a state. Also: update the documentation and make it more obvious that these /must/ be called by /all/ atomic drivers supporting MST. Changes since v6: - Keep a kref to all of the ports we have allocations on. This required a good bit of changing to when we call drm_dp_find_vcpi_slots(), mainly that we need to ensure that we only redo VCPI allocations on actual mode or CRTC changes, not crtc_state->active changes. Additionally, we no longer take the registration of the DRM connector for each port into account because so long as we have a kref to the port in the new or previous atomic state, the connector will stay registered. - Use the small changes to drm_dp_put_port() to add even more error checking to make misusage of the helpers more obvious. I added this after having to chase down various use-after-free conditions that started popping up from the new helpers so no one else has to troubleshoot that. - Move some accidental DRM_DEBUG_KMS() calls to DRM_DEBUG_ATOMIC() - Update documentation again, note that find/release() should both not be called on the same port in a single atomic check phase (but multiple calls to one or the other is OK) Changes since v4: - Don't skip the atomic checks for VCPI allocations if no new VCPI allocations happen in a state. This makes the next change I'm about to list here a lot easier to implement. - Don't ignore VCPI allocations on destroyed ports, instead ensure that when ports are destroyed and still have VCPI allocations in the topology state, the only state changes allowed are releasing said ports' VCPI. This prevents a state with a mix of VCPI allocations from destroyed ports, and allocations from valid ports. Changes since v3: - Don't release VCPI allocations in the topology state immediately in drm_dp_atomic_release_vcpi_slots(), instead mark them as 0 and skip over them in drm_dp_mst_duplicate_state(). This makes it so drm_dp_atomic_release_vcpi_slots() is still idempotent while also throwing warnings if the driver messes up it's book keeping and tries to release VCPI slots on a port that doesn't have any pre-existing VCPI allocation - danvet - Change mst_state/state in some debugging messages to "mst state" Changes since v2: - Use kmemdup() for duplicating MST state - danvet - Move port validation out of duplicate state callback - danvet - Handle looping through MST topology states in drm_dp_mst_atomic_check() so the driver doesn't have to do it - Fix documentation in drm_dp_atomic_find_vcpi_slots() - Move the atomic check for each individual topology state into it's own function, reduces indenting - Don't consider "stale" MST ports when calculating the bandwidth requirements. This is needed because originally we relied on the state duplication functions to prune any stale ports from the new state, which would prevent us from incorrectly considering their bandwidth requirements alongside legitimate new payloads. - Add function references in drm_dp_atomic_release_vcpi_slots() - danvet - Annotate atomic VCPI and atomic check functions with __must_check - danvet Changes since v1: - Don't use the now-removed ->atomic_check() for private objects hook, just give drivers a function to call themselves Signed-off-by: Lyude Paul Cc: Daniel Vetter --- drivers/gpu/dr
[Intel-gfx] [WIP PATCH 00/15] MST refcounting/atomic helpers cleanup
This is a WIP version of the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a ton of magic in the atomic helpers to work around properly and in many situations just plain doesn't work as intended. This patch series is starting to get bigger, and since there's still a few bits here and there regarding the new refcount implementation that I haven't quite decided on yet I figured I should get an opinion from everyone else. Currently I've got a couple of thoughts on how I could improve this further: * Get rid of drm_dp_mst_get_*_validated() entirely - I'm 90% sure that with the new refcounting scheme we might not actually need port validation at all anymore, assuming we make the use of malloc references in all of the DRM drivers. Either way, I don't think validation was ever actually a concept that worked: without malloc references, the port or branch device that's being passed to drm_dp_mst_get_*_validated() could be freed which also in turn means that that the stale pointer could in theory have gotten reused for a new port and thus-cause us to consider a freed port validated. * Get rid of drm_dp_mst_get_vcpi_slots() - with malloc references, I don't think there's any use for this either * Get rid of drm_dp_mst_reset_vcpi_slots() - I think the only time this function ever made sense was with port validation? Honestly, I wonder if we ever needed this at all... Note: I haven't applied some of the comments from the reviews for the series this is based off of: drm/dp_mst: Improve VCPI helpers, use in nouveau https://patchwork.freedesktop.org/series/51414/ This is just getting put on the ML so I can get some feedback on this. Lyude Paul (15): drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1() drm/dp_mst: Refactor drm_dp_update_payload_part1() drm/dp_mst: Introduce new refcounting scheme for mstbs and ports drm/dp_mst: Stop releasing VCPI when removing ports from topology drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs drm/i915: Keep malloc references to MST ports drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() drm/nouveau: Fix potential use-after-frees for MSTCs drm/nouveau: Stop unsetting mstc->port, use malloc refs drm/nouveau: Grab payload lock in nv50_msto_payload() drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI allocations drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() drm/nouveau: Use atomic VCPI helpers for MST .../gpu/dp-mst/topology-figure-1.dot | 31 + .../gpu/dp-mst/topology-figure-2.dot | 37 + .../gpu/dp-mst/topology-figure-3.dot | 40 + Documentation/gpu/drm-kms-helpers.rst | 125 ++- drivers/gpu/drm/drm_dp_mst_topology.c | 910 ++ drivers/gpu/drm/i915/intel_connector.c| 4 + drivers/gpu/drm/i915/intel_display.c | 4 + drivers/gpu/drm/i915/intel_dp_mst.c | 66 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 94 +- include/drm/drm_dp_mst_helper.h | 139 ++- 10 files changed, 1178 insertions(+), 272 deletions(-) create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-2.dot create mode 100644 Documentation/gpu/dp-mst/topology-figure-3.dot -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 03/15] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current scheme works like this:
drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When
this refcount hits 0 for either of the two, they're removed from the
topology state, but not immediately freed. Both ports and branch devices
will reinitialize their kref once it's hit 0 before actually destroying
themselves. The intended purpose behind this is so that we can avoid
problems like not being able to free a remote payload that might still
be active, due to us having removed all of the port/branch device
structures in memory, as per:
91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
Which may have worked, but then it caused use-after-free errors. Being
new to MST at the time, I tried fixing it;
263efde31f97 ("drm/dp/mst: Get validated port ref in
drm_dp_update_payload_part1()")
But, that was broken: both drm_dp_mst_port and drm_dp_mst_branch structs
are validated in almost every DP MST helper function. Simply put, this
means we go through the topology and try to see if the given
drm_dp_mst_branch or drm_dp_mst_port is still attached to something
before trying to use it in order to avoid dereferencing freed memory
(something that has happened a LOT in the past with this library).
Because of this it doesn't actually matter whether or not we keep keep
the ports and branches around in memory as that's not enough, because
any function that validates the branches and ports passed to it will
still reject them anyway since they're no longer in the topology
structure. So, use-after-free errors were fixed but payload deallocation
was completely broken.
Two years later, AMD informed me about this issue and I attempted to
come up with a temporary fix, pending a long-overdue cleanup of this
library:
c54c7374ff44 ("drm/dp_mst: Skip validating ports during destruction, just ref")
But then that introduced use-after-free errors, so I quickly reverted
it:
9765635b3075 ("Revert "drm/dp_mst: Skip validating ports during destruction,
just ref"")
And in the process, learned that there is just no simple fix for this:
the design is just broken. Unfortuntely, the usage of these helpers are
quite broken as well. Some drivers like i915 have been smart enough to
avoid accessing any kind of information from MST port structures, but
others like nouveau have assumed, understandably so, that
drm_dp_mst_port structures are normal and can just be accessed at any
time without worrying about use-after-free errors.
After a lot of discussion, me and Daniel Vetter came up with a better
idea to replace all of this.
To summarize, since this is documented far more indepth in the
documentation this patch introduces, we make it so that drm_dp_mst_port
and drm_dp_mst_branch structures have two different classes of
refcounts: topology_kref, and malloc_kref. topology_kref corresponds to
the lifetime of the given drm_dp_mst_port or drm_dp_mst_branch in it's
given topology. Once it hits zero, any associated connectors are removed
and the branch or port can no longer be validated. malloc_kref
corresponds to the lifetime of the memory allocation for the actual
structure, and will always be non-zero so long as the topology_kref is
non-zero. This gives us a way to allow callers to hold onto port and
branch device structures past their topology lifetime, and dramatically
simplifies the lifetimes of both structures. This also finally fixes the
port deallocation problem, properly.
Additionally: since this now means that we can keep ports and branch
devices allocated in memory for however long we need, we no longer need
a significant amount of the port validation that we currently do.
Additionally, there is one last scenario that this fixes, which couldn't
have been fixed properly beforehand:
- CPU1 unrefs port from topology (refcount 1->0)
- CPU2 refs port in topology(refcount 0->1)
Since we now can guarantee memory safety for ports and branches
as-needed, we also can make our main reference counting functions fix
this problem by using kref_get_unless_zero() internally so that topology
refcounts can only ever reach 0 once.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
.../gpu/dp-mst/topology-figure-1.dot | 31 ++
.../gpu/dp-mst/topology-figure-2.dot | 37 ++
.../gpu/dp-mst/topology-figure-3.dot | 40 ++
Documentation/gpu/drm-kms-helpers.rst | 125 -
drivers/gpu/drm/drm_dp_mst_topology.c | 512 +-
include/drm/drm_dp_mst_helper.h | 19 +-
6 files changed, 637 insertions(+), 127 deletions(-)
create mode 100644 Documentation/gpu/dp-mst/topology-figure-1.dot
create mode 100644 Do
[Intel-gfx] [WIP PATCH 06/15] drm/i915: Keep malloc references to MST ports
So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/intel_connector.c | 4 drivers/gpu/drm/i915/intel_dp_mst.c| 2 ++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_connector.c b/drivers/gpu/drm/i915/intel_connector.c index 18e370f607bc..37d2c644f4b8 100644 --- a/drivers/gpu/drm/i915/intel_connector.c +++ b/drivers/gpu/drm/i915/intel_connector.c @@ -95,6 +95,10 @@ void intel_connector_destroy(struct drm_connector *connector) intel_panel_fini(&intel_connector->panel); drm_connector_cleanup(connector); + + if (intel_connector->port) + drm_dp_mst_put_port_malloc(intel_connector->port); + kfree(connector); } diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index f05427b74e34..4d6ced34d465 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -484,6 +484,8 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo if (ret) goto err; + drm_dp_mst_get_port_malloc(port); + return connector; err: -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 07/15] drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 26af45785939..641252208e67 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1099,11 +1099,8 @@ nv50_mstm_add_connector(struct drm_dp_mst_topology_mgr
*mgr,
int ret;
ret = nv50_mstc_new(mstm, port, path, &mstc);
- if (ret) {
- if (mstc)
- mstc->connector.funcs->destroy(&mstc->connector);
+ if (ret)
return NULL;
- }
return &mstc->connector;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 01/15] drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1()
There's no reason we need this, it's just confusing looking.
Signed-off-by: Lyude Paul
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ad0fb6d003be..9b1b5c9b1fa0 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1896,9 +1896,7 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
req_payload.num_slots = 0;
}
- if (mgr->payloads[i].start_slot != req_payload.start_slot) {
- mgr->payloads[i].start_slot = req_payload.start_slot;
- }
+ mgr->payloads[i].start_slot = req_payload.start_slot;
/* work out what is required to happen with this payload */
if (mgr->payloads[i].num_slots != req_payload.num_slots) {
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 08/15] drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks are meant to protect against.
More importantly though, we're about to stop clearing mstc->port in the
next commit, which means if we could potentially hit a use-after-free
error if we tried to check mstc->port->vcpi here. So to make life easier
for anyone who bisects this code in the future, use msto->disabled
instead to check whether or not we need to deallocate VCPI instead.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 641252208e67..0f7d72518604 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -704,14 +704,17 @@ nv50_msto_cleanup(struct nv50_msto *msto)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
+ if (!msto->disabled)
+ return;
+
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
- if (mstc->port && mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
+
+ if (mstc->port)
drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
- if (msto->disabled) {
- msto->mstc = NULL;
- msto->head = NULL;
- msto->disabled = false;
- }
+
+ msto->mstc = NULL;
+ msto->head = NULL;
+ msto->disabled = false;
}
static void
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [WIP PATCH 02/15] drm/dp_mst: Refactor drm_dp_update_payload_part1()
There should be no functional changes here
Signed-off-by: Lyude Paul
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 71 ---
1 file changed, 42 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9b1b5c9b1fa0..2ab16c9e6243 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1879,39 +1879,48 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
mutex_lock(&mgr->payload_lock);
for (i = 0; i < mgr->max_payloads; i++) {
+ struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
+ struct drm_dp_payload *payload = &mgr->payloads[i];
+
/* solve the current payloads - compare to the hw ones
- update the hw view */
req_payload.start_slot = cur_slots;
- if (mgr->proposed_vcpis[i]) {
- port = container_of(mgr->proposed_vcpis[i], struct
drm_dp_mst_port, vcpi);
+ if (vcpi) {
+ port = container_of(vcpi, struct drm_dp_mst_port,
+ vcpi);
port = drm_dp_get_validated_port_ref(mgr, port);
if (!port) {
mutex_unlock(&mgr->payload_lock);
return -EINVAL;
}
- req_payload.num_slots =
mgr->proposed_vcpis[i]->num_slots;
- req_payload.vcpi = mgr->proposed_vcpis[i]->vcpi;
+ req_payload.num_slots = vcpi->num_slots;
+ req_payload.vcpi = vcpi->vcpi;
} else {
port = NULL;
req_payload.num_slots = 0;
}
- mgr->payloads[i].start_slot = req_payload.start_slot;
+ payload->start_slot = req_payload.start_slot;
/* work out what is required to happen with this payload */
- if (mgr->payloads[i].num_slots != req_payload.num_slots) {
+ if (payload->num_slots != req_payload.num_slots) {
/* need to push an update for this payload */
if (req_payload.num_slots) {
- drm_dp_create_payload_step1(mgr,
mgr->proposed_vcpis[i]->vcpi, &req_payload);
- mgr->payloads[i].num_slots =
req_payload.num_slots;
- mgr->payloads[i].vcpi = req_payload.vcpi;
- } else if (mgr->payloads[i].num_slots) {
- mgr->payloads[i].num_slots = 0;
- drm_dp_destroy_payload_step1(mgr, port,
mgr->payloads[i].vcpi, &mgr->payloads[i]);
- req_payload.payload_state =
mgr->payloads[i].payload_state;
- mgr->payloads[i].start_slot = 0;
+ drm_dp_create_payload_step1(mgr, vcpi->vcpi,
+ &req_payload);
+ payload->num_slots = req_payload.num_slots;
+ payload->vcpi = req_payload.vcpi;
+
+ } else if (payload->num_slots) {
+ payload->num_slots = 0;
+ drm_dp_destroy_payload_step1(mgr, port,
+payload->vcpi,
+payload);
+ req_payload.payload_state =
+ payload->payload_state;
+ payload->start_slot = 0;
}
- mgr->payloads[i].payload_state =
req_payload.payload_state;
+ payload->payload_state = req_payload.payload_state;
}
cur_slots += req_payload.num_slots;
@@ -1920,22 +1929,26 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
}
for (i = 0; i < mgr->max_payloads; i++) {
- if (mgr->payloads[i].payload_state == DP_PAYLOAD_DELETE_LOCAL) {
- DRM_DEBUG_KMS("removing payload %d\n", i);
- for (j = i; j < mgr->max_payloads - 1; j++) {
- memcpy(&mgr->payloads[j], &mgr->payloads[j +
1], sizeof(struct drm_dp_payload));
- mgr->proposed_vcpis[j] = mgr->proposed_vcpis[j
+ 1];
- if (mgr->proposed_vcpis[j] &&
mgr->proposed_vcpis[j]->num_slots) {
- set_bit(j + 1, &mgr->payload_mask);
- } else {
- clear_bit(j + 1, &mgr->payload_mask);
-
Re: [Intel-gfx] [PATCH 2/3] drm/i915/icl: Fix TypeC legacy HDMI HPD handling
On Thu, Dec 13, 2018 at 01:06:51PM -0800, Rodrigo Vivi wrote:
> On Thu, Dec 13, 2018 at 09:48:49PM +0200, Imre Deak wrote:
> > Atm HPD disconnect events on TypeC ports will break things, since we'll
> > switch the TypeC mode (between Legacy and disconnected modes as well as
> > among USB DP alternate, Thunderbolt alternate and disconnected modes) on
> > the fly from the HPD disconnect interrupt work while the port may be
> > still active.
> >
> > Even if the port happens to be not active during the disconnect we'd
> > still have a problem during a subsequent modeset or AUX transfer that
> > could happen regardless of the port's connected state. For instance the
> > system resume display mode restore code and userspace could perform a
> > modeset on the port or userspace could start an AUX transfer even if the
> > port is in disconnected state.
> >
> > To fix this keep legacy TypeC ports in TypeC legacy mode whenever we're
> > not suspended. The legacy mode is a static configuration as opposed to
> > the Thunderbolt and USB DP alternate modes between which we can switch
> > dynamically.
> >
> > We don't have yet an explicit way to detect TypeC legacy ports, but we
> > can imply that at least in case of HDMI enabled ports, since HDMI can
> > only be provided in legacy mode. So mark TypeC HDMI enabled ports as
> > legacy and run the TypeC PHY connect sequence explicitly during driver
> > loading and system resume. The connect will succeed even if the display
> > is not connected to begin with (or disappears during the suspended
> > state) since for legacy ports the PORT_TX_DFLEXDPPMS /
> > DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB
> > DP alternate mode where it gets set only when a display is connected).
> >
> > Correspondingly run the TypeC PHY disconnect sequence during system
> > suspend and driver unloading, but disconnect during suspend only for
> > legacy TypeC mode. We will need to disconnect even in USB DP alternate
> > mode in the future, but atm we don't have a way to reconnect the port
> > in this mode during resume if the display disappears while being
> > suspended. So for now punt on this case.
> >
> > Note that we do not disconnect the port during runtime suspend; in
> > legacy mode there are no shared HW resources (PHY lanes) with other HW
> > blocks (USB), so no need to release / reacquire these resources as with
> > USB DP alternate mode. The only reason to disconnect legacy ports during
> > system suspend is that the PORT_TX_DFLEXDPPMS /
> > DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
> > connected again during system resume. We may also need to turn the check
> > for this flag into a poll, depending on further tests and clarifications
> > we are expecting from HW/FW people.
> >
> > If VBT says that the port provides only DP functionality then we can't
> > assume that it's a legacy port as for HDMI (since it could as well be
> > a TBT/DP Alt connector), so we'll solve HPD handling for the DP case
> > with a different method in the next patch.
> >
> > Eventually - instead of the above method - we'll depend on an explicit
> > detection method provided either via a VBT flag or a FW/HW register both
> > for the HDMI and DP case.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
> > Cc: Paulo Zanoni
> > Cc: Ville Syrjälä
> > Cc: José Roberto de Souza
> > Cc: Rodrigo Vivi
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 54
> > +---
> > drivers/gpu/drm/i915/intel_dp.c | 29 ++---
> > drivers/gpu/drm/i915/intel_drv.h | 5 +++-
> > 3 files changed, 75 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index f3e1d6a0b7dd..2e47ffa1c95a 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3901,9 +3901,50 @@ static bool intel_ddi_compute_config(struct
> > intel_encoder *encoder,
> >
> > }
> >
> > +static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> > +{
> > + struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > +
> > + intel_dp_encoder_suspend(encoder);
> > +
> > + /*
> > +* TODO: disconnect also from USB DP alternate mode once we have a
> > +* way to handle the modeset restore in that mode during resume
> > +* even if the sink has disappeared while being suspended.
> > +*/
> > + if (dig_port->tc_legacy_port)
> > + icl_tc_phy_disconnect(i915, dig_port);
> > +}
> > +
> > +static void intel_ddi_encoder_reset(struct drm_encoder *drm_encoder)
> > +{
> > + struct intel_digital_port *dig_port = enc_to_dig_port(drm_encoder);
> > + struct drm_i915_private *i915 = to_i915(drm_encoder->dev);
> > +
> >
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well
On Thu, 2018-12-13 at 07:18 +0200, Ville Syrjälä wrote:
> On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Fill out the AVI infoframe quantization range bits using
> > > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as
> > > well.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> > > 1 file changed, 10 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > > b/drivers/gpu/drm/i915/intel_sdvo.c
> > > index 1277d31adb54..9c16e273fb8d 100644
> > > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > > @@ -984,6 +984,8 @@ static bool
> > > intel_sdvo_set_avi_infoframe(struct
> > > intel_sdvo *intel_sdvo,
> > >const struct intel_crtc_state
> > > *pipe_config,
> > >const struct
> > > drm_connector_state *conn_state)
> > > {
> > > + const struct drm_display_mode *adjusted_mode =
> > > + &pipe_config->base.adjusted_mode;
> > > uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> > > union hdmi_infoframe frame;
> > > int ret;
> > > @@ -991,20 +993,19 @@ static bool
> > > intel_sdvo_set_avi_infoframe(struct
> > > intel_sdvo *intel_sdvo,
> > >
> > > ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
> > > conn_state-
> > > > connector,
> > >
> > > -&pipe_config-
> > > > base.adjusted_mode);
> > >
> > > +adjusted_mode);
> > > if (ret < 0) {
> > > DRM_ERROR("couldn't fill AVI infoframe\n");
> > > return false;
> > > }
> > >
> > > - if (intel_sdvo->rgb_quant_range_selectable) {
> > > - if (pipe_config->limited_color_range)
> > > - frame.avi.quantization_range =
> > > - HDMI_QUANTIZATION_RANGE_LIMITED;
> > > - else
> > > - frame.avi.quantization_range =
> > > - HDMI_QUANTIZATION_RANGE_FULL;
> > > - }
> > > + drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> > > +conn_state->connector,
> > > +adjusted_mode,
> > > +pipe_config-
> > > > limited_color_range ?
> > >
> > > +rgb_quant_range_selectableTE
> > > D :
> > > +HDMI_QUANTIZATION_RANGE_FULL
> > > ,
> > > +intel_sdvo-
> > > > rgb_quant_range_selectable);
> >
> > Seems like avi.quantization_range can now get set to _LIMITED or
> > _FULL
> > even when ->rgb_quant_range_selectable == false, i.e., it is not
> > _DEFAULT anymore. Is that change in behavior intended?
>
> ->quant_range_selectable will be passed to
> drm_hdmi_avi_infoframe_quant_range() which will do the right thing
> with
> it.
>
> That said, there is a slight behavioural change in that it will set
Okay, I was indeed referring to this case.
> the Q bit even with QS==1 iff the quantization range matches the
> default quantization range for the mode. I noted this in the radeon
> patch but forgot to mention it here.
I'll let someone else with knowledge of HDMI to review this behavioral
change. I'm trying to get hold of the HDMI spec now and will review if
this hasn't been looked at by then.
>
> >
> >
> > >
> > > len = hdmi_infoframe_pack(&frame, sdvo_data,
> > > sizeof(sdvo_data));
> > > if (len < 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 Add gamma/degamma LUT validation helper
== Series Details ==
Series: Add gamma/degamma LUT validation helper
URL : https://patchwork.freedesktop.org/series/54023/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5315 -> Patchwork_11092
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11092 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11092, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54023/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11092:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: PASS -> SKIP +2
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: SKIP -> PASS +33
Known issues
Here are the changes found in Patchwork_11092 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@gem_ctx_create@basic-files:
- fi-bsw-kefka: PASS -> FAIL [fdo#108656]
* igt@i915_module_load@reload:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: PASS -> DMESG-WARN [fdo#107709]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108622]
* igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-7500u: PASS -> DMESG-WARN [fdo#102505] / [fdo#103558] /
[fdo#105602]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* {igt@runner@aborted}:
- fi-bsw-kefka: NOTRUN -> FAIL [fdo#107709]
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622]
Possible fixes
* igt@i915_selftest@live_contexts:
- fi-kbl-7560u: INCOMPLETE [fdo#108767] -> PASS
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:DMESG-FAIL [fdo#108735] -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
Participating hosts (53 -> 46)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-icl-y
Build changes
-
* Linux: CI_DRM_5315 -> Patchwork_11092
CI_DRM_5315: 4faa99f4b2a0d9273881329504615e846eeeb1c4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11092: 7b1ce27ddf366744ffb2548aadcbca2c2906cae7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7b1ce27ddf36 drm/i915: Validate userspace-provided color management LUT's (v2)
e8602a936ce9 drm: Add color management LUT validation helper (v2)
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11092/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add gamma/degamma LUT validation helper
== Series Details == Series: Add gamma/degamma LUT validation helper URL : https://patchwork.freedesktop.org/series/54023/ State : warning == Summary == $ dim checkpatch origin/drm-tip e8602a936ce9 drm: Add color management LUT validation helper (v2) -:57: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #57: FILE: drivers/gpu/drm/drm_color_mgmt.c:489: +int drm_color_lut_check(struct drm_property_blob *lut, +uint32_t tests) total: 0 errors, 0 warnings, 1 checks, 76 lines checked 7b1ce27ddf36 drm/i915: Validate userspace-provided color management LUT's (v2) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm: Add color management LUT validation helper (v2)
Some hardware may place additional restrictions on the gamma/degamma
curves described by our LUT properties. E.g., that a gamma curve never
decreases or that the red/green/blue channels of a LUT's entries must be
equal. Let's add a helper function that drivers can use to test that a
userspace-provided LUT is valid and doesn't violate hardware
requirements.
v2:
- Combine into a single helper that just takes a bitmask of the tests
to apply. (Brian Starkey)
- Add additional check (always performed) that LUT property blob size
is always a multiple of the LUT entry size. (stolen from ARM driver)
Cc: Uma Shankar
Cc: Swati Sharma
Cc: Brian Starkey
Signed-off-by: Matt Roper
Reviewed-by(v1): Brian Starkey
---
drivers/gpu/drm/drm_color_mgmt.c | 64
include/drm/drm_color_mgmt.h | 5
2 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 07dcf47daafe..5c2a2d228412 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -462,3 +462,67 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_properties);
+
+/**
+ * drm_color_lut_check - check validity of lookup table
+ * @lut: property blob containing LUT to check
+ * @tests: bitmask of tests to run
+ *
+ * Helper to check whether a userspace-provided lookup table is valid and
+ * satisfies additional hardware requirements. All table sizes should be a
+ * multiple of sizeof(struct drm_color_lut). Drivers pass a bitmask indicating
+ * which of the following additional tests should also be performed:
+ *
+ * "DRM_COLOR_LUT_EQUAL_CHANNELS":
+ * Checks whether the entries of a LUT all have equal values for the red,
+ * green, and blue channels. Intended for hardware that only accepts a
+ * single value per LUT entry and assumes that value applies to all three
+ * color components.
+ *
+ * "DRM_COLOR_LUT_INCREASING":
+ * Checks whether the entries of a LUT are always flat or increasing
+ * (never decreasing).
+ *
+ * Returns 0 on success, -EINVAL on failure.
+ */
+int drm_color_lut_check(struct drm_property_blob *lut,
+uint32_t tests)
+{
+ struct drm_color_lut *entry;
+ int i;
+
+ if (!lut)
+ return 0;
+
+ if (lut->length % sizeof(struct drm_color_lut)) {
+ DRM_DEBUG_KMS("LUT size (%lu) is not a multiple of LUT entry
size (%lu)\n",
+ lut->length, sizeof(struct drm_color_lut));
+ return -EINVAL;
+ }
+
+ if (!tests)
+ return 0;
+
+ entry = lut->data;
+ for (i = 0; i < drm_color_lut_size(lut); i++) {
+ if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
+ if (entry[i].red != entry[i].blue ||
+ entry[i].red != entry[i].green) {
+ DRM_DEBUG_KMS("All LUT entries must have equal
r/g/b\n");
+ return -EINVAL;
+ }
+ }
+
+ if (i > 0 && tests & DRM_COLOR_LUT_INCREASING) {
+ if (entry[i].red < entry[i - 1].red ||
+ entry[i].green < entry[i - 1].green ||
+ entry[i].blue < entry[i - 1].blue) {
+ DRM_DEBUG_KMS("LUT entries must never
decrease.\n");
+ return -EINVAL;
+ }
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_color_lut_check);
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 90ef9996d9a4..7de16f70bcc3 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -69,4 +69,9 @@ int drm_plane_create_color_properties(struct drm_plane *plane,
u32 supported_ranges,
enum drm_color_encoding default_encoding,
enum drm_color_range default_range);
+
+#define DRM_COLOR_LUT_EQUAL_CHANNELS BIT(0)
+#define DRM_COLOR_LUT_INCREASING BIT(1)
+int drm_color_lut_check(struct drm_property_blob *lut,
+ uint32_t tests);
#endif
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Validate userspace-provided color management LUT's (v2)
We currently program userspace-provided gamma and degamma LUT's into our
hardware without really checking to see whether they satisfy our
hardware's rules. We should try to catch tables that are invalid for
our hardware early and reject the atomic transaction.
All of our platforms that accept a degamma LUT expect that the entries
in the LUT are always flat or increasing, never decreasing. Also, our
GLK and ICL platforms only accept degamma tables with r=g=b entries; so
we should also add the relevant checks for that in anticipation of
degamma support landing for those platforms.
v2:
- Use new API (single check function with bitmask of tests to apply)
- Call helper for our gamma table as well (with no additional tests
specified) so that the table size will be validated.
Cc: Uma Shankar
Cc: Swati Sharma
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_color.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 37fd9ddf762e..5ad4459a5f3c 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -609,10 +609,29 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
size_t gamma_length, degamma_length;
+ uint32_t tests = DRM_COLOR_LUT_INCREASING;
degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ /*
+* All of our platforms mandate that the degamma curve be
+* non-decreasing. Additionally, GLK and gen11 only accept a single
+* value for red, green, and blue in the degamma table. Make sure
+* userspace didn't try to pass us something we can't handle.
+*
+* We don't have any extra hardware constraints on the gamma table,
+* so we just test that it's a proper size multiple
+* (tablesize % entrysize == 0).
+*/
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
+
+ if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
+ return -EINVAL;
+ if (drm_color_lut_check(crtc_state->base.gamma_lut, 0) != 0)
+ return -EINVAL;
+
/*
* We allow both degamma & gamma luts at the right size or
* NULL.
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] Add gamma/degamma LUT validation helper
Previous version of this series was here: https://lists.freedesktop.org/archives/dri-devel/2018-December/200178.html Gamma and degamma LUT's uploaded by userspace need to be checked to ensure they're valid tables and that they meet any additional constraints of a given platform's hardware. Let's add a DRM helper that drivers can call to perform some common LUT sanity tests that are likely to be useful on multiple platforms: - LUT entries are always increasing or flat, never decreasing - LUT entries have equal red, green, and blue values for each entry - LUT size is valid (i.e., it's a multiple of sizeof(struct drm_color_lut)) The size test will always be performed (since it's verifying that the proper ABI was followed), but the other two tests are optional and will only be applied as requested by the driver. This revision incorporates Brian Starkey's suggestion to combine the separate helpers into a single function that takes a bitmask of tests to apply. It also adds an additional LUT size test inspired by the ARM malidp driver. Matt Roper (2): drm: Add color management LUT validation helper (v2) drm/i915: Validate userspace-provided color management LUT's (v2) drivers/gpu/drm/drm_color_mgmt.c | 64 ++ drivers/gpu/drm/i915/intel_color.c | 19 +++ include/drm/drm_color_mgmt.h | 5 +++ 3 files changed, 88 insertions(+) -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: Fix TypeC legacy DP HPD handling
On Thu, Dec 13, 2018 at 09:48:50PM +0200, Imre Deak wrote: > TypeC legacy DP ports can't be implied the same way we implied TypeC > legacy HDMI ports in the previous patch. So that we still have > functioning DP legacy ports, mark them as legacy at the first connect > event. After that we treat the port the same way as in the HDMI case, > that is keep it in legacy mode whenever we are not suspended. > > Eventually - instead of the methods in this and the previous patch - > we'll depend on an explicit way to detect both HDMI and DP TypeC legacy > ports either via a VBT option or a HW/FW register. > > Suggested-by: Ville Syrjälä > Cc: Paulo Zanoni > Cc: Ville Syrjälä > Cc: José Roberto de Souza > Cc: Rodrigo Vivi > Signed-off-by: Imre Deak Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_dp.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 19e49adab548..f5de0d079ab5 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -5220,8 +5220,14 @@ static bool icl_tc_port_connected(struct > drm_i915_private *dev_priv, > bool is_legacy, is_typec, is_tbt; > u32 dpsp; > > - is_legacy = intel_dig_port->tc_legacy_port || > + /* > + * TODO: Depend only on the tc_legacy_port flag to identify legacy > + * ports, once we have an explicit detection method for legacy mode > + * (via VBT or a HW/FW register). > + */ > + intel_dig_port->tc_legacy_port |= > I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port); > + is_legacy = intel_dig_port->tc_legacy_port; > > /* >* The spec says we shouldn't be using the ISR bits for detecting > -- > 2.13.2 > > ___ > 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 2/3] drm/i915/icl: Fix TypeC legacy HDMI HPD handling
On Thu, Dec 13, 2018 at 09:48:49PM +0200, Imre Deak wrote:
> Atm HPD disconnect events on TypeC ports will break things, since we'll
> switch the TypeC mode (between Legacy and disconnected modes as well as
> among USB DP alternate, Thunderbolt alternate and disconnected modes) on
> the fly from the HPD disconnect interrupt work while the port may be
> still active.
>
> Even if the port happens to be not active during the disconnect we'd
> still have a problem during a subsequent modeset or AUX transfer that
> could happen regardless of the port's connected state. For instance the
> system resume display mode restore code and userspace could perform a
> modeset on the port or userspace could start an AUX transfer even if the
> port is in disconnected state.
>
> To fix this keep legacy TypeC ports in TypeC legacy mode whenever we're
> not suspended. The legacy mode is a static configuration as opposed to
> the Thunderbolt and USB DP alternate modes between which we can switch
> dynamically.
>
> We don't have yet an explicit way to detect TypeC legacy ports, but we
> can imply that at least in case of HDMI enabled ports, since HDMI can
> only be provided in legacy mode. So mark TypeC HDMI enabled ports as
> legacy and run the TypeC PHY connect sequence explicitly during driver
> loading and system resume. The connect will succeed even if the display
> is not connected to begin with (or disappears during the suspended
> state) since for legacy ports the PORT_TX_DFLEXDPPMS /
> DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB
> DP alternate mode where it gets set only when a display is connected).
>
> Correspondingly run the TypeC PHY disconnect sequence during system
> suspend and driver unloading, but disconnect during suspend only for
> legacy TypeC mode. We will need to disconnect even in USB DP alternate
> mode in the future, but atm we don't have a way to reconnect the port
> in this mode during resume if the display disappears while being
> suspended. So for now punt on this case.
>
> Note that we do not disconnect the port during runtime suspend; in
> legacy mode there are no shared HW resources (PHY lanes) with other HW
> blocks (USB), so no need to release / reacquire these resources as with
> USB DP alternate mode. The only reason to disconnect legacy ports during
> system suspend is that the PORT_TX_DFLEXDPPMS /
> DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
> connected again during system resume. We may also need to turn the check
> for this flag into a poll, depending on further tests and clarifications
> we are expecting from HW/FW people.
>
> If VBT says that the port provides only DP functionality then we can't
> assume that it's a legacy port as for HDMI (since it could as well be
> a TBT/DP Alt connector), so we'll solve HPD handling for the DP case
> with a different method in the next patch.
>
> Eventually - instead of the above method - we'll depend on an explicit
> detection method provided either via a VBT flag or a FW/HW register both
> for the HDMI and DP case.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Cc: Rodrigo Vivi
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 54
> +---
> drivers/gpu/drm/i915/intel_dp.c | 29 ++---
> drivers/gpu/drm/i915/intel_drv.h | 5 +++-
> 3 files changed, 75 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f3e1d6a0b7dd..2e47ffa1c95a 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3901,9 +3901,50 @@ static bool intel_ddi_compute_config(struct
> intel_encoder *encoder,
>
> }
>
> +static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
> +{
> + struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + intel_dp_encoder_suspend(encoder);
> +
> + /*
> + * TODO: disconnect also from USB DP alternate mode once we have a
> + * way to handle the modeset restore in that mode during resume
> + * even if the sink has disappeared while being suspended.
> + */
> + if (dig_port->tc_legacy_port)
> + icl_tc_phy_disconnect(i915, dig_port);
> +}
> +
> +static void intel_ddi_encoder_reset(struct drm_encoder *drm_encoder)
> +{
> + struct intel_digital_port *dig_port = enc_to_dig_port(drm_encoder);
> + struct drm_i915_private *i915 = to_i915(drm_encoder->dev);
> +
> + if (intel_port_is_tc(i915, dig_port->base.port))
> + intel_digital_port_connected(&dig_port->base);
> +
> + intel_dp_encoder_reset(drm_encoder);
do we need all of that? or could simply
intel_dp->reset_link_params = t
Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: Add a debug print for TypeC port disconnection
On Thu, Dec 13, 2018 at 09:48:48PM +0200, Imre Deak wrote:
> It's useful to see at which point a TypeC port gets disconnected, so add
> add a debug print for it.
>
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Cc: Rodrigo Vivi
> Signed-off-by: Imre Deak
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 34 --
> 1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e94faa0a42eb..082594bb65a7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5066,28 +5066,38 @@ static bool icl_combo_port_connected(struct
> drm_i915_private *dev_priv,
> return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
> }
>
> +static const char *tc_type_name(enum tc_port_type type)
> +{
> + static const char *names[] = {
> + [TC_PORT_UNKNOWN] = "unknown",
> + [TC_PORT_LEGACY] = "legacy",
> + [TC_PORT_TYPEC] = "typec",
> + [TC_PORT_TBT] = "tbt",
> + };
> +
> + if (WARN_ON(type >= ARRAY_SIZE(names)))
> + type = TC_PORT_UNKNOWN;
> +
> + return names[type];
> +}
> +
> static void icl_update_tc_port_type(struct drm_i915_private *dev_priv,
> struct intel_digital_port *intel_dig_port,
> bool is_legacy, bool is_typec, bool is_tbt)
> {
> enum port port = intel_dig_port->base.port;
> enum tc_port_type old_type = intel_dig_port->tc_type;
> - const char *type_str;
>
> WARN_ON(is_legacy + is_typec + is_tbt != 1);
>
> - if (is_legacy) {
> + if (is_legacy)
> intel_dig_port->tc_type = TC_PORT_LEGACY;
> - type_str = "legacy";
> - } else if (is_typec) {
> + else if (is_typec)
> intel_dig_port->tc_type = TC_PORT_TYPEC;
> - type_str = "typec";
> - } else if (is_tbt) {
> + else if (is_tbt)
> intel_dig_port->tc_type = TC_PORT_TBT;
> - type_str = "tbt";
> - } else {
> + else
> return;
> - }
>
> /* Types are not supposed to be changed at runtime. */
> WARN_ON(old_type != TC_PORT_UNKNOWN &&
> @@ -5095,7 +5105,7 @@ static void icl_update_tc_port_type(struct
> drm_i915_private *dev_priv,
>
> if (old_type != intel_dig_port->tc_type)
> DRM_DEBUG_KMS("Port %c has TC type %s\n", port_name(port),
> - type_str);
> + tc_type_name(intel_dig_port->tc_type));
> }
>
> static void icl_tc_phy_disconnect(struct drm_i915_private *dev_priv,
> @@ -5187,6 +5197,10 @@ static void icl_tc_phy_disconnect(struct
> drm_i915_private *dev_priv,
> I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
> }
>
> + DRM_DEBUG_KMS("Port %c TC type %s disconnected\n",
> + port_name(dig_port->base.port),
> + tc_type_name(dig_port->tc_type));
> +
> dig_port->tc_type = TC_PORT_UNKNOWN;
> }
>
> --
> 2.13.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: Fix TypeC legacy HPD handling
== Series Details == Series: drm/i915/icl: Fix TypeC legacy HPD handling URL : https://patchwork.freedesktop.org/series/54017/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5313 -> Patchwork_11091 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11091 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11091, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54017/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11091: ### IGT changes ### Possible regressions * igt@pm_rpm@basic-rte: - fi-byt-j1900: PASS -> FAIL - fi-bsw-kefka: PASS -> FAIL Warnings * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: SKIP -> PASS +2 * igt@pm_rpm@basic-pci-d3-state: - fi-byt-j1900: PASS -> SKIP - fi-bsw-kefka: PASS -> SKIP Known issues Here are the changes found in Patchwork_11091 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic-files: - fi-bsw-kefka: PASS -> FAIL [fdo#108656] * igt@i915_selftest@live_contexts: - fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569] - fi-icl-u2: NOTRUN -> DMESG-FAIL [fdo#108569] * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: PASS -> FAIL [fdo#108767] * igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1 Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@kms_chamelium@common-hpd-after-suspend: - fi-icl-u2: DMESG-FAIL [fdo#103375] / [fdo#107732] / [fdo#108070] / [fdo#108924] -> PASS * igt@kms_flip@basic-flip-vs-dpms: - fi-icl-u3: DMESG-WARN [fdo#108924] / [fdo#109044] -> PASS * igt@kms_frontbuffer_tracking@basic: - fi-byt-clapper: FAIL [fdo#103167] -> PASS * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107732]: https://bugs.freedesktop.org/show_bug.cgi?id=107732 [fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 [fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924 [fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044 Participating hosts (50 -> 46) -- Additional (2): fi-glk-dsi fi-bsw-n3050 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y Build changes - * Linux: CI_DRM_5313 -> Patchwork_11091 CI_DRM_5313: 539600d0a77b59892c5c29edacd2637580d094fe @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4747: ad821d1dc5d0eea4ac3a0e8e29c56c7f66191108 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_11091: 6dcacf85c9ee02659815fcfd43b9595ddf1e7f2e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6dcacf85c9ee drm/i915/icl: Fix TypeC legacy DP HPD handling f67b633f6c34 drm/i915/icl: Fix TypeC legacy HDMI HPD handling 865ff59f3e7d drm/i915/icl: Add a debug print for TypeC port disconnection == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11091/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Fix TypeC legacy HPD handling
== Series Details ==
Series: drm/i915/icl: Fix TypeC legacy HPD handling
URL : https://patchwork.freedesktop.org/series/54017/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
865ff59f3e7d drm/i915/icl: Add a debug print for TypeC port disconnection
-:28: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should
probably be static const char * const
#28: FILE: drivers/gpu/drm/i915/intel_dp.c:5071:
+ static const char *names[] = {
total: 0 errors, 1 warnings, 0 checks, 65 lines checked
f67b633f6c34 drm/i915/icl: Fix TypeC legacy HDMI HPD handling
-:250: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool
bitfields as unsigned int or u<8|16|32>
#250: FILE: drivers/gpu/drm/i915/intel_drv.h:1237:
+ bool tc_legacy_port:1;
total: 0 errors, 1 warnings, 0 checks, 175 lines checked
6dcacf85c9ee drm/i915/icl: Fix TypeC legacy DP HPD handling
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/icl: Fix TypeC legacy DP HPD handling
TypeC legacy DP ports can't be implied the same way we implied TypeC legacy HDMI ports in the previous patch. So that we still have functioning DP legacy ports, mark them as legacy at the first connect event. After that we treat the port the same way as in the HDMI case, that is keep it in legacy mode whenever we are not suspended. Eventually - instead of the methods in this and the previous patch - we'll depend on an explicit way to detect both HDMI and DP TypeC legacy ports either via a VBT option or a HW/FW register. Suggested-by: Ville Syrjälä Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: José Roberto de Souza Cc: Rodrigo Vivi Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_dp.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 19e49adab548..f5de0d079ab5 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5220,8 +5220,14 @@ static bool icl_tc_port_connected(struct drm_i915_private *dev_priv, bool is_legacy, is_typec, is_tbt; u32 dpsp; - is_legacy = intel_dig_port->tc_legacy_port || + /* +* TODO: Depend only on the tc_legacy_port flag to identify legacy +* ports, once we have an explicit detection method for legacy mode +* (via VBT or a HW/FW register). +*/ + intel_dig_port->tc_legacy_port |= I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port); + is_legacy = intel_dig_port->tc_legacy_port; /* * The spec says we shouldn't be using the ISR bits for detecting -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/icl: Add a debug print for TypeC port disconnection
It's useful to see at which point a TypeC port gets disconnected, so add
add a debug print for it.
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e94faa0a42eb..082594bb65a7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5066,28 +5066,38 @@ static bool icl_combo_port_connected(struct
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
}
+static const char *tc_type_name(enum tc_port_type type)
+{
+ static const char *names[] = {
+ [TC_PORT_UNKNOWN] = "unknown",
+ [TC_PORT_LEGACY] = "legacy",
+ [TC_PORT_TYPEC] = "typec",
+ [TC_PORT_TBT] = "tbt",
+ };
+
+ if (WARN_ON(type >= ARRAY_SIZE(names)))
+ type = TC_PORT_UNKNOWN;
+
+ return names[type];
+}
+
static void icl_update_tc_port_type(struct drm_i915_private *dev_priv,
struct intel_digital_port *intel_dig_port,
bool is_legacy, bool is_typec, bool is_tbt)
{
enum port port = intel_dig_port->base.port;
enum tc_port_type old_type = intel_dig_port->tc_type;
- const char *type_str;
WARN_ON(is_legacy + is_typec + is_tbt != 1);
- if (is_legacy) {
+ if (is_legacy)
intel_dig_port->tc_type = TC_PORT_LEGACY;
- type_str = "legacy";
- } else if (is_typec) {
+ else if (is_typec)
intel_dig_port->tc_type = TC_PORT_TYPEC;
- type_str = "typec";
- } else if (is_tbt) {
+ else if (is_tbt)
intel_dig_port->tc_type = TC_PORT_TBT;
- type_str = "tbt";
- } else {
+ else
return;
- }
/* Types are not supposed to be changed at runtime. */
WARN_ON(old_type != TC_PORT_UNKNOWN &&
@@ -5095,7 +5105,7 @@ static void icl_update_tc_port_type(struct
drm_i915_private *dev_priv,
if (old_type != intel_dig_port->tc_type)
DRM_DEBUG_KMS("Port %c has TC type %s\n", port_name(port),
- type_str);
+ tc_type_name(intel_dig_port->tc_type));
}
static void icl_tc_phy_disconnect(struct drm_i915_private *dev_priv,
@@ -5187,6 +5197,10 @@ static void icl_tc_phy_disconnect(struct
drm_i915_private *dev_priv,
I915_WRITE(PORT_TX_DFLEXDPCSSS, val);
}
+ DRM_DEBUG_KMS("Port %c TC type %s disconnected\n",
+ port_name(dig_port->base.port),
+ tc_type_name(dig_port->tc_type));
+
dig_port->tc_type = TC_PORT_UNKNOWN;
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915/icl: Fix TypeC legacy HPD handling
This patchset fixes the HPD handling for TypeC legacy ports. It depends on an indirect detection method described in patch 2 and 3, which will be replaced by a direct method once the BIOS/HW/FW team delivers a promised SW/HW flag for this purpose. There is no issue with the indirect method I know of, except for the DP legacy case (as opposed to the HDMI case), where doing a modeset/DP AUX read before the first HPD connect event will still result in mayham. But that is already the situation now and we have a plan in place (the direct method mentioned above), so the change is an improvement even for the DP case. This will leave the Thunderbolt and USB DP alternate mode HPD handling still disfunctional, but that's another story, we have some plan to fix that too (in cooperation with the HW/FW team). Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: José Roberto de Souza Cc: Rodrigo Vivi Imre Deak (3): drm/i915/icl: Add a debug print for TypeC port disconnection drm/i915/icl: Add fix for TypeC legacy HDMI HPD handling drm/i915/icl: Add fix for TypeC legacy DP HPD handling drivers/gpu/drm/i915/intel_ddi.c | 54 +-- drivers/gpu/drm/i915/intel_dp.c | 69 +--- drivers/gpu/drm/i915/intel_drv.h | 5 ++- 3 files changed, 105 insertions(+), 23 deletions(-) -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/icl: Fix TypeC legacy HDMI HPD handling
Atm HPD disconnect events on TypeC ports will break things, since we'll
switch the TypeC mode (between Legacy and disconnected modes as well as
among USB DP alternate, Thunderbolt alternate and disconnected modes) on
the fly from the HPD disconnect interrupt work while the port may be
still active.
Even if the port happens to be not active during the disconnect we'd
still have a problem during a subsequent modeset or AUX transfer that
could happen regardless of the port's connected state. For instance the
system resume display mode restore code and userspace could perform a
modeset on the port or userspace could start an AUX transfer even if the
port is in disconnected state.
To fix this keep legacy TypeC ports in TypeC legacy mode whenever we're
not suspended. The legacy mode is a static configuration as opposed to
the Thunderbolt and USB DP alternate modes between which we can switch
dynamically.
We don't have yet an explicit way to detect TypeC legacy ports, but we
can imply that at least in case of HDMI enabled ports, since HDMI can
only be provided in legacy mode. So mark TypeC HDMI enabled ports as
legacy and run the TypeC PHY connect sequence explicitly during driver
loading and system resume. The connect will succeed even if the display
is not connected to begin with (or disappears during the suspended
state) since for legacy ports the PORT_TX_DFLEXDPPMS /
DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB
DP alternate mode where it gets set only when a display is connected).
Correspondingly run the TypeC PHY disconnect sequence during system
suspend and driver unloading, but disconnect during suspend only for
legacy TypeC mode. We will need to disconnect even in USB DP alternate
mode in the future, but atm we don't have a way to reconnect the port
in this mode during resume if the display disappears while being
suspended. So for now punt on this case.
Note that we do not disconnect the port during runtime suspend; in
legacy mode there are no shared HW resources (PHY lanes) with other HW
blocks (USB), so no need to release / reacquire these resources as with
USB DP alternate mode. The only reason to disconnect legacy ports during
system suspend is that the PORT_TX_DFLEXDPPMS /
DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be
connected again during system resume. We may also need to turn the check
for this flag into a poll, depending on further tests and clarifications
we are expecting from HW/FW people.
If VBT says that the port provides only DP functionality then we can't
assume that it's a legacy port as for HDMI (since it could as well be
a TBT/DP Alt connector), so we'll solve HPD handling for the DP case
with a different method in the next patch.
Eventually - instead of the above method - we'll depend on an explicit
detection method provided either via a VBT flag or a FW/HW register both
for the HDMI and DP case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924
Cc: Paulo Zanoni
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c | 54 +---
drivers/gpu/drm/i915/intel_dp.c | 29 ++---
drivers/gpu/drm/i915/intel_drv.h | 5 +++-
3 files changed, 75 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f3e1d6a0b7dd..2e47ffa1c95a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3901,9 +3901,50 @@ static bool intel_ddi_compute_config(struct
intel_encoder *encoder,
}
+static void intel_ddi_encoder_suspend(struct intel_encoder *encoder)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(&encoder->base);
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_dp_encoder_suspend(encoder);
+
+ /*
+* TODO: disconnect also from USB DP alternate mode once we have a
+* way to handle the modeset restore in that mode during resume
+* even if the sink has disappeared while being suspended.
+*/
+ if (dig_port->tc_legacy_port)
+ icl_tc_phy_disconnect(i915, dig_port);
+}
+
+static void intel_ddi_encoder_reset(struct drm_encoder *drm_encoder)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(drm_encoder);
+ struct drm_i915_private *i915 = to_i915(drm_encoder->dev);
+
+ if (intel_port_is_tc(i915, dig_port->base.port))
+ intel_digital_port_connected(&dig_port->base);
+
+ intel_dp_encoder_reset(drm_encoder);
+}
+
+static void intel_ddi_encoder_destroy(struct drm_encoder *encoder)
+{
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+ struct drm_i915_private *i915 = to_i915(encoder->dev);
+
+ intel_dp_encoder_flush_work(encoder);
+
+ if (intel_port_is_tc(i915, dig_port->base
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/icl: Define MOCS table for Icelake
On Thu, Dec 13, 2018 at 5:46 AM Joonas Lahtinen
wrote:
>
> Quoting Tvrtko Ursulin (2018-12-10 17:17:29)
> >
> > On 07/11/2018 15:16, Tomasz Lis wrote:
> > > The table has been unified across OSes to minimize virtualization
> > > overhead.
> > >
> > > The MOCS table is now published as part of bspec, and versioned. Entries
> > > are supposed to never be modified, but new ones can be added. Adding
> > > entries increases table version. The patch includes version 1 entries.
> > >
> > > Meaning of each entry is now explained in bspec, and user mode clients
> > > are expected to know what each entry means. The 3 entries used for
> > > previous
> > > platforms are still compatible with their legacy definitions, but that is
> > > not guaranteed to be true for future platforms.
> > >
> > > v2: Fixed SCC values, improved commit comment (Daniele)
> > > v3: Improved MOCS table comment (Daniele)
> > > v4: Moved new entries below gen9 ones. Put common entries into
> > > definition to be used in multiple arrays. (Lucas)
> > > v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
> > > to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas)
> > > v6: Removed definitions of reserved entries. (Michal)
> > > Increased limit of entries sent to the hardware on gen11+.
> > >
> > > BSpec: 34007
> > > BSpec: 560
> > > Signed-off-by: Tomasz Lis
> > > Reviewed-by: Daniele Ceraolo Spurio (v4)
> >
> > R-b upgrade needed here as well.
> >
> > > Cc: Joonas Lahtinen
> > > Cc: Chris Wilson
> > > Cc: Mika Kuoppala
> > > Cc: Daniele Ceraolo Spurio
> > > Cc: Zhenyu Wang
> > > Cc: Zhi A Wang
> > > Cc: Anuj Phogat
> > > Cc: Adam Cetnerowski
> > > Cc: Piotr Rozenfeld
> > > Cc: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/intel_mocs.c | 222
> > > +-
> > > 1 file changed, 197 insertions(+), 25 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> > > b/drivers/gpu/drm/i915/intel_mocs.c
> > > index 8d08a7b..4eb05c6 100644
> > > --- a/drivers/gpu/drm/i915/intel_mocs.c
> > > +++ b/drivers/gpu/drm/i915/intel_mocs.c
> > > @@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
> > > #define LE_SCC(value) ((value) << 8)
> > > #define LE_PFM(value) ((value) << 11)
> > > #define LE_SCF(value) ((value) << 14)
> > > +#define LE_COS(value)((value) << 15)
> > > +#define LE_SSE(value)((value) << 17)
> > >
> > > /* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per
> > > word */
> > > #define L3_ESC(value) ((value) << 0)
> > > @@ -52,6 +54,10 @@ struct drm_i915_mocs_table {
> > >
> > > /* Helper defines */
> > > #define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are
> > > reserved. */
> > > +#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but
> > > configured. */
> > > +
> > > +#define NUM_MOCS_ENTRIES(i915) \
> > > + (INTEL_GEN(i915) < 11 ? GEN9_NUM_MOCS_ENTRIES :
> > > GEN11_NUM_MOCS_ENTRIES)
> >
> > I have a suggestion to make this a bit more elegant by avoiding a
> > sprinkle of conditionals throughout the code - since I count ten
> > non-debug call sites of this macros.
> >
> > Since the MOCS code seems nicely driven from struct drm_i915_mocs_table,
> > the suggestion is to store both the used and maximum valid number of
> > entries per platform in that structure.
> >
> > It's all nicely consolidated in get_mocs_settings, where all the sanity
> > checks could be moved as well. Other bits of the code would then just
> > trust the table.
> >
> > >
> > > /* (e)LLC caching options */
> > > #define LE_PAGETABLE0
> > > @@ -80,21 +86,21 @@ struct drm_i915_mocs_table {
> > >* LNCFCMOCS0 - LNCFCMOCS32 registers.
> > >*
> > >* These tables are intended to be kept reasonably consistent across
> > > - * platforms. However some of the fields are not applicable to all of
> > > - * them.
> > > + * HW platforms, and for ICL+, be identical across OSes. To achieve
> > > + * that, for Icelake and above, list of entries is published as part
> > > + * of bspec.
> > >*
> > >* Entries not part of the following tables are undefined as far as
> > > - * userspace is concerned and shouldn't be relied upon. For the time
> > > - * being they will be implicitly initialized to the strictest caching
> > > - * configuration (uncached) to guarantee forwards compatibility with
> > > - * userspace programs written against more recent kernels providing
> > > - * additional MOCS entries.
> > > + * userspace is concerned and shouldn't be relied upon.
> > > + *
> > > + * The last two entries are reserved by the hardware. For ICL+ they
> > > + * should be initialized according to bspec and never used, for older
> > > + * platforms they should never be written to.
> > >*
> > > - * NOTE: These tables MUST start with being uncached and the length
> > > - * MUST be less than 63 as the last tw
Re: [Intel-gfx] [PATCH] drm/amd: Compile fix for amdgpu_dm.c
Hi Mika,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20181213]
[cannot apply to v4.20-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mika-Kuoppala/drm-amd-Compile-fix-for-amdgpu_dm-c/20181213-062039
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'amdgpu_dm_mode_config_init':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:30: error:
passing argument 1 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
drm_atomic_private_obj_init(adev->ddev,
^~~~
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: expected 'struct drm_private_obj *'
but argument is of type 'struct drm_device *'
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1667:9: error:
passing argument 2 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
&adev->dm.atomic_obj,
^
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: expected 'struct drm_private_state *'
but argument is of type 'struct drm_private_obj *'
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1668:9: error:
passing argument 3 of 'drm_atomic_private_obj_init' from incompatible pointer
type [-Werror=incompatible-pointer-types]
&state->base,
^
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: expected 'const struct
drm_private_state_funcs *' but argument is of type 'struct drm_private_state *'
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1666:2: error:
>> too many arguments to function 'drm_atomic_private_obj_init'
drm_atomic_private_obj_init(adev->ddev,
^~~
In file included from include/drm/drm_dp_mst_helper.h:27:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:46,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:57,
from
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
include/drm/drm_atomic.h:403:6: note: declared here
void drm_atomic_private_obj_init(struct drm_private_obj *obj,
^~~
cc1: some warnings being treated as errors
vim +/drm_atomic_private_obj_init +1666
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c
1631
1632 static int amdgpu_dm_mode_config_init(struct amdgpu_device *adev)
1633 {
1634 struct dm_atomic_state *state;
1635 int r;
1636
1637 adev->mode_info.mode_config_initialized = true;
1638
1639 adev->ddev->mode_config.funcs = (void *)&amdgpu_dm_mode_funcs;
1640 adev->ddev->mode_config.helper_private =
&amdgpu_dm_mode_config_helperfuncs;
1641
1642 adev->ddev->mode_config.max_width = 16384;
1643 adev->ddev->mode_config.max_height = 16384;
1644
1645 adev->ddev->mode_config.preferred_depth = 24;
1646 adev->ddev->mode_config.prefer_sha
Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
Am 13.12.18 um 18:26 schrieb Daniel Vetter: >>> Code sharing just because the code looks similar is imo a really >>> bad idea, when the semantics are entirely different (that was also the >>> reason behind not reusing all the cpu event stuff for dma_fence, they're >>> not normal cpu events). >> Ok, the last sentence is what I don't understand. >> >> What exactly is the semantic difference between the dma_fence_wait and >> the wait_event interface? >> >> I mean the wait_event interface was introduced to prevent drivers from >> openly coding an event interface and getting it wrong all the time. >> >> So a good part of the bugs we have seen around waiting for dma-fences >> are exactly why wait_event was invented in the first place. >> >> The only big thing I can see missing in the wait_event interface is >> waiting for many events at the same time, but that should be a rather >> easy addition. > So this bikeshed was years ago, maybe I should type a patch to > document it, but as far as I remember the big difference is: > > - wait_event and friends generally Just Work. It can go wrong of > course, but the usual pattern is that the waker-side does and > uncoditional wake_up_all, and hence all the waiter needs to do is add > themselves to the waiter list. > > - dma_buf otoh is entirely different: We wanted to support all kinds > fo signalling modes, including having interrupts disabled by default > (not sure whether we actually achieve this still with all the cpu-side > scheduling the big drivers do). Which means the waker does not > unconditionally call wake_up_all, at least not timeline, and waiters > need to call dma_fence_enable_signalling before they can add > themselves to the waiter list and call schedule(). Well that is not something I'm questioning because we really need this behavior as well. But all of this can be perfectly implemented on top of wake_up_all. > The other bit difference is how you check for the classic wakeup races > where the event happens between when you checked for it and when you > go to sleep. Because hw is involved, the rules are again a bit > different, and their different between drivers because hw is > incoherent/broken in all kinds of ways. So there's also really tricky > things going on between adding the waiter to the waiter list and > dma_fence_enable_signalling. For pure cpu events you can ignore this > and bake the few necessary barriers into the various macros, dma_fence > needs more. Ah, yes I think I know what you mean with that and I also consider this a bad idea as well. Only very few drivers actually need this behavior and the ones who do should be perfectly able to implement this inside the driver code. The crux is that leaking this behavior into the dma-fence made it unnecessary complicated and result in quite a bunch of unnecessary irq_work and delayed_work usage. I will take a look at this over the holidays. Shouldn't be to hard to fix and actually has some value additional to being just a nice cleanup. Regards, Christian. > > Adding Maarten, maybe there was more. I definitely remember huge&very > long discussions about all this. > -Daniel ___ 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: Apply missed interrupt after reset w/a to all ringbuffer gen (rev6)
== Series Details == Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev6) URL : https://patchwork.freedesktop.org/series/53979/ State : success == Summary == CI Bug Log - changes from CI_DRM_5311_full -> Patchwork_11087_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11087_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11087_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_11087_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-kbl: SKIP -> PASS Known issues Here are the changes found in Patchwork_11087_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-apl: NOTRUN -> FAIL [fdo#103158] * igt@gem_exec_schedule@pi-ringfull-render: - shard-skl: NOTRUN -> FAIL [fdo#103158] - shard-iclb: NOTRUN -> FAIL [fdo#103158] * igt@gem_softpin@noreloc-s3: - shard-iclb: PASS -> INCOMPLETE [fdo#107713] +1 - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@gem_userptr_blits@readonly-unsync: - shard-skl: NOTRUN -> TIMEOUT [fdo#108887] * igt@kms_available_modes_crc@available_mode_test_crc: - shard-apl: PASS -> FAIL [fdo#106641] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_ccs@pipe-a-crc-primary-rotation-180: - shard-iclb: NOTRUN -> FAIL [fdo#107725] +2 * igt@kms_cursor_crc@cursor-256x256-dpms: - shard-glk: PASS -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_legacy@2x-flip-vs-cursor-legacy: - shard-glk: PASS -> FAIL [fdo#104873] * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-xtiled: - shard-iclb: PASS -> WARN [fdo#108336] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-apl: PASS -> FAIL [fdo#103167] / [fdo#105682] * igt@kms_frontbuffer_tracking@fbc-badstride: - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +10 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +6 * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt: - shard-iclb: PASS -> FAIL [fdo#103167] +1 * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-iclb: NOTRUN -> FAIL [fdo#108948] +1 * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-iclb: PASS -> DMESG-FAIL [fdo#103166] / [fdo#107724] * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-iclb: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +4 * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] +2 * igt@kms_plane_multiple@atomic-pipe-c-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] * igt@kms_vblank@pipe-a-ts-continuation-idle: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +20 * igt@pm_rpm@universal-planes: - shard-iclb: PASS -> DMESG-WARN [fdo#108654] / [fdo#108756] Possible fixes * igt@gem_userptr_blits@readonly-unsync: - shard-iclb: TIMEOUT -> PASS * igt@gem_workarounds@suspend-resume-context: - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] -> PASS * igt@i915_suspend@sysfs-reader: - shard-skl: INCOMPLETE [fdo#104108] -> PASS * igt@kms_ccs@pipe-b-crc-sprite-planes-basic: - shard-glk: FAIL [fdo#108145] -> PASS * igt@kms_cursor_crc@cursor-128x128-sliding: - shard-apl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-256x256-sliding: - shard-glk: FAIL
Re: [Intel-gfx] [PATCH 5/5] drm/i915/debugfs: Print PSR selective update status register values
On Tue, 2018-12-11 at 14:20 -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> > The value of this registers will be used to test if PSR2 is doing
> > selective update and if the number of blocks match with the
> > expected.
> >
> > Cc: Rodrigo Vivi
> > Cc: Dhinakaran Pandiyan
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 42
> > ++-
> > --
> > 1 file changed, 38 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 505d93b31eb6..754b33194e09 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2760,10 +2760,44 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > seq_printf(m, "Performance counter: %u\n", val);
> > }
> >
> > - if ((psr->debug & I915_PSR_DEBUG_IRQ) && !psr->psr2_enabled) {
> > - seq_printf(m, "Last attempted entry at: %lld\n",
> > - psr->last_entry_attempt);
> > - seq_printf(m, "Last exit at: %lld\n", psr->last_exit);
> > + if (!psr->psr2_enabled) {
> > + if (psr->debug & I915_PSR_DEBUG_IRQ) {
> > + seq_printf(m, "Last attempted entry at:
> > %lld\n",
> > + psr->last_entry_attempt);
> > + seq_printf(m, "Last exit at: %lld\n", psr-
> > > last_exit);
> > + }
> > + } else {
> > + u8 i;
> > +
> > + val = I915_READ(EDP_PSR2_SU_STATUS);
> > + seq_printf(m, "PSR2 SU status: 0x%08x\n", val);
> > + for (i = 0; val && i < 3; i++) {
> > + u32 num;
> > +
> > + num = val &
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i);
> > + num = num >>
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i);
> > + seq_printf(m, "\tSU num blocks in frame N-%u:
> > %u\n", i, num);
> > + }
> > +
> > + val = I915_READ(EDP_PSR2_SU_STATUS2);
> > + seq_printf(m, "PSR2 SU status2: 0x%08x\n", val);
> > + for (i = 0; val && i < 3; i++) {
> > + u32 num;
> > +
> > + num = val &
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i);
> > + num = num >>
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i);
> > + seq_printf(m, "\tSU num blocks in frame N-%u:
> > %u\n", i + 3, num);
> > + }
> > +
> > + val = I915_READ(EDP_PSR2_SU_STATUS3);
> > + seq_printf(m, "PSR2 SU status3: 0x%08x\n", val);
> > + for (i = 0; val && i < 2; i++) {
> > + u32 num;
> > +
> > + num = val &
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_MASK(i);
> > + num = num >>
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_IN_FRAME_SHIFT(i);
> > + seq_printf(m, "\tSU num blocks in frame N-%u:
> > %u\n", i + 6, num);
> nitpick: Have you considered reducing the text that's getting printed
> here? I guess we might not need to increase the read buffer size in
> IGT
> if we do some thing like this.
>
> Frame SU blocks
> 0 f
> 1 o
> 2 o
>
>
> I'll leave it to you if you want to change, but I do prefer making
> this
> less verbose.
Down to this:
Sink support: yes [0x03]
PSR mode: PSR2 enabled
Source PSR ctl: enabled [0xc2000216]
Source PSR status: CAPTURE [0x14080030]
Busy frontbuffer bits: 0x
Frame: PSR2 SU blocks:
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
I will just check if the SU blocks are easy to parse from IGT tests.
>
> > + }
> > }
> >
> > unlock:
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas wrote: > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam > > wrote: > > > > > > Tomas and Daniel, > > > > > > We got an issue here. > > > > > > The relationship that we try to build between I915 and mei_hdcp is as > > > follows: > > > > > > We are using the components to establish the relationship. > > > I915 is component master where as mei_hdcp is component. > > > I915 adds the component master during the module load. mei_hdcp adds the > > component when the driver->probe is called (on device driver binding). > > > I915 forces itself such that until mei_hdcp component is added I915_load > > wont be complete. > > > Similarly on complete system, if mei_hdcp component is removed, > > immediately I915 unregister itself and HW will be shutdown. > > > > > > This is completely fine when the modules are loaded and unloaded. > > > > > > But during suspend, mei device disappears and mei bus handles it by > > unbinding device and driver by calling driver->remove. > > > This in-turn removes the component and triggers the master unbind of I915 > > where, I915 unregister itself. > > > This cause the HW state mismatch during the suspend and resume. > > > > > > Please check the powerwell mismatch errors at CI report for v9 > > > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/igt@ > > > gem_exec_susp...@basic-s3.html > > > > > > More over unregistering I915 during the suspend is not expected. So how do > > we handle this? > > > > Bit more context from our irc discussion with Ram: > > > > I found this very surprising, since I don't know of any other subsystems > > where > > the devices get outright removed when going through a suspend/resume cycle. > > The device model was built to handle this stuff > > correctly: First clients/devices/interfaces get suspend, then the > > parent/bridge/bus. Same dance in reverse when resuming. This even holds for > > lots of hotpluggable buses, where child devices could indeed disappear on > > resume, but as long as they don't, everything stays the same. It's really > > surprising for something that's soldered onto the board like ME. > > HDCP is an application in the ME it's not ME itself.. On the linux side > HDCP2 is a virtual device on mei client virtual bus, > the bus is teared down on ME reset, which mostly happen on power > transitions. > Theoretically, we could keep it up during power transitions, but so fare it > was not necessary > and second it's not guarantie that the all ME applications will reappear > after reset. When does this happen that an ME application doesn't come back after e.g. suspend/resume? Also, what's all the place where this reset can happen? Just suspend/resume/hibernate and all these, or also at other times? How does userspace deal with the reset over s/r? I'm assuming that at least the device node file will become invalid (or whatever you're using as userspace api), so if userspace is accessing stuff on the me at the same time as we do a suspend/resume, what happens? > > Aside: We'll probably need a device_link to make sure mei_hdcp is fully > > resumed before i915 gets resumed, but that's kinda a detail for later on. > > Frankly I don’t believe there is currently exact abstraction that supports > this model, > neither components nor device_link . > So fare we used class interface for other purposes, it worked well. I'm not clear on what class interface has to do with component or device link. They all solve different problems, at least as far as I understand all this stuff ... -Daniel > > Tomas, can you pls explain why mei is designed like this? Or is there > > something > > else we're missing (I didn't dig through the mei bus in detail at all, so > > not clear > > on what exactly is going on there). > Above. > > > > Also pulling in device model and suspend/resume experts. > > > > Thanks, Daniel > > > > > > > > -Ram > > > > > > On 12/13/2018 9:31 AM, Ramalingam C wrote: > > > > > > Mei hdcp driver is designed as component slave for the I915 component > > > master. > > > > > > v2: Rebased. > > > v3: > > > Notifier chain is adopted for cldev state update [Tomas] > > > v4: > > > Made static dummy functions as inline in mei_hdcp.h > > > API for polling client device status > > > IS_ENABLED used in header, for config status for mei_hdcp. > > > v5: > > > Replacing the notifier with component framework. [Daniel] > > > v6: > > > Rebased on the I915 comp master redesign. > > > v7: > > > mei_hdcp_component_registered is made static [Uma] > > > Need for global static variable mei_cldev is removed. > > > > > > Signed-off-by: Ramalingam C > > > Reviewed-by: Uma Shankar > > > --- > > > drivers/misc/mei/hdcp/mei_hdcp.c | 67 > > > +--- > > > 1 file changed, 63 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c > > > b/drivers/misc/mei/hdcp/mei_hdcp.c > > > index b22a71e8c5d7..3de1700dcc9f 1006
Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
On Thu, Dec 13, 2018 at 5:47 PM Koenig, Christian
wrote:
>
> Am 13.12.18 um 17:01 schrieb Daniel Vetter:
> > On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
> >> Am 13.12.18 um 13:21 schrieb Chris Wilson:
> >>> Quoting Koenig, Christian (2018-12-13 12:11:10)
> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> > Quoting Chunming Zhou (2018-12-11 10:34:45)
> >> From: Christian König
> >>
> >> Implement finding the right timeline point in drm_syncobj_find_fence.
> >>
> >> v2: return -EINVAL when the point is not submitted yet.
> >> v3: fix reference counting bug, add flags handling as well
> >>
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/drm_syncobj.c | 43
> >> ---
> >> 1 file changed, 40 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_syncobj.c
> >> b/drivers/gpu/drm/drm_syncobj.c
> >> index 76ce13dafc4d..d964b348ecba 100644
> >> --- a/drivers/gpu/drm/drm_syncobj.c
> >> +++ b/drivers/gpu/drm/drm_syncobj.c
> >> @@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file
> >> *file_private,
> >> struct dma_fence **fence)
> >> {
> >>struct drm_syncobj *syncobj =
> >> drm_syncobj_find(file_private, handle);
> >> - int ret = 0;
> >> + struct syncobj_wait_entry wait;
> >> + int ret;
> >>
> >>if (!syncobj)
> >>return -ENOENT;
> >>
> >>*fence = drm_syncobj_fence_get(syncobj);
> >> - if (!*fence) {
> >> + drm_syncobj_put(syncobj);
> >> +
> >> + if (*fence) {
> >> + ret = dma_fence_chain_find_seqno(fence, point);
> >> + if (!ret)
> >> + return 0;
> >> + dma_fence_put(*fence);
> >> + } else {
> >>ret = -EINVAL;
> >>}
> >> - drm_syncobj_put(syncobj);
> >> +
> >> + if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
> >> + return ret;
> >> +
> >> + memset(&wait, 0, sizeof(wait));
> >> + wait.task = current;
> >> + wait.point = point;
> >> + drm_syncobj_fence_add_wait(syncobj, &wait);
> >> +
> >> + do {
> >> + set_current_state(TASK_INTERRUPTIBLE);
> >> + if (wait.fence) {
> >> + ret = 0;
> >> + break;
> >> + }
> >> +
> >> + if (signal_pending(current)) {
> >> + ret = -ERESTARTSYS;
> >> + break;
> >> + }
> >> +
> >> + schedule();
> >> + } while (1);
> > I've previously used a dma_fence_proxy so that we could do nonblocking
> > waits on future submits. That would be preferrable (a requirement for
> > our stupid BKL-driven code).
> That is exactly what I would definitely NAK.
>
> I would rather say we should come up with a wait_multiple_events() macro
> and completely nuke the custom implementation of this in:
> 1. dma_fence_default_wait and dma_fence_wait_any_timeout
> 2. the radeon fence implementation
> 3. the nouveau fence implementation
> 4. the syncobj code
>
> Cause all of them do exactly the same. The dma_fence implementation
> unfortunately came up with a custom event handling mechanism instead of
> extending the core Linux wait_event() system.
> >>> I don't want a blocking wait at all.
> >> Ok I wasn't clear enough :) That is exactly what I would NAK!
> >>
> >> The wait must be blocking or otherwise you would allow wait-before-signal.
> > Well the current implementation is pulling a rather big trick on readers
> > in this regard: It looks like a dma_fence, it's implemented as one even,
> > heck you even open-code a dma_fence_wait here.
> >
> > Except the semantics are completely different.
> >
> > So aside from the discussion whether we really want to fully chain them I
> > think it just doesn't make sense to implement the "wait for fence submit"
> > as a dma_fence wait. And I'd outright remove that part from the uapi, and
> > force the wait. The current radv/anv plans I discussed with Jason was that
> > we'd have a separate submit thread, and hence unconditionally blocking
> > until the fence has materialized is the right thing to do. Even allowing
> > that option, either through a flag, or making these things look like
> > dma_fences (they are _not_) just tricks folks into misunderstanding what's
> > going on.
>
> Good, that sounds strongly like something I can agree on as well.
>
> > Code sharing just because the code looks similar is imo a really
> > bad idea, when the semantics are entirely different
Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
Am 13.12.18 um 17:01 schrieb Daniel Vetter:
> On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
>> Am 13.12.18 um 13:21 schrieb Chris Wilson:
>>> Quoting Koenig, Christian (2018-12-13 12:11:10)
Am 13.12.18 um 12:37 schrieb Chris Wilson:
> Quoting Chunming Zhou (2018-12-11 10:34:45)
>> From: Christian König
>>
>> Implement finding the right timeline point in drm_syncobj_find_fence.
>>
>> v2: return -EINVAL when the point is not submitted yet.
>> v3: fix reference counting bug, add flags handling as well
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 43
>> ---
>> 1 file changed, 40 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>> b/drivers/gpu/drm/drm_syncobj.c
>> index 76ce13dafc4d..d964b348ecba 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file
>> *file_private,
>> struct dma_fence **fence)
>> {
>>struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
>> handle);
>> - int ret = 0;
>> + struct syncobj_wait_entry wait;
>> + int ret;
>>
>>if (!syncobj)
>>return -ENOENT;
>>
>>*fence = drm_syncobj_fence_get(syncobj);
>> - if (!*fence) {
>> + drm_syncobj_put(syncobj);
>> +
>> + if (*fence) {
>> + ret = dma_fence_chain_find_seqno(fence, point);
>> + if (!ret)
>> + return 0;
>> + dma_fence_put(*fence);
>> + } else {
>>ret = -EINVAL;
>>}
>> - drm_syncobj_put(syncobj);
>> +
>> + if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
>> + return ret;
>> +
>> + memset(&wait, 0, sizeof(wait));
>> + wait.task = current;
>> + wait.point = point;
>> + drm_syncobj_fence_add_wait(syncobj, &wait);
>> +
>> + do {
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + if (wait.fence) {
>> + ret = 0;
>> + break;
>> + }
>> +
>> + if (signal_pending(current)) {
>> + ret = -ERESTARTSYS;
>> + break;
>> + }
>> +
>> + schedule();
>> + } while (1);
> I've previously used a dma_fence_proxy so that we could do nonblocking
> waits on future submits. That would be preferrable (a requirement for
> our stupid BKL-driven code).
That is exactly what I would definitely NAK.
I would rather say we should come up with a wait_multiple_events() macro
and completely nuke the custom implementation of this in:
1. dma_fence_default_wait and dma_fence_wait_any_timeout
2. the radeon fence implementation
3. the nouveau fence implementation
4. the syncobj code
Cause all of them do exactly the same. The dma_fence implementation
unfortunately came up with a custom event handling mechanism instead of
extending the core Linux wait_event() system.
>>> I don't want a blocking wait at all.
>> Ok I wasn't clear enough :) That is exactly what I would NAK!
>>
>> The wait must be blocking or otherwise you would allow wait-before-signal.
> Well the current implementation is pulling a rather big trick on readers
> in this regard: It looks like a dma_fence, it's implemented as one even,
> heck you even open-code a dma_fence_wait here.
>
> Except the semantics are completely different.
>
> So aside from the discussion whether we really want to fully chain them I
> think it just doesn't make sense to implement the "wait for fence submit"
> as a dma_fence wait. And I'd outright remove that part from the uapi, and
> force the wait. The current radv/anv plans I discussed with Jason was that
> we'd have a separate submit thread, and hence unconditionally blocking
> until the fence has materialized is the right thing to do. Even allowing
> that option, either through a flag, or making these things look like
> dma_fences (they are _not_) just tricks folks into misunderstanding what's
> going on.
Good, that sounds strongly like something I can agree on as well.
> Code sharing just because the code looks similar is imo a really
> bad idea, when the semantics are entirely different (that was also the
> reason behind not reusing all the cpu event stuff for dma_fence, they're
> not normal cpu events).
Ok, the last sentence is what I don't understand.
What exactly is the semantic difference between the dma_fence_wait and
the wait_event interface?
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix Cherryview oops on boot
== Series Details ==
Series: drm/i915: Fix Cherryview oops on boot
URL : https://patchwork.freedesktop.org/series/54007/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11090
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11090 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11090, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54007/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11090:
### IGT changes ###
Possible regressions
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: NOTRUN -> FAIL
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11090 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: PASS -> FAIL [fdo#108880]
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602] / [fdo#108529] +1
* igt@i915_selftest@live_hangcheck:
- fi-kbl-7560u: NOTRUN -> INCOMPLETE [fdo#108044]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: NOTRUN -> DMESG-WARN [fdo#108924] / [fdo#109044]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-ilk-650: PASS -> DMESG-WARN [fdo#106387]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@module-reload:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108529]
* {igt@runner@aborted}:
- fi-icl-u3: NOTRUN -> FAIL [fdo#108924]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-WARN [fdo#108473] -> DMESG-FAIL [fdo#105079]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044
Participating hosts (47 -> 46)
--
Additional (3): fi-bsw-kefka fi-icl-u3 fi-bsw-n3050
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5311 -> Patchwork_11090
CI_DRM_5311: a42fd8bf199784ee4ff1cdb5ee03eedd9a535d4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11090: efebc101c12c0316e642bbb366e7acb5649d9aab @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
efebc101c12c drm/i915: Fix Cherryview oops on boot
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11090/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
> On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> wrote:
> >
> > Tomas and Daniel,
> >
> > We got an issue here.
> >
> > The relationship that we try to build between I915 and mei_hdcp is as
> > follows:
> >
> > We are using the components to establish the relationship.
> > I915 is component master where as mei_hdcp is component.
> > I915 adds the component master during the module load. mei_hdcp adds the
> component when the driver->probe is called (on device driver binding).
> > I915 forces itself such that until mei_hdcp component is added I915_load
> wont be complete.
> > Similarly on complete system, if mei_hdcp component is removed,
> immediately I915 unregister itself and HW will be shutdown.
> >
> > This is completely fine when the modules are loaded and unloaded.
> >
> > But during suspend, mei device disappears and mei bus handles it by
> unbinding device and driver by calling driver->remove.
> > This in-turn removes the component and triggers the master unbind of I915
> where, I915 unregister itself.
> > This cause the HW state mismatch during the suspend and resume.
> >
> > Please check the powerwell mismatch errors at CI report for v9
> > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/igt@
> > gem_exec_susp...@basic-s3.html
> >
> > More over unregistering I915 during the suspend is not expected. So how do
> we handle this?
>
> Bit more context from our irc discussion with Ram:
>
> I found this very surprising, since I don't know of any other subsystems where
> the devices get outright removed when going through a suspend/resume cycle.
> The device model was built to handle this stuff
> correctly: First clients/devices/interfaces get suspend, then the
> parent/bridge/bus. Same dance in reverse when resuming. This even holds for
> lots of hotpluggable buses, where child devices could indeed disappear on
> resume, but as long as they don't, everything stays the same. It's really
> surprising for something that's soldered onto the board like ME.
HDCP is an application in the ME it's not ME itself.. On the linux side HDCP2
is a virtual device on mei client virtual bus,
the bus is teared down on ME reset, which mostly happen on power transitions.
Theoretically, we could keep it up during power transitions, but so fare it
was not necessary
and second it's not guarantie that the all ME applications will reappear after
reset.
>
> Aside: We'll probably need a device_link to make sure mei_hdcp is fully
> resumed before i915 gets resumed, but that's kinda a detail for later on.
Frankly I don’t believe there is currently exact abstraction that supports this
model,
neither components nor device_link .
So fare we used class interface for other purposes, it worked well.
>
> Tomas, can you pls explain why mei is designed like this? Or is there
> something
> else we're missing (I didn't dig through the mei bus in detail at all, so not
> clear
> on what exactly is going on there).
Above.
>
> Also pulling in device model and suspend/resume experts.
>
> Thanks, Daniel
>
> >
> > -Ram
> >
> > On 12/13/2018 9:31 AM, Ramalingam C wrote:
> >
> > Mei hdcp driver is designed as component slave for the I915 component
> > master.
> >
> > v2: Rebased.
> > v3:
> > Notifier chain is adopted for cldev state update [Tomas]
> > v4:
> > Made static dummy functions as inline in mei_hdcp.h
> > API for polling client device status
> > IS_ENABLED used in header, for config status for mei_hdcp.
> > v5:
> > Replacing the notifier with component framework. [Daniel]
> > v6:
> > Rebased on the I915 comp master redesign.
> > v7:
> > mei_hdcp_component_registered is made static [Uma]
> > Need for global static variable mei_cldev is removed.
> >
> > Signed-off-by: Ramalingam C
> > Reviewed-by: Uma Shankar
> > ---
> > drivers/misc/mei/hdcp/mei_hdcp.c | 67
> > +---
> > 1 file changed, 63 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > index b22a71e8c5d7..3de1700dcc9f 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > @@ -23,11 +23,14 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > #include "mei_hdcp.h"
> >
> > +static bool mei_hdcp_component_registered;
> > +
> > /**
> > * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME
> FW
> > * @dev: device corresponding to the mei_cl_device @@ -691,8 +694,7
> > @@ mei_close_hdcp_session(struct device *dev, struct hdcp_port_data
> *data)
> > return 0;
> > }
> >
> > -static __attribute__((unused))
> > -struct i915_hdcp_component_ops mei_hdcp_ops = {
> > +static struct i915_hdcp_component_ops mei_hdcp_ops = {
> > .owner = THIS_MODULE,
> > .initiate_hdcp2_session = mei_initiate_hdcp2_session,
> > .verify_receiver_cert_prepare_km =
> > mei_verify_receiver_cert_prepare_km,
> > @@ -707,20 +709,77 @@
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
Hi, On 13-12-18 17:05, Patchwork wrote: == Series Details == Series: series starting with [v4,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements URL : https://patchwork.freedesktop.org/series/54003/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11089 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11089 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11089, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/54003/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11089: ### IGT changes ### Possible regressions * igt@pm_rpm@basic-rte: - fi-byt-n2820: PASS -> FAIL This seems to be a false-positive, my changes only touch DSI code paths and looking at the dmesg messages in the logs for this test, there is no DSI involved / present on the test system. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix Cherryview oops on boot
== Series Details == Series: drm/i915: Fix Cherryview oops on boot URL : https://patchwork.freedesktop.org/series/54007/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Fix Cherryview oops on boot +drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/intel_color.c:101:33: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix Cherryview oops on boot
== Series Details == Series: drm/i915: Fix Cherryview oops on boot URL : https://patchwork.freedesktop.org/series/54007/ State : warning == Summary == $ dim checkpatch origin/drm-tip efebc101c12c drm/i915: Fix Cherryview oops on boot -:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #12: <1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at 0048 total: 0 errors, 1 warnings, 0 checks, 20 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix Cherryview oops on boot
On Thu, Dec 13, 2018 at 04:12:41PM +, Chris Wilson wrote:
> Do not dereference the LUT blob before checking whether that blob
> exists. Or else,
>
> <1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at
> 0048
> <6>[ 13.978718] PGD 0 P4D 0
> <4>[ 13.978733] Oops: [#1] PREEMPT SMP PTI
> <4>[ 13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted
> 4.20.0-rc5-CI-CI_DRM_5294+ #1
> <4>[ 13.978773] Hardware name: /NUC5CPYB, BIOS
> PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016
> <4>[ 13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915]
> <4>[ 13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02
> 00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48>
> 8b 50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75
> <4>[ 13.979001] RSP: 0018:c926f840 EFLAGS: 00010246
> <4>[ 13.979018] RAX: RBX: 88816550 RCX:
> 7885fe62
> <4>[ 13.979039] RDX: 0020 RSI: 88816553a008 RDI:
> 888165464a88
> <4>[ 13.979060] RBP: 888165464a88 R08: 0ed0e429 R09:
> 0001
> <4>[ 13.979080] R10: R11: R12:
> 4000
> <4>[ 13.979101] R13: 4000 R14: 88816550 R15:
> 888165464a88
> <4>[ 13.979122] FS: 7fb69c4f3540() GS:88817ba0()
> knlGS:
> <4>[ 13.979146] CS: 0010 DS: ES: CR0: 80050033
> <4>[ 13.979163] CR2: 0048 CR3: 00016d7fa000 CR4:
> 001006f0
> <4>[ 13.979184] Call Trace:
> <4>[ 13.979302] intel_update_crtc+0x18f/0x2b0 [i915]
> <4>[ 13.979421] intel_update_crtcs+0x49/0x60 [i915]
> <4>[ 13.979538] intel_atomic_commit_tail+0x1ea/0xd70 [i915]
> <4>[ 13.979657] ? intel_atomic_commit_ready+0x3f/0x50 [i915]
> <4>[ 13.979762] ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
> <4>[ 13.979884] intel_atomic_commit+0x244/0x330 [i915]
> <4>[ 13.980002] intel_initial_commit+0xb6/0x140 [i915]
> <4>[ 13.980127] intel_modeset_init+0x7a1/0x1880 [i915]
> <4>[ 13.980235] i915_driver_load+0xcbb/0x15c0 [i915]
> <4>[ 13.980257] ? __pm_runtime_resume+0x4f/0x80
> <4>[ 13.980277] ? _raw_spin_unlock_irqrestore+0x4c/0x60
> <4>[ 13.980296] ? lockdep_hardirqs_on+0xe0/0x1b0
> <4>[ 13.980401] i915_pci_probe+0x29/0xa0 [i915]
> <4>[ 13.980421] pci_device_probe+0xa1/0x130
> <4>[ 13.980440] really_probe+0xf3/0x3e0
> <4>[ 13.980456] driver_probe_device+0x10a/0x120
> <4>[ 13.980474] __driver_attach+0xdb/0x100
> <4>[ 13.980489] ? driver_probe_device+0x120/0x120
> <4>[ 13.980505] ? driver_probe_device+0x120/0x120
> <4>[ 13.980522] bus_for_each_dev+0x74/0xc0
> <4>[ 13.980539] bus_add_driver+0x15f/0x250
> <4>[ 13.980554] ? 0xa0348000
> <4>[ 13.980568] driver_register+0x56/0xe0
> <4>[ 13.980583] ? 0xa0348000
> <4>[ 13.980597] do_one_initcall+0x58/0x2e0
> <4>[ 13.980615] ? do_init_module+0x1d/0x1ea
> <4>[ 13.980631] ? rcu_read_lock_sched_held+0x6f/0x80
> <4>[ 13.980649] ? kmem_cache_alloc_trace+0x264/0x290
> <4>[ 13.980668] do_init_module+0x56/0x1ea
> <4>[ 13.980685] load_module+0x227a/0x29c0
> <4>[ 13.980715] ? __se_sys_finit_module+0xd3/0xf0
> <4>[ 13.980731] __se_sys_finit_module+0xd3/0xf0
> <4>[ 13.980756] do_syscall_64+0x55/0x190
> <4>[ 13.980772] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> <4>[ 13.980789] RIP: 0033:0x7fb69c019839
> <4>[ 13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48
> 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48>
> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
> <4>[ 13.980851] RSP: 002b:7ffdc112e3a8 EFLAGS: 0246 ORIG_RAX:
> 0139
> <4>[ 13.980875] RAX: ffda RBX: 55c689fe0b30 RCX:
> 7fb69c019839
> <4>[ 13.980895] RDX: RSI: 55c689a05d2e RDI:
>
> <4>[ 13.980916] RBP: 55c689a05d2e R08: R09:
>
> <4>[ 13.980936] R10: R11: 0246 R12:
>
> <4>[ 13.980957] R13: 55c689fe0c60 R14: 0004 R15:
> 55c689fe0b30
> <4>[ 13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec
> snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers
> <4>[ 13.981027] CR2: 0048
>
> Fixes: 302da0cdf784 ("drm/i915: Use intel_ types more consistently for color
> management code (v2)")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054
> Signed-off-by: Chris Wilson
> Cc: Matt Roper
> Cc: Ville Syrjälä
Reviewed-by: Matt Roper
Pushed to dinq; thanks for the patch.
Matt
> ---
> drivers/gpu/drm/i915/intel_color.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 1d572e83db7f..37fd9ddf7
[Intel-gfx] [PATCH] drm/i915: Fix Cherryview oops on boot
Do not dereference the LUT blob before checking whether that blob
exists. Or else,
<1>[ 13.978684] BUG: unable to handle kernel NULL pointer dereference at
0048
<6>[ 13.978718] PGD 0 P4D 0
<4>[ 13.978733] Oops: [#1] PREEMPT SMP PTI
<4>[ 13.978750] CPU: 0 PID: 282 Comm: modprobe Not tainted
4.20.0-rc5-CI-CI_DRM_5294+ #1
<4>[ 13.978773] Hardware name: /NUC5CPYB, BIOS
PYBSWCEL.86A.0058.2016.1102.1842 11/02/2016
<4>[ 13.978932] RIP: 0010:cherryview_load_csc_matrix+0x1e6/0x210 [i915]
<4>[ 13.978953] Code: 41 5c 41 5d e9 7b 83 aa e1 41 c1 e4 0d 48 83 bd 00 02
00 00 00 48 8b 85 10 02 00 00 45 89 e5 74 09 ba 01 00 00 00 31 c9 eb 9d <48> 8b
50 48 48 c1 ea 03 81 fa 00 01 00 00 75 07 31 d2 48 85 c0 75
<4>[ 13.979001] RSP: 0018:c926f840 EFLAGS: 00010246
<4>[ 13.979018] RAX: RBX: 88816550 RCX:
7885fe62
<4>[ 13.979039] RDX: 0020 RSI: 88816553a008 RDI:
888165464a88
<4>[ 13.979060] RBP: 888165464a88 R08: 0ed0e429 R09:
0001
<4>[ 13.979080] R10: R11: R12:
4000
<4>[ 13.979101] R13: 4000 R14: 88816550 R15:
888165464a88
<4>[ 13.979122] FS: 7fb69c4f3540() GS:88817ba0()
knlGS:
<4>[ 13.979146] CS: 0010 DS: ES: CR0: 80050033
<4>[ 13.979163] CR2: 0048 CR3: 00016d7fa000 CR4:
001006f0
<4>[ 13.979184] Call Trace:
<4>[ 13.979302] intel_update_crtc+0x18f/0x2b0 [i915]
<4>[ 13.979421] intel_update_crtcs+0x49/0x60 [i915]
<4>[ 13.979538] intel_atomic_commit_tail+0x1ea/0xd70 [i915]
<4>[ 13.979657] ? intel_atomic_commit_ready+0x3f/0x50 [i915]
<4>[ 13.979762] ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
<4>[ 13.979884] intel_atomic_commit+0x244/0x330 [i915]
<4>[ 13.980002] intel_initial_commit+0xb6/0x140 [i915]
<4>[ 13.980127] intel_modeset_init+0x7a1/0x1880 [i915]
<4>[ 13.980235] i915_driver_load+0xcbb/0x15c0 [i915]
<4>[ 13.980257] ? __pm_runtime_resume+0x4f/0x80
<4>[ 13.980277] ? _raw_spin_unlock_irqrestore+0x4c/0x60
<4>[ 13.980296] ? lockdep_hardirqs_on+0xe0/0x1b0
<4>[ 13.980401] i915_pci_probe+0x29/0xa0 [i915]
<4>[ 13.980421] pci_device_probe+0xa1/0x130
<4>[ 13.980440] really_probe+0xf3/0x3e0
<4>[ 13.980456] driver_probe_device+0x10a/0x120
<4>[ 13.980474] __driver_attach+0xdb/0x100
<4>[ 13.980489] ? driver_probe_device+0x120/0x120
<4>[ 13.980505] ? driver_probe_device+0x120/0x120
<4>[ 13.980522] bus_for_each_dev+0x74/0xc0
<4>[ 13.980539] bus_add_driver+0x15f/0x250
<4>[ 13.980554] ? 0xa0348000
<4>[ 13.980568] driver_register+0x56/0xe0
<4>[ 13.980583] ? 0xa0348000
<4>[ 13.980597] do_one_initcall+0x58/0x2e0
<4>[ 13.980615] ? do_init_module+0x1d/0x1ea
<4>[ 13.980631] ? rcu_read_lock_sched_held+0x6f/0x80
<4>[ 13.980649] ? kmem_cache_alloc_trace+0x264/0x290
<4>[ 13.980668] do_init_module+0x56/0x1ea
<4>[ 13.980685] load_module+0x227a/0x29c0
<4>[ 13.980715] ? __se_sys_finit_module+0xd3/0xf0
<4>[ 13.980731] __se_sys_finit_module+0xd3/0xf0
<4>[ 13.980756] do_syscall_64+0x55/0x190
<4>[ 13.980772] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 13.980789] RIP: 0033:0x7fb69c019839
<4>[ 13.980804] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48
89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
<4>[ 13.980851] RSP: 002b:7ffdc112e3a8 EFLAGS: 0246 ORIG_RAX:
0139
<4>[ 13.980875] RAX: ffda RBX: 55c689fe0b30 RCX:
7fb69c019839
<4>[ 13.980895] RDX: RSI: 55c689a05d2e RDI:
<4>[ 13.980916] RBP: 55c689a05d2e R08: R09:
<4>[ 13.980936] R10: R11: 0246 R12:
<4>[ 13.980957] R13: 55c689fe0c60 R14: 0004 R15:
55c689fe0b30
<4>[ 13.980986] Modules linked in: i915(+) snd_hda_intel snd_hda_codec
snd_hwdep snd_hda_core snd_pcm pinctrl_cherryview prime_numbers
<4>[ 13.981027] CR2: 0048
Fixes: 302da0cdf784 ("drm/i915: Use intel_ types more consistently for color
management code (v2)")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109054
Signed-off-by: Chris Wilson
Cc: Matt Roper
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_color.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 1d572e83db7f..37fd9ddf762e 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -74,14 +74,17 @@
#define ILK_CSC_COEFF_1_0 \
((7 << 12) | ILK_CSC_COEFF_FP(CTM_COEFF_1_0, 8))
-static bool crtc_state_is_legacy_gamma(struct intel_crtc_state *crtc_state)
+static bool lut_is_legacy(struct drm_prop
Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam wrote:
>
> Tomas and Daniel,
>
> We got an issue here.
>
> The relationship that we try to build between I915 and mei_hdcp is as follows:
>
> We are using the components to establish the relationship.
> I915 is component master where as mei_hdcp is component.
> I915 adds the component master during the module load. mei_hdcp adds the
> component when the driver->probe is called (on device driver binding).
> I915 forces itself such that until mei_hdcp component is added I915_load wont
> be complete.
> Similarly on complete system, if mei_hdcp component is removed, immediately
> I915 unregister itself and HW will be shutdown.
>
> This is completely fine when the modules are loaded and unloaded.
>
> But during suspend, mei device disappears and mei bus handles it by unbinding
> device and driver by calling driver->remove.
> This in-turn removes the component and triggers the master unbind of I915
> where, I915 unregister itself.
> This cause the HW state mismatch during the suspend and resume.
>
> Please check the powerwell mismatch errors at CI report for v9
> https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/igt@gem_exec_susp...@basic-s3.html
>
> More over unregistering I915 during the suspend is not expected. So how do we
> handle this?
Bit more context from our irc discussion with Ram:
I found this very surprising, since I don't know of any other
subsystems where the devices get outright removed when going through a
suspend/resume cycle. The device model was built to handle this stuff
correctly: First clients/devices/interfaces get suspend, then the
parent/bridge/bus. Same dance in reverse when resuming. This even
holds for lots of hotpluggable buses, where child devices could indeed
disappear on resume, but as long as they don't, everything stays the
same. It's really surprising for something that's soldered onto the
board like ME.
Aside: We'll probably need a device_link to make sure mei_hdcp is
fully resumed before i915 gets resumed, but that's kinda a detail for
later on.
Tomas, can you pls explain why mei is designed like this? Or is there
something else we're missing (I didn't dig through the mei bus in
detail at all, so not clear on what exactly is going on there).
Also pulling in device model and suspend/resume experts.
Thanks, Daniel
>
> -Ram
>
> On 12/13/2018 9:31 AM, Ramalingam C wrote:
>
> Mei hdcp driver is designed as component slave for the I915 component
> master.
>
> v2: Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
> v4:
> Made static dummy functions as inline in mei_hdcp.h
> API for polling client device status
> IS_ENABLED used in header, for config status for mei_hdcp.
> v5:
> Replacing the notifier with component framework. [Daniel]
> v6:
> Rebased on the I915 comp master redesign.
> v7:
> mei_hdcp_component_registered is made static [Uma]
> Need for global static variable mei_cldev is removed.
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Uma Shankar
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 67
> +---
> 1 file changed, 63 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index b22a71e8c5d7..3de1700dcc9f 100644
> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -23,11 +23,14 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> #include "mei_hdcp.h"
>
> +static bool mei_hdcp_component_registered;
> +
> /**
> * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME
> FW
> * @dev: device corresponding to the mei_cl_device
> @@ -691,8 +694,7 @@ mei_close_hdcp_session(struct device *dev, struct
> hdcp_port_data *data)
> return 0;
> }
>
> -static __attribute__((unused))
> -struct i915_hdcp_component_ops mei_hdcp_ops = {
> +static struct i915_hdcp_component_ops mei_hdcp_ops = {
> .owner = THIS_MODULE,
> .initiate_hdcp2_session = mei_initiate_hdcp2_session,
> .verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
> @@ -707,20 +709,77 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
> .close_hdcp_session = mei_close_hdcp_session,
> };
>
> +static int mei_hdcp_component_bind(struct device *mei_kdev,
> + struct device *i915_kdev, void *data)
> +{
> + struct i915_component_master *master_comp = data;
> +
> + dev_info(mei_kdev, "MEI HDCP comp bind\n");
> + WARN_ON(master_comp->hdcp_ops);
> + master_comp->hdcp_ops = &mei_hdcp_ops;
> + master_comp->mei_dev = mei_kdev;
> +
> + return 0;
> +}
> +
> +static void mei_hdcp_component_unbind(struct device *mei_kdev,
> + struct device *i915_kdev, void *data)
> +{
> + struct i915_component_master *master_comp = data;
> +
> + dev_info(mei_kdev, "MEI HDCP comp unbind\n");
> + master_comp->hdcp_ops = NULL;
> + master_comp->mei_dev = NULL;
> +}
> +
> +static const struct component_ops mei_hdcp_component_
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Series Details ==
Series: series starting with [v4,1/3] ACPI / PMIC: Add support for executing
PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/54003/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11089
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11089 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11089, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/54003/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11089:
### IGT changes ###
Possible regressions
* igt@pm_rpm@basic-rte:
- fi-byt-n2820: PASS -> FAIL
Warnings
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: PASS -> SKIP +36
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +33
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-n2820: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11089 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602] / [fdo#108529] +1
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: NOTRUN -> DMESG-WARN [fdo#108924] / [fdo#109044]
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362] +1
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@pm_rpm@module-reload:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108529]
* {igt@runner@aborted}:
- fi-icl-u3: NOTRUN -> FAIL [fdo#108924]
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-WARN [fdo#108473] -> DMESG-FAIL [fdo#105079]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044
Participating hosts (47 -> 45)
--
Additional (2): fi-icl-y fi-icl-u3
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5311 -> Patchwork_11089
CI_DRM_5311: a42fd8bf199784ee4ff1cdb5ee03eedd9a535d4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11089: 715d38e2ddb4a7ba0a6df7f0be439a510a6df035 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
715d38e2ddb4 drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
f8ff55af50c5 ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey
Cove PMIC
13a3d26bad7a ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11089/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
On Thu, Dec 13, 2018 at 12:24:57PM +, Koenig, Christian wrote:
> Am 13.12.18 um 13:21 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2018-12-13 12:11:10)
> >> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> >>> Quoting Chunming Zhou (2018-12-11 10:34:45)
> From: Christian König
>
> Implement finding the right timeline point in drm_syncobj_find_fence.
>
> v2: return -EINVAL when the point is not submitted yet.
> v3: fix reference counting bug, add flags handling as well
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_syncobj.c | 43 ---
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c
> b/drivers/gpu/drm/drm_syncobj.c
> index 76ce13dafc4d..d964b348ecba 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file
> *file_private,
> struct dma_fence **fence)
> {
> struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
> handle);
> - int ret = 0;
> + struct syncobj_wait_entry wait;
> + int ret;
>
> if (!syncobj)
> return -ENOENT;
>
> *fence = drm_syncobj_fence_get(syncobj);
> - if (!*fence) {
> + drm_syncobj_put(syncobj);
> +
> + if (*fence) {
> + ret = dma_fence_chain_find_seqno(fence, point);
> + if (!ret)
> + return 0;
> + dma_fence_put(*fence);
> + } else {
> ret = -EINVAL;
> }
> - drm_syncobj_put(syncobj);
> +
> + if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
> + return ret;
> +
> + memset(&wait, 0, sizeof(wait));
> + wait.task = current;
> + wait.point = point;
> + drm_syncobj_fence_add_wait(syncobj, &wait);
> +
> + do {
> + set_current_state(TASK_INTERRUPTIBLE);
> + if (wait.fence) {
> + ret = 0;
> + break;
> + }
> +
> + if (signal_pending(current)) {
> + ret = -ERESTARTSYS;
> + break;
> + }
> +
> + schedule();
> + } while (1);
> >>> I've previously used a dma_fence_proxy so that we could do nonblocking
> >>> waits on future submits. That would be preferrable (a requirement for
> >>> our stupid BKL-driven code).
> >> That is exactly what I would definitely NAK.
> >>
> >> I would rather say we should come up with a wait_multiple_events() macro
> >> and completely nuke the custom implementation of this in:
> >> 1. dma_fence_default_wait and dma_fence_wait_any_timeout
> >> 2. the radeon fence implementation
> >> 3. the nouveau fence implementation
> >> 4. the syncobj code
> >>
> >> Cause all of them do exactly the same. The dma_fence implementation
> >> unfortunately came up with a custom event handling mechanism instead of
> >> extending the core Linux wait_event() system.
> > I don't want a blocking wait at all.
>
> Ok I wasn't clear enough :) That is exactly what I would NAK!
>
> The wait must be blocking or otherwise you would allow wait-before-signal.
Well the current implementation is pulling a rather big trick on readers
in this regard: It looks like a dma_fence, it's implemented as one even,
heck you even open-code a dma_fence_wait here.
Except the semantics are completely different.
So aside from the discussion whether we really want to fully chain them I
think it just doesn't make sense to implement the "wait for fence submit"
as a dma_fence wait. And I'd outright remove that part from the uapi, and
force the wait. The current radv/anv plans I discussed with Jason was that
we'd have a separate submit thread, and hence unconditionally blocking
until the fence has materialized is the right thing to do. Even allowing
that option, either through a flag, or making these things look like
dma_fences (they are _not_) just tricks folks into misunderstanding what's
going on. Code sharing just because the code looks similar is imo a really
bad idea, when the semantics are entirely different (that was also the
reason behind not reusing all the cpu event stuff for dma_fence, they're
not normal cpu events).
-Daniel
>
> Christian.
>
> > -Chris
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts
Quoting Chris Wilson (2018-12-13 15:36:43) > Quoting Antonio Argenziano (2018-12-13 15:28:00) > > > > > > On 13/12/18 03:57, Chris Wilson wrote: > > > amdgpu has started to report out of space after creating a few contexts. > > > This is not the scope of this test as here we just verifying that fences > > > created in amd can be imported and used for synchronisation by i915 and > > > for that we just need at least one context created! > > > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=109049 > > > Signed-off-by: Chris Wilson > > > > LGTM. > > > > Reviwed-by: Antonio Argenziano > > > > > --- > > > tests/amdgpu/amd_prime.c | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu/amd_prime.c > > > index bda0ce83d..518c88963 100644 > > > --- a/tests/amdgpu/amd_prime.c > > > +++ b/tests/amdgpu/amd_prime.c > > > @@ -354,8 +354,8 @@ static void amd_to_i915(int i915, int amd, > > > amdgpu_device_handle device) > > > > doesn't i915_to_amd have the same issue? > > Only if you manage to run out of swap in 2s or used gen11. We don't like > to mention the feature improvements. Actually, in i915 we use asynchronous destruction of contexts and so immediately release the resources and can reallocate as required. But amdgpu uses synchronous context destruction and so we have to hold on to the context even though we only want to import the fence into i915. If we run out of contexts here with i915 (even on icl), it's a kernel bug. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts
On Thu, Dec 13, 2018 at 6:57 AM Chris Wilson wrote:
>
> amdgpu has started to report out of space after creating a few contexts.
> This is not the scope of this test as here we just verifying that fences
> created in amd can be imported and used for synchronisation by i915 and
> for that we just need at least one context created!
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109049
> Signed-off-by: Chris Wilson
Acked-by: Alex Deucher
> ---
> tests/amdgpu/amd_prime.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu/amd_prime.c
> index bda0ce83d..518c88963 100644
> --- a/tests/amdgpu/amd_prime.c
> +++ b/tests/amdgpu/amd_prime.c
> @@ -354,8 +354,8 @@ static void amd_to_i915(int i915, int amd,
> amdgpu_device_handle device)
> contexts = realloc(contexts, size *
> sizeof(*contexts));
> }
>
> - r = amdgpu_cs_ctx_create(device, &contexts[count]);
> - igt_assert_eq(r, 0);
> + if (amdgpu_cs_ctx_create(device, &contexts[count]))
> + break;
>
> r = amdgpu_cs_submit(contexts[count], 0, &ibs_request, 1);
> igt_assert_eq(r, 0);
> @@ -364,6 +364,7 @@ static void amd_to_i915(int i915, int amd,
> amdgpu_device_handle device)
> }
>
> igt_info("Reservation width = %ld\n", count);
> + igt_require(count);
>
> amdgpu_bo_export(ib_result_handle,
> amdgpu_bo_handle_type_dma_buf_fd,
> --
> 2.20.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts
Quoting Antonio Argenziano (2018-12-13 15:28:00) > > > On 13/12/18 03:57, Chris Wilson wrote: > > amdgpu has started to report out of space after creating a few contexts. > > This is not the scope of this test as here we just verifying that fences > > created in amd can be imported and used for synchronisation by i915 and > > for that we just need at least one context created! > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=109049 > > Signed-off-by: Chris Wilson > > LGTM. > > Reviwed-by: Antonio Argenziano > > > --- > > tests/amdgpu/amd_prime.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu/amd_prime.c > > index bda0ce83d..518c88963 100644 > > --- a/tests/amdgpu/amd_prime.c > > +++ b/tests/amdgpu/amd_prime.c > > @@ -354,8 +354,8 @@ static void amd_to_i915(int i915, int amd, > > amdgpu_device_handle device) > > doesn't i915_to_amd have the same issue? Only if you manage to run out of swap in 2s or used gen11. We don't like to mention the feature improvements. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
Add support for PMIC MIPI sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
This fixes the DSI LCD panel not lighting up when not initialized by the
GOP (because an external monitor was connected) on GPD win and GPD pocket
devices.
Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be
driven high, which is done through a PMIC MIPI sequence. Before this commit
if the sequence was not executed by the GOP the pin would stay low causing
the LCD panel to not work. Having the MIPI sequences properly control this
GPIO should also help save some power when the panel is off.
Changes in v2, v3:
-Only changes to other patches in this patch-set
Changes in v4:
-Move decoding of the raw 15 bytes PMIC MIPI sequence element into
i2c-address, register-address, value and mask into the mipi_exec_pmic()
function instead of passing the raw data to
intel_soc_pmic_exec_mipi_pmic_seq_element()
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index f27af47c6e49..ebe7e25614ce 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -29,9 +29,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include "i915_drv.h"
#include "intel_drv.h"
@@ -371,7 +373,25 @@ static const u8 *mipi_exec_spi(struct intel_dsi
*intel_dsi, const u8 *data)
static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
{
- DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+#ifdef CONFIG_PMIC_OPREGION
+ u32 value, mask, reg_address;
+ u16 i2c_address;
+ int ret;
+
+ /* byte 0 aka PMIC Flag is reserved */
+ i2c_address = get_unaligned_le16(data + 1);
+ reg_address = get_unaligned_le32(data + 3);
+ value = get_unaligned_le32(data + 7);
+ mask= get_unaligned_le32(data + 11);
+
+ ret = intel_soc_pmic_exec_mipi_pmic_seq_element(i2c_address,
+ reg_address,
+ value, mask);
+ if (ret)
+ DRM_ERROR("%s failed, error: %d\n", __func__, ret);
+#else
+ DRM_ERROR("Your hardware requires CONFIG_PMIC_OPREGION and it is not
set\n");
+#endif
return data + 15;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to have support for these PMIC specific MIPI
sequence elements somwhere. Since we already instantiate a special platform
device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
with PMIC specific implementations of the OpRegion, the handling of MIPI
sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
function, which is to be backed by a PMIC specific
exec_mipi_pmic_seq_element callback. This function will be called by the
i915 code to execture MIPI sequence PMIC elements.
Signed-off-by: Hans de Goede
---
Changes in v4:
-Pass i2c-address + register-address + value + mask as separate arguments to
the intel_soc_pmic_exec_mipi_pmic_seq_element function. Instead of passing
the 15 bytes of raw MIPI sequence data. The decoding will be done in the
i915 VBT code instead.
Changes in v3:
-Add kerneldoc for intel_soc_pmic_exec_mipi_pmic_seq_element
-Make intel_soc_pmic_exec_mipi_pmic_seq_element return errors
---
drivers/acpi/pmic/intel_pmic.c | 49 ++
drivers/acpi/pmic/intel_pmic.h | 2 ++
include/linux/mfd/intel_soc_pmic.h | 3 ++
3 files changed, 54 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index ca18e0d23df9..6bd25e96f41f 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include "intel_pmic.h"
@@ -36,6 +37,8 @@ struct intel_pmic_opregion {
struct intel_pmic_regs_handler_ctx ctx;
};
+static struct intel_pmic_opregion *intel_pmic_opregion;
+
static int pmic_get_reg_bit(int address, struct pmic_table *table,
int count, int *reg, int *bit)
{
@@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device *dev,
acpi_handle handle,
}
opregion->data = d;
+ intel_pmic_opregion = opregion;
return 0;
out_remove_thermal_handler:
@@ -319,3 +323,48 @@ int intel_pmic_install_opregion_handler(struct device
*dev, acpi_handle handle,
return ret;
}
EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
+
+/**
+ * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
+ * @i2c_address: I2C client address for the PMIC
+ * @reg_address: PMIC register address
+ * @value:New value for the register bits to change
+ * @mask: Mask indicating which register bits to change
+ *
+ * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
+ * BIOS Tables) using so called MIPI sequences. One possible element in these
+ * sequences is a PMIC specific element of 15 bytes.
+ *
+ * This function executes these PMIC specific elements sending the embedded
+ * commands to the PMIC.
+ *
+ * Return 0 on success, < 0 on failure.
+ */
+int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32 reg_address,
+ u32 value, u32 mask)
+{
+ struct intel_pmic_opregion_data *d;
+ int ret;
+
+ if (!intel_pmic_opregion) {
+ pr_warn("%s: No PMIC registered\n", __func__);
+ return -ENXIO;
+ }
+
+ d = intel_pmic_opregion->data;
+ if (!d->exec_mipi_pmic_seq_element) {
+ pr_warn("%s: Not implemented\n", __func__);
+ pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
0x%x\n",
+ __func__, i2c_address, reg_address, value, mask);
+ return -EOPNOTSUPP;
+ }
+
+ mutex_lock(&intel_pmic_opregion->lock);
+ ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap,
+ i2c_address, reg_address,
+ value, mask);
+ mutex_unlock(&intel_pmic_opregion->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 095afc96952e..5cd195fabca8 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -15,6 +15,8 @@ struct intel_pmic_opregion_data {
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
+ int (*exec_mipi_pmic_seq_element)(struct regmap *r, u16 i2c_address,
+ u32 reg_address, u32 value, u32 mask);
struct pmic_table *power_table;
int power_table_count;
struct pmic_table *thermal
[Intel-gfx] [PATCH v4 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Signed-off-by: Hans de Goede
---
Changes in v4:
-The decoding of the raw data of the PMIC MIPI sequence element is now done
in our caller, so drop this and adjust the callback prototype to accept
the decoded addresses, value and mask
Changes in v3:
-Use hex values for out of range checks
-Make intel_cht_wc_exec_mipi_pmic_seq_element return errors
Changes in v2:
-Interpret data passed to the PMIC MIPI elements according to the docs
instead of my own reverse engineered interpretation
---
drivers/acpi/pmic/intel_pmic_chtwc.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..c5037c5c5219 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "intel_pmic.h"
#define CHT_WC_V1P05A_CTRL 0x6e3b
@@ -231,6 +232,24 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
}
+static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ u16 i2c_client_address,
+ u32 reg_address,
+ u32 value, u32 mask)
+{
+ u32 address;
+
+ if (i2c_client_address > 0xff || reg_address > 0xff) {
+ pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+ __func__, i2c_client_address, reg_address);
+ return -ERANGE;
+ }
+
+ address = (i2c_client_address << 8) | reg_address;
+
+ return regmap_update_bits(regmap, address, mask, value);
+}
+
/*
* The thermal table and ops are empty, we do not support the Thermal opregion
* (DPTF) due to lacking documentation.
@@ -238,6 +257,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
.get_power = intel_cht_wc_pmic_get_power,
.update_power = intel_cht_wc_pmic_update_power,
+ .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
.power_table= power_table,
.power_table_count = ARRAY_SIZE(power_table),
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts
On 13/12/18 03:57, Chris Wilson wrote:
amdgpu has started to report out of space after creating a few contexts.
This is not the scope of this test as here we just verifying that fences
created in amd can be imported and used for synchronisation by i915 and
for that we just need at least one context created!
References: https://bugs.freedesktop.org/show_bug.cgi?id=109049
Signed-off-by: Chris Wilson
LGTM.
Reviwed-by: Antonio Argenziano
---
tests/amdgpu/amd_prime.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu/amd_prime.c
index bda0ce83d..518c88963 100644
--- a/tests/amdgpu/amd_prime.c
+++ b/tests/amdgpu/amd_prime.c
@@ -354,8 +354,8 @@ static void amd_to_i915(int i915, int amd,
amdgpu_device_handle device)
doesn't i915_to_amd have the same issue?
Antonio
contexts = realloc(contexts, size * sizeof(*contexts));
}
- r = amdgpu_cs_ctx_create(device, &contexts[count]);
- igt_assert_eq(r, 0);
+ if (amdgpu_cs_ctx_create(device, &contexts[count]))
+ break;
r = amdgpu_cs_submit(contexts[count], 0, &ibs_request, 1);
igt_assert_eq(r, 0);
@@ -364,6 +364,7 @@ static void amd_to_i915(int i915, int amd,
amdgpu_device_handle device)
}
igt_info("Reservation width = %ld\n", count);
+ igt_require(count);
amdgpu_bo_export(ib_result_handle,
amdgpu_bo_handle_type_dma_buf_fd,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Quoting Ville Syrjälä (2018-12-13 12:45:00)
> On Thu, Dec 13, 2018 at 12:34:02PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-12-13 12:29:15)
> > > On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> > > > Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > > > > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > > > > Having completed a test run of gem_eio across all machines in CI we
> > > > > > also
> > > > > > observe the phenomenon (of lost interrupts after resetting the GPU)
> > > > > > on
> > > > > > gen3 machines as well as the previously sighted gen6/gen7. Let's
> > > > > > apply
> > > > > > the same HWSTAM workaround that was effective for gen6+ for all, as
> > > > > > although we haven't seen the same failure on gen4/5 it seems
> > > > > > prudent to
> > > > > > keep the code the same.
> > > > > >
> > > > > > As a consequence we can remove the extra setting of HWSTAM and
> > > > > > apply the
> > > > > > register from a single site.
> > > > > >
> > > > > > v2: Delazy and move the HWSTAM into its own function
> > > > > >
> > > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> > > > > > Signed-off-by: Chris Wilson
> > > > > > Cc: Tvrtko Ursulin
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_irq.c | 9 --
> > > > > > drivers/gpu/drm/i915/intel_ringbuffer.c | 41
> > > > > > -
> > > > > > 2 files changed, 27 insertions(+), 23 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > index e2dac9b5f4ce..0c7fc9890891 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct
> > > > > > drm_device *dev)
> > > > > > {
> > > > > > struct drm_i915_private *dev_priv = to_i915(dev);
> > > > > >
> > > > > > - if (IS_GEN(dev_priv, 5))
> > > > > > - I915_WRITE(HWSTAM, 0x);
> > > > > > -
> > > > > > GEN3_IRQ_RESET(DE);
> > > > > > if (IS_GEN(dev_priv, 7))
> > > > > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > > > > @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device
> > > > > > *dev)
> > > > > >
> > > > > > i9xx_pipestat_irq_reset(dev_priv);
> > > > > >
> > > > > > - I915_WRITE16(HWSTAM, 0x);
> > > > > > -
> > > > > > GEN2_IRQ_RESET();
> > > > > > }
> > > > > >
> > > > > > @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device
> > > > > > *dev)
> > > > > >
> > > > > > i9xx_pipestat_irq_reset(dev_priv);
> > > > > >
> > > > > > - I915_WRITE(HWSTAM, 0x);
> > > > > > -
> > > > > > GEN3_IRQ_RESET();
> > > > > > }
> > > > > >
> > > > > > @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device
> > > > > > *dev)
> > > > > >
> > > > > > i9xx_pipestat_irq_reset(dev_priv);
> > > > > >
> > > > > > - I915_WRITE(HWSTAM, 0x);
> > > > > > -
> > > > > > GEN3_IRQ_RESET();
> > > > > > }
> > > > >
> > > > > So we're not worried about enabling interrupts and having
> > > > > something unmasked in HWSTAM by accident before we have the
> > > > > status page set up?
> > > >
> > > > Sanitization of the HWSP setup would be off during early engine setup.
> > > > We do the irq install & reset during i915_load_modeset_init after we do
> > > > the status page setup. Unless I'm mistaken, moving the HWSTAM alongside
> > > > HWSP moves the sanitisation earlier.
> > >
> > > To me it looks like the hwsp setup happens via i915_gem_init(), which
> > > gets called after irq install. But maybe I'm just hopelessly lost
> > > in the maze.
> >
> > i915_driver_init_hw -> i915_gem_init_hw -> init_ringbuffer...
>
> i915_gem_init_hw() doesn't seem to be called from there, unless I'm
> looking at a stale tree already. I did checkout ~4 hours ago so
> could very well be outdated already :)
Indeed not. So moved the sanitization to
i915_driver_init_mmio -> intel_engines_init_mmio
which is unarguably as early as we can do it :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/opregion: rvda is relative from opregion base, not absolute
== Series Details ==
Series: drm/i915/opregion: rvda is relative from opregion base, not absolute
URL : https://patchwork.freedesktop.org/series/53996/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11088
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11088 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11088, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53996/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11088:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-apl-guc: PASS -> DMESG-WARN
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: PASS -> FAIL
* {igt@runner@aborted}:
- fi-apl-guc: NOTRUN -> FAIL
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +33
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11088 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602] / [fdo#108529] +1
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: NOTRUN -> DMESG-WARN [fdo#108924] / [fdo#109044]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@module-reload:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108529]
* {igt@runner@aborted}:
- fi-icl-u3: NOTRUN -> FAIL [fdo#108924]
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-WARN [fdo#108473] -> DMESG-FAIL [fdo#105079]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044
Participating hosts (47 -> 44)
--
Additional (2): fi-icl-y fi-icl-u3
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-bxt-dsi fi-byt-squawks
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5311 -> Patchwork_11088
CI_DRM_5311: a42fd8bf199784ee4ff1cdb5ee03eedd9a535d4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11088: 715b0f2a84bf94eedb0f5b73ca71f56b5d75b92a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
715b0f2a84bf drm/i915/opregion: rvda is relative from opregion base, not
absolute
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11088/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/psr: Disable DRRS if enabled when enabling PSR from debugfs
On Wed, 2018-12-12 at 17:11 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-12-12 at 05:02 -0800, Souza, Jose wrote:
> > On Tue, 2018-12-11 at 14:02 -0800, Dhinakaran Pandiyan wrote:
> > > On Mon, 2018-11-12 at 11:17 +0100, Maarten Lankhorst wrote:
> > > > Op 09-11-18 om 21:20 schreef José Roberto de Souza:
> > > > > If panel supports DRRS and PSR and if driver is loaded
> > > > > without
> > > > > PSR
> > > > > enabled, driver will enable DRRS as expected but if PSR is
> > > > > enabled
> > > > > by
> > > > > debugfs latter it will keep PSR and DRRS enabled causing
> > > > > possible
> > > > > problems as DRRS will lower the refresh rate while PSR
> > > > > enabled.
> > > > >
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341
> > > > > Cc: Maarten Lankhorst
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Signed-off-by: José Roberto de Souza
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_psr.c | 5 -
> > > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > > index 853e3f1370a0..bfc6a08b5cf4 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > > @@ -904,8 +904,11 @@ int intel_psr_set_debugfs_mode(struct
> > > > > drm_i915_private *dev_priv,
> > > > >
> > > > > intel_psr_irq_control(dev_priv, dev_priv->psr.debug);
> > > > >
> > > > > - if (dev_priv->psr.prepared && enable)
> > > > > + if (dev_priv->psr.prepared && enable) {
> > > > > + if (crtc_state)
> > > > > + intel_edp_drrs_disable(dp, crtc_state);
> > > > > intel_psr_enable_locked(dev_priv, crtc_state);
> > > > > + }
> > > > >
> > > > > mutex_unlock(&dev_priv->psr.lock);
> > > > > return ret;
> > > >
> > > > I've considered this, but I thought it was a feature, not a
> > > > bug.
> > > > It's
> > > > a pain to track
> > > > how we handle this as intended.
> > > >
> > > > kms_frontbuffer_tracking is also controlling DRRS during the
> > > > test,
> > > > so
> > > > perhaps simply
> > > > fix the test?
> > > >
> > > > It seems the no_drrs test simply checks that if PSR is enabled,
> > > > we
> > > > don't have drrs
> > > > enabled. We probably care about the default configuration, so I
> > > > would
> > > > simply disable
> > > > the pipe, update the PSR flag, and then start running the
> > > > tests.
> > > > Else
> > > > the only thing
> > > > we test is that debugfs disables DRRS. Not that the default
> > > > modeset
> > > > path prevents
> > > > PSR and DRRS simultaneously.
> > > >
> > > > ~Maarten
> > > >
> > > > Maybe something like below?
> > > >
> > > > Perhaps move the drrs manipulation functions from
> > > > kms_frontbuffer_tracking to lib/kms_psr.c
> > > >
> > > > 8<---
> > > > diff --git a/tests/kms_psr.c b/tests/kms_psr.c
> > > > index 9767f475bf23..ffc356df06ce 100644
> > > > --- a/tests/kms_psr.c
> > > > +++ b/tests/kms_psr.c
> > > > @@ -414,9 +414,6 @@ int main(int argc, char *argv[])
> > > > kmstest_set_vt_graphics_mode();
> > > > data.devid = intel_get_drm_devid(data.drm_fd);
> > > >
> > > > - if (!data.with_psr_disabled)
> > > > - psr_enable(data.debugfs_fd);
> > > > -
> > > > igt_require_f(sink_support(&data),
> > > > "Sink does not support PSR\n");
> > > >
> > > > @@ -428,18 +425,25 @@ int main(int argc, char *argv[])
> > > > }
> > > >
> > > > igt_subtest("basic") {
> > > > - setup_test_plane(&data,
> > > > DRM_PLANE_TYPE_PRIMARY);
> > > > - igt_assert(psr_wait_entry_if_enabled(&data));
> > > > - test_cleanup(&data);
> > > > - }
> > > > + /* Disable display to get a default setup. */
> > > > + igt_display_commit2(&data.display,
> > > > data.display.is_atomic ? COMMIT_ATOMIC : COMMIT_LEGACY);
> > > > +
> > > > + if (!data.with_psr_disabled)
> > > > + psr_enable(data.debugfs_fd);
> > > >
> > > > - igt_subtest("no_drrs") {
> > > > setup_test_plane(&data,
> > > > DRM_PLANE_TYPE_PRIMARY);
> > > > igt_assert(psr_wait_entry_if_enabled(&data));
> > > > igt_assert(drrs_disabled(&data));
> > > > test_cleanup(&data);
> > >
> > > This makes a lot more sense to me, ensuring that DRRS does not
> > > get
> > > enabled in the default code path was the goal of the no-drrs
> > > test.
> >
> > The problem with this approach is if user wants to run just one
> > test
> > the basic test will not run and DRRS will be kept on, it will not
> > fail
> > the no_drrs test but DRRS could interfere with other PSR tests.
> Disable DRRS for the other sub-tests, doesn't this work?
> echo 0 > /sys/kernel/debug/dri/0/i915_drrs_ctl
It would work
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev6)
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
(rev6)
URL : https://patchwork.freedesktop.org/series/53979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11087
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11087 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11087, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53979/revisions/6/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11087:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11087 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602] / [fdo#108529] +1
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: NOTRUN -> DMESG-WARN [fdo#108924] / [fdo#109044]
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@pm_rpm@module-reload:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108529]
* {igt@runner@aborted}:
- fi-icl-u3: NOTRUN -> FAIL [fdo#108924]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-WARN [fdo#108473] -> DMESG-FAIL [fdo#105079]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044
Participating hosts (47 -> 44)
--
Additional (1): fi-icl-u3
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5311 -> Patchwork_11087
CI_DRM_5311: a42fd8bf199784ee4ff1cdb5ee03eedd9a535d4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11087: 3d73335eb4f6f635113e7c49cb70e7a9888972b8 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3d73335eb4f6 drm/i915: Apply missed interrupt after reset w/a to all ringbuffer
gen
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11087/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Hi,
On 13-12-18 14:08, Ville Syrjälä wrote:
On Thu, Dec 13, 2018 at 01:40:27PM +0100, Hans de Goede wrote:
Hi,
On 13-12-18 13:14, Ville Syrjälä wrote:
+static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ const u8 *data)
+{
+ u32 value, mask, reg_address, address;
+ u16 i2c_client_address;
+
+ /* byte 0 aka PMIC Flag is reserved */
+ i2c_client_address = get_unaligned_le16(data + 1);
+ reg_address = get_unaligned_le32(data + 3);
+ value = get_unaligned_le32(data + 7);
+ mask= get_unaligned_le32(data + 11);
Upon further reflection maybe it would better to do this decoding in
the i915 code and just pass each parameter to this hook separately?
That way we wouldn't be spreading the vbt details all over the place.
Interesting point, if the VBT spec says that this encoding is PMIC
independent, then yes we should probably fo the decoding in the VBT
code and change the intel_soc_pmic_exec_mipi_pmic_seq_element
prototype to:
int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32 reg_address,
u32 value, u32 mask);
If you agree please let me know and I will do a v4 of the patchset.
Yeah, I think that's probably better. The spec has just the one
interpretation for the sequence.
Ok, v4. coming up.
Oh, and we should probably change the DRM_DEBUG_KMS() for the
PMIC_OPREGION=n case to a DRM_ERROR() which tells people to
enable PMIC_OPREGION=y.
Will do.
Regards,
Hans
p.s.
Have you also seen these 2 DSI related series (I've not see any feedback
on these 2 series yet) ? :
https://patchwork.kernel.org/patch/10707629/ (patch 1/4)
https://patchwork.kernel.org/patch/10707647/ (patch 1/4)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Series Details == Series: series starting with [v3,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements URL : https://patchwork.freedesktop.org/series/53986/ State : success == Summary == CI Bug Log - changes from CI_DRM_5311_full -> Patchwork_11085_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_11085_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11085_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_11085_full: ### IGT changes ### Warnings * igt@pm_rc6_residency@rc6-accuracy: - shard-kbl: SKIP -> PASS - shard-snb: SKIP -> PASS Known issues Here are the changes found in Patchwork_11085_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-apl: NOTRUN -> FAIL [fdo#103158] * igt@gem_exec_schedule@pi-ringfull-render: - shard-skl: NOTRUN -> FAIL [fdo#103158] - shard-iclb: NOTRUN -> FAIL [fdo#103158] * igt@gem_userptr_blits@readonly-unsync: - shard-skl: NOTRUN -> TIMEOUT [fdo#108887] * igt@i915_selftest@live_workarounds: - shard-iclb: PASS -> DMESG-FAIL [fdo#108954] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-iclb: PASS -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_ccs@pipe-a-crc-primary-rotation-180: - shard-iclb: NOTRUN -> FAIL [fdo#107725] +2 * igt@kms_color@pipe-a-ctm-blue-to-red: - shard-skl: PASS -> FAIL [fdo#107201] * igt@kms_color@pipe-b-ctm-0-75: - shard-apl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +4 * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-sliding: - shard-iclb: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-random: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_draw_crc@draw-method-xrgb-blt-ytiled: - shard-skl: PASS -> FAIL [fdo#107589] * igt@kms_draw_crc@fill-fb: - shard-skl: PASS -> FAIL [fdo#103184] * igt@kms_flip@2x-busy-flip: - shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: - shard-skl: PASS -> FAIL [fdo#103167] +2 * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-apl: PASS -> DMESG-FAIL [fdo#103167] / [fdo#103558] / [fdo#105602] * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-skl: PASS -> FAIL [fdo#105682] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-iclb: NOTRUN -> FAIL [fdo#108948] +1 * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-apl: PASS -> FAIL [fdo#103166] +1 - shard-glk: PASS -> FAIL [fdo#103166] +1 * igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb: - shard-skl: NOTRUN -> FAIL [fdo#108145] +3 * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-iclb: PASS -> FAIL [fdo#103166] * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: - shard-iclb: PASS -> DMESG-WARN [fdo#107724] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> DMESG-FAIL [fdo#108950] * igt@kms_setmode@basic: - shard-apl: PASS -> FAIL [fdo#99912] * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend: - shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@pm_rpm@cursor-dpms: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@pm_rpm@debugfs-read: - shard-iclb: PASS -> INCOMPLETE [fdo#108840] Possible fixes * igt@gem_userptr_blits@readonly-unsync: - shard-iclb: TIMEOUT -> PASS * igt@gem_workarounds@suspend-resume-context: - shard-skl: INCOMPLETE [fdo#10
Re: [Intel-gfx] [PATCH v3 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
HI,
On 13-12-18 14:45, Jani Nikula wrote:
On Thu, 13 Dec 2018, Hans de Goede wrote:
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to have support for these PMIC specific MIPI
sequence elements somwhere. Since we already instantiate a special platform
device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
with PMIC specific implementations of the OpRegion, the handling of MIPI
sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
function, which is to be backed by a PMIC specific
exec_mipi_pmic_seq_element callback. This function will be called by the
i915 code to execture MIPI sequence PMIC elements.
Signed-off-by: Hans de Goede
---
Changes in v3:
-Add kerneldoc for intel_soc_pmic_exec_mipi_pmic_seq_element
-Make intel_soc_pmic_exec_mipi_pmic_seq_element return errors
---
drivers/acpi/pmic/intel_pmic.c | 42 ++
drivers/acpi/pmic/intel_pmic.h | 1 +
include/linux/mfd/intel_soc_pmic.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
index ca18e0d23df9..61f99735fd41 100644
--- a/drivers/acpi/pmic/intel_pmic.c
+++ b/drivers/acpi/pmic/intel_pmic.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include "intel_pmic.h"
@@ -36,6 +37,8 @@ struct intel_pmic_opregion {
struct intel_pmic_regs_handler_ctx ctx;
};
+static struct intel_pmic_opregion *intel_pmic_opregion;
+
static int pmic_get_reg_bit(int address, struct pmic_table *table,
int count, int *reg, int *bit)
{
@@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device *dev,
acpi_handle handle,
}
opregion->data = d;
+ intel_pmic_opregion = opregion;
return 0;
out_remove_thermal_handler:
@@ -319,3 +323,41 @@ int intel_pmic_install_opregion_handler(struct device
*dev, acpi_handle handle,
return ret;
}
EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
+
+/**
+ * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
+ * @data: Pointer to *15* byte PMIC MIPI sequence element
+ *
+ * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
+ * BIOS Tables) using so called MIPI sequences. One possible element in these
+ * sequences is a PMIC specific element of 15 bytes.
+ *
+ * This function executes these PMIC specific elements sending the embedded
+ * commands to the PMIC.
+ *
+ * Return 0 on success, < 0 on failure.
+ */
+int intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data)
+{
+ struct intel_pmic_opregion_data *d;
+ int ret;
+
+ if (!intel_pmic_opregion) {
+ pr_warn("%s: No PMIC registered\n", __func__);
+ return -ENXIO;
+ }
+
+ d = intel_pmic_opregion->data;
+ if (!d->exec_mipi_pmic_seq_element) {
+ pr_warn("%s: Not implemented\n", __func__);
+ pr_warn("%s: Data: %15ph\n", __func__, data);
+ return -EOPNOTSUPP;
+ }
+
+ mutex_lock(&intel_pmic_opregion->lock);
+ ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap, data);
+ mutex_unlock(&intel_pmic_opregion->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
index 095afc96952e..1cc5e69af0c3 100644
--- a/drivers/acpi/pmic/intel_pmic.h
+++ b/drivers/acpi/pmic/intel_pmic.h
@@ -15,6 +15,7 @@ struct intel_pmic_opregion_data {
int (*update_aux)(struct regmap *r, int reg, int raw_temp);
int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
+ int (*exec_mipi_pmic_seq_element)(struct regmap *r, const u8 *data);
struct pmic_table *power_table;
int power_table_count;
struct pmic_table *thermal_table;
diff --git a/include/linux/mfd/intel_soc_pmic.h
b/include/linux/mfd/intel_soc_pmic.h
index ed1dfba5e5f9..71a8607a0a8c 100644
--- a/include/linux/mfd/intel_soc_pmic.h
+++ b/include/linux/mfd/intel_soc_pmic.h
@@ -26,4 +26,6 @@ struct intel_soc_pmic {
struct device *dev;
};
+int intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data);
Add a static inline dummy implementation with error return for
CONFIG_PMIC_OPREGION=n? Maybe even with pr_err or pr_warn or something?
There is only one caller and Ville has requested for the caller to
do a DRM_ERROR("Your hardware requires CONFIG_PMIC_OPREGION and it is not set")
if we hit that code-path and CONFIG_PMIC_OPREGION is not se
Re: [Intel-gfx] [PATCH] drm/i915/opregion: rvda is relative from opregion base, not absolute
On Thu, 13 Dec 2018, Jani Nikula wrote:
> We've supported the opregion RVDA/RVDS fields for VBT size >= 6 KB since
> commit 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6
> KB"). That's three years, almost to the date.
>
> The implementation was based on spec only, in anticipation of systems
> with big VBT. Now, the spec has been changed. The RVDA is supposed to be
> relative from the beginning of opregion, not absolute address.
>
> This is obviously a backward/forward incompatible change. I've been told
> there are no systems out there using the field. Fingers crossed. This
> will still be problematic for older kernels, and we can only try to
> backport the fix.
Should add this to the commit message:
While at it, add the missing memunmap() on the failure path for
completeness.
>
> Fixes: 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6 KB")
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index b8f106d9ecf8..700fddaa8d9e 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -119,7 +119,7 @@ struct opregion_asle {
> u64 fdss;
> u32 fdsp;
> u32 stat;
> - u64 rvda; /* Physical address of raw vbt data */
> + u64 rvda; /* Address of raw vbt data, relative from opregion */
> u32 rvds; /* Size of raw vbt data */
> u8 rsvd[58];
> } __packed;
> @@ -955,7 +955,13 @@ int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
>
> if (opregion->header->opregion_ver >= 2 && opregion->asle &&
> opregion->asle->rvda && opregion->asle->rvds) {
> - opregion->rvda = memremap(opregion->asle->rvda,
> + /*
> + * rvda is unsigned, relative from opregion base, and should
> + * never point within opregion.
> + */
> + WARN_ON(opregion->asle->rvda < OPREGION_SIZE);
> +
> + opregion->rvda = memremap(asls + opregion->asle->rvda,
> opregion->asle->rvds,
> MEMREMAP_WB);
> vbt = opregion->rvda;
> @@ -967,6 +973,8 @@ int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> goto out;
> } else {
> DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (RVDA)\n");
> + memunmap(opregion->rvda);
> + opregion->rvda = NULL;
> }
> }
--
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 3/3] drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
On Thu, 13 Dec 2018, Hans de Goede wrote:
> Add support for PMIC MIPI sequences using the new
> intel_soc_pmic_exec_mipi_pmic_seq_element function.
>
> This fixes the DSI LCD panel not lighting up when not initialized by the
> GOP (because an external monitor was connected) on GPD win and GPD pocket
> devices.
>
> Specifically the LCD panel seems to need GPIO pin 9 on the PMIC to be
> driven high, which is done through a PMIC MIPI sequence. Before this commit
> if the sequence was not executed by the GOP the pin would stay low causing
> the LCD panel to not work. Having the MIPI sequences properly control this
> GPIO should also help save some power when the panel is off.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index f27af47c6e49..6a2ed1ca72e0 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -371,7 +372,11 @@ static const u8 *mipi_exec_spi(struct intel_dsi
> *intel_dsi, const u8 *data)
>
> static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
> {
> +#ifdef CONFIG_PMIC_OPREGION
> + intel_soc_pmic_exec_mipi_pmic_seq_element(data);
> +#else
> DRM_DEBUG_KMS("Skipping PMIC element execution\n");
> +#endif
Please check the return value, and log with DRM_DEBUG_KMS or
DRM_ERROR. With the dummy implementation of
intel_soc_pmic_exec_mipi_pmic_seq_element() returning e.g. -ENODEV this
would also cover the CONFIG_PMIC_OPREGION=n case.
BR,
Jani.
>
> return data + 15;
> }
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/opregion: rvda is relative from opregion base, not absolute
We've supported the opregion RVDA/RVDS fields for VBT size >= 6 KB since
commit 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6
KB"). That's three years, almost to the date.
The implementation was based on spec only, in anticipation of systems
with big VBT. Now, the spec has been changed. The RVDA is supposed to be
relative from the beginning of opregion, not absolute address.
This is obviously a backward/forward incompatible change. I've been told
there are no systems out there using the field. Fingers crossed. This
will still be problematic for older kernels, and we can only try to
backport the fix.
Fixes: 04ebaadb9f2d ("drm/i915/opregion: handle VBT sizes bigger than 6 KB")
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_opregion.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index b8f106d9ecf8..700fddaa8d9e 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -119,7 +119,7 @@ struct opregion_asle {
u64 fdss;
u32 fdsp;
u32 stat;
- u64 rvda; /* Physical address of raw vbt data */
+ u64 rvda; /* Address of raw vbt data, relative from opregion */
u32 rvds; /* Size of raw vbt data */
u8 rsvd[58];
} __packed;
@@ -955,7 +955,13 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (opregion->header->opregion_ver >= 2 && opregion->asle &&
opregion->asle->rvda && opregion->asle->rvds) {
- opregion->rvda = memremap(opregion->asle->rvda,
+ /*
+* rvda is unsigned, relative from opregion base, and should
+* never point within opregion.
+*/
+ WARN_ON(opregion->asle->rvda < OPREGION_SIZE);
+
+ opregion->rvda = memremap(asls + opregion->asle->rvda,
opregion->asle->rvds,
MEMREMAP_WB);
vbt = opregion->rvda;
@@ -967,6 +973,8 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
goto out;
} else {
DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (RVDA)\n");
+ memunmap(opregion->rvda);
+ opregion->rvda = NULL;
}
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915/icl: Define MOCS table for Icelake
Quoting Tvrtko Ursulin (2018-12-10 17:17:29)
>
> On 07/11/2018 15:16, Tomasz Lis wrote:
> > The table has been unified across OSes to minimize virtualization overhead.
> >
> > The MOCS table is now published as part of bspec, and versioned. Entries
> > are supposed to never be modified, but new ones can be added. Adding
> > entries increases table version. The patch includes version 1 entries.
> >
> > Meaning of each entry is now explained in bspec, and user mode clients
> > are expected to know what each entry means. The 3 entries used for previous
> > platforms are still compatible with their legacy definitions, but that is
> > not guaranteed to be true for future platforms.
> >
> > v2: Fixed SCC values, improved commit comment (Daniele)
> > v3: Improved MOCS table comment (Daniele)
> > v4: Moved new entries below gen9 ones. Put common entries into
> > definition to be used in multiple arrays. (Lucas)
> > v5: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
> > to MOCS_ENTRIES. Switched LE_CoS to upper case. (Joonas)
> > v6: Removed definitions of reserved entries. (Michal)
> > Increased limit of entries sent to the hardware on gen11+.
> >
> > BSpec: 34007
> > BSpec: 560
> > Signed-off-by: Tomasz Lis
> > Reviewed-by: Daniele Ceraolo Spurio (v4)
>
> R-b upgrade needed here as well.
>
> > Cc: Joonas Lahtinen
> > Cc: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Daniele Ceraolo Spurio
> > Cc: Zhenyu Wang
> > Cc: Zhi A Wang
> > Cc: Anuj Phogat
> > Cc: Adam Cetnerowski
> > Cc: Piotr Rozenfeld
> > Cc: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/intel_mocs.c | 222
> > +-
> > 1 file changed, 197 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> > b/drivers/gpu/drm/i915/intel_mocs.c
> > index 8d08a7b..4eb05c6 100644
> > --- a/drivers/gpu/drm/i915/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/intel_mocs.c
> > @@ -44,6 +44,8 @@ struct drm_i915_mocs_table {
> > #define LE_SCC(value) ((value) << 8)
> > #define LE_PFM(value) ((value) << 11)
> > #define LE_SCF(value) ((value) << 14)
> > +#define LE_COS(value)((value) << 15)
> > +#define LE_SSE(value)((value) << 17)
> >
> > /* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word
> > */
> > #define L3_ESC(value) ((value) << 0)
> > @@ -52,6 +54,10 @@ struct drm_i915_mocs_table {
> >
> > /* Helper defines */
> > #define GEN9_NUM_MOCS_ENTRIES 62 /* 62 out of 64 - 63 & 64 are
> > reserved. */
> > +#define GEN11_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but
> > configured. */
> > +
> > +#define NUM_MOCS_ENTRIES(i915) \
> > + (INTEL_GEN(i915) < 11 ? GEN9_NUM_MOCS_ENTRIES :
> > GEN11_NUM_MOCS_ENTRIES)
>
> I have a suggestion to make this a bit more elegant by avoiding a
> sprinkle of conditionals throughout the code - since I count ten
> non-debug call sites of this macros.
>
> Since the MOCS code seems nicely driven from struct drm_i915_mocs_table,
> the suggestion is to store both the used and maximum valid number of
> entries per platform in that structure.
>
> It's all nicely consolidated in get_mocs_settings, where all the sanity
> checks could be moved as well. Other bits of the code would then just
> trust the table.
>
> >
> > /* (e)LLC caching options */
> > #define LE_PAGETABLE0
> > @@ -80,21 +86,21 @@ struct drm_i915_mocs_table {
> >* LNCFCMOCS0 - LNCFCMOCS32 registers.
> >*
> >* These tables are intended to be kept reasonably consistent across
> > - * platforms. However some of the fields are not applicable to all of
> > - * them.
> > + * HW platforms, and for ICL+, be identical across OSes. To achieve
> > + * that, for Icelake and above, list of entries is published as part
> > + * of bspec.
> >*
> >* Entries not part of the following tables are undefined as far as
> > - * userspace is concerned and shouldn't be relied upon. For the time
> > - * being they will be implicitly initialized to the strictest caching
> > - * configuration (uncached) to guarantee forwards compatibility with
> > - * userspace programs written against more recent kernels providing
> > - * additional MOCS entries.
> > + * userspace is concerned and shouldn't be relied upon.
> > + *
> > + * The last two entries are reserved by the hardware. For ICL+ they
> > + * should be initialized according to bspec and never used, for older
> > + * platforms they should never be written to.
> >*
> > - * NOTE: These tables MUST start with being uncached and the length
> > - * MUST be less than 63 as the last two registers are reserved
> > - * by the hardware. These tables are part of the kernel ABI and
> > - * may only be updated incrementally by adding entries at the
> > - * end.
> > + * NOTE: These tables are part of bspec and defined as part of hardwa
Re: [Intel-gfx] [PATCH v3 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Thu, 13 Dec 2018, Ville Syrjälä wrote:
> On Thu, Dec 13, 2018 at 01:40:27PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 13-12-18 13:14, Ville Syrjälä wrote:
>> > On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
>> >> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
>> >> PMIC.
>> >>
>> >> On some CHT devices this fixes the LCD panel not lighting up when it was
>> >> not initialized by the GOP, because an external monitor was plugged in and
>> >> the GOP initialized only the external monitor.
>> >>
>> >> Signed-off-by: Hans de Goede
>> >> ---
>> >> Changes in v2:
>> >> -Interpret data passed to the PMIC MIPI elements according to the docs
>> >> instead of my own reverse engineered interpretation
>> >> Changes in v3:
>> >> -Use hex values for out of range checks
>> >> -Make intel_cht_wc_exec_mipi_pmic_seq_element return errors
>> >> ---
>> >> drivers/acpi/pmic/intel_pmic_chtwc.c | 25 +
>> >> 1 file changed, 25 insertions(+)
>> >>
>> >> diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
>> >> b/drivers/acpi/pmic/intel_pmic_chtwc.c
>> >> index 078b0448f30a..8ede74e9b89f 100644
>> >> --- a/drivers/acpi/pmic/intel_pmic_chtwc.c
>> >> +++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
>> >> @@ -12,6 +12,7 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >> #include "intel_pmic.h"
>> >>
>> >> #define CHT_WC_V1P05A_CTRL 0x6e3b
>> >> @@ -231,6 +232,29 @@ static int intel_cht_wc_pmic_update_power(struct
>> >> regmap *regmap, int reg,
>> >> return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
>> >> }
>> >>
>> >> +static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
>> >> +const u8 *data)
>> >> +{
>> >> + u32 value, mask, reg_address, address;
>> >> + u16 i2c_client_address;
>> >> +
>> >> + /* byte 0 aka PMIC Flag is reserved */
>> >> + i2c_client_address = get_unaligned_le16(data + 1);
>> >> + reg_address = get_unaligned_le32(data + 3);
>> >> + value = get_unaligned_le32(data + 7);
>> >> + mask= get_unaligned_le32(data + 11);
>> >
>> > Upon further reflection maybe it would better to do this decoding in
>> > the i915 code and just pass each parameter to this hook separately?
>> > That way we wouldn't be spreading the vbt details all over the place.
>>
>> Interesting point, if the VBT spec says that this encoding is PMIC
>> independent, then yes we should probably fo the decoding in the VBT
>> code and change the intel_soc_pmic_exec_mipi_pmic_seq_element
>> prototype to:
>>
>> int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32
>> reg_address,
>>u32 value, u32 mask);
>>
>> If you agree please let me know and I will do a v4 of the patchset.
>
> Yeah, I think that's probably better. The spec has just the one
> interpretation for the sequence.
Agreed.
BR,
Jani.
>
>>
>> I've also been thinking about trying to make the implementation
>> under drivers/acpi/pmic pmic independent, but not all pmic
>> drivers use the regmap the same way. The CHT Whiskey Cove PMIC
>> mfd driver uses a regmap with 16 bit addresses where the upper
>> byte is the i2c client address and the lower byte is the register
>> address (this PMIC listens on multiple addresses, with different
>> registers behind each i2c address).
>>
>> Where as most PMIC mfd drivers simply use the standard
>> devm_regmap_init_i2c() method of creating a regmap. For these
>> others we could do a standard implementation where we check the
>> passed in i2c_address is what we expect (for that type PMIC) and
>> then pass the other 3 parameters to regmap_update_bits.
>>
>> But I think it would be best to wait with such a generic implementation
>> until we encounter a device using the PMIC MIPI sequence element
>> with another type of PMIC. Since we still need the special
>> implementation for the CHT WC case, we still need an operation
>> pointer for this in intel_pmic_opregion_data anyways, so we can
>> easily plug in the generic implementation for others later.
>
> Yeah, probably not worth worrying about this until we
> encounter a machine that needs it.
>
> Oh, and we should probably change the DRM_DEBUG_KMS() for the
> PMIC_OPREGION=n case to a DRM_ERROR() which tells people to
> enable PMIC_OPREGION=y. Not sure why all these random knobs are
> even user configurable. No one can really be expected to know
> how to configure them properly. There was a recent problem with
> someone having set I2C_DESIGNWARE_BAYTRAIL=n as well because
> they had a CHT/BSW instead of a BYT :(
--
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 1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
On Thu, 13 Dec 2018, Hans de Goede wrote:
> DSI LCD panels describe an initialization sequence in the Video BIOS
> Tables using so called MIPI sequences. One possible element in these
> sequences is a PMIC specific element of 15 bytes.
>
> Although this is not really an ACPI opregion, the ACPI opregion code is the
> closest thing we have. We need to have support for these PMIC specific MIPI
> sequence elements somwhere. Since we already instantiate a special platform
> device for Intel PMICs for the ACPI PMIC OpRegion handler to bind to,
> with PMIC specific implementations of the OpRegion, the handling of MIPI
> sequence PMIC elements fits very well in the ACPI PMIC OpRegion code.
>
> This commit adds a new intel_soc_pmic_exec_mipi_pmic_seq_element()
> function, which is to be backed by a PMIC specific
> exec_mipi_pmic_seq_element callback. This function will be called by the
> i915 code to execture MIPI sequence PMIC elements.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> -Add kerneldoc for intel_soc_pmic_exec_mipi_pmic_seq_element
> -Make intel_soc_pmic_exec_mipi_pmic_seq_element return errors
> ---
> drivers/acpi/pmic/intel_pmic.c | 42 ++
> drivers/acpi/pmic/intel_pmic.h | 1 +
> include/linux/mfd/intel_soc_pmic.h | 2 ++
> 3 files changed, 45 insertions(+)
>
> diff --git a/drivers/acpi/pmic/intel_pmic.c b/drivers/acpi/pmic/intel_pmic.c
> index ca18e0d23df9..61f99735fd41 100644
> --- a/drivers/acpi/pmic/intel_pmic.c
> +++ b/drivers/acpi/pmic/intel_pmic.c
> @@ -15,6 +15,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include "intel_pmic.h"
> @@ -36,6 +37,8 @@ struct intel_pmic_opregion {
> struct intel_pmic_regs_handler_ctx ctx;
> };
>
> +static struct intel_pmic_opregion *intel_pmic_opregion;
> +
> static int pmic_get_reg_bit(int address, struct pmic_table *table,
> int count, int *reg, int *bit)
> {
> @@ -304,6 +307,7 @@ int intel_pmic_install_opregion_handler(struct device
> *dev, acpi_handle handle,
> }
>
> opregion->data = d;
> + intel_pmic_opregion = opregion;
> return 0;
>
> out_remove_thermal_handler:
> @@ -319,3 +323,41 @@ int intel_pmic_install_opregion_handler(struct device
> *dev, acpi_handle handle,
> return ret;
> }
> EXPORT_SYMBOL_GPL(intel_pmic_install_opregion_handler);
> +
> +/**
> + * intel_soc_pmic_exec_mipi_pmic_seq_element - Execute PMIC MIPI sequence
> + * @data: Pointer to *15* byte PMIC MIPI sequence element
> + *
> + * DSI LCD panels describe an initialization sequence in the i915 VBT (Video
> + * BIOS Tables) using so called MIPI sequences. One possible element in these
> + * sequences is a PMIC specific element of 15 bytes.
> + *
> + * This function executes these PMIC specific elements sending the embedded
> + * commands to the PMIC.
> + *
> + * Return 0 on success, < 0 on failure.
> + */
> +int intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data)
> +{
> + struct intel_pmic_opregion_data *d;
> + int ret;
> +
> + if (!intel_pmic_opregion) {
> + pr_warn("%s: No PMIC registered\n", __func__);
> + return -ENXIO;
> + }
> +
> + d = intel_pmic_opregion->data;
> + if (!d->exec_mipi_pmic_seq_element) {
> + pr_warn("%s: Not implemented\n", __func__);
> + pr_warn("%s: Data: %15ph\n", __func__, data);
> + return -EOPNOTSUPP;
> + }
> +
> + mutex_lock(&intel_pmic_opregion->lock);
> + ret = d->exec_mipi_pmic_seq_element(intel_pmic_opregion->regmap, data);
> + mutex_unlock(&intel_pmic_opregion->lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(intel_soc_pmic_exec_mipi_pmic_seq_element);
> diff --git a/drivers/acpi/pmic/intel_pmic.h b/drivers/acpi/pmic/intel_pmic.h
> index 095afc96952e..1cc5e69af0c3 100644
> --- a/drivers/acpi/pmic/intel_pmic.h
> +++ b/drivers/acpi/pmic/intel_pmic.h
> @@ -15,6 +15,7 @@ struct intel_pmic_opregion_data {
> int (*update_aux)(struct regmap *r, int reg, int raw_temp);
> int (*get_policy)(struct regmap *r, int reg, int bit, u64 *value);
> int (*update_policy)(struct regmap *r, int reg, int bit, int enable);
> + int (*exec_mipi_pmic_seq_element)(struct regmap *r, const u8 *data);
> struct pmic_table *power_table;
> int power_table_count;
> struct pmic_table *thermal_table;
> diff --git a/include/linux/mfd/intel_soc_pmic.h
> b/include/linux/mfd/intel_soc_pmic.h
> index ed1dfba5e5f9..71a8607a0a8c 100644
> --- a/include/linux/mfd/intel_soc_pmic.h
> +++ b/include/linux/mfd/intel_soc_pmic.h
> @@ -26,4 +26,6 @@ struct intel_soc_pmic {
> struct device *dev;
> };
>
> +int intel_soc_pmic_exec_mipi_pmic_seq_element(const u8 *data);
Add a static inline dummy implementation with error return for
CONFIG_PMIC_OPREGION=n? Maybe even with pr_err or pr_warn or something?
BR,
Jani.
> +
> #endif /* __INTEL_SOC_PMIC_H__ */
--
Jani Nikula, Intel Open Source Gr
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev5)
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
(rev5)
URL : https://patchwork.freedesktop.org/series/53979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11086
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11086 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11086, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53979/revisions/5/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11086:
### IGT changes ###
Warnings
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: PASS -> SKIP +33
Known issues
Here are the changes found in Patchwork_11086 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602] / [fdo#108529] +1
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> DMESG-WARN [fdo#108622]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: NOTRUN -> DMESG-WARN [fdo#108924] / [fdo#109044]
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: PASS -> FAIL [fdo#103167]
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@pm_rpm@module-reload:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108529]
* {igt@runner@aborted}:
- fi-icl-u3: NOTRUN -> FAIL [fdo#108924]
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-WARN [fdo#108473] -> DMESG-FAIL [fdo#105079]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044
Participating hosts (47 -> 45)
--
Additional (2): fi-icl-y fi-icl-u3
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5311 -> Patchwork_11086
CI_DRM_5311: a42fd8bf199784ee4ff1cdb5ee03eedd9a535d4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11086: 3f34af703e8e3ad78f1b903d0e523c3b15afc2bb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3f34af703e8e drm/i915: Apply missed interrupt after reset w/a to all ringbuffer
gen
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11086/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Thu, Dec 13, 2018 at 01:40:27PM +0100, Hans de Goede wrote:
> Hi,
>
> On 13-12-18 13:14, Ville Syrjälä wrote:
> > On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
> >> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> >> PMIC.
> >>
> >> On some CHT devices this fixes the LCD panel not lighting up when it was
> >> not initialized by the GOP, because an external monitor was plugged in and
> >> the GOP initialized only the external monitor.
> >>
> >> Signed-off-by: Hans de Goede
> >> ---
> >> Changes in v2:
> >> -Interpret data passed to the PMIC MIPI elements according to the docs
> >> instead of my own reverse engineered interpretation
> >> Changes in v3:
> >> -Use hex values for out of range checks
> >> -Make intel_cht_wc_exec_mipi_pmic_seq_element return errors
> >> ---
> >> drivers/acpi/pmic/intel_pmic_chtwc.c | 25 +
> >> 1 file changed, 25 insertions(+)
> >>
> >> diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
> >> b/drivers/acpi/pmic/intel_pmic_chtwc.c
> >> index 078b0448f30a..8ede74e9b89f 100644
> >> --- a/drivers/acpi/pmic/intel_pmic_chtwc.c
> >> +++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
> >> @@ -12,6 +12,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include "intel_pmic.h"
> >>
> >> #define CHT_WC_V1P05A_CTRL 0x6e3b
> >> @@ -231,6 +232,29 @@ static int intel_cht_wc_pmic_update_power(struct
> >> regmap *regmap, int reg,
> >>return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
> >> }
> >>
> >> +static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
> >> + const u8 *data)
> >> +{
> >> + u32 value, mask, reg_address, address;
> >> + u16 i2c_client_address;
> >> +
> >> + /* byte 0 aka PMIC Flag is reserved */
> >> + i2c_client_address = get_unaligned_le16(data + 1);
> >> + reg_address = get_unaligned_le32(data + 3);
> >> + value = get_unaligned_le32(data + 7);
> >> + mask= get_unaligned_le32(data + 11);
> >
> > Upon further reflection maybe it would better to do this decoding in
> > the i915 code and just pass each parameter to this hook separately?
> > That way we wouldn't be spreading the vbt details all over the place.
>
> Interesting point, if the VBT spec says that this encoding is PMIC
> independent, then yes we should probably fo the decoding in the VBT
> code and change the intel_soc_pmic_exec_mipi_pmic_seq_element
> prototype to:
>
> int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32
> reg_address,
> u32 value, u32 mask);
>
> If you agree please let me know and I will do a v4 of the patchset.
Yeah, I think that's probably better. The spec has just the one
interpretation for the sequence.
>
> I've also been thinking about trying to make the implementation
> under drivers/acpi/pmic pmic independent, but not all pmic
> drivers use the regmap the same way. The CHT Whiskey Cove PMIC
> mfd driver uses a regmap with 16 bit addresses where the upper
> byte is the i2c client address and the lower byte is the register
> address (this PMIC listens on multiple addresses, with different
> registers behind each i2c address).
>
> Where as most PMIC mfd drivers simply use the standard
> devm_regmap_init_i2c() method of creating a regmap. For these
> others we could do a standard implementation where we check the
> passed in i2c_address is what we expect (for that type PMIC) and
> then pass the other 3 parameters to regmap_update_bits.
>
> But I think it would be best to wait with such a generic implementation
> until we encounter a device using the PMIC MIPI sequence element
> with another type of PMIC. Since we still need the special
> implementation for the CHT WC case, we still need an operation
> pointer for this in intel_pmic_opregion_data anyways, so we can
> easily plug in the generic implementation for others later.
Yeah, probably not worth worrying about this until we
encounter a machine that needs it.
Oh, and we should probably change the DRM_DEBUG_KMS() for the
PMIC_OPREGION=n case to a DRM_ERROR() which tells people to
enable PMIC_OPREGION=y. Not sure why all these random knobs are
even user configurable. No one can really be expected to know
how to configure them properly. There was a recent problem with
someone having set I2C_DESIGNWARE_BAYTRAIL=n as well because
they had a CHT/BSW instead of a BYT :(
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Having completed a test run of gem_eio across all machines in CI we also
observe the phenomenon (of lost interrupts after resetting the GPU) on
gen3 machines as well as the previously sighted gen6/gen7. Let's apply
the same HWSTAM workaround that was effective for gen6+ for all, as
although we haven't seen the same failure on gen4/5 it seems prudent to
keep the code the same.
As a consequence we can remove the extra setting of HWSTAM and apply the
register from a single site.
v2: Delazy and move the HWSTAM into its own function
v3: Mask off all HWSP writes on driver unload and engine cleanup.
v4: And what about the physical hwsp?
v5: No, engine->init_hw() is not called from driver_init_hw(), don't be
daft. Really scrub HWSTAM as early as we can in driver_init_mmio()
References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 9 --
drivers/gpu/drm/i915/intel_engine_cs.c | 24 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 107 +++-
3 files changed, 92 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e2dac9b5f4ce..0c7fc9890891 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- if (IS_GEN(dev_priv, 5))
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET(DE);
if (IS_GEN(dev_priv, 7))
I915_WRITE(GEN7_ERR_INT, 0x);
@@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE16(HWSTAM, 0x);
-
GEN2_IRQ_RESET();
}
@@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET();
}
@@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET();
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 6f165f9ad2bf..24245dba3207 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -261,6 +261,24 @@ static void __sprint_engine_name(char *name, const struct
engine_info *info)
info->instance) >= INTEL_ENGINE_CS_MAX_NAME);
}
+static void set_hwsp(struct intel_engine_cs *engine, u32 mask)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ i915_reg_t hwstam;
+
+ hwstam = RING_HWSTAM(engine->mmio_base);
+ if (INTEL_GEN(dev_priv) >= 3)
+ I915_WRITE(hwstam, mask);
+ else
+ I915_WRITE16(hwstam, mask);
+}
+
+static void intel_engine_sanitize_mmio(struct intel_engine_cs *engine)
+{
+ /* Mask off all writes into the unknown HWSP */
+ set_hwsp(engine, ~0u);
+}
+
static int
intel_engine_setup(struct drm_i915_private *dev_priv,
enum intel_engine_id id)
@@ -312,6 +330,9 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
ATOMIC_INIT_NOTIFIER_HEAD(&engine->context_status_notifier);
+ /* Scrub mmio state on takeover */
+ intel_engine_sanitize_mmio(engine);
+
dev_priv->engine_class[info->class][info->instance] = engine;
dev_priv->engine[id] = engine;
return 0;
@@ -495,6 +516,9 @@ void intel_engine_setup_common(struct intel_engine_cs
*engine)
static void cleanup_status_page(struct intel_engine_cs *engine)
{
+ /* Stop writing into the status page before returnig it to the system */
+ set_hwsp(engine, ~0u);
+
if (HWS_NEEDS_PHYSICAL(engine->i915)) {
void *addr = fetch_and_zero(&engine->status_page.page_addr);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index fdeca2b877c9..88f50e30a0c4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -379,11 +379,31 @@ gen7_render_ring_flush(struct i915_request *rq, u32 mode)
return 0;
}
-static void ring_setup_phys_status_page(struct intel_engine_cs *engine)
+static void set_hwstam(struct intel_engine_cs *engine, u32 mask)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ i915_reg_t hwstam = RING_HWSTAM(engine->mmio_base);
+
+ /*
+* Keep the render interrupt unmasked as this papers over
+* lost interrupts following a reset.
+*/
+ if (engine->id == RCS) {
+ if (INTEL_GEN(engine->i915) >= 6)
+ mask &= ~BIT(0);
+ else
+ mask &= ~I915_USER_INTERRUPT;
+ }
+
+ if (INTEL_GEN(dev
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
On Thu, Dec 13, 2018 at 12:34:02PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-12-13 12:29:15)
> > On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> > > Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > > > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > > > Having completed a test run of gem_eio across all machines in CI we
> > > > > also
> > > > > observe the phenomenon (of lost interrupts after resetting the GPU) on
> > > > > gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> > > > > the same HWSTAM workaround that was effective for gen6+ for all, as
> > > > > although we haven't seen the same failure on gen4/5 it seems prudent
> > > > > to
> > > > > keep the code the same.
> > > > >
> > > > > As a consequence we can remove the extra setting of HWSTAM and apply
> > > > > the
> > > > > register from a single site.
> > > > >
> > > > > v2: Delazy and move the HWSTAM into its own function
> > > > >
> > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> > > > > Signed-off-by: Chris Wilson
> > > > > Cc: Tvrtko Ursulin
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_irq.c | 9 --
> > > > > drivers/gpu/drm/i915/intel_ringbuffer.c | 41
> > > > > -
> > > > > 2 files changed, 27 insertions(+), 23 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > index e2dac9b5f4ce..0c7fc9890891 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct
> > > > > drm_device *dev)
> > > > > {
> > > > > struct drm_i915_private *dev_priv = to_i915(dev);
> > > > >
> > > > > - if (IS_GEN(dev_priv, 5))
> > > > > - I915_WRITE(HWSTAM, 0x);
> > > > > -
> > > > > GEN3_IRQ_RESET(DE);
> > > > > if (IS_GEN(dev_priv, 7))
> > > > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > > > @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device
> > > > > *dev)
> > > > >
> > > > > i9xx_pipestat_irq_reset(dev_priv);
> > > > >
> > > > > - I915_WRITE16(HWSTAM, 0x);
> > > > > -
> > > > > GEN2_IRQ_RESET();
> > > > > }
> > > > >
> > > > > @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device
> > > > > *dev)
> > > > >
> > > > > i9xx_pipestat_irq_reset(dev_priv);
> > > > >
> > > > > - I915_WRITE(HWSTAM, 0x);
> > > > > -
> > > > > GEN3_IRQ_RESET();
> > > > > }
> > > > >
> > > > > @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device
> > > > > *dev)
> > > > >
> > > > > i9xx_pipestat_irq_reset(dev_priv);
> > > > >
> > > > > - I915_WRITE(HWSTAM, 0x);
> > > > > -
> > > > > GEN3_IRQ_RESET();
> > > > > }
> > > >
> > > > So we're not worried about enabling interrupts and having
> > > > something unmasked in HWSTAM by accident before we have the
> > > > status page set up?
> > >
> > > Sanitization of the HWSP setup would be off during early engine setup.
> > > We do the irq install & reset during i915_load_modeset_init after we do
> > > the status page setup. Unless I'm mistaken, moving the HWSTAM alongside
> > > HWSP moves the sanitisation earlier.
> >
> > To me it looks like the hwsp setup happens via i915_gem_init(), which
> > gets called after irq install. But maybe I'm just hopelessly lost
> > in the maze.
>
> i915_driver_init_hw -> i915_gem_init_hw -> init_ringbuffer...
i915_gem_init_hw() doesn't seem to be called from there, unless I'm
looking at a stale tree already. I did checkout ~4 hours ago so
could very well be outdated already :)
>
> i915_load_modeset_init -> intel_irq_install -> irq_reset
>
> Aiui, with init_hw called before modeset_init.
>
> > Oh, and what about the hws_needs_physical case?
>
> Good point.
> -Chris
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
Hi,
On 13-12-18 13:14, Ville Syrjälä wrote:
On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Interpret data passed to the PMIC MIPI elements according to the docs
instead of my own reverse engineered interpretation
Changes in v3:
-Use hex values for out of range checks
-Make intel_cht_wc_exec_mipi_pmic_seq_element return errors
---
drivers/acpi/pmic/intel_pmic_chtwc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
b/drivers/acpi/pmic/intel_pmic_chtwc.c
index 078b0448f30a..8ede74e9b89f 100644
--- a/drivers/acpi/pmic/intel_pmic_chtwc.c
+++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "intel_pmic.h"
#define CHT_WC_V1P05A_CTRL 0x6e3b
@@ -231,6 +232,29 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
}
+static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
+ const u8 *data)
+{
+ u32 value, mask, reg_address, address;
+ u16 i2c_client_address;
+
+ /* byte 0 aka PMIC Flag is reserved */
+ i2c_client_address = get_unaligned_le16(data + 1);
+ reg_address = get_unaligned_le32(data + 3);
+ value = get_unaligned_le32(data + 7);
+ mask= get_unaligned_le32(data + 11);
Upon further reflection maybe it would better to do this decoding in
the i915 code and just pass each parameter to this hook separately?
That way we wouldn't be spreading the vbt details all over the place.
Interesting point, if the VBT spec says that this encoding is PMIC
independent, then yes we should probably fo the decoding in the VBT
code and change the intel_soc_pmic_exec_mipi_pmic_seq_element
prototype to:
int intel_soc_pmic_exec_mipi_pmic_seq_element(u16 i2c_address, u32 reg_address,
u32 value, u32 mask);
If you agree please let me know and I will do a v4 of the patchset.
I've also been thinking about trying to make the implementation
under drivers/acpi/pmic pmic independent, but not all pmic
drivers use the regmap the same way. The CHT Whiskey Cove PMIC
mfd driver uses a regmap with 16 bit addresses where the upper
byte is the i2c client address and the lower byte is the register
address (this PMIC listens on multiple addresses, with different
registers behind each i2c address).
Where as most PMIC mfd drivers simply use the standard
devm_regmap_init_i2c() method of creating a regmap. For these
others we could do a standard implementation where we check the
passed in i2c_address is what we expect (for that type PMIC) and
then pass the other 3 parameters to regmap_update_bits.
But I think it would be best to wait with such a generic implementation
until we encounter a device using the PMIC MIPI sequence element
with another type of PMIC. Since we still need the special
implementation for the CHT WC case, we still need an operation
pointer for this in intel_pmic_opregion_data anyways, so we can
easily plug in the generic implementation for others later.
Regards,
Hans
+
+ if (i2c_client_address > 0xff || reg_address > 0xff) {
+ pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
+ __func__, i2c_client_address, reg_address);
+ return -ERANGE;
+ }
+
+ address = (i2c_client_address << 8) | reg_address;
+
+ return regmap_update_bits(regmap, address, mask, value);
+}
+
/*
* The thermal table and ops are empty, we do not support the Thermal opregion
* (DPTF) due to lacking documentation.
@@ -238,6 +262,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap
*regmap, int reg,
static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
.get_power = intel_cht_wc_pmic_get_power,
.update_power = intel_cht_wc_pmic_update_power,
+ .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
.power_table= power_table,
.power_table_count = ARRAY_SIZE(power_table),
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Having completed a test run of gem_eio across all machines in CI we also
observe the phenomenon (of lost interrupts after resetting the GPU) on
gen3 machines as well as the previously sighted gen6/gen7. Let's apply
the same HWSTAM workaround that was effective for gen6+ for all, as
although we haven't seen the same failure on gen4/5 it seems prudent to
keep the code the same.
As a consequence we can remove the extra setting of HWSTAM and apply the
register from a single site.
v2: Delazy and move the HWSTAM into its own function
v3: Mask off all HWSP writes on driver unload and engine cleanup.
v4: And what about the physical hwsp?
References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 9 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 114
2 files changed, 75 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e2dac9b5f4ce..0c7fc9890891 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- if (IS_GEN(dev_priv, 5))
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET(DE);
if (IS_GEN(dev_priv, 7))
I915_WRITE(GEN7_ERR_INT, 0x);
@@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE16(HWSTAM, 0x);
-
GEN2_IRQ_RESET();
}
@@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET();
}
@@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET();
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index fdeca2b877c9..cefac3d9bba2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -379,11 +379,36 @@ gen7_render_ring_flush(struct i915_request *rq, u32 mode)
return 0;
}
-static void ring_setup_phys_status_page(struct intel_engine_cs *engine)
+static void __set_hwstam(struct intel_engine_cs *engine, u32 mask)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ i915_reg_t hwstam = RING_HWSTAM(engine->mmio_base);
+
+ if (INTEL_GEN(dev_priv) >= 3)
+ I915_WRITE(hwstam, mask);
+ else
+ I915_WRITE16(hwstam, mask);
+}
+
+static void set_hwstam(struct intel_engine_cs *engine, u32 mask)
+{
+ /*
+* Keep the render interrupt unmasked as this papers over
+* lost interrupts following a reset.
+*/
+ if (engine->id == RCS) {
+ if (INTEL_GEN(engine->i915) >= 6)
+ mask &= ~BIT(0);
+ else
+ mask &= ~I915_USER_INTERRUPT;
+ }
+
+ __set_hwstam(engine, mask);
+}
+
+static void set_hws_pga(struct intel_engine_cs *engine, phys_addr_t phys)
{
struct drm_i915_private *dev_priv = engine->i915;
- struct page *page = virt_to_page(engine->status_page.page_addr);
- phys_addr_t phys = PFN_PHYS(page_to_pfn(page));
u32 addr;
addr = lower_32_bits(phys);
@@ -393,12 +418,22 @@ static void ring_setup_phys_status_page(struct
intel_engine_cs *engine)
I915_WRITE(HWS_PGA, addr);
}
-static void intel_ring_setup_status_page(struct intel_engine_cs *engine)
+static void ring_setup_phys_status_page(struct intel_engine_cs *engine)
+{
+ struct page *page = virt_to_page(engine->status_page.page_addr);
+ phys_addr_t phys = PFN_PHYS(page_to_pfn(page));
+
+ set_hws_pga(engine, phys);
+ set_hwstam(engine, ~0u);
+}
+
+static void set_hwsp(struct intel_engine_cs *engine, u32 offset)
{
struct drm_i915_private *dev_priv = engine->i915;
- i915_reg_t mmio;
+ i915_reg_t hwsp;
- /* The ring status page addresses are no longer next to the rest of
+ /*
+* The ring status page addresses are no longer next to the rest of
* the ring registers as of gen7.
*/
if (IS_GEN(dev_priv, 7)) {
@@ -410,56 +445,55 @@ static void intel_ring_setup_status_page(struct
intel_engine_cs *engine)
default:
GEM_BUG_ON(engine->id);
case RCS:
- mmio = RENDER_HWS_PGA_GEN7;
+ hwsp = RENDER_HWS_PGA_GEN7;
break;
case BCS:
- mmio = BLT_HWS_PGA_GEN7;
+ hwsp = BLT_HWS_PGA_GEN7;
break;
ca
Re: [Intel-gfx] [PATCH v9 35/39] misc/mei/hdcp: Component framework for I915 Interface
Tomas and Daniel,
We got an issue here.
The relationship that we try to build between I915 and mei_hdcp is as follows:
* We are using the components to establish the relationship.
* I915 is component master where as mei_hdcp is component.
* I915 adds the component master during the module load. mei_hdcp adds
the component when the driver->probe is called (on device driver
binding).
* I915 forces itself such that until mei_hdcp component is added
I915_load wont be complete.
* Similarly on complete system, if mei_hdcp component is removed,
immediately I915 unregister itself and HW will be shutdown.
This is completely fine when the modules are loaded and unloaded.
But during suspend, mei device disappears and mei bus handles it by unbinding
device and driver by calling driver->remove.
This in-turn removes the component and triggers the master unbind of I915
where, I915 unregister itself.
This cause the HW state mismatch during the suspend and resume.
Please check the powerwell mismatch errors at CI report for v9
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_3412/fi-glk-j4005/igt@gem_exec_susp...@basic-s3.html
More over unregistering I915 during the suspend is not expected. So how do we
handle this?
-Ram
On 12/13/2018 9:31 AM, Ramalingam C wrote:
Mei hdcp driver is designed as component slave for the I915 component
master.
v2: Rebased.
v3:
Notifier chain is adopted for cldev state update [Tomas]
v4:
Made static dummy functions as inline in mei_hdcp.h
API for polling client device status
IS_ENABLED used in header, for config status for mei_hdcp.
v5:
Replacing the notifier with component framework. [Daniel]
v6:
Rebased on the I915 comp master redesign.
v7:
mei_hdcp_component_registered is made static [Uma]
Need for global static variable mei_cldev is removed.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
---
drivers/misc/mei/hdcp/mei_hdcp.c | 67 +---
1 file changed, 63 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index b22a71e8c5d7..3de1700dcc9f 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,11 +23,14 @@
#include
#include
#include
+#include
#include
#include
#include "mei_hdcp.h"
+static bool mei_hdcp_component_registered;
+
/**
* mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -691,8 +694,7 @@ mei_close_hdcp_session(struct device *dev, struct
hdcp_port_data *data)
return 0;
}
-static __attribute__((unused))
-struct i915_hdcp_component_ops mei_hdcp_ops = {
+static struct i915_hdcp_component_ops mei_hdcp_ops = {
.owner = THIS_MODULE,
.initiate_hdcp2_session = mei_initiate_hdcp2_session,
.verify_receiver_cert_prepare_km = mei_verify_receiver_cert_prepare_km,
@@ -707,20 +709,77 @@ struct i915_hdcp_component_ops mei_hdcp_ops = {
.close_hdcp_session = mei_close_hdcp_session,
};
+static int mei_hdcp_component_bind(struct device *mei_kdev,
+ struct device *i915_kdev, void *data)
+{
+ struct i915_component_master *master_comp = data;
+
+ dev_info(mei_kdev, "MEI HDCP comp bind\n");
+ WARN_ON(master_comp->hdcp_ops);
+ master_comp->hdcp_ops = &mei_hdcp_ops;
+ master_comp->mei_dev = mei_kdev;
+
+ return 0;
+}
+
+static void mei_hdcp_component_unbind(struct device *mei_kdev,
+ struct device *i915_kdev, void *data)
+{
+ struct i915_component_master *master_comp = data;
+
+ dev_info(mei_kdev, "MEI HDCP comp unbind\n");
+ master_comp->hdcp_ops = NULL;
+ master_comp->mei_dev = NULL;
+}
+
+static const struct component_ops mei_hdcp_component_bind_ops = {
+ .bind = mei_hdcp_component_bind,
+ .unbind = mei_hdcp_component_unbind,
+};
+
+static void mei_hdcp_component_init(struct device *dev)
+{
+ int ret;
+
+ dev_info(dev, "MEI HDCP comp init\n");
+ ret = component_add(dev, &mei_hdcp_component_bind_ops);
+ if (ret < 0) {
+ dev_err(dev, "Failed to add MEI HDCP comp (%d)\n", ret);
+ return;
+ }
+
+ mei_hdcp_component_registered = true;
+}
+
+static void mei_hdcp_component_cleanup(struct device *dev)
+{
+ if (!mei_hdcp_component_registered)
+ return;
+
+ dev_info(dev, "MEI HDCP comp cleanup\n");
+ component_del(dev, &mei_hdcp_component_bind_ops);
+ mei_hdcp_component_registered = false;
+}
+
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id)
{
int ret;
ret = mei_cldev_enable(cldev);
- if (ret < 0)
+ if (ret < 0) {
dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
+ return ret;
+
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Quoting Ville Syrjälä (2018-12-13 12:29:15)
> On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > > Having completed a test run of gem_eio across all machines in CI we also
> > > > observe the phenomenon (of lost interrupts after resetting the GPU) on
> > > > gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> > > > the same HWSTAM workaround that was effective for gen6+ for all, as
> > > > although we haven't seen the same failure on gen4/5 it seems prudent to
> > > > keep the code the same.
> > > >
> > > > As a consequence we can remove the extra setting of HWSTAM and apply the
> > > > register from a single site.
> > > >
> > > > v2: Delazy and move the HWSTAM into its own function
> > > >
> > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> > > > Signed-off-by: Chris Wilson
> > > > Cc: Tvrtko Ursulin
> > > > ---
> > > > drivers/gpu/drm/i915/i915_irq.c | 9 --
> > > > drivers/gpu/drm/i915/intel_ringbuffer.c | 41 -
> > > > 2 files changed, 27 insertions(+), 23 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index e2dac9b5f4ce..0c7fc9890891 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device
> > > > *dev)
> > > > {
> > > > struct drm_i915_private *dev_priv = to_i915(dev);
> > > >
> > > > - if (IS_GEN(dev_priv, 5))
> > > > - I915_WRITE(HWSTAM, 0x);
> > > > -
> > > > GEN3_IRQ_RESET(DE);
> > > > if (IS_GEN(dev_priv, 7))
> > > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > > @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
> > > >
> > > > i9xx_pipestat_irq_reset(dev_priv);
> > > >
> > > > - I915_WRITE16(HWSTAM, 0x);
> > > > -
> > > > GEN2_IRQ_RESET();
> > > > }
> > > >
> > > > @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
> > > >
> > > > i9xx_pipestat_irq_reset(dev_priv);
> > > >
> > > > - I915_WRITE(HWSTAM, 0x);
> > > > -
> > > > GEN3_IRQ_RESET();
> > > > }
> > > >
> > > > @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
> > > >
> > > > i9xx_pipestat_irq_reset(dev_priv);
> > > >
> > > > - I915_WRITE(HWSTAM, 0x);
> > > > -
> > > > GEN3_IRQ_RESET();
> > > > }
> > >
> > > So we're not worried about enabling interrupts and having
> > > something unmasked in HWSTAM by accident before we have the
> > > status page set up?
> >
> > Sanitization of the HWSP setup would be off during early engine setup.
> > We do the irq install & reset during i915_load_modeset_init after we do
> > the status page setup. Unless I'm mistaken, moving the HWSTAM alongside
> > HWSP moves the sanitisation earlier.
>
> To me it looks like the hwsp setup happens via i915_gem_init(), which
> gets called after irq install. But maybe I'm just hopelessly lost
> in the maze.
i915_driver_init_hw -> i915_gem_init_hw -> init_ringbuffer...
i915_load_modeset_init -> intel_irq_install -> irq_reset
Aiui, with init_hw called before modeset_init.
> Oh, and what about the hws_needs_physical case?
Good point.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/4] tests/gem_media_vme: Shut down half of subslices to avoid gpu hang on ICL
Quoting Tvrtko Ursulin (2018-12-13 12:06:36)
> +static void shut_non_vme_subslices(int drm_fd, uint32_t ctx)
> +{
> + struct drm_i915_gem_context_param_sseu sseu = { };
> + struct drm_i915_gem_context_param arg = {
> + .param = I915_CONTEXT_PARAM_SSEU,
> + .ctx_id = ctx,
> + .size = sizeof(sseu),
> + .value = to_user_pointer(&sseu),
> + };
> + int ret;
> +
> + if (__gem_context_get_param(drm_fd, &arg))
> + return; /* no sseu support */
> +
> + ret = __gem_context_set_param(drm_fd, &arg);
> + igt_assert(ret == 0 || ret == -ENODEV || ret == -EINVAL);
> + if (ret)
> + return; /* no sseu support */
/* no sseu reconfiguration */
That justifies for me the two step is-supported check.
get -> does the kernel recognise this param and do we have sseu
set -> does the kernel/device allow us to adjust sseu
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Series Details ==
Series: series starting with [v3,1/3] ACPI / PMIC: Add support for executing
PMIC MIPI sequence elements
URL : https://patchwork.freedesktop.org/series/53986/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11085
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_11085 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11085, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53986/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11085:
### IGT changes ###
Warnings
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: PASS -> SKIP +7
Known issues
Here are the changes found in Patchwork_11085 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@debugfs_test@read_all_entries:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602]
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#103558] / [fdo#105079] /
[fdo#105602]
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#105602] / [fdo#108529] +1
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7567u: PASS -> FAIL [fdo#108767] +2
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: NOTRUN -> DMESG-WARN [fdo#108924] / [fdo#109044]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-7567u: PASS -> DMESG-FAIL [fdo#105079]
* igt@kms_setmode@basic-clone-single-crtc:
- fi-ilk-650: PASS -> DMESG-WARN [fdo#106387]
* igt@pm_rpm@module-reload:
- fi-kbl-7567u: PASS -> DMESG-WARN [fdo#108529]
* {igt@runner@aborted}:
- fi-icl-u3: NOTRUN -> FAIL [fdo#108924]
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: DMESG-WARN [fdo#108473] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108473]: https://bugs.freedesktop.org/show_bug.cgi?id=108473
[fdo#108529]: https://bugs.freedesktop.org/show_bug.cgi?id=108529
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108924]: https://bugs.freedesktop.org/show_bug.cgi?id=108924
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109044]: https://bugs.freedesktop.org/show_bug.cgi?id=109044
Participating hosts (47 -> 45)
--
Additional (2): fi-icl-y fi-icl-u3
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5311 -> Patchwork_11085
CI_DRM_5311: a42fd8bf199784ee4ff1cdb5ee03eedd9a535d4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11085: a6a19013e822938da76771d319deefebfc6a5360 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a6a19013e822 drm/i915/intel_dsi_vbt: Add support for PMIC MIPI sequences
b397452a9437 ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey
Cove PMIC
9ca8ee14648f ACPI / PMIC: Add support for executing PMIC MIPI sequence elements
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11085/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
On Thu, Dec 13, 2018 at 12:07:35PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > Having completed a test run of gem_eio across all machines in CI we also
> > > observe the phenomenon (of lost interrupts after resetting the GPU) on
> > > gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> > > the same HWSTAM workaround that was effective for gen6+ for all, as
> > > although we haven't seen the same failure on gen4/5 it seems prudent to
> > > keep the code the same.
> > >
> > > As a consequence we can remove the extra setting of HWSTAM and apply the
> > > register from a single site.
> > >
> > > v2: Delazy and move the HWSTAM into its own function
> > >
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> > > Signed-off-by: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 9 --
> > > drivers/gpu/drm/i915/intel_ringbuffer.c | 41 -
> > > 2 files changed, 27 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index e2dac9b5f4ce..0c7fc9890891 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device
> > > *dev)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > >
> > > - if (IS_GEN(dev_priv, 5))
> > > - I915_WRITE(HWSTAM, 0x);
> > > -
> > > GEN3_IRQ_RESET(DE);
> > > if (IS_GEN(dev_priv, 7))
> > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE16(HWSTAM, 0x);
> > > -
> > > GEN2_IRQ_RESET();
> > > }
> > >
> > > @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE(HWSTAM, 0x);
> > > -
> > > GEN3_IRQ_RESET();
> > > }
> > >
> > > @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE(HWSTAM, 0x);
> > > -
> > > GEN3_IRQ_RESET();
> > > }
> >
> > So we're not worried about enabling interrupts and having
> > something unmasked in HWSTAM by accident before we have the
> > status page set up?
>
> Sanitization of the HWSP setup would be off during early engine setup.
> We do the irq install & reset during i915_load_modeset_init after we do
> the status page setup. Unless I'm mistaken, moving the HWSTAM alongside
> HWSP moves the sanitisation earlier.
To me it looks like the hwsp setup happens via i915_gem_init(), which
gets called after irq install. But maybe I'm just hopelessly lost
in the maze.
Oh, and what about the hws_needs_physical case?
>
> The only question then is order inside the HWSP setup, and the
> suggestion would be to make sure the HWSP is set before the HWSTAM to be
> safe on the bits we control.
> -Chris
--
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 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
Am 13.12.18 um 13:21 schrieb Chris Wilson:
> Quoting Koenig, Christian (2018-12-13 12:11:10)
>> Am 13.12.18 um 12:37 schrieb Chris Wilson:
>>> Quoting Chunming Zhou (2018-12-11 10:34:45)
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 43 ---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 76ce13dafc4d..d964b348ecba 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
struct dma_fence **fence)
{
struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
handle);
- int ret = 0;
+ struct syncobj_wait_entry wait;
+ int ret;
if (!syncobj)
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
+ drm_syncobj_put(syncobj);
+
+ if (*fence) {
+ ret = dma_fence_chain_find_seqno(fence, point);
+ if (!ret)
+ return 0;
+ dma_fence_put(*fence);
+ } else {
ret = -EINVAL;
}
- drm_syncobj_put(syncobj);
+
+ if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+ return ret;
+
+ memset(&wait, 0, sizeof(wait));
+ wait.task = current;
+ wait.point = point;
+ drm_syncobj_fence_add_wait(syncobj, &wait);
+
+ do {
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (wait.fence) {
+ ret = 0;
+ break;
+ }
+
+ if (signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
+
+ schedule();
+ } while (1);
>>> I've previously used a dma_fence_proxy so that we could do nonblocking
>>> waits on future submits. That would be preferrable (a requirement for
>>> our stupid BKL-driven code).
>> That is exactly what I would definitely NAK.
>>
>> I would rather say we should come up with a wait_multiple_events() macro
>> and completely nuke the custom implementation of this in:
>> 1. dma_fence_default_wait and dma_fence_wait_any_timeout
>> 2. the radeon fence implementation
>> 3. the nouveau fence implementation
>> 4. the syncobj code
>>
>> Cause all of them do exactly the same. The dma_fence implementation
>> unfortunately came up with a custom event handling mechanism instead of
>> extending the core Linux wait_event() system.
> I don't want a blocking wait at all.
Ok I wasn't clear enough :) That is exactly what I would NAK!
The wait must be blocking or otherwise you would allow wait-before-signal.
Christian.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
Quoting Koenig, Christian (2018-12-13 12:11:10)
> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> > Quoting Chunming Zhou (2018-12-11 10:34:45)
> >> From: Christian König
> >>
> >> Implement finding the right timeline point in drm_syncobj_find_fence.
> >>
> >> v2: return -EINVAL when the point is not submitted yet.
> >> v3: fix reference counting bug, add flags handling as well
> >>
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/drm_syncobj.c | 43 ---
> >> 1 file changed, 40 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> >> index 76ce13dafc4d..d964b348ecba 100644
> >> --- a/drivers/gpu/drm/drm_syncobj.c
> >> +++ b/drivers/gpu/drm/drm_syncobj.c
> >> @@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file
> >> *file_private,
> >> struct dma_fence **fence)
> >> {
> >> struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
> >> handle);
> >> - int ret = 0;
> >> + struct syncobj_wait_entry wait;
> >> + int ret;
> >>
> >> if (!syncobj)
> >> return -ENOENT;
> >>
> >> *fence = drm_syncobj_fence_get(syncobj);
> >> - if (!*fence) {
> >> + drm_syncobj_put(syncobj);
> >> +
> >> + if (*fence) {
> >> + ret = dma_fence_chain_find_seqno(fence, point);
> >> + if (!ret)
> >> + return 0;
> >> + dma_fence_put(*fence);
> >> + } else {
> >> ret = -EINVAL;
> >> }
> >> - drm_syncobj_put(syncobj);
> >> +
> >> + if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
> >> + return ret;
> >> +
> >> + memset(&wait, 0, sizeof(wait));
> >> + wait.task = current;
> >> + wait.point = point;
> >> + drm_syncobj_fence_add_wait(syncobj, &wait);
> >> +
> >> + do {
> >> + set_current_state(TASK_INTERRUPTIBLE);
> >> + if (wait.fence) {
> >> + ret = 0;
> >> + break;
> >> + }
> >> +
> >> + if (signal_pending(current)) {
> >> + ret = -ERESTARTSYS;
> >> + break;
> >> + }
> >> +
> >> + schedule();
> >> + } while (1);
> > I've previously used a dma_fence_proxy so that we could do nonblocking
> > waits on future submits. That would be preferrable (a requirement for
> > our stupid BKL-driven code).
>
> That is exactly what I would definitely NAK.
>
> I would rather say we should come up with a wait_multiple_events() macro
> and completely nuke the custom implementation of this in:
> 1. dma_fence_default_wait and dma_fence_wait_any_timeout
> 2. the radeon fence implementation
> 3. the nouveau fence implementation
> 4. the syncobj code
>
> Cause all of them do exactly the same. The dma_fence implementation
> unfortunately came up with a custom event handling mechanism instead of
> extending the core Linux wait_event() system.
I don't want a blocking wait at all.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Having completed a test run of gem_eio across all machines in CI we also
observe the phenomenon (of lost interrupts after resetting the GPU) on
gen3 machines as well as the previously sighted gen6/gen7. Let's apply
the same HWSTAM workaround that was effective for gen6+ for all, as
although we haven't seen the same failure on gen4/5 it seems prudent to
keep the code the same.
As a consequence we can remove the extra setting of HWSTAM and apply the
register from a single site.
v2: Delazy and move the HWSTAM into its own function
v3: Mask off all HWSP writes on driver unload and engine cleanup.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 9 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 97 -
2 files changed, 63 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e2dac9b5f4ce..0c7fc9890891 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- if (IS_GEN(dev_priv, 5))
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET(DE);
if (IS_GEN(dev_priv, 7))
I915_WRITE(GEN7_ERR_INT, 0x);
@@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE16(HWSTAM, 0x);
-
GEN2_IRQ_RESET();
}
@@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET();
}
@@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
i9xx_pipestat_irq_reset(dev_priv);
- I915_WRITE(HWSTAM, 0x);
-
GEN3_IRQ_RESET();
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index fdeca2b877c9..5ab564999cc6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -393,12 +393,13 @@ static void ring_setup_phys_status_page(struct
intel_engine_cs *engine)
I915_WRITE(HWS_PGA, addr);
}
-static void intel_ring_setup_status_page(struct intel_engine_cs *engine)
+static void set_hwsp(struct intel_engine_cs *engine, u32 offset)
{
struct drm_i915_private *dev_priv = engine->i915;
- i915_reg_t mmio;
+ i915_reg_t hwsp;
- /* The ring status page addresses are no longer next to the rest of
+ /*
+* The ring status page addresses are no longer next to the rest of
* the ring registers as of gen7.
*/
if (IS_GEN(dev_priv, 7)) {
@@ -410,56 +411,82 @@ static void intel_ring_setup_status_page(struct
intel_engine_cs *engine)
default:
GEM_BUG_ON(engine->id);
case RCS:
- mmio = RENDER_HWS_PGA_GEN7;
+ hwsp = RENDER_HWS_PGA_GEN7;
break;
case BCS:
- mmio = BLT_HWS_PGA_GEN7;
+ hwsp = BLT_HWS_PGA_GEN7;
break;
case VCS:
- mmio = BSD_HWS_PGA_GEN7;
+ hwsp = BSD_HWS_PGA_GEN7;
break;
case VECS:
- mmio = VEBOX_HWS_PGA_GEN7;
+ hwsp = VEBOX_HWS_PGA_GEN7;
break;
}
} else if (IS_GEN(dev_priv, 6)) {
- mmio = RING_HWS_PGA_GEN6(engine->mmio_base);
+ hwsp = RING_HWS_PGA_GEN6(engine->mmio_base);
} else {
- mmio = RING_HWS_PGA(engine->mmio_base);
+ hwsp = RING_HWS_PGA(engine->mmio_base);
}
- if (INTEL_GEN(dev_priv) >= 6) {
- u32 mask = ~0u;
+ I915_WRITE(hwsp, offset);
+ POSTING_READ(hwsp);
+}
- /*
-* Keep the render interrupt unmasked as this papers over
-* lost interrupts following a reset.
-*/
- if (engine->id == RCS)
- mask &= ~BIT(0);
+static void __set_hwstam(struct intel_engine_cs *engine, u32 mask)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ i915_reg_t hwstam = RING_HWSTAM(engine->mmio_base);
+
+ if (INTEL_GEN(dev_priv) >= 3)
+ I915_WRITE(hwstam, mask);
+ else
+ I915_WRITE16(hwstam, mask);
+}
- I915_WRITE(RING_HWSTAM(engine->mmio_base), mask);
+static void set_hwstam(struct intel_engine_cs *engine, u32 mask)
+{
+ /*
+* Keep the render interrupt unmasked as this papers over
+* lost interrupts following a reset.
+
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Quoting Chris Wilson (2018-12-13 12:07:35)
> Quoting Ville Syrjälä (2018-12-13 11:59:28)
> > On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > > Having completed a test run of gem_eio across all machines in CI we also
> > > observe the phenomenon (of lost interrupts after resetting the GPU) on
> > > gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> > > the same HWSTAM workaround that was effective for gen6+ for all, as
> > > although we haven't seen the same failure on gen4/5 it seems prudent to
> > > keep the code the same.
> > >
> > > As a consequence we can remove the extra setting of HWSTAM and apply the
> > > register from a single site.
> > >
> > > v2: Delazy and move the HWSTAM into its own function
> > >
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> > > Signed-off-by: Chris Wilson
> > > Cc: Tvrtko Ursulin
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 9 --
> > > drivers/gpu/drm/i915/intel_ringbuffer.c | 41 -
> > > 2 files changed, 27 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index e2dac9b5f4ce..0c7fc9890891 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device
> > > *dev)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > >
> > > - if (IS_GEN(dev_priv, 5))
> > > - I915_WRITE(HWSTAM, 0x);
> > > -
> > > GEN3_IRQ_RESET(DE);
> > > if (IS_GEN(dev_priv, 7))
> > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE16(HWSTAM, 0x);
> > > -
> > > GEN2_IRQ_RESET();
> > > }
> > >
> > > @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE(HWSTAM, 0x);
> > > -
> > > GEN3_IRQ_RESET();
> > > }
> > >
> > > @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE(HWSTAM, 0x);
> > > -
> > > GEN3_IRQ_RESET();
> > > }
> >
> > So we're not worried about enabling interrupts and having
> > something unmasked in HWSTAM by accident before we have the
> > status page set up?
>
> Sanitization of the HWSP setup would be off during early engine setup.
> We do the irq install & reset during i915_load_modeset_init after we do
> the status page setup. Unless I'm mistaken, moving the HWSTAM alongside
> HWSP moves the sanitisation earlier.
More aptly though, we should reset the mask on unload. Which should be
taken care of by issuing a GPU reset. But in any case probably wise to
make sure all writes are masked off.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/3] ACPI / PMIC: Implement exec_mipi_pmic_seq_element for CHT Whiskey Cove PMIC
On Thu, Dec 13, 2018 at 12:21:35PM +0100, Hans de Goede wrote:
> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> PMIC.
>
> On some CHT devices this fixes the LCD panel not lighting up when it was
> not initialized by the GOP, because an external monitor was plugged in and
> the GOP initialized only the external monitor.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> -Interpret data passed to the PMIC MIPI elements according to the docs
> instead of my own reverse engineered interpretation
> Changes in v3:
> -Use hex values for out of range checks
> -Make intel_cht_wc_exec_mipi_pmic_seq_element return errors
> ---
> drivers/acpi/pmic/intel_pmic_chtwc.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/acpi/pmic/intel_pmic_chtwc.c
> b/drivers/acpi/pmic/intel_pmic_chtwc.c
> index 078b0448f30a..8ede74e9b89f 100644
> --- a/drivers/acpi/pmic/intel_pmic_chtwc.c
> +++ b/drivers/acpi/pmic/intel_pmic_chtwc.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include "intel_pmic.h"
>
> #define CHT_WC_V1P05A_CTRL 0x6e3b
> @@ -231,6 +232,29 @@ static int intel_cht_wc_pmic_update_power(struct regmap
> *regmap, int reg,
> return regmap_update_bits(regmap, reg, bitmask, on ? 1 : 0);
> }
>
> +static int intel_cht_wc_exec_mipi_pmic_seq_element(struct regmap *regmap,
> +const u8 *data)
> +{
> + u32 value, mask, reg_address, address;
> + u16 i2c_client_address;
> +
> + /* byte 0 aka PMIC Flag is reserved */
> + i2c_client_address = get_unaligned_le16(data + 1);
> + reg_address = get_unaligned_le32(data + 3);
> + value = get_unaligned_le32(data + 7);
> + mask= get_unaligned_le32(data + 11);
Upon further reflection maybe it would better to do this decoding in
the i915 code and just pass each parameter to this hook separately?
That way we wouldn't be spreading the vbt details all over the place.
> +
> + if (i2c_client_address > 0xff || reg_address > 0xff) {
> + pr_warn("%s warning addresses too big client 0x%x reg 0x%x\n",
> + __func__, i2c_client_address, reg_address);
> + return -ERANGE;
> + }
> +
> + address = (i2c_client_address << 8) | reg_address;
> +
> + return regmap_update_bits(regmap, address, mask, value);
> +}
> +
> /*
> * The thermal table and ops are empty, we do not support the Thermal
> opregion
> * (DPTF) due to lacking documentation.
> @@ -238,6 +262,7 @@ static int intel_cht_wc_pmic_update_power(struct regmap
> *regmap, int reg,
> static struct intel_pmic_opregion_data intel_cht_wc_pmic_opregion_data = {
> .get_power = intel_cht_wc_pmic_get_power,
> .update_power = intel_cht_wc_pmic_update_power,
> + .exec_mipi_pmic_seq_element = intel_cht_wc_exec_mipi_pmic_seq_element,
> .power_table= power_table,
> .power_table_count = ARRAY_SIZE(power_table),
> };
> --
> 2.19.2
--
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 06/10] drm/syncobj: use the timeline point in drm_syncobj_find_fence v3
Am 13.12.18 um 12:37 schrieb Chris Wilson:
> Quoting Chunming Zhou (2018-12-11 10:34:45)
>> From: Christian König
>>
>> Implement finding the right timeline point in drm_syncobj_find_fence.
>>
>> v2: return -EINVAL when the point is not submitted yet.
>> v3: fix reference counting bug, add flags handling as well
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/drm_syncobj.c | 43 ---
>> 1 file changed, 40 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
>> index 76ce13dafc4d..d964b348ecba 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -231,16 +231,53 @@ int drm_syncobj_find_fence(struct drm_file
>> *file_private,
>> struct dma_fence **fence)
>> {
>> struct drm_syncobj *syncobj = drm_syncobj_find(file_private,
>> handle);
>> - int ret = 0;
>> + struct syncobj_wait_entry wait;
>> + int ret;
>>
>> if (!syncobj)
>> return -ENOENT;
>>
>> *fence = drm_syncobj_fence_get(syncobj);
>> - if (!*fence) {
>> + drm_syncobj_put(syncobj);
>> +
>> + if (*fence) {
>> + ret = dma_fence_chain_find_seqno(fence, point);
>> + if (!ret)
>> + return 0;
>> + dma_fence_put(*fence);
>> + } else {
>> ret = -EINVAL;
>> }
>> - drm_syncobj_put(syncobj);
>> +
>> + if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
>> + return ret;
>> +
>> + memset(&wait, 0, sizeof(wait));
>> + wait.task = current;
>> + wait.point = point;
>> + drm_syncobj_fence_add_wait(syncobj, &wait);
>> +
>> + do {
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + if (wait.fence) {
>> + ret = 0;
>> + break;
>> + }
>> +
>> + if (signal_pending(current)) {
>> + ret = -ERESTARTSYS;
>> + break;
>> + }
>> +
>> + schedule();
>> + } while (1);
> I've previously used a dma_fence_proxy so that we could do nonblocking
> waits on future submits. That would be preferrable (a requirement for
> our stupid BKL-driven code).
That is exactly what I would definitely NAK.
I would rather say we should come up with a wait_multiple_events() macro
and completely nuke the custom implementation of this in:
1. dma_fence_default_wait and dma_fence_wait_any_timeout
2. the radeon fence implementation
3. the nouveau fence implementation
4. the syncobj code
Cause all of them do exactly the same. The dma_fence implementation
unfortunately came up with a custom event handling mechanism instead of
extending the core Linux wait_event() system.
This in turn lead to a lot of this duplicated handling.
Christian.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Quoting Ville Syrjälä (2018-12-13 11:59:28)
> On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> > Having completed a test run of gem_eio across all machines in CI we also
> > observe the phenomenon (of lost interrupts after resetting the GPU) on
> > gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> > the same HWSTAM workaround that was effective for gen6+ for all, as
> > although we haven't seen the same failure on gen4/5 it seems prudent to
> > keep the code the same.
> >
> > As a consequence we can remove the extra setting of HWSTAM and apply the
> > register from a single site.
> >
> > v2: Delazy and move the HWSTAM into its own function
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 9 --
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 41 -
> > 2 files changed, 27 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index e2dac9b5f4ce..0c7fc9890891 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >
> > - if (IS_GEN(dev_priv, 5))
> > - I915_WRITE(HWSTAM, 0x);
> > -
> > GEN3_IRQ_RESET(DE);
> > if (IS_GEN(dev_priv, 7))
> > I915_WRITE(GEN7_ERR_INT, 0x);
> > @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
> >
> > i9xx_pipestat_irq_reset(dev_priv);
> >
> > - I915_WRITE16(HWSTAM, 0x);
> > -
> > GEN2_IRQ_RESET();
> > }
> >
> > @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
> >
> > i9xx_pipestat_irq_reset(dev_priv);
> >
> > - I915_WRITE(HWSTAM, 0x);
> > -
> > GEN3_IRQ_RESET();
> > }
> >
> > @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
> >
> > i9xx_pipestat_irq_reset(dev_priv);
> >
> > - I915_WRITE(HWSTAM, 0x);
> > -
> > GEN3_IRQ_RESET();
> > }
>
> So we're not worried about enabling interrupts and having
> something unmasked in HWSTAM by accident before we have the
> status page set up?
Sanitization of the HWSP setup would be off during early engine setup.
We do the irq install & reset during i915_load_modeset_init after we do
the status page setup. Unless I'm mistaken, moving the HWSTAM alongside
HWSP moves the sanitisation earlier.
The only question then is order inside the HWSP setup, and the
suggestion would be to make sure the HWSP is set before the HWSTAM to be
safe on the bits we control.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/4] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests
From: Lionel Landwerlin
Verify that the per-context dynamic SSEU uAPI works as expected.
v2: Add subslice tests (Lionel)
Use MI_SET_PREDICATE for further verification when available (Lionel)
v3: Rename to gem_ctx_rpcs (Lionel)
v4: Update kernel API (Lionel)
Add 0 value test (Lionel)
Exercise invalid values (Lionel)
v5: Add perf tests (Lionel)
v6: Add new sysfs entry tests (Lionel)
v7: Test rsvd fields
Update for kernel series changes
v8: Drop test_no_sseu_support() test (Kelvin)
Drop drm_intel_*() apis (Chris)
v9: by Chris:
Drop all do_ioctl/do_ioctl_err()
Use gem_context_[gs]et_param()
Use gem_read() instead of mapping memory
by Lionel:
Test dynamic sseu on/off more
Tvrtko Ursulin:
v10:
* Various style tweaks and refactorings.
* New test coverage.
v11:
* Change platform support to just Gen11.
* Simplify availability test. (Chris Wilson)
* More invalid pointer tests. (Chris Wilson)
v12:
* Fix MAP_FIXED use (doh!).
* Fix get/set copy&paste errors.
* Drop supported platform test. (Chris Wilson)
* Add mmap__gtt test. (Chris Wilson)
v13:
* Commit message tweaks.
* Added reset/hang/suspend tests. (Chris Wilson)
* Assert spinner is busy. (Chris Wilson)
* Remove some more ABI assumptions. (Chris Wilson)
v14:
* Use default resume time. (Chris Wilson)
* Trigger hang after rpcs read batch has been submitted. (Chris Wilson)
v15:
* Adjust for uAPI restrictions.
v16:
* Build system changes.
v17:
* Remove all subtests which read the RPCS register. (Joonas Lahtinen)
v18:
* Tidy curly braces. (Joonas Lahtinen)
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v14
Reviewed-by: Joonas Lahtinen
---
tests/Makefile.am | 1 +
tests/Makefile.sources | 3 +
tests/i915/gem_ctx_param.c | 4 +-
tests/i915/gem_ctx_sseu.c | 532 +
tests/meson.build | 8 +
5 files changed, 547 insertions(+), 1 deletion(-)
create mode 100644 tests/i915/gem_ctx_sseu.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 48d77535b6bd..42463bde7f30 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -111,6 +111,7 @@ gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_close_race_LDADD = $(LDADD) -lpthread
gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_ctx_thrash_LDADD = $(LDADD) -lpthread
+gem_ctx_sseu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
gem_exec_capture_LDADD = $(LDADD) -lz
gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_exec_parallel_LDADD = $(LDADD) -lpthread
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index eedde1e817cb..3dfeb5b67274 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -161,6 +161,9 @@ gem_ctx_isolation_SOURCES = i915/gem_ctx_isolation.c
TESTS_progs += gem_ctx_param
gem_ctx_param_SOURCES = i915/gem_ctx_param.c
+TESTS_progs += gem_ctx_sseu
+gem_ctx_sseu_SOURCES = i915/gem_ctx_sseu.c
+
TESTS_progs += gem_ctx_switch
gem_ctx_switch_SOURCES = i915/gem_ctx_switch.c
diff --git a/tests/i915/gem_ctx_param.c b/tests/i915/gem_ctx_param.c
index 0bbc5effbf9f..acc1e6297750 100644
--- a/tests/i915/gem_ctx_param.c
+++ b/tests/i915/gem_ctx_param.c
@@ -294,11 +294,13 @@ igt_main
set_priority(fd);
}
+ /* I915_CONTEXT_PARAM_SSEU tests are located in gem_ctx_sseu.c */
+
/* NOTE: This testcase intentionally tests for the next free parameter
* to catch ABI extensions. Don't "fix" this testcase without adding all
* the tests for the new param first.
*/
- arg.param = I915_CONTEXT_PARAM_PRIORITY + 1;
+ arg.param = I915_CONTEXT_PARAM_SSEU + 1;
igt_subtest("invalid-param-get") {
arg.ctx_id = ctx;
diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
new file mode 100644
index ..b5d5910ec128
--- /dev/null
+++ b/tests/i915/gem_ctx_sseu.c
@@ -0,0 +1,532 @@
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ *
[Intel-gfx] [PATCH i-g-t 0/4] Per context dynamic (sub)slice power-gating
From: Tvrtko Ursulin Tests to accompany the respective i915 series. Contributed by Tony Ye is a new test, gem_media_vme, which exercises the media VME block to demonstrate the effectiveness of the uAPI for this particular issue. New in this version is the source code for the VME kernel and some other small tweaks. Lionel Landwerlin (1): tests/gem_ctx_sseu: Dynamic (sub)slice programming tests Tony Ye (2): tests/gem_media_vme: Simple test to exercise the VME block tests/gem_media_vme: Shut down half of subslices to avoid gpu hang on ICL Tvrtko Ursulin (1): headers: bump include/drm-uapi/drm_mode.h | 19 + include/drm-uapi/i915_drm.h | 43 ++ include/drm-uapi/msm_drm.h | 25 +- include/drm-uapi/v3d_drm.h | 33 ++ lib/gpu_cmds.c | 148 ++ lib/gpu_cmds.h | 23 +- lib/i915/shaders/media/README_media_vme.txt | 65 +++ lib/i915/shaders/media/media_vme.gxa| 51 ++ lib/intel_batchbuffer.c | 9 + lib/intel_batchbuffer.h | 7 + lib/media_fill.c| 110 lib/media_fill.h| 6 + lib/surfaceformat.h | 2 + tests/Makefile.am | 1 + tests/Makefile.sources | 6 + tests/i915/gem_ctx_param.c | 4 +- tests/i915/gem_ctx_sseu.c | 532 tests/i915/gem_media_vme.c | 178 +++ tests/meson.build | 9 + 19 files changed, 1262 insertions(+), 9 deletions(-) create mode 100755 lib/i915/shaders/media/README_media_vme.txt create mode 100755 lib/i915/shaders/media/media_vme.gxa create mode 100644 tests/i915/gem_ctx_sseu.c create mode 100644 tests/i915/gem_media_vme.c -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/4] tests/gem_media_vme: Shut down half of subslices to avoid gpu hang on ICL
From: Tony Ye
On Icelake we need to turn off subslices not containing the VME block or
the VME kernel will hang.
v2: (Tvrtko Ursulin)
* Remove libdrm usage for setting context param.
* Cleanup bitmask operation.
* Only apply the workaround for ICL.
v3: (Tvrtko Ursulin)
* Added hang detector. (Chris Wilson)
v4: (Tvrtko Ursulin)
* Rebase for hang detector moved to previous patch.
* Tidy curly braces.
Signed-off-by: Tony Ye
Signed-off-by: Tvrtko Ursulin
Cc: Tony Ye
---
lib/gpu_cmds.c | 12
lib/gpu_cmds.h | 3 ++
lib/media_fill.c | 2 +-
tests/i915/gem_media_vme.c | 60 ++
4 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/lib/gpu_cmds.c b/lib/gpu_cmds.c
index b490a63bdfef..8d270ee86229 100644
--- a/lib/gpu_cmds.c
+++ b/lib/gpu_cmds.c
@@ -36,6 +36,18 @@ gen7_render_flush(struct intel_batchbuffer *batch, uint32_t
batch_end)
igt_assert(ret == 0);
}
+void
+gen7_render_context_flush(struct intel_batchbuffer *batch, uint32_t batch_end)
+{
+ int ret;
+
+ ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
+ if (ret == 0)
+ ret = drm_intel_gem_bo_context_exec(batch->bo, batch->ctx,
+ batch_end, 0);
+ igt_assert(ret == 0);
+}
+
uint32_t
gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
uint8_t color)
diff --git a/lib/gpu_cmds.h b/lib/gpu_cmds.h
index ca671fb52daf..1321af446161 100644
--- a/lib/gpu_cmds.h
+++ b/lib/gpu_cmds.h
@@ -40,6 +40,9 @@
void
gen7_render_flush(struct intel_batchbuffer *batch, uint32_t batch_end);
+void
+gen7_render_context_flush(struct intel_batchbuffer *batch, uint32_t batch_end);
+
uint32_t
gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
uint8_t color);
diff --git a/lib/media_fill.c b/lib/media_fill.c
index b1e84727394a..03b5e71e101b 100644
--- a/lib/media_fill.c
+++ b/lib/media_fill.c
@@ -338,7 +338,7 @@ __gen11_media_vme_func(struct intel_batchbuffer *batch,
batch_end = intel_batchbuffer_align(batch, 8);
assert(batch_end < BATCH_STATE_SPLIT);
- gen7_render_flush(batch, batch_end);
+ gen7_render_context_flush(batch, batch_end);
intel_batchbuffer_reset(batch);
}
diff --git a/tests/i915/gem_media_vme.c b/tests/i915/gem_media_vme.c
index 47e949c781f2..34383cb123d4 100644
--- a/tests/i915/gem_media_vme.c
+++ b/tests/i915/gem_media_vme.c
@@ -81,6 +81,52 @@ static void scratch_buf_init_dst(drm_intel_bufmgr *bufmgr,
struct igt_buf *buf)
buf->stride = 1;
}
+static uint64_t switch_off_n_bits(uint64_t mask, unsigned int n)
+{
+ unsigned int i;
+
+ igt_assert(n > 0 && n <= (sizeof(mask) * 8));
+ igt_assert(n <= __builtin_popcount(mask));
+
+ for (i = 0; n && i < (sizeof(mask) * 8); i++) {
+ uint64_t bit = 1ULL << i;
+
+ if (bit & mask) {
+ mask &= ~bit;
+ n--;
+ }
+ }
+
+ return mask;
+}
+
+static void shut_non_vme_subslices(int drm_fd, uint32_t ctx)
+{
+ struct drm_i915_gem_context_param_sseu sseu = { };
+ struct drm_i915_gem_context_param arg = {
+ .param = I915_CONTEXT_PARAM_SSEU,
+ .ctx_id = ctx,
+ .size = sizeof(sseu),
+ .value = to_user_pointer(&sseu),
+ };
+ int ret;
+
+ if (__gem_context_get_param(drm_fd, &arg))
+ return; /* no sseu support */
+
+ ret = __gem_context_set_param(drm_fd, &arg);
+ igt_assert(ret == 0 || ret == -ENODEV || ret == -EINVAL);
+ if (ret)
+ return; /* no sseu support */
+
+ /* shutdown half subslices*/
+ sseu.subslice_mask =
+ switch_off_n_bits(sseu.subslice_mask,
+ __builtin_popcount(sseu.subslice_mask) / 2);
+
+ gem_context_set_param(drm_fd, &arg);
+}
+
igt_simple_main
{
int drm_fd;
@@ -108,6 +154,20 @@ igt_simple_main
scratch_buf_init_src(bufmgr, &src);
scratch_buf_init_dst(bufmgr, &dst);
+ batch->ctx = drm_intel_gem_context_create(bufmgr);
+ igt_assert(batch->ctx);
+
+ /* ICL hangs if non-VME enabled slices are enabled with a VME kernel. */
+ if (intel_gen(devid) == 11) {
+ uint32_t ctx_id;
+ int ret;
+
+ ret = drm_intel_gem_context_get_id(batch->ctx, &ctx_id);
+ igt_assert_eq(ret, 0);
+
+ shut_non_vme_subslices(drm_fd, ctx_id);
+ }
+
igt_fork_hang_detector(drm_fd);
media_vme(batch, &src, WIDTH, HEIGHT, &dst);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/4] headers: bump
From: Tvrtko Ursulin
---
include/drm-uapi/drm_mode.h | 19
include/drm-uapi/i915_drm.h | 43 +
include/drm-uapi/msm_drm.h | 25 +++--
include/drm-uapi/v3d_drm.h | 33
4 files changed, 114 insertions(+), 6 deletions(-)
diff --git a/include/drm-uapi/drm_mode.h b/include/drm-uapi/drm_mode.h
index d3e0fe31efc5..a439c2e67896 100644
--- a/include/drm-uapi/drm_mode.h
+++ b/include/drm-uapi/drm_mode.h
@@ -888,6 +888,25 @@ struct drm_mode_revoke_lease {
__u32 lessee_id;
};
+/**
+ * struct drm_mode_rect - Two dimensional rectangle.
+ * @x1: Horizontal starting coordinate (inclusive).
+ * @y1: Vertical starting coordinate (inclusive).
+ * @x2: Horizontal ending coordinate (exclusive).
+ * @y2: Vertical ending coordinate (exclusive).
+ *
+ * With drm subsystem using struct drm_rect to manage rectangular area this
+ * export it to user-space.
+ *
+ * Currently used by drm_mode_atomic blob property FB_DAMAGE_CLIPS.
+ */
+struct drm_mode_rect {
+ __s32 x1;
+ __s32 y1;
+ __s32 x2;
+ __s32 y2;
+};
+
#if defined(__cplusplus)
}
#endif
diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index e39b26d4bb3d..6b43c34bc436 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -1486,9 +1486,52 @@ struct drm_i915_gem_context_param {
#define I915_CONTEXT_MAX_USER_PRIORITY 1023 /* inclusive */
#define I915_CONTEXT_DEFAULT_PRIORITY0
#define I915_CONTEXT_MIN_USER_PRIORITY -1023 /* inclusive */
+ /*
+* When using the following param, value should be a pointer to
+* drm_i915_gem_context_param_sseu.
+*/
+#define I915_CONTEXT_PARAM_SSEU0x7
__u64 value;
};
+struct drm_i915_gem_context_param_sseu {
+ /*
+* Engine class & instance to be configured or queried.
+*/
+ __u16 class;
+ __u16 instance;
+
+ /*
+* Unused for now. Must be cleared to zero.
+*/
+ __u32 rsvd1;
+
+ /*
+* Mask of slices to enable for the context. Valid values are a subset
+* of the bitmask value returned for I915_PARAM_SLICE_MASK.
+*/
+ __u64 slice_mask;
+
+ /*
+* Mask of subslices to enable for the context. Valid values are a
+* subset of the bitmask value return by I915_PARAM_SUBSLICE_MASK.
+*/
+ __u64 subslice_mask;
+
+ /*
+* Minimum/Maximum number of EUs to enable per subslice for the
+* context. min_eus_per_subslice must be inferior or equal to
+* max_eus_per_subslice.
+*/
+ __u16 min_eus_per_subslice;
+ __u16 max_eus_per_subslice;
+
+ /*
+* Unused for now. Must be cleared to zero.
+*/
+ __u32 rsvd2;
+};
+
enum drm_i915_oa_format {
I915_OA_FORMAT_A13 = 1, /* HSW only */
I915_OA_FORMAT_A29, /* HSW only */
diff --git a/include/drm-uapi/msm_drm.h b/include/drm-uapi/msm_drm.h
index c06d0a5bdd80..91a16b333c69 100644
--- a/include/drm-uapi/msm_drm.h
+++ b/include/drm-uapi/msm_drm.h
@@ -105,14 +105,24 @@ struct drm_msm_gem_new {
__u32 handle; /* out */
};
-#define MSM_INFO_IOVA 0x01
-
-#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
+/* Get or set GEM buffer info. The requested value can be passed
+ * directly in 'value', or for data larger than 64b 'value' is a
+ * pointer to userspace buffer, with 'len' specifying the number of
+ * bytes copied into that buffer. For info returned by pointer,
+ * calling the GEM_INFO ioctl with null 'value' will return the
+ * required buffer size in 'len'
+ */
+#define MSM_INFO_GET_OFFSET0x00 /* get mmap() offset, returned by value
*/
+#define MSM_INFO_GET_IOVA 0x01 /* get iova, returned by value */
+#define MSM_INFO_SET_NAME 0x02 /* set the debug name (by pointer) */
+#define MSM_INFO_GET_NAME 0x03 /* get debug name, returned by pointer */
struct drm_msm_gem_info {
__u32 handle; /* in */
- __u32 flags; /* in - combination of MSM_INFO_* flags */
- __u64 offset; /* out, mmap() offset or iova */
+ __u32 info; /* in - one of MSM_INFO_* */
+ __u64 value; /* in or out */
+ __u32 len;/* in or out */
+ __u32 pad;
};
#define MSM_PREP_READ0x01
@@ -188,8 +198,11 @@ struct drm_msm_gem_submit_cmd {
*/
#define MSM_SUBMIT_BO_READ 0x0001
#define MSM_SUBMIT_BO_WRITE0x0002
+#define MSM_SUBMIT_BO_DUMP 0x0004
-#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ |
MSM_SUBMIT_BO_WRITE)
+#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ | \
+ MSM_SUBMIT_BO_WRITE | \
+ MSM_SUBMIT_BO_DUMP)
struct drm_msm_gem_submit_bo {
__u32 flags; /* in, mask of M
[Intel-gfx] [PATCH i-g-t 3/4] tests/gem_media_vme: Simple test to exercise the VME block
From: Tony Ye
Simple test which exercises the VME fixed function block.
v2: (Tvrtko Ursulin)
* Small cleanups like copyright date, tabs, remove unused bits.
v3: (Tony Ye)
* Added curbe data entry for dst surface.
* Read the dst surface after the VME kernel being executed.
v4: (Tony Ye)
* Added the media_vme.gxa kernel source code and compile instructions.
v5: (Tvrtko Ursulin)
* Added hang detector.
Signed-off-by: Tony Ye
Signed-off-by: Tvrtko Ursulin
Cc: Tony Ye
---
lib/gpu_cmds.c | 136
lib/gpu_cmds.h | 20 ++-
lib/i915/shaders/media/README_media_vme.txt | 65 ++
lib/i915/shaders/media/media_vme.gxa| 51
lib/intel_batchbuffer.c | 9 ++
lib/intel_batchbuffer.h | 7 +
lib/media_fill.c| 110
lib/media_fill.h| 6 +
lib/surfaceformat.h | 2 +
tests/Makefile.sources | 3 +
tests/i915/gem_media_vme.c | 118 +
tests/meson.build | 1 +
12 files changed, 526 insertions(+), 2 deletions(-)
create mode 100755 lib/i915/shaders/media/README_media_vme.txt
create mode 100755 lib/i915/shaders/media/media_vme.gxa
create mode 100644 tests/i915/gem_media_vme.c
diff --git a/lib/gpu_cmds.c b/lib/gpu_cmds.c
index 556a94c6f0b6..b490a63bdfef 100644
--- a/lib/gpu_cmds.c
+++ b/lib/gpu_cmds.c
@@ -52,6 +52,22 @@ gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
return offset;
}
+uint32_t
+gen11_fill_curbe_buffer_data(struct intel_batchbuffer *batch)
+{
+ uint32_t *curbe_buffer;
+ uint32_t offset;
+
+ curbe_buffer = intel_batchbuffer_subdata_alloc(batch,
+ sizeof(uint32_t) * 8,
+ 64);
+ offset = intel_batchbuffer_subdata_offset(batch, curbe_buffer);
+ *curbe_buffer++ = 0;
+ *curbe_buffer = 1;
+
+ return offset;
+}
+
uint32_t
gen7_fill_surface_state(struct intel_batchbuffer *batch,
const struct igt_buf *buf,
@@ -119,6 +135,26 @@ gen7_fill_binding_table(struct intel_batchbuffer *batch,
return offset;
}
+uint32_t
+gen11_fill_binding_table(struct intel_batchbuffer *batch,
+ const struct igt_buf *src,const struct igt_buf *dst)
+{
+ uint32_t *binding_table, offset;
+
+ binding_table = intel_batchbuffer_subdata_alloc(batch, 64, 64);
+ offset = intel_batchbuffer_subdata_offset(batch, binding_table);
+ binding_table[0] = gen11_fill_surface_state(batch, src,
+
SURFACE_1D,SURFACEFORMAT_R32G32B32A32_FLOAT,
+ 0,0,
+ 0);
+ binding_table[1] = gen11_fill_surface_state(batch, dst,
+ SURFACE_BUFFER,
SURFACEFORMAT_RAW,
+ 1,1,
+ 1);
+
+ return offset;
+}
+
uint32_t
gen7_fill_kernel(struct intel_batchbuffer *batch,
const uint32_t kernel[][4],
@@ -384,6 +420,71 @@ gen8_fill_surface_state(struct intel_batchbuffer *batch,
return offset;
}
+uint32_t
+gen11_fill_surface_state(struct intel_batchbuffer *batch,
+ const struct igt_buf *buf,
+ uint32_t surface_type,
+ uint32_t format,
+ uint32_t vertical_alignment,
+ uint32_t horizontal_alignment,
+ int is_dst)
+{
+ struct gen8_surface_state *ss;
+ uint32_t write_domain, read_domain, offset;
+ int ret;
+
+ if (is_dst) {
+ write_domain = read_domain = I915_GEM_DOMAIN_RENDER;
+ } else {
+ write_domain = 0;
+ read_domain = I915_GEM_DOMAIN_SAMPLER;
+ }
+
+ ss = intel_batchbuffer_subdata_alloc(batch, sizeof(*ss), 64);
+ offset = intel_batchbuffer_subdata_offset(batch, ss);
+
+ ss->ss0.surface_type = surface_type;
+ ss->ss0.surface_format = format;
+ ss->ss0.render_cache_read_write = 1;
+ ss->ss0.vertical_alignment = vertical_alignment; /* align 4 */
+ ss->ss0.horizontal_alignment = horizontal_alignment; /* align 4 */
+
+ if (buf->tiling == I915_TILING_X)
+ ss->ss0.tiled_mode = 2;
+ else if (buf->tiling == I915_TILING_Y)
+ ss->ss0.tiled_mode = 3;
+ else
+ ss->ss0.tiled_mode = 0;
+
+ ss->ss8.base_addr = buf->bo->offset;
+
+ ret = drm_intel_bo_emit_reloc(batch->bo,
+ intel_batchbuffer_subdata_offset(batch, ss) + 8
* 4,
+ buf->bo, 0, r
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
On Thu, Dec 13, 2018 at 11:01:05AM +, Chris Wilson wrote:
> Having completed a test run of gem_eio across all machines in CI we also
> observe the phenomenon (of lost interrupts after resetting the GPU) on
> gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> the same HWSTAM workaround that was effective for gen6+ for all, as
> although we haven't seen the same failure on gen4/5 it seems prudent to
> keep the code the same.
>
> As a consequence we can remove the extra setting of HWSTAM and apply the
> register from a single site.
>
> v2: Delazy and move the HWSTAM into its own function
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_irq.c | 9 --
> drivers/gpu/drm/i915/intel_ringbuffer.c | 41 -
> 2 files changed, 27 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index e2dac9b5f4ce..0c7fc9890891 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
>
> - if (IS_GEN(dev_priv, 5))
> - I915_WRITE(HWSTAM, 0x);
> -
> GEN3_IRQ_RESET(DE);
> if (IS_GEN(dev_priv, 7))
> I915_WRITE(GEN7_ERR_INT, 0x);
> @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
>
> i9xx_pipestat_irq_reset(dev_priv);
>
> - I915_WRITE16(HWSTAM, 0x);
> -
> GEN2_IRQ_RESET();
> }
>
> @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
>
> i9xx_pipestat_irq_reset(dev_priv);
>
> - I915_WRITE(HWSTAM, 0x);
> -
> GEN3_IRQ_RESET();
> }
>
> @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
>
> i9xx_pipestat_irq_reset(dev_priv);
>
> - I915_WRITE(HWSTAM, 0x);
> -
> GEN3_IRQ_RESET();
> }
So we're not worried about enabling interrupts and having
something unmasked in HWSTAM by accident before we have the
status page set up?
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index fdeca2b877c9..10e7b7a6ba88 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -393,12 +393,38 @@ static void ring_setup_phys_status_page(struct
> intel_engine_cs *engine)
> I915_WRITE(HWS_PGA, addr);
> }
>
> +static void set_hwstam_mask(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *dev_priv = engine->i915;
> + i915_reg_t hwstam = RING_HWSTAM(engine->mmio_base);
> + u32 mask = ~0u;
> +
> + /*
> + * Keep the render interrupt unmasked as this papers over
> + * lost interrupts following a reset.
> + */
> + if (engine->id == RCS) {
> + if (INTEL_GEN(dev_priv) >= 6)
> + mask &= ~BIT(0);
> + else
> + mask &= ~I915_USER_INTERRUPT;
> + }
> +
> + if (INTEL_GEN(dev_priv) >= 3)
> + I915_WRITE(hwstam, mask);
> + else
> + I915_WRITE16(hwstam, mask);
> +}
> +
> static void intel_ring_setup_status_page(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *dev_priv = engine->i915;
> i915_reg_t mmio;
>
> - /* The ring status page addresses are no longer next to the rest of
> + set_hwstam_mask(engine);
> +
> + /*
> + * The ring status page addresses are no longer next to the rest of
>* the ring registers as of gen7.
>*/
> if (IS_GEN(dev_priv, 7)) {
> @@ -428,19 +454,6 @@ static void intel_ring_setup_status_page(struct
> intel_engine_cs *engine)
> mmio = RING_HWS_PGA(engine->mmio_base);
> }
>
> - if (INTEL_GEN(dev_priv) >= 6) {
> - u32 mask = ~0u;
> -
> - /*
> - * Keep the render interrupt unmasked as this papers over
> - * lost interrupts following a reset.
> - */
> - if (engine->id == RCS)
> - mask &= ~BIT(0);
> -
> - I915_WRITE(RING_HWSTAM(engine->mmio_base), mask);
> - }
> -
> I915_WRITE(mmio, engine->status_page.ggtt_offset);
> POSTING_READ(mmio);
>
> --
> 2.20.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] igt/amdgpu_amd_prime: Bail if we fail to create more contexts
amdgpu has started to report out of space after creating a few contexts.
This is not the scope of this test as here we just verifying that fences
created in amd can be imported and used for synchronisation by i915 and
for that we just need at least one context created!
References: https://bugs.freedesktop.org/show_bug.cgi?id=109049
Signed-off-by: Chris Wilson
---
tests/amdgpu/amd_prime.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu/amd_prime.c
index bda0ce83d..518c88963 100644
--- a/tests/amdgpu/amd_prime.c
+++ b/tests/amdgpu/amd_prime.c
@@ -354,8 +354,8 @@ static void amd_to_i915(int i915, int amd,
amdgpu_device_handle device)
contexts = realloc(contexts, size * sizeof(*contexts));
}
- r = amdgpu_cs_ctx_create(device, &contexts[count]);
- igt_assert_eq(r, 0);
+ if (amdgpu_cs_ctx_create(device, &contexts[count]))
+ break;
r = amdgpu_cs_submit(contexts[count], 0, &ibs_request, 1);
igt_assert_eq(r, 0);
@@ -364,6 +364,7 @@ static void amd_to_i915(int i915, int amd,
amdgpu_device_handle device)
}
igt_info("Reservation width = %ld\n", count);
+ igt_require(count);
amdgpu_bo_export(ib_result_handle,
amdgpu_bo_handle_type_dma_buf_fd,
--
2.20.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev2)
== Series Details ==
Series: drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
(rev2)
URL : https://patchwork.freedesktop.org/series/53979/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5311 -> Patchwork_11084
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_11084 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_11084, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53979/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_11084:
### IGT changes ###
Possible regressions
* igt@pm_rpm@basic-rte:
- fi-byt-n2820: PASS -> FAIL
- fi-byt-j1900: PASS -> FAIL
Warnings
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: PASS -> SKIP
- fi-byt-n2820: PASS -> SKIP
Known issues
Here are the changes found in Patchwork_11084 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* {igt@runner@aborted}:
- fi-icl-y: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-kbl-7560u: INCOMPLETE [fdo#103665] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Participating hosts (47 -> 44)
--
Additional (1): fi-icl-y
Missing(4): fi-kbl-soraka fi-ctg-p8600 fi-byt-squawks fi-ilk-m540
Build changes
-
* Linux: CI_DRM_5311 -> Patchwork_11084
CI_DRM_5311: a42fd8bf199784ee4ff1cdb5ee03eedd9a535d4a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4746: 2c793666d8c8328733f5769b16ae5858fee97f3f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_11084: faea0cabad7732d0ac7d3554897f08b42cbf517e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
faea0cabad77 drm/i915: Apply missed interrupt after reset w/a to all ringbuffer
gen
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11084/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
