[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] dma-buf: change DMA-buf locking convention v2
== Series Details ==
Series: series starting with [1/4] dma-buf: change DMA-buf locking convention v2
URL : https://patchwork.freedesktop.org/series/68330/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7144_full -> Patchwork_14908_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14908_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14908_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_14908_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock_requests:
- shard-glk: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-glk2/igt@i915_selftest@mock_requests.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-glk4/igt@i915_selftest@mock_requests.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
- {shard-tglb}: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-tglb3/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html
* igt@gem_persistent_relocs@forked-interruptible-thrashing:
- {shard-tglb}: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-tglb6/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-cpu:
- {shard-tglb}: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-tglb2/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-mmap-cpu.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-tglb4/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-shrfb-draw-mmap-cpu.html
Known issues
Here are the changes found in Patchwork_14908_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@bcs0-s3:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-apl4/igt@gem_ctx_isolat...@bcs0-s3.html
* igt@gem_ctx_isolation@vcs0-s3:
- shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103665])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-kbl6/igt@gem_ctx_isolat...@vcs0-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-kbl4/igt@gem_ctx_isolat...@vcs0-s3.html
* igt@gem_ctx_shared@q-smoketest-bsd2:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +11 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-iclb4/igt@gem_ctx_sha...@q-smoketest-bsd2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-iclb8/igt@gem_ctx_sha...@q-smoketest-bsd2.html
* igt@gem_ctx_switch@vcs1-heavy-queue:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112080]) +9 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-iclb2/igt@gem_ctx_swi...@vcs1-heavy-queue.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-iclb8/igt@gem_ctx_swi...@vcs1-heavy-queue.html
* igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#111325]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-iclb6/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-iclb1/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-hsw: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-hsw1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shard-hsw1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-snb: [PASS][19] -> [DMESG-WARN][20] ([fdo#111870]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/shard-snb7/igt@gem_userptr_bl...@sync-unmap-cycles.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/shar
[Intel-gfx] ✓ Fi.CI.BAT: success for DP MST Refactors + debugging tools + suspend/resume reprobing
== Series Details ==
Series: DP MST Refactors + debugging tools + suspend/resume reprobing
URL : https://patchwork.freedesktop.org/series/68359/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7144 -> Patchwork_14911
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14911:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-cfl-8109u: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-cfl-8109u/igt@i915_selftest@live_gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-cfl-8109u/igt@i915_selftest@live_gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_14911 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@bad-open:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@gem_flink_ba...@bad-open.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-icl-u3/igt@gem_flink_ba...@bad-open.html
Possible fixes
* igt@gem_mmap@basic:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@gem_m...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-icl-u3/igt@gem_m...@basic.html
* igt@i915_selftest@live_execlists:
- fi-icl-u2: [DMESG-FAIL][7] ([fdo#112046]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u2/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-icl-u2/igt@i915_selftest@live_execlists.html
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-cml-u: [DMESG-FAIL][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_hangcheck:
- {fi-tgl-u2}:[INCOMPLETE][11] ([fdo#111747]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-tgl-u2/igt@i915_selftest@live_hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-tgl-u2/igt@i915_selftest@live_hangcheck.html
- {fi-icl-dsi}: [INCOMPLETE][13] ([fdo#107713] / [fdo#108569]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [FAIL][16] ([fdo#111045]
/ [fdo#111096])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14911/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111747]: https://bugs.freedesktop.org/show_bug.cgi?id=111747
[fdo#112046]: https://bugs.freedesktop.org/show_bug.cgi?id=112046
[fdo#112055]: https://bugs.freedesktop.org/show_bug.cgi?id=112055
Participating hosts (52 -> 46)
--
Additional (1): fi-kbl-soraka
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7144 -> Patchwork_14911
CI-20190529: 20190529
CI_DRM_7144: 5a109994e39e3c50909199ed6e970219155b5471 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @
git://anongit.freedesktop.org/xorg/app/inte
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DP MST Refactors + debugging tools + suspend/resume reprobing
== Series Details == Series: DP MST Refactors + debugging tools + suspend/resume reprobing URL : https://patchwork.freedesktop.org/series/68359/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/dp_mst: Destroy MSTBs asynchronously Okay! Commit: drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and refactor Okay! Commit: drm/dp_mst: Refactor pdt setup/teardown, add more locking Okay! Commit: drm/dp_mst: Handle UP requests asynchronously Okay! Commit: drm/dp_mst: Add probe_lock + ^~~ +drivers/gpu/drm/drm_dp_mst_topology.c:2178:21: warning: unused variable ‘dev’ [-Wunused-variable] +drivers/gpu/drm/drm_dp_mst_topology.c: In function ‘drm_dp_mst_link_probe_work’: + struct drm_device *dev = mgr->dev; Commit: drm/dp_mst: Protect drm_dp_mst_port members with locking - ^~~ -drivers/gpu/drm/drm_dp_mst_topology.c:2244:21: warning: unused variable ‘dev’ [-Wunused-variable] -drivers/gpu/drm/drm_dp_mst_topology.c: In function ‘drm_dp_mst_link_probe_work’: - struct drm_device *dev = mgr->dev; Commit: drm/dp_mst: Don't forget to update port->input in drm_dp_mst_handle_conn_stat() Okay! Commit: drm/dp_mst: Lessen indenting in drm_dp_mst_topology_mgr_resume() Okay! Commit: drm/nouveau: Don't grab runtime PM refs for HPD IRQs Okay! Commit: drm/nouveau: Resume hotplug interrupts earlier Okay! Commit: drm/amdgpu: Iterate through DRM connectors correctly -drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1919:24: warning: symbol 'dm_atomic_get_new_state' was not declared. Should it be static? -drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1937:24: warning: symbol 'dm_atomic_get_old_state' was not declared. Should it be static? -drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c::6: warning: symbol 'dm_drm_plane_destroy_state' was not declared. Should it be static? +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1922:24: warning: symbol 'dm_atomic_get_new_state' was not declared. Should it be static? +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:1940:24: warning: symbol 'dm_atomic_get_old_state' was not declared. Should it be static? +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4447:6: warning: symbol 'dm_drm_plane_destroy_state' was not declared. Should it be static? Commit: drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology Okay! Commit: drm/dp_mst: Add basic topology reprobing when resuming Okay! Commit: drm/dp_mst: Add topology ref history tracking for debugging 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 DP MST Refactors + debugging tools + suspend/resume reprobing
== Series Details ==
Series: DP MST Refactors + debugging tools + suspend/resume reprobing
URL : https://patchwork.freedesktop.org/series/68359/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dfa95c8ecbba drm/dp_mst: Destroy MSTBs asynchronously
-:313: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#313: FILE: include/drm/drm_dp_mst_helper.h:592:
+ struct mutex delayed_destroy_lock;
total: 0 errors, 0 warnings, 1 checks, 263 lines checked
ce25890ebeae drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and
refactor
bb814cd52770 drm/dp_mst: Refactor pdt setup/teardown, add more locking
8ccc1d69d33c drm/dp_mst: Handle UP requests asynchronously
01ea755bc87f drm/dp_mst: Add probe_lock
6ef467a9247f drm/dp_mst: Protect drm_dp_mst_port members with locking
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#9:
This is a complicated one. Essentially, there's currently a problem in the MST
total: 0 errors, 1 warnings, 0 checks, 635 lines checked
1c3c0e119049 drm/dp_mst: Don't forget to update port->input in
drm_dp_mst_handle_conn_stat()
5afcdf3d0133 drm/dp_mst: Lessen indenting in drm_dp_mst_topology_mgr_resume()
1e380e0d635f drm/nouveau: Don't grab runtime PM refs for HPD IRQs
-:43: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#43: FILE: drivers/gpu/drm/nouveau/nouveau_connector.c:1138:
+ if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP)))
-:66: ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#66: FILE: drivers/gpu/drm/nouveau/nouveau_connector.c:1166:
+ if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP))) {
total: 2 errors, 0 warnings, 0 checks, 48 lines checked
0f7f40f17cf0 drm/nouveau: Resume hotplug interrupts earlier
-:39: WARNING:LINE_SPACING: Missing a blank line after declarations
#39: FILE: drivers/gpu/drm/nouveau/nouveau_display.c:417:
+ struct nouveau_connector *conn = nouveau_connector(connector);
+ nvif_notify_get(&conn->hpd);
total: 0 errors, 1 warnings, 0 checks, 31 lines checked
b7d9bc12c03e drm/amdgpu: Iterate through DRM connectors correctly
58f9462ec3a8 drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology
2e43a68e1d76 drm/dp_mst: Add basic topology reprobing when resuming
-:211: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#211: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2261:
+static int drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_branch *mstb)
-:277: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#277: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:2581:
+static int drm_dp_send_link_address(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_branch *mstb)
total: 0 errors, 0 warnings, 2 checks, 373 lines checked
4e7abcd7af53 drm/dp_mst: Add topology ref history tracking for debugging
-:141: WARNING:RETURN_VOID: void function return statements are not generally
useful
#141: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1459:
+ return;
+}
-:185: WARNING:VSPRINTF_SPECIFIER_PX: Using vsprintf specifier '%px'
potentially exposes the kernel memory layout, if you don't really need the
address please consider using '%p'.
#185: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1503:
+ drm_printf(&p,
+ "%s (%p/%px) topology count reached 0, dumping history:\n",
+ type_str, ptr, ptr);
-:380: WARNING:VSPRINTF_SPECIFIER_PX: Using vsprintf specifier '%px'
potentially exposes the kernel memory layout, if you don't really need the
address please consider using '%p'.
#380: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:1798:
+ DRM_DEBUG("port %p/%px (%d)\n",
+ port, port, kref_read(&port->topology_kref) - 1);
total: 0 errors, 3 warnings, 0 checks, 413 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 13/14] drm/dp_mst: Add basic topology reprobing when resuming
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes that happened during that period. That can be a big
problem if the machine was connected to a different topology on the same
port before resuming, as we won't bother reprobing any of the ports and
likely cause the user's monitors not to come back up as expected.
So, we start fixing this by teaching our MST helpers how to reprobe the
link addresses of each connected topology when resuming. As it turns
out, the behavior that we want here is identical to the behavior we want
when initially probing a newly connected MST topology, with a couple of
important differences:
- We need to be more careful about handling the potential races between
events from the MST hub that could change the topology state as we're
performing the link address reprobe
- We need to be more careful about handling unlikely state changes on
ports - such as an input port turning into an output port, something
that would be far more likely to happen in situations like the MST hub
we're connected to being changed while we're suspend
Both of which have been solved by previous commits. That leaves one
requirement:
- We need to prune any MST ports in our in-memory topology state that
were present when suspending, but have not appeared in the post-resume
link address response from their parent branch device
Which we can now handle in this commit by modifying
drm_dp_send_link_address(). We then introduce suspend/resume reprobing
by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call
in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology
state to indicate that each mstb needs it's link address resent and PBN
resources reprobed.
On resume, we start back up &mgr->work and have it reprobe the topology
in the same way we would on a hotplug, removing any leftover ports that
no longer appear in the topology state.
Changes since v4:
* Split indenting changes in drm_dp_mst_topology_mgr_resume() into a
separate patch
* Only fire hotplugs when something has actually changed after a link
address probe
* Don't try to change port->connector at all on ports, just throw out
ports that need their connectors removed to make things easier.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 182 ++
drivers/gpu/drm/i915/display/intel_dp.c | 3 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +-
include/drm/drm_dp_mst_helper.h | 3 +-
5 files changed, 156 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8f67d301ad81..6c34f640f419 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -974,7 +974,7 @@ static void s3_handle_mst(struct drm_device *dev, bool
suspend)
if (suspend) {
drm_dp_mst_topology_mgr_suspend(mgr);
} else {
- ret = drm_dp_mst_topology_mgr_resume(mgr);
+ ret = drm_dp_mst_topology_mgr_resume(mgr, true);
if (ret < 0) {
drm_dp_mst_topology_mgr_set_mst(mgr, false);
need_hotplug = true;
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d486d15aa002..428160270482 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -67,8 +67,8 @@ static int drm_dp_send_dpcd_write(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port,
int offset, int size, u8 *bytes);
-static void drm_dp_send_link_address(struct drm_dp_mst_topology_mgr *mgr,
-struct drm_dp_mst_branch *mstb);
+static int drm_dp_send_link_address(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb);
static int drm_dp_send_enum_path_resources(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_branch *mstb,
struct drm_dp_mst_port *port);
@@ -1977,7 +1977,7 @@ drm_dp_mst_add_port(struct drm_device *dev,
return port;
}
-static void
+static int
drm_dp_mst_handle_link_address_port(struct drm_dp_mst_branch *mstb,
struct drm_device *dev,
struct
[Intel-gfx] [PATCH v5 14/14] drm/dp_mst: Add topology ref history tracking for debugging
For very subtle mistakes with topology refs, it can be rather difficult
to trace them down with the debugging info that we already have. I had
one such issue recently while trying to implement suspend/resume
reprobing for MST, and ended up coming up with this.
Inspired by Chris Wilson's wakeref tracking for i915, this adds a very
similar feature to the DP MST helpers, which allows for partial tracking
of topology refs for both ports and branch devices. This is a lot less
advanced then wakeref tracking: we merely keep a count of all of the
spots where a topology ref has been grabbed or dropped, then dump out
that history in chronological order when a port or branch device's
topology refcount reaches 0. So far, I've found this incredibly useful
for debugging topology refcount errors.
Since this has the potential to be somewhat slow and loud, we add an
expert kernel config option to enable or disable this feature,
CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS.
Changes since v1:
* Don't forget to destroy topology_ref_history_lock
Changes since v4:
* Correct order of kref_put()/topology_ref_history_unlock - we can't
unlock the history after kref_put() since the memory might have been
freed by that point
* Don't print message on allocation error failures, the kernel already
does this for us
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/Kconfig | 14 ++
drivers/gpu/drm/drm_dp_mst_topology.c | 241 --
include/drm/drm_dp_mst_helper.h | 45 +
3 files changed, 290 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 36357a36a281..f3f5910743d4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -93,6 +93,20 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
+bool "Enable refcount backtrace history in the DP MST helpers"
+select STACKDEPOT
+depends on DRM_KMS_HELPER
+depends on DEBUG_KERNEL
+depends on EXPERT
+help
+ Enables debug tracing for topology refs in DRM's DP MST helpers. A
+ history of each topology reference/dereference will be printed to the
+ kernel log once a port or branch device's topology refcount reaches
0.
+
+ This has the potential to use a lot of memory and print some very
+ large kernel messages. If in doubt, say "N".
+
config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 428160270482..cedfa281a22e 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -28,6 +28,13 @@
#include
#include
+#if IS_ENABLED(CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS)
+#include
+#include
+#include
+#include
+#endif
+
#include
#include
#include
@@ -1399,12 +1406,187 @@ drm_dp_mst_put_port_malloc(struct drm_dp_mst_port
*port)
}
EXPORT_SYMBOL(drm_dp_mst_put_port_malloc);
+#if IS_ENABLED(CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS)
+
+#define STACK_DEPTH 8
+
+static noinline void
+__topology_ref_save(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_topology_ref_history *history,
+ enum drm_dp_mst_topology_ref_type type)
+{
+ struct drm_dp_mst_topology_ref_entry *entry = NULL;
+ depot_stack_handle_t backtrace;
+ ulong stack_entries[STACK_DEPTH];
+ uint n;
+ int i;
+
+ n = stack_trace_save(stack_entries, ARRAY_SIZE(stack_entries), 1);
+ backtrace = stack_depot_save(stack_entries, n, GFP_KERNEL);
+ if (!backtrace)
+ return;
+
+ /* Try to find an existing entry for this backtrace */
+ for (i = 0; i < history->len; i++) {
+ if (history->entries[i].backtrace == backtrace) {
+ entry = &history->entries[i];
+ break;
+ }
+ }
+
+ /* Otherwise add one */
+ if (!entry) {
+ struct drm_dp_mst_topology_ref_entry *new;
+ int new_len = history->len + 1;
+
+ new = krealloc(history->entries, sizeof(*new) * new_len,
+ GFP_KERNEL);
+ if (!new)
+ return;
+
+ entry = &new[history->len];
+ history->len = new_len;
+ history->entries = new;
+
+ entry->backtrace = backtrace;
+ entry->type = type;
+ entry->count = 0;
+ }
+ entry->count++;
+ entry->ts_nsec = ktime_get_ns();
+
+ return;
+}
+
+static int
+topology_ref_history_cmp(const void *a, const void *b)
+{
+ const struct drm_dp_mst_topology_ref_entry *entry_a = a, *entry_b
[Intel-gfx] [PATCH v5 12/14] drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Changes since v3:
* Fix typo in comments
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 887bc1d5d9e2..8f67d301ad81 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1186,15 +1186,15 @@ static int dm_resume(void *handle)
/* program HPD filter */
dc_resume(dm->dc);
- /* On resume we need to rewrite the MSTM control bits to enamble MST*/
- s3_handle_mst(ddev, false);
-
/*
* early enable HPD Rx IRQ, should be done before set mode as short
* pulse interrupts are used for MST
*/
amdgpu_dm_irq_resume_early(adev);
+ /* On resume we need to rewrite the MSTM control bits to enable MST*/
+ s3_handle_mst(ddev, false);
+
/* Do detection*/
drm_connector_list_iter_begin(ddev, &iter);
drm_for_each_connector_iter(connector, &iter) {
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 11/14] drm/amdgpu: Iterate through DRM connectors correctly
Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewed-by: Alex Deucher
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 13 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 40 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 ++-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 34
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 34
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 40 ++-
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 34
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 ---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 10 -
11 files changed, 195 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index d8729285f731..a62cbc8199de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1019,8 +1019,12 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
*/
if (amdgpu_connector->shared_ddc && (ret ==
connector_status_connected)) {
struct drm_connector *list_connector;
+ struct drm_connector_list_iter iter;
struct amdgpu_connector *list_amdgpu_connector;
- list_for_each_entry(list_connector,
&dev->mode_config.connector_list, head) {
+
+ drm_connector_list_iter_begin(dev, &iter);
+ drm_for_each_connector_iter(list_connector,
+ &iter) {
if (connector == list_connector)
continue;
list_amdgpu_connector =
to_amdgpu_connector(list_connector);
@@ -1037,6 +1041,7 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
}
}
}
+ drm_connector_list_iter_end(&iter);
}
}
}
@@ -1494,6 +1499,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
{
struct drm_device *dev = adev->ddev;
struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
struct amdgpu_connector *amdgpu_connector;
struct amdgpu_connector_atom_dig *amdgpu_dig_connector;
struct drm_encoder *encoder;
@@ -1508,10 +1514,12 @@ amdgpu_connector_add(struct amdgpu_device *adev,
return;
/* see if we already added it */
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ drm_connector_list_iter_begin(dev, &iter);
+ drm_for_each_connector_iter(connector, &iter) {
amdgpu_connector = to_amdgpu_connector(connector);
if (amdgpu_connector->connector_id == connector_id) {
amdgpu_connector->devices |= supported_device;
+ drm_connector_list_iter_end(&iter);
return;
}
if (amdgpu_connector->ddc_bus && i2c_bus->valid) {
@@ -1526,6 +1534,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
}
}
}
+ drm_connector_list_iter_end(&iter);
/* check if it's a dp bridge */
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5a1939dbd4e3..cff16f554f2e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3007,6 +3007,7 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
suspend, bool fbcon)
struct amdgpu_device *adev;
struct drm_crtc *crtc;
struct drm_connector *connector;
+ struct drm_connector_list_iter iter;
int r;
if (dev == NULL || dev->dev_private == NULL) {
@@ -3029,9 +3030,11 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
suspend, bool fbcon)
if (!amdgpu_device_has_dc_support(adev)) {
/* turn off display hw */
drm_modeset_lock_all(dev);
- list_for_each_entry(connector,
&dev->mode_config.connector_list,
[Intel-gfx] [PATCH v5 09/14] drm/nouveau: Don't grab runtime PM refs for HPD IRQs
In order for suspend/resume reprobing to work, we need to be able to
perform sideband communications during suspend/resume, along with
runtime PM suspend/resume. In order to do so, we also need to make sure
that nouveau doesn't bother grabbing a runtime PM reference to do so,
since otherwise we'll start deadlocking runtime PM again.
Note that we weren't able to do this before, because of the DP MST
helpers processing UP requests from topologies in the same context as
drm_dp_mst_hpd_irq() which would have caused us to open ourselves up to
receiving hotplug events and deadlocking with runtime suspend/resume.
Now that those requests are handled asynchronously, this change should
be completely safe.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 33 +++--
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 3a5db17bc5c7..5b413588b823 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1130,6 +1130,16 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
const char *name = connector->name;
struct nouveau_encoder *nv_encoder;
int ret;
+ bool plugged = (rep->mask != NVIF_NOTIFY_CONN_V0_UNPLUG);
+
+ if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
+ NV_DEBUG(drm, "service %s\n", name);
+ drm_dp_cec_irq(&nv_connector->aux);
+ if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP)))
+ nv50_mstm_service(nv_encoder->dp.mstm);
+
+ return NVIF_NOTIFY_KEEP;
+ }
ret = pm_runtime_get(drm->dev->dev);
if (ret == 0) {
@@ -1150,25 +1160,16 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
return NVIF_NOTIFY_DROP;
}
- if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
- NV_DEBUG(drm, "service %s\n", name);
- drm_dp_cec_irq(&nv_connector->aux);
- if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP)))
- nv50_mstm_service(nv_encoder->dp.mstm);
- } else {
- bool plugged = (rep->mask != NVIF_NOTIFY_CONN_V0_UNPLUG);
-
+ if (!plugged)
+ drm_dp_cec_unset_edid(&nv_connector->aux);
+ NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name);
+ if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP))) {
if (!plugged)
- drm_dp_cec_unset_edid(&nv_connector->aux);
- NV_DEBUG(drm, "%splugged %s\n", plugged ? "" : "un", name);
- if ((nv_encoder = find_encoder(connector, DCB_OUTPUT_DP))) {
- if (!plugged)
- nv50_mstm_remove(nv_encoder->dp.mstm);
- }
-
- drm_helper_hpd_irq_event(connector->dev);
+ nv50_mstm_remove(nv_encoder->dp.mstm);
}
+ drm_helper_hpd_irq_event(connector->dev);
+
pm_runtime_mark_last_busy(drm->dev->dev);
pm_runtime_put_autosuspend(drm->dev->dev);
return NVIF_NOTIFY_KEEP;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 10/14] drm/nouveau: Resume hotplug interrupts earlier
Currently, we enable hotplug detection only after we re-enable the
display. However, this is too late if we're planning on sending sideband
messages during the resume process - which we'll need to do in order to
reprobe the topology on resume.
So, enable hotplug events before reinitializing the display.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 6f038511a03a..53f9bceaf17a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -407,6 +407,17 @@ nouveau_display_init(struct drm_device *dev, bool resume,
bool runtime)
struct drm_connector_list_iter conn_iter;
int ret;
+ /*
+* Enable hotplug interrupts (done as early as possible, since we need
+* them for MST)
+*/
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ nouveau_for_each_non_mst_connector_iter(connector, &conn_iter) {
+ struct nouveau_connector *conn = nouveau_connector(connector);
+ nvif_notify_get(&conn->hpd);
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
ret = disp->init(dev, resume, runtime);
if (ret)
return ret;
@@ -416,14 +427,6 @@ nouveau_display_init(struct drm_device *dev, bool resume,
bool runtime)
*/
drm_kms_helper_poll_enable(dev);
- /* enable hotplug interrupts */
- drm_connector_list_iter_begin(dev, &conn_iter);
- nouveau_for_each_non_mst_connector_iter(connector, &conn_iter) {
- struct nouveau_connector *conn = nouveau_connector(connector);
- nvif_notify_get(&conn->hpd);
- }
- drm_connector_list_iter_end(&conn_iter);
-
return ret;
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 01/14] drm/dp_mst: Destroy MSTBs asynchronously
When reprobing an MST topology during resume, we have to account for the
fact that while we were suspended it's possible that mstbs may have been
removed from any ports in the topology. Since iterating downwards in the
topology requires that we hold &mgr->lock, destroying MSTBs from this
context would result in attempting to lock &mgr->lock a second time and
deadlocking.
So, fix this by first moving destruction of MSTBs into
destroy_connector_work, then rename destroy_connector_work and friends
to reflect that they now destroy both ports and mstbs.
Note that even though this means that MSTBs will still be accessible for
a short period of time between their removal from the topology and
delayed destruction, we are still protected against referencing a MSTB
with a refcount of 0 since we use kref_get_unless_zero() in most places.
Changes since v1:
* s/destroy_connector_list/destroy_port_list/
s/connector_destroy_lock/delayed_destroy_lock/
s/connector_destroy_work/delayed_destroy_work/
s/drm_dp_finish_destroy_branch_device/drm_dp_delayed_destroy_mstb/
s/drm_dp_finish_destroy_port/drm_dp_delayed_destroy_port/
- danvet
* Use two loops in drm_dp_delayed_destroy_work() - danvet
* Better explain why we need to do this - danvet
* Use cancel_work_sync() instead of flush_work() - flush_work() doesn't
account for work requeing
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 164 +-
include/drm/drm_dp_mst_helper.h | 26 ++--
2 files changed, 128 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 95e63309..66ff226d8c86 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1398,34 +1398,17 @@ static void drm_dp_destroy_mst_branch_device(struct
kref *kref)
struct drm_dp_mst_branch *mstb =
container_of(kref, struct drm_dp_mst_branch, topology_kref);
struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
- struct drm_dp_mst_port *port, *tmp;
- bool wake_tx = false;
- mutex_lock(&mgr->lock);
- list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
- list_del(&port->next);
- drm_dp_mst_topology_put_port(port);
- }
- mutex_unlock(&mgr->lock);
-
- /* drop any tx slots msg */
- mutex_lock(&mstb->mgr->qlock);
- if (mstb->tx_slots[0]) {
- mstb->tx_slots[0]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
- mstb->tx_slots[0] = NULL;
- wake_tx = true;
- }
- if (mstb->tx_slots[1]) {
- mstb->tx_slots[1]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
- mstb->tx_slots[1] = NULL;
- wake_tx = true;
- }
- mutex_unlock(&mstb->mgr->qlock);
+ INIT_LIST_HEAD(&mstb->destroy_next);
- if (wake_tx)
- wake_up_all(&mstb->mgr->tx_waitq);
-
- drm_dp_mst_put_mstb_malloc(mstb);
+ /*
+* This can get called under mgr->mutex, so we need to perform the
+* actual destruction of the mstb in another worker
+*/
+ mutex_lock(&mgr->delayed_destroy_lock);
+ list_add(&mstb->destroy_next, &mgr->destroy_branch_device_list);
+ mutex_unlock(&mgr->delayed_destroy_lock);
+ schedule_work(&mgr->delayed_destroy_work);
}
/**
@@ -1540,10 +1523,10 @@ static void drm_dp_destroy_port(struct kref *kref)
* we might be holding the mode_config.mutex
* from an EDID retrieval */
- mutex_lock(&mgr->destroy_connector_lock);
- list_add(&port->next, &mgr->destroy_connector_list);
- mutex_unlock(&mgr->destroy_connector_lock);
- schedule_work(&mgr->destroy_connector_work);
+ mutex_lock(&mgr->delayed_destroy_lock);
+ list_add(&port->next, &mgr->destroy_port_list);
+ mutex_unlock(&mgr->delayed_destroy_lock);
+ schedule_work(&mgr->delayed_destroy_work);
return;
}
/* no need to clean up vcpi
@@ -3085,7 +3068,7 @@ void drm_dp_mst_topology_mgr_suspend(struct
drm_dp_mst_topology_mgr *mgr)
DP_MST_EN | DP_UPSTREAM_IS_SRC);
mutex_unlock(&mgr->lock);
flush_work(&mgr->work);
- flush_work(&mgr->destroy_connector_work);
+ flush_work(&mgr->delayed_destroy_work);
}
EXPORT_SYMBOL(drm_dp_mst_topology_mgr_suspend);
@@ -3995,34 +3978,104 @@ static void drm_dp_tx_work(struct work_struct *work)
mutex_unlock(&mgr->qlock);
}
-static void drm_dp_destroy_connector_work(struct work_struct *work)
+static inline void
+drm_dp_delayed_destroy_port(struct drm_dp_mst_port *port)
{
-
[Intel-gfx] [PATCH v5 07/14] drm/dp_mst: Don't forget to update port->input in drm_dp_mst_handle_conn_stat()
This probably hasn't caused any problems up until now since it's
probably nearly impossible to encounter this in the wild, however if we
were to receive a connection status notification from the MST hub after
resume while we're in the middle of reprobing the link addresses for a
topology then there's a much larger chance that a port could have
changed from being an output port to input port (or vice versa). If we
forget to update this bit of information, we'll potentially ignore a
valid PDT change on a downstream port because we think it's an input
port.
So, make sure we read the input_port field in connection status
notifications in drm_dp_mst_handle_conn_stat() to prevent this from
happening once we've implemented suspend/resume reprobing.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 52 +++
1 file changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7bf4db91ff90..c8e218b902ae 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2079,18 +2079,40 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
*mstb,
{
struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
struct drm_dp_mst_port *port;
- int old_ddps;
- bool dowork = false;
+ int old_ddps, ret;
+ u8 new_pdt;
+ bool dowork = false, create_connector = false;
port = drm_dp_get_port(mstb, conn_stat->port_number);
if (!port)
return;
- /* Locking is only needed if the port's exposed to userspace */
- if (port->connector)
+ if (port->connector) {
+ if (!port->input && conn_stat->input_port) {
+ /*
+* We can't remove a connector from an already exposed
+* port, so just throw the port out and make sure we
+* reprobe the link address of it's parent MSTB
+*/
+ drm_dp_mst_topology_unlink_port(mgr, port);
+ mstb->link_address_sent = false;
+ dowork = true;
+ goto out;
+ }
+
+ /*
+* Locking is only needed if the port's exposed to userspace
+*/
drm_modeset_lock(&mgr->base.lock, NULL);
+ } else if (port->input && !conn_stat->input_port) {
+ create_connector = true;
+ /* Reprobe link address so we get num_sdp_streams */
+ mstb->link_address_sent = false;
+ dowork = true;
+ }
old_ddps = port->ddps;
+ port->input = conn_stat->input_port;
port->mcs = conn_stat->message_capability_status;
port->ldps = conn_stat->legacy_device_plug_status;
port->ddps = conn_stat->displayport_device_plug_status;
@@ -2103,21 +2125,23 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
*mstb,
}
}
- if (!port->input) {
- int ret = drm_dp_port_set_pdt(port,
- conn_stat->peer_device_type);
- if (ret == 1) {
- dowork = true;
- } else if (ret < 0) {
- DRM_ERROR("Failed to change PDT for port %p: %d\n",
- port, ret);
- dowork = false;
- }
+ new_pdt = port->input ? DP_PEER_DEVICE_NONE :
conn_stat->peer_device_type;
+
+ ret = drm_dp_port_set_pdt(port, new_pdt);
+ if (ret == 1) {
+ dowork = true;
+ } else if (ret < 0) {
+ DRM_ERROR("Failed to change PDT for port %p: %d\n",
+ port, ret);
+ dowork = false;
}
if (port->connector)
drm_modeset_unlock(&mgr->base.lock);
+ else if (create_connector)
+ drm_dp_mst_port_add_connector(mstb, port);
+out:
drm_dp_mst_topology_put_port(port);
if (dowork)
queue_work(system_long_wq, &mstb->mgr->work);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 06/14] drm/dp_mst: Protect drm_dp_mst_port members with locking
This is a complicated one. Essentially, there's currently a problem in the MST core that hasn't really caused any issues that we're aware of (emphasis on "that we're aware of"): locking. When we go through and probe the link addresses and path resources in a topology, we hold no locks when updating ports with said information. The members I'm referring to in particular are: - ldps - ddps - mcs - pdt - dpcd_rev - num_sdp_streams - num_sdp_stream_sinks - available_pbn - input - connector Now that we're handling UP requests asynchronously and will be using some of the struct members mentioned above in atomic modesetting in the future for features such as PBN validation, this is going to become a lot more important. As well, the next few commits that prepare us for and introduce suspend/resume reprobing will also need clear locking in order to prevent from additional racing hilarities that we never could have hit in the past. So, let's solve this issue by using &mgr->base.lock, the modesetting lock which currently only protects &mgr->base.state. This works perfectly because it allows us to avoid blocking connection_mutex unnecessarily, and we can grab this in connector detection paths since it's a ww mutex. We start by having drm_dp_mst_handle_up_req() hold this when updating ports. For drm_dp_mst_handle_link_address_port() things are a bit more complicated. As I've learned the hard way, we can grab &mgr->lock.base for everything except for port->connector. See, our normal driver probing paths end up generating this rather obvious lockdep chain: &drm->mode_config.mutex -> crtc_ww_class_mutex/crtc_ww_class_acquire -> &connector->mutex However, sysfs grabs &drm->mode_config.mutex in order to protect itself from connector state changing under it. Because this entails grabbing kn->count, e.g. the lock that the kernel provides for protecting sysfs contexts, we end up grabbing kn->count followed by &drm->mode_config.mutex. This ends up creating an extremely rude chain: &kn->count -> &drm->mode_config.mutex -> crtc_ww_class_mutex/crtc_ww_class_acquire -> &connector->mutex I mean, look at that thing! It's just evil!!! This gross thing ends up making any calls to drm_connector_register()/drm_connector_unregister() impossible when holding any kind of modesetting lock. This is annoying because ideally, we always want to ensure that drm_dp_mst_port->connector never changes when doing an atomic commit or check that would affect the atomic topology state so that it can reliably and easily be used from future DRM DP MST helpers to assist with tasks such as scanning through the current VCPI allocations and adding connectors which need to have their allocations updated in response to a bandwidth change or the like. Being able to hold &mgr->base.lock throughout the entire link probe process would have been _great_, since we could prevent userspace from ever seeing any states in-between individual port changes and as a result likely end up with a much faster probe and more consistent results from said probes. But without some rework of how we handle connector probing in sysfs it's not at all currently possible. In the future, maybe we can try using the sysfs locks to protect updates to connector probing state and fix this mess. So for now, to protect everything other than port->connector under &mgr->base.lock and ensure that we still have the guarantee that atomic check/commit contexts will never see port->connector change we use a silly trick. See: port->connector only needs to change in order to ensure that input ports (see the MST spec) never have a ghost connector associated with them. But, there's nothing stopping us from simply throwing the entire port out and creating a new one in order to maintain that requirement while still keeping port->connector consistent across the lifetime of the port in atomic check/commit contexts. For all intended purposes this works fine, as we validate ports in any contexts we care about before using them and as such will end up reporting the connector as disconnected until it's port's destruction finalizes. So, we just do that in cases where we detect port->input has transitioned from true->false. We don't need to worry about the other direction, since a port without a connector isn't visible to userspace and as such doesn't need to be protected by &mgr->base.lock until we finish registering a connector for it. For updating members of drm_dp_mst_port other than port->connector, we simply grab &mgr->base.lock in drm_dp_mst_link_probe_work() for already registered ports, update said members and drop the lock before potentially registering a connector and probing the link address of it's children. Finally, we modify drm_dp_mst_detect_port() to take a modesetting lock acquisition context in order to acquire &mgr->base.lock under &connection_mutex and convert all it's users over to using the .detect_ctx probe hooks. With that, we finally have well defined locking.
[Intel-gfx] [PATCH v5 05/14] drm/dp_mst: Add probe_lock
Currently, MST lacks locking in a lot of places that really should have
some sort of locking. Hotplugging and link address code paths are some
of the offenders here, as there is actually nothing preventing us from
running a link address probe while at the same time handling a
connection status update request - something that's likely always been
possible but never seen in the wild because hotplugging has been broken
for ages now (with the exception of amdgpu, for reasons I don't think
are worth digging into very far).
Note: I'm going to start using the term "in-memory topology layout" here
to refer to drm_dp_mst_port->mstb and drm_dp_mst_branch->ports.
Locking in these places is a little tougher then it looks though.
Generally we protect anything having to do with the in-memory topology
layout under &mgr->lock. But this becomes nearly impossible to do from
the context of link address probes due to the fact that &mgr->lock is
usually grabbed under random various modesetting locks, meaning that
there's no way we can just invert the &mgr->lock order and keep it
locked throughout the whole process of updating the topology.
Luckily there are only two workers which can modify the in-memory
topology layout: drm_dp_mst_up_req_work() and
drm_dp_mst_link_probe_work(), meaning as long as we prevent these two
workers from traveling the topology layout in parallel with the intent
of updating it we don't need to worry about grabbing &mgr->lock in these
workers for reads. We only need to grab &mgr->lock in these workers for
writes, so that readers outside these two workers are still protected
from the topology layout changing beneath them.
So, add the new &mgr->probe_lock and use it in both
drm_dp_mst_link_probe_work() and drm_dp_mst_up_req_work(). Additionally,
add some more detailed explanations for how this locking is intended to
work to drm_dp_mst_port->mstb and drm_dp_mst_branch->ports.
Signed-off-by: Lyude Paul
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 28 ++-
include/drm/drm_dp_mst_helper.h | 32 +++
2 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 08c316a727df..11d842f0bff5 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2147,37 +2147,40 @@ static void drm_dp_check_and_send_link_address(struct
drm_dp_mst_topology_mgr *m
struct drm_dp_mst_branch *mstb)
{
struct drm_dp_mst_port *port;
- struct drm_dp_mst_branch *mstb_child;
+
if (!mstb->link_address_sent)
drm_dp_send_link_address(mgr, mstb);
list_for_each_entry(port, &mstb->ports, next) {
- if (port->input)
- continue;
+ struct drm_dp_mst_branch *mstb_child = NULL;
- if (!port->ddps)
+ if (port->input || !port->ddps)
continue;
if (!port->available_pbn)
drm_dp_send_enum_path_resources(mgr, mstb, port);
- if (port->mstb) {
+ if (port->mstb)
mstb_child = drm_dp_mst_topology_get_mstb_validated(
mgr, port->mstb);
- if (mstb_child) {
- drm_dp_check_and_send_link_address(mgr,
mstb_child);
- drm_dp_mst_topology_put_mstb(mstb_child);
- }
+
+ if (mstb_child) {
+ drm_dp_check_and_send_link_address(mgr, mstb_child);
+ drm_dp_mst_topology_put_mstb(mstb_child);
}
}
}
static void drm_dp_mst_link_probe_work(struct work_struct *work)
{
- struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
drm_dp_mst_topology_mgr, work);
+ struct drm_dp_mst_topology_mgr *mgr =
+ container_of(work, struct drm_dp_mst_topology_mgr, work);
+ struct drm_device *dev = mgr->dev;
struct drm_dp_mst_branch *mstb;
int ret;
+ mutex_lock(&mgr->probe_lock);
+
mutex_lock(&mgr->lock);
mstb = mgr->mst_primary;
if (mstb) {
@@ -2190,6 +2193,7 @@ static void drm_dp_mst_link_probe_work(struct work_struct
*work)
drm_dp_check_and_send_link_address(mgr, mstb);
drm_dp_mst_topology_put_mstb(mstb);
}
+ mutex_unlock(&mgr->probe_lock);
}
static bool drm_dp_validate_guid(struct drm_dp_mst_topology_mgr *mgr,
@@ -3313,6 +3317,7 @@ static void drm_dp_mst_up_req_work(struct work_struct
*work)
up_req_work);
struct drm_dp_pending_up_req *up_req;
+ mutex_lock(&mgr->probe_lock);
while (true) {
mutex_lock(&mgr->u
[Intel-gfx] [PATCH v5 08/14] drm/dp_mst: Lessen indenting in drm_dp_mst_topology_mgr_resume()
Does what it says on the tin.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c8e218b902ae..d486d15aa002 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3212,45 +3212,44 @@ EXPORT_SYMBOL(drm_dp_mst_topology_mgr_suspend);
*/
int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr)
{
- int ret = 0;
+ int ret;
+ u8 guid[16];
mutex_lock(&mgr->lock);
+ if (!mgr->mst_primary)
+ goto out_fail;
- if (mgr->mst_primary) {
- int sret;
- u8 guid[16];
+ ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
+ DP_RECEIVER_CAP_SIZE);
+ if (ret != DP_RECEIVER_CAP_SIZE) {
+ DRM_DEBUG_KMS("dpcd read failed - undocked during suspend?\n");
+ goto out_fail;
+ }
- sret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
DP_RECEIVER_CAP_SIZE);
- if (sret != DP_RECEIVER_CAP_SIZE) {
- DRM_DEBUG_KMS("dpcd read failed - undocked during
suspend?\n");
- ret = -1;
- goto out_unlock;
- }
+ ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
+DP_MST_EN |
+DP_UP_REQ_EN |
+DP_UPSTREAM_IS_SRC);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("mst write failed - undocked during suspend?\n");
+ goto out_fail;
+ }
- ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
-DP_MST_EN | DP_UP_REQ_EN |
DP_UPSTREAM_IS_SRC);
- if (ret < 0) {
- DRM_DEBUG_KMS("mst write failed - undocked during
suspend?\n");
- ret = -1;
- goto out_unlock;
- }
+ /* Some hubs forget their guids after they resume */
+ ret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
+ if (ret != 16) {
+ DRM_DEBUG_KMS("dpcd read failed - undocked during suspend?\n");
+ goto out_fail;
+ }
+ drm_dp_check_mstb_guid(mgr->mst_primary, guid);
- /* Some hubs forget their guids after they resume */
- sret = drm_dp_dpcd_read(mgr->aux, DP_GUID, guid, 16);
- if (sret != 16) {
- DRM_DEBUG_KMS("dpcd read failed - undocked during
suspend?\n");
- ret = -1;
- goto out_unlock;
- }
- drm_dp_check_mstb_guid(mgr->mst_primary, guid);
+ mutex_unlock(&mgr->lock);
- ret = 0;
- } else
- ret = -1;
+ return 0;
-out_unlock:
+out_fail:
mutex_unlock(&mgr->lock);
- return ret;
+ return -1;
}
EXPORT_SYMBOL(drm_dp_mst_topology_mgr_resume);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 04/14] drm/dp_mst: Handle UP requests asynchronously
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging timeouts and causes the whole topology state to go
out of sync with reality, usually resulting in the user needing to
replug the entire topology in hopes that it actually fixes things.
The reason for this is because the way we currently handle UP requests
in MST is completely bogus. drm_dp_mst_handle_up_req() is called from
drm_dp_mst_hpd_irq(), which is usually called from the driver's hotplug
handler. Because we handle sending the hotplug event from this function,
we actually cause the driver's hotplug handler (and in turn, all
sideband transactions) to block on
drm_device->mode_config.connection_mutex. This makes it impossible to
send any sideband messages from the driver's connector probing
functions, resulting in the aforementioned sideband message timeout.
There's even more problems with this beyond breaking hotplugging on MST
branch devices. It also makes it almost impossible to protect
drm_dp_mst_port struct members under a lock because we then have to
worry about dealing with all of the lock dependency issues that ensue.
So, let's finally actually fix this issue by handling the processing of
up requests asyncronously. This way we can send sideband messages from
most contexts without having to deal with getting blocked if we hold
connection_mutex. This also fixes MST branch device hotplugging on i915,
finally!
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 146 +++---
include/drm/drm_dp_mst_helper.h | 16 +++
2 files changed, 122 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 3f16c0cb094b..08c316a727df 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -45,6 +45,12 @@
* protocol. The helpers contain a topology manager and bandwidth manager.
* The helpers encapsulate the sending and received of sideband msgs.
*/
+struct drm_dp_pending_up_req {
+ struct drm_dp_sideband_msg_hdr hdr;
+ struct drm_dp_sideband_msg_req_body msg;
+ struct list_head next;
+};
+
static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
char *buf);
@@ -3091,6 +3097,7 @@ void drm_dp_mst_topology_mgr_suspend(struct
drm_dp_mst_topology_mgr *mgr)
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
DP_MST_EN | DP_UPSTREAM_IS_SRC);
mutex_unlock(&mgr->lock);
+ flush_work(&mgr->up_req_work);
flush_work(&mgr->work);
flush_work(&mgr->delayed_destroy_work);
}
@@ -3263,12 +3270,70 @@ static int drm_dp_mst_handle_down_rep(struct
drm_dp_mst_topology_mgr *mgr)
return 0;
}
+static inline void
+drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_pending_up_req *up_req)
+{
+ struct drm_dp_mst_branch *mstb = NULL;
+ struct drm_dp_sideband_msg_req_body *msg = &up_req->msg;
+ struct drm_dp_sideband_msg_hdr *hdr = &up_req->hdr;
+
+ if (hdr->broadcast) {
+ const u8 *guid = NULL;
+
+ if (msg->req_type == DP_CONNECTION_STATUS_NOTIFY)
+ guid = msg->u.conn_stat.guid;
+ else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
+ guid = msg->u.resource_stat.guid;
+
+ mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
+ } else {
+ mstb = drm_dp_get_mst_branch_device(mgr, hdr->lct, hdr->rad);
+ }
+
+ if (!mstb) {
+ DRM_DEBUG_KMS("Got MST reply from unknown device %d\n",
+ hdr->lct);
+ return;
+ }
+
+ /* TODO: Add missing handler for DP_RESOURCE_STATUS_NOTIFY events */
+ if (msg->req_type == DP_CONNECTION_STATUS_NOTIFY) {
+ drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat);
+ drm_kms_helper_hotplug_event(mgr->dev);
+ }
+
+ drm_dp_mst_topology_put_mstb(mstb);
+}
+
+static void drm_dp_mst_up_req_work(struct work_struct *work)
+{
+ struct drm_dp_mst_topology_mgr *mgr =
+ container_of(work, struct drm_dp_mst_topology_mgr,
+up_req_work);
+ struct drm_dp_pending_up_req *up_req;
+
+ while (true) {
+ mutex_lock(&mgr->up_req_lock);
+ up_req = list_first_entry_or_null(&mgr->up_req_list,
+ struct drm_dp_pending_up_req,
+ next);
+ i
[Intel-gfx] [PATCH v5 03/14] drm/dp_mst: Refactor pdt setup/teardown, add more locking
Since we're going to be implementing suspend/resume reprobing very soon,
we need to make sure we are extra careful to ensure that our locking
actually protects the topology state where we expect it to. Turns out
this isn't the case with drm_dp_port_setup_pdt() and
drm_dp_port_teardown_pdt(), both of which change port->mstb without
grabbing &mgr->lock.
Additionally, since most callers of these functions are just using it to
teardown the port's previous PDT and setup a new one we can simplify
things a bit and combine drm_dp_port_setup_pdt() and
drm_dp_port_teardown_pdt() into a single function:
drm_dp_port_set_pdt(). This function also handles actually ensuring that
we grab the correct locks when we need to modify port->mstb.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 181 +++---
include/drm/drm_dp_mst_helper.h | 6 +-
2 files changed, 110 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 204d0c832c65..3f16c0cb094b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1486,24 +1486,6 @@ drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch
*mstb)
kref_put(&mstb->topology_kref, drm_dp_destroy_mst_branch_device);
}
-static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int old_pdt)
-{
- struct drm_dp_mst_branch *mstb;
-
- switch (old_pdt) {
- case DP_PEER_DEVICE_DP_LEGACY_CONV:
- case DP_PEER_DEVICE_SST_SINK:
- /* remove i2c over sideband */
- drm_dp_mst_unregister_i2c_bus(&port->aux);
- break;
- case DP_PEER_DEVICE_MST_BRANCHING:
- mstb = port->mstb;
- port->mstb = NULL;
- drm_dp_mst_topology_put_mstb(mstb);
- break;
- }
-}
-
static void drm_dp_destroy_port(struct kref *kref)
{
struct drm_dp_mst_port *port =
@@ -1713,38 +1695,79 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port
*port,
return parent_lct + 1;
}
-/*
- * return sends link address for new mstb
- */
-static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
+static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt)
{
- int ret;
- u8 rad[6], lct;
- bool send_link = false;
+ struct drm_dp_mst_topology_mgr *mgr = port->mgr;
+ struct drm_dp_mst_branch *mstb;
+ u8 rad[8], lct;
+ int ret = 0;
+
+ if (port->pdt == new_pdt)
+ return 0;
+
+ /* Teardown the old pdt, if there is one */
+ switch (port->pdt) {
+ case DP_PEER_DEVICE_DP_LEGACY_CONV:
+ case DP_PEER_DEVICE_SST_SINK:
+ /*
+* If the new PDT would also have an i2c bus, don't bother
+* with reregistering it
+*/
+ if (new_pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
+ new_pdt == DP_PEER_DEVICE_SST_SINK) {
+ port->pdt = new_pdt;
+ return 0;
+ }
+
+ /* remove i2c over sideband */
+ drm_dp_mst_unregister_i2c_bus(&port->aux);
+ break;
+ case DP_PEER_DEVICE_MST_BRANCHING:
+ mutex_lock(&mgr->lock);
+ drm_dp_mst_topology_put_mstb(port->mstb);
+ port->mstb = NULL;
+ mutex_unlock(&mgr->lock);
+ break;
+ }
+
+ port->pdt = new_pdt;
switch (port->pdt) {
case DP_PEER_DEVICE_DP_LEGACY_CONV:
case DP_PEER_DEVICE_SST_SINK:
/* add i2c over sideband */
ret = drm_dp_mst_register_i2c_bus(&port->aux);
break;
+
case DP_PEER_DEVICE_MST_BRANCHING:
lct = drm_dp_calculate_rad(port, rad);
+ mstb = drm_dp_add_mst_branch_device(lct, rad);
+ if (!mstb) {
+ ret = -ENOMEM;
+ DRM_ERROR("Failed to create MSTB for port %p", port);
+ goto out;
+ }
- port->mstb = drm_dp_add_mst_branch_device(lct, rad);
- if (port->mstb) {
- port->mstb->mgr = port->mgr;
- port->mstb->port_parent = port;
- /*
-* Make sure this port's memory allocation stays
-* around until its child MSTB releases it
-*/
- drm_dp_mst_get_port_malloc(port);
+ mutex_lock(&mgr->lock);
+ port->mstb = mstb;
+ mstb->mgr = port->mgr;
+ mstb->port_parent = port;
- send_link = true;
- }
+ /*
+* Make sure this port's memory al
[Intel-gfx] [PATCH v5 02/14] drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and refactor
This will allow us to add some locking for port->* members, in
particular the PDT and ->connector, which can't be done from
drm_dp_destroy_port() since we don't know what locks the caller might be
holding.
Note that we already do this in delayed_destroy_work (renamed from
destroy_connector_work in this patch) for ports, we're just making it so
mstbs are also destroyed in this worker.
Changes since v2:
* Clarify commit message
Changes since v4:
* Clarify commit message more
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 40 +++
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 66ff226d8c86..204d0c832c65 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1510,31 +1510,22 @@ static void drm_dp_destroy_port(struct kref *kref)
container_of(kref, struct drm_dp_mst_port, topology_kref);
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
- if (!port->input) {
- kfree(port->cached_edid);
+ /* There's nothing that needs locking to destroy an input port yet */
+ if (port->input) {
+ drm_dp_mst_put_port_malloc(port);
+ return;
+ }
- /*
-* The only time we don't have a connector
-* on an output port is if the connector init
-* fails.
-*/
- if (port->connector) {
- /* we can't destroy the connector here, as
-* we might be holding the mode_config.mutex
-* from an EDID retrieval */
+ kfree(port->cached_edid);
- mutex_lock(&mgr->delayed_destroy_lock);
- list_add(&port->next, &mgr->destroy_port_list);
- mutex_unlock(&mgr->delayed_destroy_lock);
- schedule_work(&mgr->delayed_destroy_work);
- return;
- }
- /* no need to clean up vcpi
-* as if we have no connector we never setup a vcpi */
- drm_dp_port_teardown_pdt(port, port->pdt);
- port->pdt = DP_PEER_DEVICE_NONE;
- }
- drm_dp_mst_put_port_malloc(port);
+ /*
+* we can't destroy the connector here, as we might be holding the
+* mode_config.mutex from an EDID retrieval
+*/
+ mutex_lock(&mgr->delayed_destroy_lock);
+ list_add(&port->next, &mgr->destroy_port_list);
+ mutex_unlock(&mgr->delayed_destroy_lock);
+ schedule_work(&mgr->delayed_destroy_work);
}
/**
@@ -3981,7 +3972,8 @@ static void drm_dp_tx_work(struct work_struct *work)
static inline void
drm_dp_delayed_destroy_port(struct drm_dp_mst_port *port)
{
- port->mgr->cbs->destroy_connector(port->mgr, port->connector);
+ if (port->connector)
+ port->mgr->cbs->destroy_connector(port->mgr, port->connector);
drm_dp_port_teardown_pdt(port, port->pdt);
port->pdt = DP_PEER_DEVICE_NONE;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 00/14] DP MST Refactors + debugging tools + suspend/resume reprobing
This is the final portion of the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: * Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. * Added some debugging tools along the way that I ended up needing to figure out some issues in my own code Note that there's still one important part of this process missing that's not included in this patch series: EDID reprobing, which I believe Stanislav Lisovskiy from Intel is currently working on. The main purpose of this series is to fix the issue of the in-memory topology state (e.g. connectors connected to an MST hub, branch devices, etc.) going out of sync if a topology connected to a connector is swapped out with a different topology while the system is resumed, or while the device housing said connector is in runtime suspend. As well, the debugging tools that are added in this include: * A limited debugging utility for dumping the list of topology references on an MST port or branch connector whose topology reference count has reached 0 Lyude Paul (14): drm/dp_mst: Destroy MSTBs asynchronously drm/dp_mst: Remove PDT teardown in drm_dp_destroy_port() and refactor drm/dp_mst: Refactor pdt setup/teardown, add more locking drm/dp_mst: Handle UP requests asynchronously drm/dp_mst: Add probe_lock drm/dp_mst: Protect drm_dp_mst_port members with locking drm/dp_mst: Don't forget to update port->input in drm_dp_mst_handle_conn_stat() drm/dp_mst: Lessen indenting in drm_dp_mst_topology_mgr_resume() drm/nouveau: Don't grab runtime PM refs for HPD IRQs drm/nouveau: Resume hotplug interrupts earlier drm/amdgpu: Iterate through DRM connectors correctly drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology drm/dp_mst: Add basic topology reprobing when resuming drm/dp_mst: Add topology ref history tracking for debugging drivers/gpu/drm/Kconfig | 14 + .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 13 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 40 +- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c |5 +- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 34 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 34 +- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 40 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 34 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 41 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 10 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 +- drivers/gpu/drm/drm_dp_mst_topology.c | 1185 + drivers/gpu/drm/i915/display/intel_dp.c |3 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 28 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 38 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 33 +- drivers/gpu/drm/nouveau/nouveau_display.c | 19 +- drivers/gpu/drm/radeon/radeon_dp_mst.c| 24 +- include/drm/drm_dp_mst_helper.h | 160 ++- 21 files changed, 1329 insertions(+), 479 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Lift i915_vma_parked() onto the gt
== Series Details ==
Series: series starting with [1/2] drm/i915: Lift i915_vma_parked() onto the gt
URL : https://patchwork.freedesktop.org/series/68329/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7142_full -> Patchwork_14907_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14907_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14907_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_14907_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock_vma:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-skl7/igt@i915_selftest@mock_vma.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-skl8/igt@i915_selftest@mock_vma.html
* igt@perf@short-reads:
- shard-hsw: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-hsw7/igt@p...@short-reads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-hsw6/igt@p...@short-reads.html
* igt@runner@aborted:
- shard-kbl: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-kbl1/igt@run...@aborted.html
- shard-apl: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-apl7/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@mock_vma:
- {shard-tglb}: [PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-tglb6/igt@i915_selftest@mock_vma.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-tglb2/igt@i915_selftest@mock_vma.html
* igt@runner@aborted:
- {shard-tglb}: NOTRUN -> [FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-tglb2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_14907_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd:
- shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#111325]) +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-iclb7/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-iclb1/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html
* igt@gem_userptr_blits@dmabuf-unsync:
- shard-snb: [PASS][12] -> [DMESG-WARN][13] ([fdo#111870])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-snb7/igt@gem_userptr_bl...@dmabuf-unsync.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-snb7/igt@gem_userptr_bl...@dmabuf-unsync.html
* igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
- shard-hsw: [PASS][14] -> [DMESG-WARN][15] ([fdo#111870]) +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-hsw1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-hsw1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
* igt@gem_workarounds@suspend-resume:
- shard-skl: [PASS][16] -> [INCOMPLETE][17] ([fdo#104108])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-skl4/igt@gem_workarou...@suspend-resume.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-skl10/igt@gem_workarou...@suspend-resume.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][18] -> [DMESG-WARN][19] ([fdo#108566]) +1
similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-apl2/igt@gem_workarou...@suspend-resume-context.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-apl4/igt@gem_workarou...@suspend-resume-context.html
* igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-kbl: [PASS][20] -> [SKIP][21] ([fdo#109271])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-kbl6/igt@i915_pm_rc6_reside...@rc6-accuracy.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html
* igt@i915_selftest@mock_vma:
- shard-hsw: [PASS][22] -> [INCOMPLETE][23] ([fdo#103540]) +1
similar issue
[22]:
https://intel-gfx-ci.01.org/tree/drm-t
Re: [Intel-gfx] [PULL] drm-misc-next
On Tue, 22 Oct 2019 at 01:49, Sean Paul wrote: > > On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen wrote: > > > > Hi, > > > > On 18/10/2019 23:11, Sean Paul wrote: > > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen > > > wrote: > > >> > > >> Hi Sean, > > >> > > >> On 17/10/2019 22:26, Sean Paul wrote: > > >> > > >>> concern for those. The omap OMAP_BO_MEM_* changes though I don't think > > >>> have > > >>> really reached non-TI eyes. There's no link in the commit message to a > > >>> UAPI > > >>> implementation and the only reference I could find is libkmsxx which > > >>> can set > > >>> them through the python bindings. Since this is TI-specific gunk in > > >>> TI-specific > > >>> headers I'm inclined to let it pass, but I would have liked to have this > > >>> conversation upfront. I figured I'd call this out so you have final say. > > >> > > >> There was some discussion about that a few years back when I initially > > >> sent the patches, but now that I look, the discussion died before really > > >> even starting. > > >> > > >> This is what I said about userspace implementation: > > >> > > >>> Yes, unfortunately that is not going to happen. I don't see how this > > >>> could be used in a generic system like Weston or X. It's meant for very > > >>> specific use cases, where you know exactly the requirements of your > > >>> application and the capabilities of the whole system, and optimize based > > >>> on that. > > > > > > Thanks for the context, Tomi. > > > > > > Indeed it looks like the discussion died, but Laurent still brought up > > > the u/s requirement and the patch was effectively dead until Daniel or > > > Dave weighed in. I'd expect at least some outreach before pushing the > > > patch directly 2+ years later. Has anything changed since then? > > > > There were new review rounds for the series this summer & autumn, but > > no, nothing else. I haven't specifically pinged anyone about the UAPI > > changes. > > > > This series introduces three new flags to an already existing UAPI, and, > > for whatever reason, this didn't register to me as a new UAPI, even if > > Laurent asked about it some years back. > > > > So, my mistake. > > > > The flags are added in a single patch, so I can easily push a revert for > > that if this patch is not acceptable. The rest of the series is cleanup. > > > > I'll wait for Dave or Daniel to weigh in on whether they want to take > this, otherwise I'll revert before sending the next pull and we can > have this conversation on the review. I'd rather we revert it, just to stick to some semblance of the rules, otherwise if we make execptions other people will drive trucks through them. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Introduce barrier pulses along engines (rev4)
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines (rev4)
URL : https://patchwork.freedesktop.org/series/68309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7142_full -> Patchwork_14906_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14906_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14906_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_14906_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@in-flight-contexts-10ms:
- shard-snb: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-snb1/igt@gem_...@in-flight-contexts-10ms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-snb2/igt@gem_...@in-flight-contexts-10ms.html
*
igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive:
- shard-apl: NOTRUN -> [TIMEOUT][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-apl3/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrash-inactive.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_shared@exec-single-timeline-bsd2:
- {shard-tglb}: [PASS][4] -> [INCOMPLETE][5] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-tglb5/igt@gem_ctx_sha...@exec-single-timeline-bsd2.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-tglb8/igt@gem_ctx_sha...@exec-single-timeline-bsd2.html
* igt@gem_ctx_switch@legacy-default-queue:
- {shard-tglb}: NOTRUN -> [INCOMPLETE][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-tglb8/igt@gem_ctx_swi...@legacy-default-queue.html
Known issues
Here are the changes found in Patchwork_14906_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@vcs1-none:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080])
+1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-iclb1/igt@gem_ctx_isolat...@vcs1-none.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-iclb5/igt@gem_ctx_isolat...@vcs1-none.html
* igt@gem_ctx_shared@q-smoketest-bsd2:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +10 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-iclb4/igt@gem_ctx_sha...@q-smoketest-bsd2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-iclb8/igt@gem_ctx_sha...@q-smoketest-bsd2.html
* igt@gem_ctx_switch@vcs1:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112080]) +3 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-iclb1/igt@gem_ctx_swi...@vcs1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-iclb5/igt@gem_ctx_swi...@vcs1.html
* igt@gem_eio@in-flight-contexts-10ms:
- shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-hsw7/igt@gem_...@in-flight-contexts-10ms.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-hsw5/igt@gem_...@in-flight-contexts-10ms.html
* igt@gem_exec_schedule@independent-bsd:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#111325]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-iclb8/igt@gem_exec_sched...@independent-bsd.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-iclb2/igt@gem_exec_sched...@independent-bsd.html
* igt@gem_linear_blits@interruptible:
- shard-apl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103927] /
[fdo#112067])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-apl3/igt@gem_linear_bl...@interruptible.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-apl5/igt@gem_linear_bl...@interruptible.html
* igt@gem_tiled_swapping@non-threaded:
- shard-apl: [PASS][19] -> [INCOMPLETE][20] ([fdo#103927]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/shard-apl3/igt@gem_tiled_swapp...@non-threaded.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/shard-apl5/igt@gem_tiled_swapp...@non-threaded.html
* igt@gem_userptr_blits@dmabuf-unsync:
- shard-snb: [PASS][21] -> [DMESG-WARN][22] ([fdo#111870])
[21]:
https://intel-gfx-ci
[Intel-gfx] [PATCH v7 i-g-t 4/4] kms_writeback: Add writeback-check-output
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
V6: Simon Ser
- Add igt documentation with igt_describe
- Replace int ret by unsigned int fd_id when calling igt_create_fb
- Add a descriptive error message if sync_fence_wait fail
- Replace color_idx variable by i
- Use in_fb instead of out_fb for getting the expected CRC
- Drop unnecessary parentheses
- Replace igt_fb_mod_to_tiling to DRM_FORMAT_MOD_LINEAR
Signed-off-by: Brian Starkey
[rebased and updated the patch to address feedback]
Signed-off-by: Rodrigo Siqueira
---
tests/kms_writeback.c | 123 ++
1 file changed, 123 insertions(+)
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
index a373ec4d..068595b9 100644
--- a/tests/kms_writeback.c
+++ b/tests/kms_writeback.c
@@ -30,6 +30,7 @@
#include "igt.h"
#include "igt_core.h"
#include "igt_fb.h"
+#include "sw_sync.h"
IGT_TEST_DESCRIPTION("Exercise writeback feature.");
@@ -196,6 +197,115 @@ static void writeback_test_fb(igt_output_t *output,
igt_fb_t *valid_fb, igt_fb_t
igt_assert(ret == -EINVAL);
}
+static void fill_fb(igt_fb_t *fb, double color[3])
+{
+ cairo_t *cr = igt_get_cairo_ctx(fb->fd, fb);
+ igt_assert(cr);
+
+ igt_paint_color(cr, 0, 0, fb->width, fb->height,
+ color[0], color[1], color[2]);
+}
+
+static void get_and_wait_out_fence(igt_output_t *output)
+{
+ int ret;
+
+ igt_assert(output->writeback_out_fence_fd >= 0);
+
+ ret = sync_fence_wait(output->writeback_out_fence_fd, 1000);
+ igt_assert_f(ret == 0, "sync_fence_wait failed: %s\n", strerror(-ret));
+ close(output->writeback_out_fence_fd);
+ output->writeback_out_fence_fd = -1;
+}
+
+static void writeback_sequence(igt_output_t *output, igt_plane_t *plane,
+ igt_fb_t *in_fb, igt_fb_t *out_fbs[], int
n_commits)
+{
+ int i;
+ double in_fb_colors[2][3] = {
+ { 1.0, 0.0, 0.0 },
+ { 0.0, 1.0, 0.0 },
+ };
+ double clear_color[3] = { 1.0, 1.0, 1.0 };
+ igt_crc_t cleared_crc, out_expected;
+
+ for (i = 0; i < n_commits; i++) {
+ /* Change the input color each time */
+ fill_fb(in_fb, in_fb_colors[i % 2]);
+
+ if (out_fbs[i]) {
+ igt_crc_t out_before;
+
+ /* Get the expected CRC */
+ igt_fb_get_crc(in_fb, &out_expected);
+
+ fill_fb(out_fbs[i], clear_color);
+ if (i == 0)
+ igt_fb_get_crc(out_fbs[i], &cleared_crc);
+ igt_fb_get_crc(out_fbs[i], &out_before);
+ igt_assert_crc_equal(&cleared_crc, &out_before);
+ }
+
+ /* Commit */
+ igt_plane_set_fb(plane, in_fb);
+ igt_output_set_writeback_fb(output, out_fbs[i]);
+
+ igt_display_commit_atomic(output->display,
+ DRM_MODE_ATOMIC_ALLOW_MODESET,
+ NULL);
+ if (out_fbs[i])
+ get_and_wait_out_fence(output);
+
+ /* Make sure the old output buffer is untouched */
+ if (i > 0 && out_fbs[i - 1] && out_fbs[i] != out_fbs[i - 1]) {
+ igt_crc_t out_prev;
+ igt_fb_get_crc(out_fbs[i - 1], &out_prev);
+ igt_assert_crc_equal(&cleared_crc, &out_prev);
+ }
+
+ /* Make sure this output buffer is written */
+ if (out_fbs[i]) {
+ igt_crc_t out_after;
+ igt_fb_get_crc(out_fbs[i], &out_after);
+ igt_assert_crc_equal(&out_expected, &out_after);
+
+ /* And clear it, for the next time */
+ fill_fb(out_fbs[i], clear_color);
+ }
+ }
+}
+
+static void writeback_check_output(igt_output_t *output, igt_plane_t *plane,
+ igt_fb_t *input_fb, igt_fb_t *output_fb)
+{
+ igt_fb_t *out_fbs[2] = { 0 };
+ igt_fb_t second_out_fb;
+ unsigned int fb_id;
+
+ /* One commit, with a writeback. */
+ writeback_sequence(output, plane, input_fb, &output_fb, 1);
+
+ /* Two commits, the second with no writeback */
+ out_fbs[0] = output_fb;
+ writeback_sequence(output, plane, input_fb, out_fbs, 2);
+
+ /* Two commits, both with writeback */
+ out_fbs[1] = output_fb;
+ writeback_sequence(output, plane, input_fb, out_fbs, 2);
+
+ fb_id = igt_create_fb(output_fb->fd,
+ output_fb->width, output_fb->height,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_MOD_LINEAR, &second_out_fb)
[Intel-gfx] [PATCH v7 i-g-t 3/4] lib: Add function to hash a framebuffer
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
(which can take advantage of word-access speedup), we can do the hash
on a cached copy, which is much faster (10x speedup on my platform).
V6: Simon Sir
- Replace #define by plain uint32_t variables
- Return -EINVAL in case fb->num_planes != 1
- Directly assign the mmap result to ptr
- No need to copy the whole stride, just copy fb->width * cpp since
we're only going to read that
v5: use igt_memcpy_from_wc() instead of plain memcpy, as suggested by
Chris Wilson
Signed-off-by: Brian Starkey
[rebased and updated to the most recent API]
Signed-off-by: Liviu Dudau
[rebased and updated the patch to address feedback]
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Simon Ser
---
lib/igt_fb.c | 68
lib/igt_fb.h | 2 ++
2 files changed, 70 insertions(+)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 6b674c1b..64d52634 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -3491,6 +3491,74 @@ bool igt_fb_supported_format(uint32_t drm_format)
return false;
}
+/*
+ * This implements the FNV-1a hashing algorithm instead of CRC, for
+ * simplicity
+ * http://www.isthe.com/chongo/tech/comp/fnv/index.html
+ *
+ * hash = offset_basis
+ * for each octet_of_data to be hashed
+ * hash = hash xor octet_of_data
+ * hash = hash * FNV_prime
+ * return hash
+ *
+ * 32 bit offset_basis = 2166136261
+ * 32 bit FNV_prime = 224 + 28 + 0x93 = 16777619
+ */
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc)
+{
+ uint32_t FNV1a_OFFSET_BIAS = 2166136261;
+ uint32_t FNV1a_PRIME = 16777619;
+ uint32_t hash;
+ void *map;
+ char *ptr, *line = NULL;
+ int x, y, cpp = igt_drm_format_to_bpp(fb->drm_format) / 8;
+ uint32_t stride = calc_plane_stride(fb, 0);
+
+ if (fb->num_planes != 1)
+ return -EINVAL;
+
+ if (fb->is_dumb)
+ ptr = kmstest_dumb_map_buffer(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ);
+ else
+ ptr = gem_mmap__gtt(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ);
+
+ /*
+* Framebuffers are often uncached, which can make byte-wise accesses
+* very slow. We copy each line of the FB into a local buffer to speed
+* up the hashing.
+*/
+ line = malloc(stride);
+ if (!line) {
+ munmap(map, fb->size);
+ return -ENOMEM;
+ }
+
+ hash = FNV1a_OFFSET_BIAS;
+
+ for (y = 0; y < fb->height; y++, ptr += stride) {
+
+ igt_memcpy_from_wc(line, ptr, fb->width * cpp);
+
+ for (x = 0; x < fb->width * cpp; x++) {
+ hash ^= line[x];
+ hash *= FNV1a_PRIME;
+ }
+ }
+
+ crc->n_words = 1;
+ crc->crc[0] = hash;
+
+ free(line);
+ munmap(map, fb->size);
+
+ return 0;
+#undef FNV1a_OFFSET_BIAS
+#undef FNV1a_PRIME
+}
+
/**
* igt_format_is_yuv:
* @drm_format: drm fourcc
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 69132b41..d2394638 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -202,5 +202,7 @@ int igt_format_plane_bpp(uint32_t drm_format, int plane);
void igt_format_array_fill(uint32_t **formats_array, unsigned int *count,
bool allow_yuv);
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc);
+
#endif /* __IGT_FB_H__ */
--
2.23.0
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 i-g-t 1/4] lib/igt_kms: Add writeback support
Add support in igt_kms for writeback connectors, with the ability
to attach framebuffers.
v5: Rebase and add DRM_CLIENT_CAP_WRITEBACK_CONNECTORS before
drmModeGetResources()
Signed-off-by: Brian Starkey
[rebased and updated to the latest igt style]
Signed-off-by: Liviu Dudau
Signed-off-by: Rodrigo Siqueira
Reviewed-by: Simon Ser
---
lib/igt_kms.c | 59 +++
lib/igt_kms.h | 6 ++
2 files changed, 65 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index e9b80b9b..2d7eabc6 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -412,6 +412,9 @@ const char * const
igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
[IGT_CONNECTOR_VRR_CAPABLE] = "vrr_capable",
[IGT_CONNECTOR_HDCP_CONTENT_TYPE] = "HDCP Content Type",
[IGT_CONNECTOR_LINK_STATUS] = "link-status",
+ [IGT_CONNECTOR_WRITEBACK_PIXEL_FORMATS] = "WRITEBACK_PIXEL_FORMATS",
+ [IGT_CONNECTOR_WRITEBACK_FB_ID] = "WRITEBACK_FB_ID",
+ [IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR] = "WRITEBACK_OUT_FENCE_PTR",
};
/*
@@ -644,6 +647,7 @@ static const struct type_name connector_type_names[] = {
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
+ { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{}
};
@@ -1853,6 +1857,14 @@ static void igt_output_reset(igt_output_t *output)
if (igt_output_has_prop(output, IGT_CONNECTOR_CONTENT_PROTECTION))
igt_output_set_prop_enum(output,
IGT_CONNECTOR_CONTENT_PROTECTION,
"Undesired");
+
+ if (igt_output_has_prop(output, IGT_CONNECTOR_WRITEBACK_FB_ID))
+ igt_output_set_prop_value(output,
IGT_CONNECTOR_WRITEBACK_FB_ID, 0);
+
+ if (igt_output_has_prop(output, IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR))
{
+ igt_output_clear_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR);
+ output->writeback_out_fence_fd = -1;
+ }
}
/**
@@ -1866,6 +1878,8 @@ static void igt_output_reset(igt_output_t *output)
* - %IGT_CONNECTOR_CRTC_ID
* - %IGT_CONNECTOR_BROADCAST_RGB (if applicable)
* %IGT_CONNECTOR_CONTENT_PROTECTION (if applicable)
+ * - %IGT_CONNECTOR_WRITEBACK_FB_ID
+ * - %IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR
* - igt_output_override_mode() to default.
*
* For pipes:
@@ -1935,6 +1949,8 @@ void igt_display_require(igt_display_t *display, int
drm_fd)
display->drm_fd = drm_fd;
+ drmSetClientCap(drm_fd, DRM_CLIENT_CAP_WRITEBACK_CONNECTORS, 1);
+
resources = drmModeGetResources(display->drm_fd);
if (!resources)
goto out;
@@ -2228,6 +2244,11 @@ static void igt_output_fini(igt_output_t *output)
kmstest_free_connector_config(&output->config);
free(output->name);
output->name = NULL;
+
+ if (output->writeback_out_fence_fd != -1) {
+ close(output->writeback_out_fence_fd);
+ output->writeback_out_fence_fd = -1;
+ }
}
/**
@@ -3290,6 +3311,11 @@ static void
igt_atomic_prepare_connector_commit(igt_output_t *output, drmModeAto
output->props[i],
output->values[i]));
}
+
+ if (output->writeback_out_fence_fd != -1) {
+ close(output->writeback_out_fence_fd);
+ output->writeback_out_fence_fd = -1;
+ }
}
/*
@@ -3412,6 +3438,16 @@ display_commit_changed(igt_display_t *display, enum
igt_commit_style s)
else
/* no modeset in universal commit, no change to crtc. */
output->changed &= 1 << IGT_CONNECTOR_CRTC_ID;
+
+ if (s == COMMIT_ATOMIC) {
+ if (igt_output_is_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR))
+ igt_assert(output->writeback_out_fence_fd >= 0);
+
+ output->values[IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR] =
0;
+ output->values[IGT_CONNECTOR_WRITEBACK_FB_ID] = 0;
+ igt_output_clear_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_FB_ID);
+ igt_output_clear_prop_changed(output,
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR);
+ }
}
if (display->first_commit) {
@@ -4084,6 +4120,29 @@ void igt_pipe_request_out_fence(igt_pipe_t *pipe)
igt_pipe_obj_set_prop_value(pipe, IGT_CRTC_OUT_FENCE_PTR,
(ptrdiff_t)&pipe->out_fence_fd);
}
+/**
+ * igt_output_set_writeback_fb:
+ * @output: Target output
+ * @fb: Target framebuffer
+ *
+ * This function sets the given @fb to be used as the target framebuffer for
the
+ * writeback engine at the next atomic commit. It will also request a writeback
+ * out fence that will contain the fd number of the out fence created by KMS if
+ * the given @fb is valid.
+ */
+void i
[Intel-gfx] [PATCH v7 i-g-t 2/4] kms_writeback: Add initial writeback tests
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
V6: Simon Ser
- Add igt documentation with igt_describe and IGT_TEST_DESCRIPTION
- Drop kmstest_force_connector with FORCE_CONNECTOR_ON in
kms_writeback_get_output since userspace won't do this operation
- Add an igt_debug statement in case we don't use writeback output
- Drop flags parameter from do_writeback_test
- Remove do_writeback_test "igt_assert(*out_fence_ptr == -1)" after
igt_display_try_commit_atomic
- Rename writeback_fb_id to writeback_test_fb
- Rework writeback_test_fb for checking buffer
- Move some tests from invalid_out_fence to writeback_test_fb
- Replace ret != 0 checking by ret == -EINVAL after invoke
do_writeback_test
- Assert on igt_output_get_plane_type()
- Replace igt_fb_mod_to_tiling to DRM_FORMAT_MOD_LINEAR
- Rename tests
- Replace int ret by unsigned int fd_id when calling igt_create_fb
Signed-off-by: Brian Starkey
[rebased and updated do_writeback_test() function to address feedback]
Signed-off-by: Liviu Dudau
[rebased and updated the patch to address feedback]
Signed-off-by: Rodrigo Siqueira
---
tests/Makefile.sources | 1 +
tests/kms_writeback.c | 290 +
tests/meson.build | 1 +
3 files changed, 292 insertions(+)
create mode 100644 tests/kms_writeback.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 343be050..331270ae 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -81,6 +81,7 @@ TESTS_progs = \
kms_universal_plane \
kms_vblank \
kms_vrr \
+ kms_writeback \
meta_test \
perf \
perf_pmu \
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
new file mode 100644
index ..a373ec4d
--- /dev/null
+++ b/tests/kms_writeback.c
@@ -0,0 +1,290 @@
+/*
+ * (C) COPYRIGHT 2017 ARM Limited. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#include "igt.h"
+#include "igt_core.h"
+#include "igt_fb.h"
+
+IGT_TEST_DESCRIPTION("Exercise writeback feature.");
+
+static drmModePropertyBlobRes *get_writeback_formats_blob(igt_output_t *output)
+{
+ drmModePropertyBlobRes *blob = NULL;
+ uint64_t blob_id;
+ int ret;
+
+ ret = kmstest_get_property(output->display->drm_fd,
+ output->config.connector->connector_id,
+ DRM_MODE_OBJECT_CONNECTOR,
+
igt_connector_prop_names[IGT_CONNECTOR_WRITEBACK_PIXEL_FORMATS],
+ NULL, &blob_id, NULL);
+ if (ret)
+ blob = drmModeGetPropertyBlob(output->display->drm_fd, blob_id);
+
+ igt_assert(blob);
+
+ return blob;
+}
+
+static bool check_writeback_config(igt_display_t *display, igt_output_t
*output)
+{
+ igt_fb_t input_fb, output_fb;
+ igt_plane_t *plane;
+ uint32_t writeback_format = DRM_FORMAT_XRGB;
+ int width, height, ret;
+ unsigned int fb_id;
+ drmModeModeInfo override_mode = {
+ .clock = 25175,
+ .hdisplay = 640,
+ .hsync_start = 656,
+ .hsync_end = 752,
+ .htotal = 800,
+ .hskew = 0,
+ .vdisplay = 480,
+ .vsync_start = 490,
+ .vsync_end = 492,
+ .vtotal = 525,
+ .vscan = 0,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .name = {"640x480-60"},
+ };
+ igt_output_override_mode(output, &override_mode);
+
+ width = override_mode.hdisplay;
+ height = override_mode.vdisplay;
+
+ fb_id = igt_create_fb(display->drm_fd, width, h
[Intel-gfx] [PATCH v7 i-g-t 0/4] Add support for testing writeback connectors
Hi, A couple of months ago, I updated and re-submitted a patchset made by Brian Starkey and Liviu Dudau for adding a writeback connectors test to IGT. It is important to highlight that DRM already have writeback connectors support, which is a way to expose in DRM the hardware functionality from display engines that allows writing back into memory the result of the DE's composition of supported planes. After I resubmitted the patchset, Simon Ser provides a long and detailed review for all of the patches (thanks Simon). As a result, I finally had time to go through all the details and prepare this new version. Follows some notes: 1. Patchset author Brian Starkey is the original author of this patchset, and I'm just trying to upstream his changes. Note that during this patch submission, the mail server from google going to overwrite Brian's mail by mine; this happens on the mail server side for avoiding malicious users to send emails as someone else. Note that I could spend time figuring out how to fix it, but I think this is not worth since I can fix it during the merge process (if it got accepted). 2. Drop the clone commits from the series After Simon's review, we decided to drop the last two patches of the original series since it was related to cloning output, and VKMS does not support it yet. However, after we finish with this series, I can try to take a look at this feature or maybe propose it as a GSoC/Outreachy project. 3. Changes Most of the changes happened in the second patch. Thanks Brian Starkey (4): lib/igt_kms: Add writeback support kms_writeback: Add initial writeback tests lib: Add function to hash a framebuffer kms_writeback: Add writeback-check-output lib/igt_fb.c | 68 +++ lib/igt_fb.h | 2 + lib/igt_kms.c | 59 ++ lib/igt_kms.h | 6 + tests/Makefile.sources | 1 + tests/kms_writeback.c | 413 + tests/meson.build | 1 + 7 files changed, 550 insertions(+) create mode 100644 tests/kms_writeback.c -- 2.23.0 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tc: Implement the TC cold exit sequence
On Sat, 2019-10-19 at 13:49 +0300, Imre Deak wrote:
> On Sat, Oct 19, 2019 at 02:59:14AM +0300, Souza, Jose wrote:
> > On Thu, 2019-10-03 at 17:50 +0300, Imre Deak wrote:
> > > On Mon, Sep 30, 2019 at 05:55:36PM -0700, José Roberto de Souza
> > > wrote:
> > > > This is required for legacy/static TC ports as IOM is not aware
> > > > of
> > > > the connection and will not trigger the TC cold exit.
> > > >
> > > > BSpec: 21750
> > > > BSpsc: 49294
> > > > Cc: Imre Deak
> > > > Cc: Lucas De Marchi
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_tc.c | 34
> > > > -
> > > >
> > > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > > 2 files changed, 29 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > index 7773169b7331..09b78027bdd5 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > @@ -7,6 +7,7 @@
> > > > #include "intel_display.h"
> > > > #include "intel_display_types.h"
> > > > #include "intel_dp_mst.h"
> > > > +#include "intel_sideband.h"
> > > > #include "intel_tc.h"
> > > >
> > > > static const char *tc_port_mode_name(enum tc_port_mode mode)
> > > > @@ -169,6 +170,22 @@ static void
> > > > tc_port_fixup_legacy_flag(struct
> > > > intel_digital_port *dig_port,
> > > > dig_port->tc_legacy_port = !dig_port->tc_legacy_port;
> > > > }
> > > >
> > > > +static int tc_cold_exit_request(struct drm_i915_private
> > > > *dev_priv)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + do {
> > > > + ret = sandybridge_pcode_write_timeout(dev_priv,
> > > > + ICL_PCODE
> > > > _EXIT_TC
> > > > COLD, 0,
> > > > + 250, 1);
> > > > +
> > > > + } while (ret == -EAGAIN);
> > > > +
> > > > + DRM_DEBUG_KMS("tccold exit %s\n", ret == 0 ?
> > > > "succeeded" :
> > > > "failed");
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > static u32 tc_port_live_status_mask(struct intel_digital_port
> > > > *dig_port)
> > > > {
> > > > struct drm_i915_private *i915 = to_i915(dig_port-
> > > > > base.base.dev);
> > > > @@ -177,13 +194,21 @@ static u32
> > > > tc_port_live_status_mask(struct
> > > > intel_digital_port *dig_port)
> > > > u32 mask = 0;
> > > > u32 val;
> > > >
> > > > + if (intel_uncore_read(uncore, SDEISR) &
> > > > SDE_TC_HOTPLUG_ICP(tc_port))
> > > > + mask |= BIT(TC_PORT_LEGACY);
> > > > +
> > > > val = intel_uncore_read(uncore,
> > > > PORT_TX_DFLEXDPSP(dig_port-
> > > > > tc_phy_fia));
> > > >
> > > > if (val == 0x) {
> > > > - DRM_DEBUG_KMS("Port %s: PHY in TCCOLD, nothing
> > > > connected\n",
> > > > - dig_port->tc_port_name);
> > > > - return mask;
> > > > + if (mask)
> > > > + tc_cold_exit_request(i915);
> >
> > Sorry for the delay, was OOO.
> >
> > > The semantic of the mbox command this needs is inherently racy on
> > > systems with preemption, the instruction to use it is:
> > >
> > > """
> > > Issue GT Driver mailbox command to exit TCCOLD, then complete
> > > steps
> > > b-d
> > > within 500 milliseconds to prevent re-entry.
> > > """
> > >
> > > We'd have to reach the point where we enable the AUX power in
> > > 500ms,
> > > which can't be guaranteed. Moreover TCCOLD could be entered just
> > > after
> > > reading PORT_TX_DFLEXDPSP, so we may not detect it.
> > >
> > > What we can do - after discussing with HW folks - is to first
> > > request
> > > AUX power and then issue the mbox command, which prevents TCCOLD
> > > re-entry until releasing the AUX power request. This also needs
> > > ignoring
> > > the timeout of the AUX power enabling ACK, since it will only be
> > > ACKed
> > > after exiting TCCOLD.
> >
> > Huum looks more robust indeed.
> >
> > > So I think we should block TCCOLD this way in
> > > __intel_tc_port_lock():
> > >
> > > if tc_link_refcount==0:
> > > intel_display_power_get(POWER_DOMAIN_AUX_)
> > > tc_cold_exit_request()
> >
> > So for non-legacy the IOM request to exit TCCOLD could have timed
> > out
> > at this point. But for most cases this will not happen, why not
> > here
> > read one FIA register and check if == 0x if so we call
> > tc_cold_exit_request().
>
> That would be racy, TCCOLD could be entered right after doing the FIA
> reg check. Getting the AUX power ref alone won't prevent a TCCOLD
> entry
> until the PCODE command has completed.
>
> > > if intel_tc_port_needs_reset():
> > > intel_tc_port_reset_mode()
> > > if tc_mode != LEGACY:
> > > intel_display_po
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/perf: Add helper macros for comparing with whitelisted registers
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/perf: Add helper macros for
comparing with whitelisted registers
URL : https://patchwork.freedesktop.org/series/68351/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7144 -> Patchwork_14910
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14910:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-kbl-8809g: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
- fi-cml-u2: [PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-cml-u2/igt@i915_selftest@live_gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-cml-u2/igt@i915_selftest@live_gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_14910 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@gem_mmap_...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-icl-u3/igt@gem_mmap_...@basic.html
Possible fixes
* igt@gem_mmap@basic:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@gem_m...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-icl-u3/igt@gem_m...@basic.html
* igt@i915_selftest@live_execlists:
- fi-icl-u2: [DMESG-FAIL][9] ([fdo#112046]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u2/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-icl-u2/igt@i915_selftest@live_execlists.html
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-cml-u: [DMESG-FAIL][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-dsi}: [INCOMPLETE][13] ([fdo#107713] / [fdo#108569]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][15] ([fdo#111407]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14910/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#112046]: https://bugs.freedesktop.org/show_bug.cgi?id=112046
Participating hosts (52 -> 46)
--
Additional (1): fi-kbl-soraka
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7144 -> Patchwork_14910
CI-20190529: 20190529
CI_DRM_7144: 5a109994e39e3c50909199ed6e970219155b5471 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14910: e93509d4da7437526a8c7ce394d4fbac34932278 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e93509d4da74 drm/i915/tgl: Add perf support on TGL
3901b4075132 drm/i915/perf: Add helper macros for comparing with whitelisted
registers
== Logs ==
Re: [Intel-gfx] [RFC 6/6] drm/i915/dp: Program vswing, pre-emphasis, test-pattern
On Thu, Oct 03, 2019 at 08:36:53PM +0530, Animesh Manna wrote:
> This patch process phy compliance request by programming requested
> vswing, pre-emphasis and test pattern.
So the design of this whole patch will need to be changed to work with the
whole kms infrastructure
Basically what you are doing here is handling the HPD test request, getting
the test patterns.
populating the intel_dp_compliance phytest struct and also writing the I915
regs right then and there.
This model does not fit the atomic KMS infrastructure, IMO this is how it
should look like:
1. Handle the test request
2. Prepare the PHY patterns where you erad the test patterns from DPCD and
populate
the intel_dp_compliance phytest struct
3. set test_active = true
4. Now in atomic_commit_tail somewhere just before enabling pipe, is where
based on if intel_dp_compliance.phytest not NULL you will need to call
ddi_disable, enable,
set_signal_levels, phy_update on the other hand all teh functions that write
data to the
I915 registers will need to happen here.
Clint, Jani N any thoughts here?
Regards
Manasi
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 62 +
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 93b1ce80c174..dd4c3a81c11d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4817,14 +4817,76 @@ static inline void intel_dp_phy_pattern_update(struct
> intel_dp *intel_dp)
> }
> }
>
> +static void
> +intel_dp_autotest_phy_ddi_disable(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum port port = intel_dig_port->base.port;
> + u32 ddi_buf_ctl_value, dp_tp_ctl_value, trans_ddi_func_ctl_value;
> +
> + ddi_buf_ctl_value = I915_READ(DDI_BUF_CTL(port));
> + dp_tp_ctl_value = I915_READ(DP_TP_CTL(port));
> + trans_ddi_func_ctl_value = I915_READ(TRANS_DDI_FUNC_CTL(port));
> +
> + ddi_buf_ctl_value&= ~(DDI_BUF_CTL_ENABLE | DDI_PORT_WIDTH_MASK);
> + dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
> + trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
> + DDI_PORT_WIDTH_MASK);
> +
> + I915_WRITE(DDI_BUF_CTL(port), ddi_buf_ctl_value);
> + I915_WRITE(DP_TP_CTL(port), dp_tp_ctl_value);
> + I915_WRITE(TRANS_DDI_FUNC_CTL(port), trans_ddi_func_ctl_value);
> +}
> +
> +static void
> +intel_dp_autotest_phy_ddi_enable(struct intel_dp *intel_dp, uint8_t lane_cnt)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum port port = intel_dig_port->base.port;
> + u32 ddi_buf_ctl_value, dp_tp_ctl_value, trans_ddi_func_ctl_value;
> +
> + ddi_buf_ctl_value = I915_READ(DDI_BUF_CTL(port));
> + dp_tp_ctl_value = I915_READ(DP_TP_CTL(port));
> + trans_ddi_func_ctl_value = I915_READ(TRANS_DDI_FUNC_CTL(port));
> +
> + ddi_buf_ctl_value|= DDI_BUF_CTL_ENABLE |
> + DDI_PORT_WIDTH(lane_cnt);
> + dp_tp_ctl_value |= DP_TP_CTL_ENABLE;
> + trans_ddi_func_ctl_value |= TRANS_DDI_FUNC_ENABLE |
> + DDI_PORT_WIDTH(lane_cnt);
> +
> + I915_WRITE(TRANS_DDI_FUNC_CTL(port), trans_ddi_func_ctl_value);
> + I915_WRITE(DP_TP_CTL(port), dp_tp_ctl_value);
> + I915_WRITE(DDI_BUF_CTL(port), ddi_buf_ctl_value);
> +}
> +
> static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
> {
> u8 test_result = DP_TEST_NAK;
> + struct drm_dp_phy_test_params *data =
> + &intel_dp->compliance.test_data.phytest;
>
> test_result = intel_dp_prepare_phytest(intel_dp);
> if (test_result != DP_TEST_ACK)
> DRM_ERROR("Phy test preparation failed\n");
>
> + intel_dp_autotest_phy_ddi_disable(intel_dp);
> +
> + intel_dp_set_signal_levels(intel_dp);
> +
> + intel_dp_phy_pattern_update(intel_dp);
> +
> + intel_dp_autotest_phy_ddi_enable(intel_dp, data->link.num_lanes);
> +
> + drm_dp_set_phy_test_pattern(&intel_dp->aux, data);
> +
> + /* Set test active flag here so userspace doesn't interrupt things */
> + intel_dp->compliance.test_active = 1;
> +
> return test_result;
> }
>
> --
> 2.22.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/6] drm/i915/dp: Preparation for DP phy compliance auto test.
On Thu, Oct 03, 2019 at 08:36:50PM +0530, Animesh Manna wrote:
> During DP phy compliance auto test mode, sink will request
> combination of different test pattern with differnt level of
> vswing, pre-emphasis. Function added to prepare for it.
>
> Signed-off-by: Animesh Manna
This patch looks good to me, could you add a comment for why
link_mst is set to false?
Manasi
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 29 +++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 976669f01a8c..5d6d44fa2594 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1142,6 +1142,7 @@ struct intel_dp_compliance_data {
> u8 video_pattern;
> u16 hdisplay, vdisplay;
> u8 bpc;
> + struct drm_dp_phy_test_params phytest;
> };
>
> struct intel_dp_compliance {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7d33e20dfc87..a19141fc672e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4738,9 +4738,38 @@ static u8 intel_dp_autotest_edid(struct intel_dp
> *intel_dp)
> return test_result;
> }
>
> +static u8 intel_dp_prepare_phytest(struct intel_dp *intel_dp)
> +{
> + struct drm_dp_phy_test_params *data =
> + &intel_dp->compliance.test_data.phytest;
> + u8 link_status[DP_LINK_STATUS_SIZE];
> +
> + if (!drm_dp_get_phy_test_pattern(&intel_dp->aux, data)) {
> + DRM_DEBUG_KMS("DP Phy Test pattern AUX read failure\n");
> + return DP_TEST_NAK;
> + }
> +
> + if (!intel_dp_get_link_status(intel_dp, link_status)) {
> + DRM_DEBUG_KMS("failed to get link status\n");
> + return DP_TEST_NAK;
> + }
> +
> + intel_dp->link_mst = false;
> +
> + /* retrieve vswing & pre-emphasis setting */
> + intel_get_adjust_train(intel_dp, link_status);
> +
> + return DP_TEST_ACK;
> +}
> +
> static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
> {
> u8 test_result = DP_TEST_NAK;
> +
> + test_result = intel_dp_prepare_phytest(intel_dp);
> + if (test_result != DP_TEST_ACK)
> + DRM_ERROR("Phy test preparation failed\n");
> +
> return test_result;
> }
>
> --
> 2.22.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/6] drm/dp: get/set phy compliance pattern.
On Thu, Oct 03, 2019 at 08:36:48PM +0530, Animesh Manna wrote:
> During phy complaince auto test mode source need to read
> requested test pattern from sink through DPCD. After processing
> the request source need to set the pattern. So set/get method
> added in drm layer as it is DP protocol.
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/drm_dp_helper.c | 77 +
> include/drm/drm_dp_helper.h | 28
> 2 files changed, 105 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f373798d82f6..3cb7170e55f4 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1484,3 +1484,80 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
> return num_bpc;
> }
> EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
> +
> +/**
> + * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data)
> +{
> + int err;
> +
> + err = drm_dp_link_probe(aux, &data->link);
> + if (err < 0)
> + return err;
> +
> + err = drm_dp_dpcd_read(aux, DP_TEST_PHY_PATTERN, &data->phy_pattern, 1);
Just use drm_dp_dpcd_readb
> + if (err < 0)
> + return err;
> +
> + switch (data->phy_pattern) {
> + case DP_TEST_PHY_PATTERN_80BIT_CUSTOM:
> + err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
> +&data->custom80, 10);
> + if (err < 0)
> + return err;
> +
> + break;
> + case DP_TEST_PHY_PATTERN_CP2520:
> + err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
> +&data->hbr2_reset, 2);
> + if (err < 0)
> + return err;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
> +
> +/**
> + * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
> + * @aux: DisplayPort AUX channel
> + * @data: DP phy compliance test parameters.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
> + struct drm_dp_phy_test_params *data)
> +{
> + int err, i;
> + u8 test_pattern;
> +
> + err = drm_dp_link_configure(aux, &data->link);
> + if (err < 0)
> + return err;
> +
> + test_pattern = data->phy_pattern;
> + if (data->link.revision < 0x12) {
> + test_pattern = (test_pattern << 2) &
> +DP_LINK_QUAL_PATTERN_11_MASK;
> + err = drm_dp_dpcd_write(aux, DP_TRAINING_PATTERN_SET,
> + &test_pattern, 1);
Same, just use drm_dp_dpcd_writeb
> + if (err < 0)
> + return err;
> + } else {
> + for (i = 0; i < data->link.num_lanes; i++) {
> + err = drm_dp_dpcd_write(aux, DP_LINK_QUAL_LANE0_SET + i,
> + &test_pattern, 1);
> + if (err < 0)
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index ed1a985745ba..77dcf5879beb 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -691,6 +691,14 @@
> # define DP_TEST_COUNT_MASK 0xf
>
> #define DP_TEST_PHY_PATTERN 0x248
This should be consistent with spec name DP_PHY_TEST_PATTERN
And since the bits below are part of the 2:0 PATTERN_SEL, I would prefer
having DP_PHY_TEST_PATTERN_SEL_MASK 0x7
> +# define DP_TEST_PHY_PATTERN_NONE 0
^ 0x0
> +# define DP_TEST_PHY_PATTERN_D10_2 1
^ 0x1 (to be consistent with
other bit defs in .h file)
Manasi
> +# define DP_TEST_PHY_PATTERN_ERROR_COUNT2
> +# define DP_TEST_PHY_PATTERN_PRBS7 3
> +# define DP_TEST_PHY_PATTERN_80BIT_CUSTOM 4
> +# define DP_TEST_PHY_PATTERN_CP2520 5
> +
> +#define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
> #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
> #define DP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251
> #define DP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252
> @@ -1523,4 +1531,24 @@ static inline void drm_dp_cec_unset_edid(struct
> drm_dp_aux *aux)
>
> #endif
>
> +/**
> + * struct drm_dp_phy_test_params - DP Phy Compliance parameters
> + * @link: Link information.
> + * @phy_pattern: DP Ph
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/perf: Add helper macros for comparing with whitelisted registers
== Series Details == Series: series starting with [v2,1/2] drm/i915/perf: Add helper macros for comparing with whitelisted registers URL : https://patchwork.freedesktop.org/series/68351/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/perf: Add helper macros for comparing with whitelisted registers Okay! Commit: drm/i915/tgl: Add perf support on TGL +drivers/gpu/drm/i915/i915_perf.c:2439:85: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/perf: Add helper macros for comparing with whitelisted registers
== Series Details == Series: series starting with [v2,1/2] drm/i915/perf: Add helper macros for comparing with whitelisted registers URL : https://patchwork.freedesktop.org/series/68351/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3901b4075132 drm/i915/perf: Add helper macros for comparing with whitelisted registers -:21: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'addr' - possible side-effects? #21: FILE: drivers/gpu/drm/i915/i915_perf.c:3518: +#define ADDR_IN_RANGE(addr, start, end) \ + ((addr) >= (start) && \ +(addr) <= (end)) -:25: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'addr' - possible side-effects? #25: FILE: drivers/gpu/drm/i915/i915_perf.c:3522: +#define REG_IN_RANGE(addr, start, end) \ + ((addr) >= i915_mmio_reg_offset(start) && \ +(addr) <= i915_mmio_reg_offset(end)) total: 0 errors, 0 warnings, 2 checks, 98 lines checked e93509d4da74 drm/i915/tgl: Add perf support on TGL -:446: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "oa_config" #446: FILE: drivers/gpu/drm/i915/i915_perf.c:2470: + oa_config != NULL); -:825: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #825: new file mode 100644 total: 0 errors, 1 warnings, 1 checks, 861 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tc: Clear DKL_TX_PMD_LANE_SUS before program voltage swing
== Series Details ==
Series: drm/i915/tc: Clear DKL_TX_PMD_LANE_SUS before program voltage swing
URL : https://patchwork.freedesktop.org/series/68349/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7144 -> Patchwork_14909
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14909:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-skl-6600u: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-skl-6600u/igt@i915_selftest@live_gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/fi-skl-6600u/igt@i915_selftest@live_gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_14909 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] /
[fdo#111381])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
Possible fixes
* igt@gem_mmap@basic:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@gem_m...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/fi-icl-u3/igt@gem_m...@basic.html
* igt@i915_selftest@live_execlists:
- fi-icl-u2: [DMESG-FAIL][9] ([fdo#112046]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u2/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/fi-icl-u2/igt@i915_selftest@live_execlists.html
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-cml-u: [DMESG-FAIL][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-dsi}: [INCOMPLETE][13] ([fdo#107713] / [fdo#108569]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
[fdo#111747]: https://bugs.freedesktop.org/show_bug.cgi?id=111747
[fdo#111887]: https://bugs.freedesktop.org/show_bug.cgi?id=111887
[fdo#112046]: https://bugs.freedesktop.org/show_bug.cgi?id=112046
Participating hosts (52 -> 46)
--
Additional (1): fi-kbl-soraka
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7144 -> Patchwork_14909
CI-20190529: 20190529
CI_DRM_7144: 5a109994e39e3c50909199ed6e970219155b5471 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14909: a55c16774ed26be26bef21df150f2f2330dbdd3e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a55c16774ed2 drm/i915/tc: Clear DKL_TX_PMD_LANE_SUS before program voltage swing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14909/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
Re: [Intel-gfx] [RFC 2/6] drm/i915/dp: Move vswing/pre-emphasis adjustment calculation
On Thu, Oct 03, 2019 at 08:36:49PM +0530, Animesh Manna wrote:
> vswing/pre-emphasis adjustment calculation is needed in processing
> of auto phy compliance request other than link training, so moved
> the same function in intel_dp.c.
>
> No functional change.
You could just make it a non static function instead of moving to intel_dp.c
Manasi
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 32 +++
> drivers/gpu/drm/i915/display/intel_dp.h | 3 ++
> .../drm/i915/display/intel_dp_link_training.c | 32 ---
> 3 files changed, 35 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1aa39e92f0df..7d33e20dfc87 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4026,6 +4026,38 @@ ivb_cpu_edp_signal_levels(u8 train_set)
> }
> }
>
> +void
> +intel_get_adjust_train(struct intel_dp *intel_dp,
> +const u8 *link_status)
> +{
> + u8 v = 0;
> + u8 p = 0;
> + int lane;
> + u8 voltage_max;
> + u8 preemph_max;
> +
> + for (lane = 0; lane < intel_dp->lane_count; lane++) {
> + u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
> lane);
> + u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
> lane);
> +
> + if (this_v > v)
> + v = this_v;
> + if (this_p > p)
> + p = this_p;
> + }
> +
> + voltage_max = intel_dp_voltage_max(intel_dp);
> + if (v >= voltage_max)
> + v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
> +
> + preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
> + if (p >= preemph_max)
> + p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> +
> + for (lane = 0; lane < 4; lane++)
> + intel_dp->train_set[lane] = v | p;
> +}
> +
> void
> intel_dp_set_signal_levels(struct intel_dp *intel_dp)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index a194b5b6da05..8f8333afd43d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -91,6 +91,9 @@ void
> intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
> u8 dp_train_pat);
> void
> +intel_get_adjust_train(struct intel_dp *intel_dp,
> +const u8 *link_status);
> +void
> intel_dp_set_signal_levels(struct intel_dp *intel_dp);
> void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
> u8
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 2a1130dd1ad0..1e38584e7d56 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -34,38 +34,6 @@ intel_dp_dump_link_status(const u8
> link_status[DP_LINK_STATUS_SIZE])
> link_status[3], link_status[4], link_status[5]);
> }
>
> -static void
> -intel_get_adjust_train(struct intel_dp *intel_dp,
> -const u8 link_status[DP_LINK_STATUS_SIZE])
> -{
> - u8 v = 0;
> - u8 p = 0;
> - int lane;
> - u8 voltage_max;
> - u8 preemph_max;
> -
> - for (lane = 0; lane < intel_dp->lane_count; lane++) {
> - u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
> lane);
> - u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
> lane);
> -
> - if (this_v > v)
> - v = this_v;
> - if (this_p > p)
> - p = this_p;
> - }
> -
> - voltage_max = intel_dp_voltage_max(intel_dp);
> - if (v >= voltage_max)
> - v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
> -
> - preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
> - if (p >= preemph_max)
> - p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> -
> - for (lane = 0; lane < 4; lane++)
> - intel_dp->train_set[lane] = v | p;
> -}
> -
> static bool
> intel_dp_set_link_train(struct intel_dp *intel_dp,
> u8 dp_train_pat)
> --
> 2.22.0
>
___
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/tgl: Add perf support on TGL
From: Lionel Landwerlin
The design of the OA unit has been split into several units. We now
have a global unit (OAG) and a render specific unit (OAR). This leads
to some changes on how we program things. Some details :
OAR:
- has its own set of counter registers, they are per-context
saved/restored
- counters are not written to the circular OA buffer
- a snapshot of the counters can be acquired with
MI_RECORD_PERF_COUNT, or a single counter can be read with
MI_STORE_REGISTER_MEM.
OAG:
- has global counters that increment across context switches
- counters are written into the circular OA buffer (if requested)
v2: Fix checkpatch warnings on code style (Lucas)
v3: (Umesh)
- Update register from which tail, status and head are read
- Update logic to sample context reports
- Update whitelist mux and b counter regs
v4: Fix a bug when updating context image for new contexts (Umesh)
v5: Squash patch enabling save/restore of counters into context image
We want this so we can preempt performance queries and keep the
system responsive even when long running queries are ongoing. We
avoid doing it for all contexts.
- use LRI to modify context control (Chris)
- use MASKED_FIELD to program just the masked bits (Chris)
- disable save/restore of counters on cleanup (Chris)
BSpec: 28727, 30021
Signed-off-by: Lionel Landwerlin
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/gt/intel_lrc.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 349 +++---
drivers/gpu/drm/i915/i915_reg.h | 103
drivers/gpu/drm/i915/oa/i915_oa_tgl.c | 121 +
drivers/gpu/drm/i915/oa/i915_oa_tgl.h | 16 ++
6 files changed, 558 insertions(+), 35 deletions(-)
create mode 100644 drivers/gpu/drm/i915/oa/i915_oa_tgl.c
create mode 100644 drivers/gpu/drm/i915/oa/i915_oa_tgl.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2fd4bed188e5..75d9493850d6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -244,7 +244,8 @@ i915-y += \
oa/i915_oa_cflgt2.o \
oa/i915_oa_cflgt3.o \
oa/i915_oa_cnl.o \
- oa/i915_oa_icl.o
+ oa/i915_oa_icl.o \
+ oa/i915_oa_tgl.o
i915-y += i915_perf.o
# Post-mortem debug and GPU hang state capture
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index 99dc576a4e25..b6daac712c9e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -43,6 +43,7 @@ struct intel_engine_cs;
#define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0)
#define CTX_CTRL_RS_CTX_ENABLE (1 << 1)
#define CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT (1 << 2)
+#define GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE (1 << 8)
#define RING_CONTEXT_STATUS_PTR(base) _MMIO((base) + 0x3a0)
#define RING_EXECLIST_SQ_CONTENTS(base)_MMIO((base) + 0x510)
#define RING_EXECLIST_CONTROL(base)_MMIO((base) + 0x550)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index f098e0c05a59..69f6ece26d5b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -217,6 +217,7 @@
#include "oa/i915_oa_cflgt3.h"
#include "oa/i915_oa_cnl.h"
#include "oa/i915_oa_icl.h"
+#include "oa/i915_oa_tgl.h"
/* HW requires this to be a power of two, between 128k and 16M, though driver
* is currently generally designed assuming the largest 16M size is used such
@@ -292,7 +293,8 @@ static u32 i915_perf_stream_paranoid = true;
#define INVALID_CTX_ID 0x
/* On Gen8+ automatically triggered OA reports include a 'reason' field... */
-#define OAREPORT_REASON_MASK 0x3f
+#define OAREPORT_REASON_MASK (IS_GEN(stream->perf->i915, 12) ? \
+ 0x7f : 0x3f)
#define OAREPORT_REASON_SHIFT 19
#define OAREPORT_REASON_TIMER (1<<0)
#define OAREPORT_REASON_CTX_SWITCH (1<<3)
@@ -338,6 +340,10 @@ static const struct i915_oa_format
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_C4_B8] = { 7, 64 },
};
+static const struct i915_oa_format gen12_oa_formats[I915_OA_FORMAT_MAX] = {
+ [I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
+};
+
#define SAMPLE_OA_REPORT (1<<0)
/**
@@ -418,6 +424,14 @@ static void free_oa_config_bo(struct i915_oa_config_bo
*oa_bo)
kfree(oa_bo);
}
+static u32 gen12_oa_hw_tail_read(struct i915_perf_stream *stream)
+{
+ struct intel_uncore *uncore = stream->uncore;
+
+ return intel_uncore_read(uncore, GEN12_OAG_OATAILPTR) &
+ GEN12_OAG_OATAILPTR_MASK;
+}
+
static u32 gen8_oa_hw_tail_read(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
@@ -538,7 +552,7 @@ static bool oa_buffer_chec
[Intel-gfx] [PATCH v2 1/2] drm/i915/perf: Add helper macros for comparing with whitelisted registers
Add helper macros for range and equality comparisons and use them to
check with whitelisted registers in oa configurations.
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 54 +---
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d2ac51fe4f04..f098e0c05a59 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3515,56 +3515,58 @@ static bool gen8_is_valid_flex_addr(struct i915_perf
*perf, u32 addr)
return false;
}
+#define ADDR_IN_RANGE(addr, start, end) \
+ ((addr) >= (start) && \
+(addr) <= (end))
+
+#define REG_IN_RANGE(addr, start, end) \
+ ((addr) >= i915_mmio_reg_offset(start) && \
+(addr) <= i915_mmio_reg_offset(end))
+
+#define REG_EQUAL(addr, mmio) \
+ ((addr) == i915_mmio_reg_offset(mmio))
+
static bool gen7_is_valid_b_counter_addr(struct i915_perf *perf, u32 addr)
{
- return (addr >= i915_mmio_reg_offset(OASTARTTRIG1) &&
- addr <= i915_mmio_reg_offset(OASTARTTRIG8)) ||
- (addr >= i915_mmio_reg_offset(OAREPORTTRIG1) &&
-addr <= i915_mmio_reg_offset(OAREPORTTRIG8)) ||
- (addr >= i915_mmio_reg_offset(OACEC0_0) &&
-addr <= i915_mmio_reg_offset(OACEC7_1));
+ return REG_IN_RANGE(addr, OASTARTTRIG1, OASTARTTRIG8) ||
+ REG_IN_RANGE(addr, OAREPORTTRIG1, OAREPORTTRIG8) ||
+ REG_IN_RANGE(addr, OACEC0_0, OACEC7_1);
}
static bool gen7_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
- return addr == i915_mmio_reg_offset(HALF_SLICE_CHICKEN2) ||
- (addr >= i915_mmio_reg_offset(MICRO_BP0_0) &&
-addr <= i915_mmio_reg_offset(NOA_WRITE)) ||
- (addr >= i915_mmio_reg_offset(OA_PERFCNT1_LO) &&
-addr <= i915_mmio_reg_offset(OA_PERFCNT2_HI)) ||
- (addr >= i915_mmio_reg_offset(OA_PERFMATRIX_LO) &&
-addr <= i915_mmio_reg_offset(OA_PERFMATRIX_HI));
+ return REG_EQUAL(addr, HALF_SLICE_CHICKEN2) ||
+ REG_IN_RANGE(addr, MICRO_BP0_0, NOA_WRITE) ||
+ REG_IN_RANGE(addr, OA_PERFCNT1_LO, OA_PERFCNT2_HI) ||
+ REG_IN_RANGE(addr, OA_PERFMATRIX_LO, OA_PERFMATRIX_HI);
}
static bool gen8_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen7_is_valid_mux_addr(perf, addr) ||
- addr == i915_mmio_reg_offset(WAIT_FOR_RC6_EXIT) ||
- (addr >= i915_mmio_reg_offset(RPM_CONFIG0) &&
-addr <= i915_mmio_reg_offset(NOA_CONFIG(8)));
+ REG_EQUAL(addr, WAIT_FOR_RC6_EXIT) ||
+ REG_IN_RANGE(addr, RPM_CONFIG0, NOA_CONFIG(8));
}
static bool gen10_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen8_is_valid_mux_addr(perf, addr) ||
- addr == i915_mmio_reg_offset(GEN10_NOA_WRITE_HIGH) ||
- (addr >= i915_mmio_reg_offset(OA_PERFCNT3_LO) &&
-addr <= i915_mmio_reg_offset(OA_PERFCNT4_HI));
+ REG_EQUAL(addr, GEN10_NOA_WRITE_HIGH) ||
+ REG_IN_RANGE(addr, OA_PERFCNT3_LO, OA_PERFCNT4_HI);
}
static bool hsw_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen7_is_valid_mux_addr(perf, addr) ||
- (addr >= 0x25100 && addr <= 0x2FF90) ||
- (addr >= i915_mmio_reg_offset(HSW_MBVID2_NOA0) &&
-addr <= i915_mmio_reg_offset(HSW_MBVID2_NOA9)) ||
- addr == i915_mmio_reg_offset(HSW_MBVID2_MISR0);
+ ADDR_IN_RANGE(addr, 0x25100, 0x2FF90) ||
+ REG_IN_RANGE(addr, HSW_MBVID2_NOA0, HSW_MBVID2_NOA9) ||
+ REG_EQUAL(addr, HSW_MBVID2_MISR0);
}
static bool chv_is_valid_mux_addr(struct i915_perf *perf, u32 addr)
{
return gen7_is_valid_mux_addr(perf, addr) ||
- (addr >= 0x182300 && addr <= 0x1823A4);
+ ADDR_IN_RANGE(addr, 0x182300, 0x1823A4);
}
static u32 mask_reg_value(u32 reg, u32 val)
@@ -3573,14 +3575,14 @@ static u32 mask_reg_value(u32 reg, u32 val)
* WaDisableSTUnitPowerOptimization workaround. Make sure the value
* programmed by userspace doesn't change this.
*/
- if (i915_mmio_reg_offset(HALF_SLICE_CHICKEN2) == reg)
+ if (REG_EQUAL(reg, HALF_SLICE_CHICKEN2))
val = val & ~_MASKED_BIT_ENABLE(GEN8_ST_PO_DISABLE);
/* WAIT_FOR_RC6_EXIT has only one bit fullfilling the function
* indicated by its name and a bunch of selection fields used by OA
* configs.
*/
- if (i915_mmio_reg_offset(WAIT_FOR_RC6_EXIT) == reg)
+ if (REG_EQUAL(reg, WAIT_FOR_RC6_EXIT))
val = val & ~_MASKED_BIT_ENABLE(HSW_WAIT_FOR_RC6_EXIT_ENABLE);
return val;
--
2.20.1
___
Intel-gfx mailin
[Intel-gfx] linux-next: build warning after merge of the vfs-fixes tree
Hi all,
[Some people didn't get this due to a typo]
This should have been reported against the vfs-fixes tree, sorry.
On Tue, 22 Oct 2019 08:07:34 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc-fixes tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from include/uapi/linux/posix_types.h:5,
> from include/uapi/linux/types.h:14,
> from include/linux/types.h:6,
> from include/linux/limits.h:6,
> from include/linux/kernel.h:7,
> from fs/aio.c:14:
> fs/aio.c: In function '__do_compat_sys_io_pgetevents':
> include/linux/stddef.h:8:14: warning: initialization of 'unsigned int' from
> 'void *' makes integer from pointer without a cast [-Wint-conversion]
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2196:38: note: in expansion of macro 'NULL'
> 2196 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
> include/linux/stddef.h:8:14: note: (near initialization for 'ksig.sigmask')
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2196:38: note: in expansion of macro 'NULL'
> 2196 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
> fs/aio.c: In function '__do_compat_sys_io_pgetevents_time64':
> include/linux/stddef.h:8:14: warning: initialization of 'unsigned int' from
> 'void *' makes integer from pointer without a cast [-Wint-conversion]
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2231:38: note: in expansion of macro 'NULL'
> 2231 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
> include/linux/stddef.h:8:14: note: (near initialization for 'ksig.sigmask')
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2231:38: note: in expansion of macro 'NULL'
> 2231 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
>
> Introduced by commit
>
> de80166a573d ("aio: Fix io_pgetevents() struct __compat_aio_sigset layout")
--
Cheers,
Stephen Rothwell
pgp5OublkBd30.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Use all physical engines for i915_active
== Series Details ==
Series: drm/i915/selftests: Use all physical engines for i915_active
URL : https://patchwork.freedesktop.org/series/68322/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7141_full -> Patchwork_14905_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14905_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14905_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_14905_full:
### IGT changes ###
Possible regressions
* igt@gem_tiled_blits@interruptible:
- shard-glk: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-glk4/igt@gem_tiled_bl...@interruptible.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-glk8/igt@gem_tiled_bl...@interruptible.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
- {shard-tglb}: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-tglb8/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html
### Piglit changes ###
Possible regressions
* spec@!opengl 1.2@tex3d-maxsize:
- pig-hsw-4770r: NOTRUN -> [FAIL][4]
[4]: None
Known issues
Here are the changes found in Patchwork_14905_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic-invalid-context-vcs1:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +6 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb4/igt@gem_ctx_e...@basic-invalid-context-vcs1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-iclb5/igt@gem_ctx_e...@basic-invalid-context-vcs1.html
* igt@gem_ctx_isolation@vcs1-clean:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080])
+1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb2/igt@gem_ctx_isolat...@vcs1-clean.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-iclb7/igt@gem_ctx_isolat...@vcs1-clean.html
* igt@gem_exec_schedule@fifo-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +8 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-iclb6/igt@gem_exec_sched...@fifo-bsd1.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#111325]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb8/igt@gem_exec_sched...@preempt-bsd.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-iclb1/igt@gem_exec_sched...@preempt-bsd.html
* igt@gem_linear_blits@interruptible:
- shard-apl: [PASS][13] -> [INCOMPLETE][14] ([fdo#103927] /
[fdo#112067])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-apl4/igt@gem_linear_bl...@interruptible.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-apl7/igt@gem_linear_bl...@interruptible.html
* igt@gem_tiled_pread_pwrite:
- shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([fdo#107713] /
[fdo#109100])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb7/igt@gem_tiled_pread_pwrite.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-iclb7/igt@gem_tiled_pread_pwrite.html
* igt@gem_userptr_blits@dmabuf-unsync:
- shard-snb: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-snb7/igt@gem_userptr_bl...@dmabuf-unsync.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-snb6/igt@gem_userptr_bl...@dmabuf-unsync.html
* igt@gem_userptr_blits@sync-unmap-after-close:
- shard-hsw: [PASS][19] -> [DMESG-WARN][20] ([fdo#111870]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-hsw1/igt@gem_userptr_bl...@sync-unmap-after-close.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/shard-hsw2/igt@gem_userptr_bl...@sync-unmap-after-close.html
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- shard-glk: [PASS][21] -> [DMESG-WARN][22] ([fdo#105763] /
[fdo#106538])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_
[Intel-gfx] [PATCH] drm/i915/tc: Clear DKL_TX_PMD_LANE_SUS before program voltage swing
This sequence was recently added to fix internal HW sequences to
reset TC ports.
HSDES: 1507287614
HSDES: 14010071447
BSpec: 49292
Cc: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9ba794cb9b4f..74cfdd8dfec4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2838,6 +2838,8 @@ tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder
*encoder, int link_clock,
for (ln = 0; ln < 2; ln++) {
I915_WRITE(HIP_INDEX_REG(tc_port), HIP_INDEX_VAL(tc_port, ln));
+ I915_WRITE(DKL_TX_PMD_LANE_SUS(tc_port), 0);
+
/* All the registers are RMW */
val = I915_READ(DKL_TX_DPCNTL0(tc_port));
val &= ~dpcnt_mask;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 855db888516c..767891c0332b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10249,6 +10249,12 @@ enum skl_power_gate {
_DKL_PHY2_BASE) + \
_DKL_TX_FW_CALIB)
+#define _DKL_TX_PMD_LANE_SUS 0xD00
+#define DKL_TX_PMD_LANE_SUS(tc_port) _MMIO(_PORT(tc_port, \
+ _DKL_PHY1_BASE, \
+ _DKL_PHY2_BASE) + \
+ _DKL_TX_PMD_LANE_SUS)
+
#define _DKL_TX_DW17 0xDC4
#define DKL_TX_DW17(tc_port) _MMIO(_PORT(tc_port, \
_DKL_PHY1_BASE, \
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] dma-buf: change DMA-buf locking convention v2
== Series Details ==
Series: series starting with [1/4] dma-buf: change DMA-buf locking convention v2
URL : https://patchwork.freedesktop.org/series/68330/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7144 -> Patchwork_14908
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14908:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-kbl-8809g: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-6770hq: [PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-skl-6770hq/igt@i915_selftest@live_gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-skl-6770hq/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-iommu: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-skl-iommu/igt@i915_selftest@live_gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-skl-iommu/igt@i915_selftest@live_gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_14908 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_busy@basic-wait-before-default:
- fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
Possible fixes
* igt@gem_mmap@basic:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u3/igt@gem_m...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-icl-u3/igt@gem_m...@basic.html
* igt@i915_selftest@live_execlists:
- fi-icl-u2: [DMESG-FAIL][11] ([fdo#112046]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-u2/igt@i915_selftest@live_execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-icl-u2/igt@i915_selftest@live_execlists.html
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-cml-u: [DMESG-FAIL][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-cml-u/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-dsi}: [INCOMPLETE][15] ([fdo#107713] / [fdo#108569]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7144/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14908/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111880]: https://bugs.freedesktop.org/show_bug.cgi?id=111880
[fdo#112046]: https://bugs.freedesktop.org/show_bug.cgi?id=112046
Participating hosts (52 -> 46)
--
Additional (1): fi-kbl-soraka
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7144 -> Patchwork_14908
CI-20190529: 20190529
CI_DRM_7144: 5a109994e39e3c50909199ed6e970219155b5471 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @
git://ano
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] dma-buf: change DMA-buf locking convention v2
== Series Details == Series: series starting with [1/4] dma-buf: change DMA-buf locking convention v2 URL : https://patchwork.freedesktop.org/series/68330/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: dma-buf: change DMA-buf locking convention v2 Okay! Commit: dma-buf: stop using the dmabuf->lock so much Okay! Commit: drm/amdgpu: add independent DMA-buf export v7 -drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:353:16: warning: symbol 'amdgpu_gem_prime_export' was not declared. Should it be static? -drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:385:23: warning: symbol 'amdgpu_gem_prime_import_sg_table' was not declared. Should it be static? -drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:434:23: warning: symbol 'amdgpu_gem_prime_import' was not declared. Should it be static? -drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:51:6: warning: symbol 'amdgpu_gem_prime_vmap' was not declared. Should it be static? -drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:71:6: warning: symbol 'amdgpu_gem_prime_vunmap' was not declared. Should it be static? -drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:89:5: warning: symbol 'amdgpu_gem_prime_mmap' was not declared. Should it be static? -O:drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:310:26: warning: symbol 'amdgpu_dmabuf_ops' was not declared. Should it be static? -O:drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:49:17: warning: symbol 'amdgpu_gem_prime_get_sg_table' was not declared. Should it be static? Commit: drm/amdgpu: add independent DMA-buf import v8 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 series starting with [1/4] dma-buf: change DMA-buf locking convention v2
== Series Details == Series: series starting with [1/4] dma-buf: change DMA-buf locking convention v2 URL : https://patchwork.freedesktop.org/series/68330/ State : warning == Summary == $ dim checkpatch origin/drm-tip d8e1ae91bced dma-buf: change DMA-buf locking convention v2 -:374: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 316 lines checked 8e66d2945c28 dma-buf: stop using the dmabuf->lock so much -:82: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 58 lines checked 126819454efd drm/amdgpu: add independent DMA-buf export v7 -:291: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 245 lines checked 24892628be48 drm/amdgpu: add independent DMA-buf import v8 -:220: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Christian König ' total: 0 errors, 1 warnings, 0 checks, 168 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for dma_resv lockdep annotations/priming
== Series Details ==
Series: dma_resv lockdep annotations/priming
URL : https://patchwork.freedesktop.org/series/68312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7141_full -> Patchwork_14903_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_14903_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_switch@legacy-default-queue:
- {shard-tglb}: [PASS][1] -> [INCOMPLETE][2] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-tglb8/igt@gem_ctx_swi...@legacy-default-queue.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-tglb8/igt@gem_ctx_swi...@legacy-default-queue.html
Known issues
Here are the changes found in Patchwork_14903_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic-invalid-context-vcs1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +7 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb4/igt@gem_ctx_e...@basic-invalid-context-vcs1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-iclb5/igt@gem_ctx_e...@basic-invalid-context-vcs1.html
* igt@gem_ctx_isolation@rcs0-s3:
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-apl5/igt@gem_ctx_isolat...@rcs0-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html
* igt@gem_ctx_isolation@vcs1-clean:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [fdo#112080])
+1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb2/igt@gem_ctx_isolat...@vcs1-clean.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-iclb7/igt@gem_ctx_isolat...@vcs1-clean.html
* igt@gem_exec_schedule@fifo-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +11 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-iclb8/igt@gem_exec_sched...@fifo-bsd1.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#111325]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb8/igt@gem_exec_sched...@preempt-bsd.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-iclb2/igt@gem_exec_sched...@preempt-bsd.html
* igt@gem_tiled_pread_pwrite:
- shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] /
[fdo#109100])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-iclb7/igt@gem_tiled_pread_pwrite.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-iclb7/igt@gem_tiled_pread_pwrite.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-hsw: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-hsw5/igt@gem_userptr_bl...@sync-unmap-cycles.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-hsw1/igt@gem_userptr_bl...@sync-unmap-cycles.html
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-hsw: [PASS][17] -> [INCOMPLETE][18] ([fdo#103540]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-hsw7/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-hsw5/igt@kms_b...@extended-pageflip-modeset-hang-oldfb-render-b.html
* igt@kms_cursor_legacy@cursor-vs-flip-varying-size:
- shard-apl: [PASS][19] -> [INCOMPLETE][20] ([fdo#103927]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-apl8/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-apl5/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: [PASS][21] -> [FAIL][22] ([fdo#105363]) +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/shard-skl3/igt@kms_f...@flip-vs-expired-vblank.html
* igt@kms_flip@flip-vs-suspend:
- shard-skl: [PASS][23] -> [INCOMPLETE][24] ([fdo#109507])
[23]:
https://intel-gfx-ci.
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc-fixes tree
Hi all,
This should have been reported against the vfs-fixes tree, sorry.
On Tue, 22 Oct 2019 08:07:34 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from include/uapi/linux/posix_types.h:5,
> from include/uapi/linux/types.h:14,
> from include/linux/types.h:6,
> from include/linux/limits.h:6,
> from include/linux/kernel.h:7,
> from fs/aio.c:14:
> fs/aio.c: In function '__do_compat_sys_io_pgetevents':
> include/linux/stddef.h:8:14: warning: initialization of 'unsigned int' from
> 'void *' makes integer from pointer without a cast [-Wint-conversion]
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2196:38: note: in expansion of macro 'NULL'
> 2196 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
> include/linux/stddef.h:8:14: note: (near initialization for 'ksig.sigmask')
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2196:38: note: in expansion of macro 'NULL'
> 2196 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
> fs/aio.c: In function '__do_compat_sys_io_pgetevents_time64':
> include/linux/stddef.h:8:14: warning: initialization of 'unsigned int' from
> 'void *' makes integer from pointer without a cast [-Wint-conversion]
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2231:38: note: in expansion of macro 'NULL'
> 2231 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
> include/linux/stddef.h:8:14: note: (near initialization for 'ksig.sigmask')
> 8 | #define NULL ((void *)0)
> | ^
> fs/aio.c:2231:38: note: in expansion of macro 'NULL'
> 2231 | struct __compat_aio_sigset ksig = { NULL, };
> | ^~~~
>
> Introduced by commit
>
> de80166a573d ("aio: Fix io_pgetevents() struct __compat_aio_sigset layout")
--
Cheers,
Stephen Rothwell
pgpIY6T52BZUV.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build warning after merge of the drm-misc-fixes tree
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from include/linux/limits.h:6,
from include/linux/kernel.h:7,
from fs/aio.c:14:
fs/aio.c: In function '__do_compat_sys_io_pgetevents':
include/linux/stddef.h:8:14: warning: initialization of 'unsigned int' from
'void *' makes integer from pointer without a cast [-Wint-conversion]
8 | #define NULL ((void *)0)
| ^
fs/aio.c:2196:38: note: in expansion of macro 'NULL'
2196 | struct __compat_aio_sigset ksig = { NULL, };
| ^~~~
include/linux/stddef.h:8:14: note: (near initialization for 'ksig.sigmask')
8 | #define NULL ((void *)0)
| ^
fs/aio.c:2196:38: note: in expansion of macro 'NULL'
2196 | struct __compat_aio_sigset ksig = { NULL, };
| ^~~~
fs/aio.c: In function '__do_compat_sys_io_pgetevents_time64':
include/linux/stddef.h:8:14: warning: initialization of 'unsigned int' from
'void *' makes integer from pointer without a cast [-Wint-conversion]
8 | #define NULL ((void *)0)
| ^
fs/aio.c:2231:38: note: in expansion of macro 'NULL'
2231 | struct __compat_aio_sigset ksig = { NULL, };
| ^~~~
include/linux/stddef.h:8:14: note: (near initialization for 'ksig.sigmask')
8 | #define NULL ((void *)0)
| ^
fs/aio.c:2231:38: note: in expansion of macro 'NULL'
2231 | struct __compat_aio_sigset ksig = { NULL, };
| ^~~~
Introduced by commit
de80166a573d ("aio: Fix io_pgetevents() struct __compat_aio_sigset layout")
--
Cheers,
Stephen Rothwell
pgp8APf1WYn2P.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/13] drm/i915/selftests: Add coverage of mocs registers
Quoting Kumar Valsan, Prathap (2019-10-21 14:52:12)
> On Sat, Oct 19, 2019 at 12:20:18AM +0100, Chris Wilson wrote:
> > Quoting Kumar Valsan, Prathap (2019-10-19 00:24:13)
> > > On Fri, Oct 18, 2019 at 11:14:39PM +0100, Chris Wilson wrote:
> > > > +static int check_l3cc_table(struct intel_engine_cs *engine,
> > > > + const struct drm_i915_mocs_table *table,
> > > > + const u32 *vaddr, int *offset)
> > > > +{
> > > > + u16 unused_value = table->table[I915_MOCS_PTE].l3cc_value;
> > > > + unsigned int i;
> > > > + u32 expect;
> > > > +
> > > > + if (1) { /* XXX skip MCR read back */
> > > > + *offset += table->n_entries / 2;
> > > > + return 0;
> > > > + }
> > >
> > > I think l3cc reset test is valid only from Gen12+. Before that since its
> > > loaded from the golden context, table stays the same between reset.
> >
> > That doesn't affect the validity of actually checking that the values
> > don't change. The problem as I understand it is that they lie inside the
> > magic 0xb00 region that is broadcast across the slices and not
> > accessible from CS, see engine_wa_list_verify() and mcr_range. Sadly
> > using the GPU is the cleanest way to emulate userspace interaction with
> > the *GPU*.
> > -Chris
> Hmmm.. But from igt test we are submiting a secure BB to read the L3
> MOCS. Not quite clear how that works then.
The simple answer is I see precisely the same fail in gem_mocs_settings
:)
The real question is why CI does not.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 7/7] drm/i915/selftests: add sanity selftest for huge-GTT-pages
Quoting Matthew Auld (2019-10-21 20:27:47)
> Now that for all the relevant backends we do randomised testing, we need
> to make sure we still sanity check the obvious cases that might blow up,
> such that introducing a temporary regression is less likely. Also
> rather than do this for every backend, just limit to our two memory
> types: system and local.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
> ---
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 103 ++
> 1 file changed, 103 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> index 1d7c2a50d636..fee8a6c338b8 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> @@ -1505,6 +1505,108 @@ static int igt_ppgtt_lmem_huge(void *arg)
> return err;
> }
>
> +static struct drm_i915_gem_object *
> +igt_create_local(struct drm_i915_private *i915, u32 size)
> +{
> + return i915_gem_object_create_lmem(i915, size, I915_ALLOC_CONTIGUOUS);
> +}
> +
> +static struct drm_i915_gem_object *
> +igt_create_system(struct drm_i915_private *i915, u32 size)
> +{
> + return huge_pages_object(i915, size, size);
Some might say that these [internal, mocks] should also be part of the
factory service ;)
> +typedef struct drm_i915_gem_object *
> +(*igt_create_fn)(struct drm_i915_private *i915, u32 size);
> +
> +static int igt_ppgtt_sanity_check(void *arg)
> +{
> + struct i915_gem_context *ctx = arg;
> + struct drm_i915_private *i915 = ctx->i915;
> + unsigned int supported = INTEL_INFO(i915)->page_sizes;
> + struct {
> + u32 size;
> + u32 pages;
> + } combos[] = {
> + { SZ_64K, SZ_64K, },
> + { SZ_2M, SZ_2M, },
> + { SZ_2M, SZ_64K, },
> + { SZ_2M + SZ_4K, SZ_64K | SZ_4K, },
> + { SZ_2M + SZ_4K, SZ_2M | SZ_4K, },
> + { SZ_2M + SZ_64K, SZ_2M | SZ_64K, },
Won't SZ_2M - PAGE_SIZE also be as interesting?
If I am not barking up the wrong tree with my understanding here,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/7] drm/i915: support creating LMEM objects
Quoting Matthew Auld (2019-10-21 20:27:41)
> diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
> b/drivers/gpu/drm/i915/intel_region_lmem.c
> new file mode 100644
> index ..199532056e1b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_region_lmem.c
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_memory_region.h"
> +#include "gem/i915_gem_lmem.h"
> +#include "gem/i915_gem_region.h"
> +#include "intel_region_lmem.h"
> +
> +const struct intel_memory_region_ops intel_region_lmem_ops = {
> + .init = intel_memory_region_init_buddy,
> + .release = intel_memory_region_release_buddy,
> + .create_object = __i915_gem_lmem_object_create,
I think the factory is misplaced, but will do for now. (I'm not fond of
ops.create_object here, that should be a GEM factory.)
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Lift i915_vma_parked() onto the gt
== Series Details ==
Series: series starting with [1/2] drm/i915: Lift i915_vma_parked() onto the gt
URL : https://patchwork.freedesktop.org/series/68329/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7142 -> Patchwork_14907
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/index.html
Known issues
Here are the changes found in Patchwork_14907 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-read:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-u3/igt@gem_mmap_...@basic-read.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-icl-u3/igt@gem_mmap_...@basic-read.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][3] -> [FAIL][4] ([fdo#108511])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@gem_basic@create-close:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-u3/igt@gem_ba...@create-close.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-icl-u3/igt@gem_ba...@create-close.html
* igt@gem_ctx_create@basic-files:
- fi-bdw-gvtdvm: [DMESG-WARN][7] ([fdo#112064]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-bdw-gvtdvm/igt@gem_ctx_cre...@basic-files.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-bdw-gvtdvm/igt@gem_ctx_cre...@basic-files.html
- {fi-icl-guc}: [INCOMPLETE][9] ([fdo#107713] / [fdo#109100]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@rcs0:
- fi-cml-u: [INCOMPLETE][11] ([fdo#110566]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-cml-u/igt@gem_ctx_swi...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-cml-u/igt@gem_ctx_swi...@rcs0.html
* igt@gem_exec_gttfill@basic:
- {fi-icl-dsi}: [DMESG-WARN][13] ([fdo#106107]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-dsi/igt@gem_exec_gttf...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-icl-dsi/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live_coherency:
- fi-cfl-8109u: [TIMEOUT][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-cfl-8109u/igt@i915_selftest@live_coherency.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-cfl-8109u/igt@i915_selftest@live_coherency.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [FAIL][18] ([fdo#111045]
/ [fdo#111096])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14907/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112064]: https://bugs.freedesktop.org/show_bug.cgi?id=112064
Participating hosts (52 -> 46)
--
Additional (1): fi-icl-u2
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7142 -> Patchwork_14907
CI-20190529: 20190529
CI_DRM_7142: 639c81d1ccbabfd8421709509bf5052213198307 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14907: 4
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Introduce barrier pulses along engines (rev4)
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines (rev4)
URL : https://patchwork.freedesktop.org/series/68309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7142 -> Patchwork_14906
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/index.html
New tests
-
New tests have been introduced between CI_DRM_7142 and Patchwork_14906:
### New IGT tests (1) ###
* igt@i915_selftest@live_gt_heartbeat:
- Statuses : 45 pass(s)
- Exec time: [0.38, 2.35] s
Known issues
Here are the changes found in Patchwork_14906 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
* igt@i915_selftest@live_hangcheck:
- fi-bsw-n3050: [PASS][3] -> [INCOMPLETE][4] ([fdo#105876])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_basic@create-close:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-u3/igt@gem_ba...@create-close.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-icl-u3/igt@gem_ba...@create-close.html
* igt@gem_ctx_create@basic-files:
- fi-bdw-gvtdvm: [DMESG-WARN][7] ([fdo#112064]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-bdw-gvtdvm/igt@gem_ctx_cre...@basic-files.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-bdw-gvtdvm/igt@gem_ctx_cre...@basic-files.html
- {fi-icl-guc}: [INCOMPLETE][9] ([fdo#107713] / [fdo#109100]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@rcs0:
- fi-cml-u: [INCOMPLETE][11] ([fdo#110566]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-cml-u/igt@gem_ctx_swi...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-cml-u/igt@gem_ctx_swi...@rcs0.html
* igt@gem_exec_gttfill@basic:
- {fi-icl-dsi}: [DMESG-WARN][13] ([fdo#106107]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-icl-dsi/igt@gem_exec_gttf...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-icl-dsi/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live_coherency:
- fi-cfl-8109u: [TIMEOUT][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-cfl-8109u/igt@i915_selftest@live_coherency.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-cfl-8109u/igt@i915_selftest@live_coherency.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [FAIL][18] ([fdo#111045]
/ [fdo#111096])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7142/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14906/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112064]: https://bugs.freedesktop.org/show_bug.cgi?id=112064
Participating hosts (52 -> 46)
--
Additional (1): fi-icl-u2
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7142 -> Pat
[Intel-gfx] [PATCH i-g-t v2] tests/kms_content_protection: check i915 and generic debugfs name for HDCP caps
The content protection tests only start if this debugfs entry exists.
Since the name is specific to intel driver these tests cannot be used with
other drivers. So we should check generic debugfs name also
v2: Check i915_* if device is i915, otherwise check the generic name.
Signed-off-by: Bhawanpreet Lakha
---
tests/kms_content_protection.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
index e676b60b..42fdc459 100644
--- a/tests/kms_content_protection.c
+++ b/tests/kms_content_protection.c
@@ -554,7 +554,11 @@ static bool sink_hdcp_capable(igt_output_t *output)
if (fd < 0)
return false;
- debugfs_read(fd, "i915_hdcp_sink_capability", buf);
+ if (is_i915_device(data.drm_fd))
+ debugfs_read(fd, "i915_hdcp_sink_capability", buf);
+ else
+ debugfs_read(fd, "hdcp_sink_capability", buf);
+
close(fd);
igt_debug("Sink capability: %s\n", buf);
@@ -571,7 +575,11 @@ static bool sink_hdcp2_capable(igt_output_t *output)
if (fd < 0)
return false;
- debugfs_read(fd, "i915_hdcp_sink_capability", buf);
+ if (is_i915_device(data.drm_fd))
+ debugfs_read(fd, "i915_hdcp_sink_capability", buf);
+ else
+ debugfs_read(fd, "hdcp_sink_capability", buf);
+
close(fd);
igt_debug("Sink capability: %s\n", buf);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/lmem: support kernel mapping
Quoting Chris Wilson (2019-10-21 20:37:46)
> Quoting Matthew Auld (2019-10-21 20:27:43)
> > @@ -244,6 +247,13 @@ static void *i915_gem_object_map(const struct
> > drm_i915_gem_object *obj,
> > pgprot_t pgprot;
> > void *addr;
> >
> > + if (i915_gem_object_is_lmem(obj)) {
> > + if (type != I915_MAP_WC)
> > + return NULL;
>
> return ERR_PTR(-EINVAL) or ERR_PTR(-ENODEV);
Belay that, wrong level. Slightly obnoxious though.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/lmem: support kernel mapping
Quoting Matthew Auld (2019-10-21 20:27:43)
> @@ -244,6 +247,13 @@ static void *i915_gem_object_map(const struct
> drm_i915_gem_object *obj,
> pgprot_t pgprot;
> void *addr;
>
> + if (i915_gem_object_is_lmem(obj)) {
> + if (type != I915_MAP_WC)
> + return NULL;
return ERR_PTR(-EINVAL) or ERR_PTR(-ENODEV);
> +
> + return i915_gem_object_lmem_io_map(obj, 0, obj->base.size);
> + }
> +
> /* A single page can always be kmapped */
> if (n_pages == 1 && type == I915_MAP_WB)
> return kmap(sg_page(sgt->sgl));
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/7] drm/i915: setup io-mapping for LMEM
From: Abdiel Janulgue
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_region_lmem.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/intel_region_lmem.c
index 199532056e1b..9a351af45ce6 100644
--- a/drivers/gpu/drm/i915/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/intel_region_lmem.c
@@ -9,8 +9,32 @@
#include "gem/i915_gem_region.h"
#include "intel_region_lmem.h"
+static void
+region_lmem_release(struct intel_memory_region *mem)
+{
+ io_mapping_fini(&mem->iomap);
+ intel_memory_region_release_buddy(mem);
+}
+
+static int
+region_lmem_init(struct intel_memory_region *mem)
+{
+ int ret;
+
+ if (!io_mapping_init_wc(&mem->iomap,
+ mem->io_start,
+ resource_size(&mem->region)))
+ return -EIO;
+
+ ret = intel_memory_region_init_buddy(mem);
+ if (ret)
+ io_mapping_fini(&mem->iomap);
+
+ return ret;
+}
+
const struct intel_memory_region_ops intel_region_lmem_ops = {
- .init = intel_memory_region_init_buddy,
- .release = intel_memory_region_release_buddy,
+ .init = region_lmem_init,
+ .release = region_lmem_release,
.create_object = __i915_gem_lmem_object_create,
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/7] drm/i915/selftests: prefer random sizes for the huge-GTT-page smoke tests
Ditch the dubious static list of sizes to enumerate, in favour of
choosing a random size within the limits of each backing store. With
repeated CI runs this should give us a wider range of object sizes, and
in turn more page-size combinations, while using less machine time.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 198 +-
1 file changed, 94 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index d4892769b739..1d7c2a50d636 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1314,20 +1314,33 @@ static int igt_ppgtt_exhaust_huge(void *arg)
return err;
}
+static u32 igt_random_size(struct rnd_state *prng,
+ u32 min_page_size,
+ u32 max_page_size)
+{
+ u64 mask;
+ u32 size;
+
+ GEM_BUG_ON(!is_power_of_2(min_page_size));
+ GEM_BUG_ON(!is_power_of_2(max_page_size));
+ GEM_BUG_ON(min_page_size < PAGE_SIZE);
+ GEM_BUG_ON(min_page_size > max_page_size);
+
+ mask = ((max_page_size << 1ULL) - 1) & PAGE_MASK;
+ size = prandom_u32_state(prng) & mask;
+ if (size < min_page_size)
+ size |= min_page_size;
+
+ return size;
+}
+
static int igt_ppgtt_internal_huge(void *arg)
{
struct i915_gem_context *ctx = arg;
struct drm_i915_private *i915 = ctx->i915;
struct drm_i915_gem_object *obj;
- static const unsigned int sizes[] = {
- SZ_64K,
- SZ_128K,
- SZ_256K,
- SZ_512K,
- SZ_1M,
- SZ_2M,
- };
- int i;
+ I915_RND_STATE(prng);
+ u32 size;
int err;
/*
@@ -1335,42 +1348,36 @@ static int igt_ppgtt_internal_huge(void *arg)
* -- ensure that our writes land in the right place.
*/
- for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
- unsigned int size = sizes[i];
-
- obj = i915_gem_object_create_internal(i915, size);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
+ size = igt_random_size(&prng, SZ_64K, SZ_2M);
- err = i915_gem_object_pin_pages(obj);
- if (err)
- goto out_put;
-
- if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
- pr_info("internal unable to allocate huge-page(s) with
size=%u\n",
- size);
- goto out_unpin;
- }
+ obj = i915_gem_object_create_internal(i915, size);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
- err = igt_write_huge(ctx, obj);
- if (err) {
- pr_err("internal write-huge failed with size=%u\n",
- size);
- goto out_unpin;
- }
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ goto out_put;
- i915_gem_object_unpin_pages(obj);
- __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
- i915_gem_object_put(obj);
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("%s unable to allocate huge-page(s) with size=%u\n",
+ __func__, size);
+ err = -ENOMEM;
+ goto out_unpin;
}
- return 0;
+ err = igt_write_huge(ctx, obj);
+ if (err)
+ pr_err("%s write-huge failed with size=%u\n", __func__, size);
out_unpin:
i915_gem_object_unpin_pages(obj);
+ __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
out_put:
i915_gem_object_put(obj);
+ if (err == -ENOMEM)
+ err = 0;
+
return err;
}
@@ -1384,14 +1391,8 @@ static int igt_ppgtt_gemfs_huge(void *arg)
struct i915_gem_context *ctx = arg;
struct drm_i915_private *i915 = ctx->i915;
struct drm_i915_gem_object *obj;
- static const unsigned int sizes[] = {
- SZ_2M,
- SZ_4M,
- SZ_8M,
- SZ_16M,
- SZ_32M,
- };
- int i;
+ I915_RND_STATE(prng);
+ u32 size;
int err;
/*
@@ -1400,46 +1401,40 @@ static int igt_ppgtt_gemfs_huge(void *arg)
*/
if (!igt_can_allocate_thp(i915)) {
- pr_info("missing THP support, skipping\n");
+ pr_info("%s missing THP support, skipping\n", __func__);
return 0;
}
- for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
- unsigned int size = sizes[i];
-
- obj = i915_gem_object_create_shmem(i915, size);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
-
[Intel-gfx] [PATCH v2 5/7] drm/i915/selftests: extend coverage to include LMEM huge-pages
Add LMEM objects to list of backends we test for huge-GTT-pages.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 121 +-
1 file changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f27772f6779a..d4892769b739 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -9,6 +9,7 @@
#include "i915_selftest.h"
#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_gt.h"
@@ -981,7 +982,7 @@ static int gpu_write(struct intel_context *ce,
vma->size >> PAGE_SHIFT, val);
}
-static int cpu_check(struct drm_i915_gem_object *obj, u32 dword, u32 val)
+static int __cpu_check_shmem(struct drm_i915_gem_object *obj, u32 dword, u32
val)
{
unsigned int needs_flush;
unsigned long n;
@@ -1013,6 +1014,51 @@ static int cpu_check(struct drm_i915_gem_object *obj,
u32 dword, u32 val)
return err;
}
+static int __cpu_check_lmem(struct drm_i915_gem_object *obj, u32 dword, u32
val)
+{
+ unsigned long n;
+ int err;
+
+ i915_gem_object_lock(obj);
+ err = i915_gem_object_set_to_wc_domain(obj, false);
+ i915_gem_object_unlock(obj);
+ if (err)
+ return err;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ return err;
+
+ for (n = 0; n < obj->base.size >> PAGE_SHIFT; ++n) {
+ u32 __iomem *base;
+ u32 read_val;
+
+ base = i915_gem_object_lmem_io_map_page_atomic(obj, n);
+
+ read_val = ioread32(base + dword);
+ io_mapping_unmap_atomic(base);
+ if (read_val != val) {
+ pr_err("n=%lu base[%u]=%u, val=%u\n",
+ n, dword, read_val, val);
+ err = -EINVAL;
+ break;
+ }
+ }
+
+ i915_gem_object_unpin_pages(obj);
+ return err;
+}
+
+static int cpu_check(struct drm_i915_gem_object *obj, u32 dword, u32 val)
+{
+ if (i915_gem_object_has_struct_page(obj))
+ return __cpu_check_shmem(obj, dword, val);
+ else if (i915_gem_object_is_lmem(obj))
+ return __cpu_check_lmem(obj, dword, val);
+
+ return -ENODEV;
+}
+
static int __igt_write_huge(struct intel_context *ce,
struct drm_i915_gem_object *obj,
u64 size, u64 offset,
@@ -1397,6 +1443,78 @@ static int igt_ppgtt_gemfs_huge(void *arg)
return err;
}
+static int igt_ppgtt_lmem_huge(void *arg)
+{
+ struct i915_gem_context *ctx = arg;
+ struct drm_i915_private *i915 = ctx->i915;
+ struct drm_i915_gem_object *obj;
+ static const unsigned int sizes[] = {
+ SZ_64K,
+ SZ_512K,
+ SZ_1M,
+ SZ_2M,
+ };
+ int i;
+ int err;
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /*
+* Sanity check that the HW uses huge pages correctly through LMEM
+* -- ensure that our writes land in the right place.
+*/
+
+ for (i = 0; i < ARRAY_SIZE(sizes); ++i) {
+ unsigned int size = sizes[i];
+
+ obj = i915_gem_object_create_lmem(i915, size,
I915_BO_ALLOC_CONTIGUOUS);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ if (err == -E2BIG) {
+ pr_info("object too big for region!\n");
+ return 0;
+ }
+
+ return err;
+ }
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM unable to allocate huge-page(s) with
size=%u\n",
+ size);
+ goto out_unpin;
+ }
+
+ err = igt_write_huge(ctx, obj);
+ if (err) {
+ pr_err("LMEM write-huge failed with size=%u\n", size);
+ goto out_unpin;
+ }
+
+ i915_gem_object_unpin_pages(obj);
+ __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ i915_gem_object_put(obj);
+ }
+
+ return 0;
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_ppgtt_pin_update(void *arg)
{
struct i915_gem_context *ctx = arg;
@@ -17
[Intel-gfx] [PATCH v2 7/7] drm/i915/selftests: add sanity selftest for huge-GTT-pages
Now that for all the relevant backends we do randomised testing, we need
to make sure we still sanity check the obvious cases that might blow up,
such that introducing a temporary regression is less likely. Also
rather than do this for every backend, just limit to our two memory
types: system and local.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 103 ++
1 file changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 1d7c2a50d636..fee8a6c338b8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1505,6 +1505,108 @@ static int igt_ppgtt_lmem_huge(void *arg)
return err;
}
+static struct drm_i915_gem_object *
+igt_create_local(struct drm_i915_private *i915, u32 size)
+{
+ return i915_gem_object_create_lmem(i915, size, I915_ALLOC_CONTIGUOUS);
+}
+
+static struct drm_i915_gem_object *
+igt_create_system(struct drm_i915_private *i915, u32 size)
+{
+ return huge_pages_object(i915, size, size);
+}
+
+typedef struct drm_i915_gem_object *
+(*igt_create_fn)(struct drm_i915_private *i915, u32 size);
+
+static int igt_ppgtt_sanity_check(void *arg)
+{
+ struct i915_gem_context *ctx = arg;
+ struct drm_i915_private *i915 = ctx->i915;
+ unsigned int supported = INTEL_INFO(i915)->page_sizes;
+ struct {
+ u32 size;
+ u32 pages;
+ } combos[] = {
+ { SZ_64K, SZ_64K, },
+ { SZ_2M, SZ_2M, },
+ { SZ_2M, SZ_64K, },
+ { SZ_2M + SZ_4K, SZ_64K | SZ_4K, },
+ { SZ_2M + SZ_4K, SZ_2M | SZ_4K, },
+ { SZ_2M + SZ_64K, SZ_2M | SZ_64K, },
+ };
+ igt_create_fn fns[] = {
+ igt_create_local,
+ igt_create_system,
+ };
+ int i, j;
+ int err;
+
+ if (supported == I915_GTT_PAGE_SIZE_4K)
+ return 0;
+
+ /*
+* Sanity check that the HW behaves with a limited set of combinations.
+* We already have a bunch of randomised testing, which should give us
+* a decent amount of variation between runs, however we should keep
+* this to limit the chances of introducing a temporary regression, by
+* testing the most obvious cases that might make something blow up.
+*/
+
+ for (i = 0; i < ARRAY_SIZE(fns); ++i) {
+ for (j = 0; j < ARRAY_SIZE(combos); ++j) {
+ struct drm_i915_gem_object *obj;
+ u32 size = combos[j].size;
+ u32 pages = combos[j].pages;
+
+ obj = fns[i](i915, size);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ if (err == -ENODEV) {
+ pr_info("Device lacks local memory,
skipping\n");
+ err = 0;
+ break;
+ }
+
+ return err;
+ }
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err) {
+ i915_gem_object_put(obj);
+ goto out;
+ }
+
+ GEM_BUG_ON(pages > obj->base.size);
+ pages = pages & supported;
+
+ if (pages)
+ obj->mm.page_sizes.sg = pages;
+
+ err = igt_write_huge(ctx, obj);
+
+ i915_gem_object_unpin_pages(obj);
+ __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ i915_gem_object_put(obj);
+
+ if (err) {
+ pr_err("%s write-huge failed with size=%u
pages=%u i=%d, j=%d\n",
+ __func__, size, pages, i, j);
+ goto out;
+ }
+ }
+
+ cond_resched();
+ }
+
+out:
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_ppgtt_pin_update(void *arg)
{
struct i915_gem_context *ctx = arg;
@@ -1867,6 +1969,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_ppgtt_gemfs_huge),
SUBTEST(igt_ppgtt_internal_huge),
SUBTEST(igt_ppgtt_lmem_huge),
+ SUBTEST(igt_ppgtt_sanity_check),
};
struct drm_file *file;
struct i915_gem_context *ctx;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
[Intel-gfx] [PATCH v2 4/7] drm/i915/selftests: add write-dword test for LMEM
Simple test writing to dwords across an object, using various engines in
a randomized order, checking that our writes land from the cpu.
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
.../drm/i915/selftests/intel_memory_region.c | 166 ++
1 file changed, 166 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index 292489371842..8e14ef3e1e32 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -11,9 +11,11 @@
#include "mock_gem_device.h"
#include "mock_region.h"
+#include "gem/i915_gem_context.h"
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_object_blt.h"
+#include "gem/selftests/igt_gem_utils.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_gt.h"
#include "selftests/igt_flush_test.h"
@@ -256,6 +258,125 @@ static int igt_mock_contiguous(void *arg)
return err;
}
+static int igt_gpu_write_dw(struct intel_context *ce,
+ struct i915_vma *vma,
+ u32 dword,
+ u32 value)
+{
+ return igt_gpu_fill_dw(ce, vma, dword * sizeof(u32),
+ vma->size >> PAGE_SHIFT, value);
+}
+
+static int igt_cpu_check(struct drm_i915_gem_object *obj, u32 dword, u32 val)
+{
+ unsigned long n;
+ int err;
+
+ i915_gem_object_lock(obj);
+ err = i915_gem_object_set_to_wc_domain(obj, false);
+ i915_gem_object_unlock(obj);
+ if (err)
+ return err;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ return err;
+
+ for (n = 0; n < obj->base.size >> PAGE_SHIFT; ++n) {
+ u32 __iomem *base;
+ u32 read_val;
+
+ base = i915_gem_object_lmem_io_map_page_atomic(obj, n);
+
+ read_val = ioread32(base + dword);
+ io_mapping_unmap_atomic(base);
+ if (read_val != val) {
+ pr_err("n=%lu base[%u]=%u, val=%u\n",
+ n, dword, read_val, val);
+ err = -EINVAL;
+ break;
+ }
+ }
+
+ i915_gem_object_unpin_pages(obj);
+ return err;
+}
+
+static int igt_gpu_write(struct i915_gem_context *ctx,
+struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ struct i915_address_space *vm = ctx->vm ?: &i915->ggtt.vm;
+ struct i915_gem_engines *engines;
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ I915_RND_STATE(prng);
+ IGT_TIMEOUT(end_time);
+ unsigned int count;
+ struct i915_vma *vma;
+ int *order;
+ int i, n;
+ int err = 0;
+
+ GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+
+ n = 0;
+ count = 0;
+ for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
+ count++;
+ if (!intel_engine_can_store_dword(ce->engine))
+ continue;
+
+ n++;
+ }
+ i915_gem_context_unlock_engines(ctx);
+ if (!n)
+ return 0;
+
+ order = i915_random_order(count * count, &prng);
+ if (!order)
+ return -ENOMEM;
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto out_free;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (err)
+ goto out_free;
+
+ i = 0;
+ engines = i915_gem_context_lock_engines(ctx);
+ do {
+ u32 rng = prandom_u32_state(&prng);
+ u32 dword = offset_in_page(rng) / 4;
+
+ ce = engines->engines[order[i] % engines->num_engines];
+ i = (i + 1) % (count * count);
+ if (!ce || !intel_engine_can_store_dword(ce->engine))
+ continue;
+
+ err = igt_gpu_write_dw(ce, vma, dword, rng);
+ if (err)
+ break;
+
+ err = igt_cpu_check(obj, dword, rng);
+ if (err)
+ break;
+ } while (!__igt_timeout(end_time, NULL));
+ i915_gem_context_unlock_engines(ctx);
+
+out_free:
+ kfree(order);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_lmem_create(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -277,6 +398,50 @@ static int igt_lmem_create(void *arg)
return err;
}
+static int igt_lmem_write_gpu(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ struct i915_gem_context *ctx;
+ struct drm_file *file;
+ I915_RND_STATE(prng);
+ u32 sz;
+ int err;
+
+ file = moc
[Intel-gfx] [PATCH v2 3/7] drm/i915/lmem: support kernel mapping
From: Abdiel Janulgue
We can create LMEM objects, but we also need to support mapping them
into kernel space for internal use.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 36 ++
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 8 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 22 +++-
.../drm/i915/selftests/intel_memory_region.c | 113 ++
5 files changed, 180 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 5168ab9fa4ce..919ce0736c69 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -9,11 +9,47 @@
#include "i915_drv.h"
const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
+ .flags = I915_GEM_OBJECT_HAS_IOMEM,
+
.get_pages = i915_gem_object_get_pages_buddy,
.put_pages = i915_gem_object_put_pages_buddy,
.release = i915_gem_object_release_memory_region,
};
+/* XXX: Time to vfunc your life up? */
+void __iomem *i915_gem_object_lmem_io_map_page(struct drm_i915_gem_object *obj,
+ unsigned long n)
+{
+ resource_size_t offset;
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+
+ return io_mapping_map_wc(&obj->mm.region->iomap, offset, PAGE_SIZE);
+}
+
+void __iomem *i915_gem_object_lmem_io_map_page_atomic(struct
drm_i915_gem_object *obj,
+ unsigned long n)
+{
+ resource_size_t offset;
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+
+ return io_mapping_map_atomic_wc(&obj->mm.region->iomap, offset);
+}
+
+void __iomem *i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+ unsigned long n,
+ unsigned long size)
+{
+ resource_size_t offset;
+
+ GEM_BUG_ON(!i915_gem_object_is_contiguous(obj));
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+
+ return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
+}
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
return obj->ops == &i915_gem_lmem_obj_ops;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index fc3f15580fe3..7c176b8b7d2f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -14,6 +14,14 @@ struct intel_memory_region;
extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
+void __iomem *i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+ unsigned long n, unsigned long size);
+void __iomem *i915_gem_object_lmem_io_map_page(struct drm_i915_gem_object *obj,
+ unsigned long n);
+void __iomem *
+i915_gem_object_lmem_io_map_page_atomic(struct drm_i915_gem_object *obj,
+ unsigned long n);
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index a387e3ee728b..96008374a412 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -31,10 +31,11 @@ struct i915_lut_handle {
struct drm_i915_gem_object_ops {
unsigned int flags;
#define I915_GEM_OBJECT_HAS_STRUCT_PAGEBIT(0)
-#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
-#define I915_GEM_OBJECT_IS_PROXY BIT(2)
-#define I915_GEM_OBJECT_NO_GGTTBIT(3)
-#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(4)
+#define I915_GEM_OBJECT_HAS_IOMEM BIT(1)
+#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(2)
+#define I915_GEM_OBJECT_IS_PROXY BIT(3)
+#define I915_GEM_OBJECT_NO_GGTTBIT(4)
+#define I915_GEM_OBJECT_ASYNC_CANCEL BIT(5)
/* Interface between the GEM object and its backing storage.
* get_pages() is called once prior to the use of the associated set
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index b0ec0959c13f..cf7f5a3cb210 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -7,6 +7,7 @@
#include "i915_drv.h"
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
+#include "i915_gem_lmem.h"
void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
struct sg_table *pages,
@@ -172,7 +173,9 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object
*obj)
void *ptr;
ptr = page_mask_bits(obj->mm.mapping)
[Intel-gfx] [PATCH v2 1/7] drm/i915: support creating LMEM objects
We currently define LMEM, or local memory, as just another memory
region, like system memory or stolen, which we can expose to userspace
and can be mapped to the CPU via some BAR.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 56 +++
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 29 ++
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/intel_region_lmem.c | 16 ++
drivers/gpu/drm/i915/intel_region_lmem.h | 11
.../drm/i915/selftests/i915_live_selftests.h | 1 +
.../drm/i915/selftests/intel_memory_region.c | 40 +
8 files changed, 158 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_lmem.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_lmem.h
create mode 100644 drivers/gpu/drm/i915/intel_region_lmem.c
create mode 100644 drivers/gpu/drm/i915/intel_region_lmem.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a16a2daef977..ababa6ecfba5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -119,6 +119,7 @@ gem-y += \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_object_blt.o \
+ gem/i915_gem_lmem.o \
gem/i915_gem_mman.o \
gem/i915_gem_pages.o \
gem/i915_gem_phys.o \
@@ -147,6 +148,7 @@ i915-y += \
i915_scheduler.o \
i915_trace_points.o \
i915_vma.o \
+ intel_region_lmem.o \
intel_wopcm.o
# general-purpose microcontroller (GuC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
new file mode 100644
index ..5168ab9fa4ce
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "intel_memory_region.h"
+#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_lmem.h"
+#include "i915_drv.h"
+
+const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops = {
+ .get_pages = i915_gem_object_get_pages_buddy,
+ .put_pages = i915_gem_object_put_pages_buddy,
+ .release = i915_gem_object_release_memory_region,
+};
+
+bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
+{
+ return obj->ops == &i915_gem_lmem_obj_ops;
+}
+
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem(struct drm_i915_private *i915,
+ resource_size_t size,
+ unsigned int flags)
+{
+ return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+size, flags);
+}
+
+ struct drm_i915_gem_object *
+__i915_gem_lmem_object_create(struct intel_memory_region *mem,
+ resource_size_t size,
+ unsigned int flags)
+{
+ struct drm_i915_private *i915 = mem->i915;
+ struct drm_i915_gem_object *obj;
+
+ if (size > BIT(mem->mm.max_order) * mem->mm.chunk_size)
+ return ERR_PTR(-E2BIG);
+
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ drm_gem_private_object_init(&i915->drm, &obj->base, size);
+ i915_gem_object_init(obj, &i915_gem_lmem_obj_ops);
+
+ obj->read_domains = I915_GEM_DOMAIN_WC | I915_GEM_DOMAIN_GTT;
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
+ i915_gem_object_init_memory_region(obj, mem, flags);
+
+ return obj;
+}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
new file mode 100644
index ..fc3f15580fe3
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef __I915_GEM_LMEM_H
+#define __I915_GEM_LMEM_H
+
+#include
+
+struct drm_i915_private;
+struct drm_i915_gem_object;
+struct intel_memory_region;
+
+extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
+
+bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
+
+struct drm_i915_gem_object *
+i915_gem_object_create_lmem(struct drm_i915_private *i915,
+ resource_size_t size,
+ unsigned int flags);
+
+struct drm_i915_gem_object *
+__i915_gem_lmem_object_create(struct intel_memory_region *mem,
+ resource_size_t size,
+ unsigned int flags);
+
+#endif /* !__I915_GEM_LMEM_H */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8882c0908c3b..79a87e706405 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -101,6 +101,8 @@
#include "i915_vma.h"
#include "i915_irq.h"
+#include "intel_region_lmem.h"
+
#i
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Introduce barrier pulses along engines (rev4)
== Series Details == Series: drm/i915/gt: Introduce barrier pulses along engines (rev4) URL : https://patchwork.freedesktop.org/series/68309/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1b7f5f7aef7e drm/i915/gt: Introduce barrier pulses along engines -:32: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #32: new file mode 100644 -:37: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #37: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:1: +/* -:38: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #38: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:2: + * SPDX-License-Identifier: MIT -:120: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #120: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:1: +/* -:121: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #121: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:2: + * SPDX-License-Identifier: MIT -:154: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #154: FILE: drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c:1: +/* -:155: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #155: FILE: drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c:2: + * SPDX-License-Identifier: MIT total: 0 errors, 7 warnings, 0 checks, 290 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove pm park/unpark notifications
On 21/10/2019 19:32, Chris Wilson wrote:
With the last user, i915_vma_parked(), retired, there are no more users
of the per-gt pm notifications and we can remove the unused
infrastructure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 25
drivers/gpu/drm/i915/gem/i915_gem_pm.h | 2 --
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 10 --
drivers/gpu/drm/i915/gt/intel_gt_pm.h| 5 -
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 --
drivers/gpu/drm/i915/i915_gem.c | 1 -
6 files changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 2aa7e9be088f..ee3279c76566 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -11,24 +11,6 @@
#include "i915_drv.h"
-static int pm_notifier(struct notifier_block *nb,
- unsigned long action,
- void *data)
-{
- struct drm_i915_private *i915 =
- container_of(nb, typeof(*i915), gem.pm_notifier);
-
- switch (action) {
- case INTEL_GT_UNPARK:
- break;
-
- case INTEL_GT_PARK:
- break;
- }
-
- return NOTIFY_OK;
-}
-
static bool switch_to_kernel_context_sync(struct intel_gt *gt)
{
bool result = !intel_gt_is_wedged(gt);
@@ -206,10 +188,3 @@ void i915_gem_resume(struct drm_i915_private *i915)
}
goto out_unlock;
}
-
-void i915_gem_init__pm(struct drm_i915_private *i915)
-{
- i915->gem.pm_notifier.notifier_call = pm_notifier;
- blocking_notifier_chain_register(&i915->gt.pm_notifications,
-&i915->gem.pm_notifier);
-}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.h
b/drivers/gpu/drm/i915/gem/i915_gem_pm.h
index 6f7d5d11ac3b..a017572778d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.h
@@ -12,8 +12,6 @@
struct drm_i915_private;
struct work_struct;
-void i915_gem_init__pm(struct drm_i915_private *i915);
-
bool i915_gem_load_power_context(struct drm_i915_private *i915);
void i915_gem_resume(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index fde5112b6650..427aded512f2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -16,11 +16,6 @@
#include "intel_rc6.h"
#include "intel_wakeref.h"
-static void pm_notify(struct intel_gt *gt, int state)
-{
- blocking_notifier_call_chain(>->pm_notifications, state, gt->i915);
-}
-
static int __gt_unpark(struct intel_wakeref *wf)
{
struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
@@ -55,8 +50,6 @@ static int __gt_unpark(struct intel_wakeref *wf)
intel_gt_queue_hangcheck(gt);
intel_gt_unpark_requests(gt);
- pm_notify(gt, INTEL_GT_UNPARK);
-
return 0;
}
@@ -68,7 +61,6 @@ static int __gt_park(struct intel_wakeref *wf)
GEM_TRACE("\n");
- pm_notify(gt, INTEL_GT_PARK);
intel_gt_park_requests(gt);
i915_vma_parked(gt);
@@ -96,8 +88,6 @@ static const struct intel_wakeref_ops wf_ops = {
void intel_gt_pm_init_early(struct intel_gt *gt)
{
intel_wakeref_init(>->wakeref, gt->uncore->rpm, &wf_ops);
-
- BLOCKING_INIT_NOTIFIER_HEAD(>->pm_notifications);
}
void intel_gt_pm_init(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 997770d3a968..0ed87da4bb68 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -12,11 +12,6 @@
#include "intel_gt_types.h"
#include "intel_wakeref.h"
-enum {
- INTEL_GT_UNPARK,
- INTEL_GT_PARK,
-};
-
static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
{
return intel_wakeref_is_active(>->wakeref);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index ae4aaf75ac78..980973e66e7f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -83,8 +83,6 @@ struct intel_gt {
struct intel_llc llc;
struct intel_rc6 rc6;
- struct blocking_notifier_head pm_notifications;
-
ktime_t last_init_time;
struct i915_vma *scratch;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2ba123f7b31..39cb0e246a88 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1435,7 +1435,6 @@ static void i915_gem_init__mm(struct drm_i915_private
*i915)
void i915_gem_init_early(struct drm_i915_private *dev_priv)
{
i915_gem_init__mm(dev_priv);
- i915_gem_init__pm(dev_priv);
spin_lock_init(&dev_priv->fb_tracking.lock);
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Lift i915_vma_parked() onto the gt
On 21/10/2019 19:32, Chris Wilson wrote:
Currently even though i915_vma_parked() operates on a per-gt struct, it
is called from a global pm notify. This oddity was only because the long
term plan is to decouple the vma cache from the pm notification, but
right now the oddity stands out like a sore thumb!
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 1 -
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
drivers/gpu/drm/i915/i915_vma.c| 32 +-
drivers/gpu/drm/i915/i915_vma.h| 2 +-
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 7987b54fb1f5..2aa7e9be088f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -23,7 +23,6 @@ static int pm_notifier(struct notifier_block *nb,
break;
case INTEL_GT_PARK:
- i915_vma_parked(i915);
break;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index b866d5b1eee0..fde5112b6650 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -71,6 +71,7 @@ static int __gt_park(struct intel_wakeref *wf)
pm_notify(gt, INTEL_GT_PARK);
intel_gt_park_requests(gt);
+ i915_vma_parked(gt);
i915_pmu_gt_parked(i915);
if (INTEL_GEN(i915) >= 6)
gen6_rps_idle(i915);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e90c4d0af8fd..d733bcf262f0 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -106,7 +106,7 @@ vma_create(struct drm_i915_gem_object *obj,
struct rb_node *rb, **p;
/* The aliasing_ppgtt should never be used directly! */
- GEM_BUG_ON(vm == &vm->i915->ggtt.alias->vm);
+ GEM_BUG_ON(vm == &vm->gt->ggtt->alias->vm);
vma = i915_vma_alloc();
if (vma == NULL)
@@ -412,7 +412,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
int err;
/* Access through the GTT requires the device to be awake. */
- assert_rpm_wakelock_held(&vma->vm->i915->runtime_pm);
+ assert_rpm_wakelock_held(vma->vm->gt->uncore->rpm);
if (GEM_WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
err = -ENODEV;
goto err;
@@ -945,7 +945,7 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
void i915_vma_close(struct i915_vma *vma)
{
- struct drm_i915_private *i915 = vma->vm->i915;
+ struct intel_gt *gt = vma->vm->gt;
unsigned long flags;
GEM_BUG_ON(i915_vma_is_closed(vma));
@@ -962,18 +962,18 @@ void i915_vma_close(struct i915_vma *vma)
* causing us to rebind the VMA once more. This ends up being a lot
* of wasted work for the steady state.
*/
- spin_lock_irqsave(&i915->gt.closed_lock, flags);
- list_add(&vma->closed_link, &i915->gt.closed_vma);
- spin_unlock_irqrestore(&i915->gt.closed_lock, flags);
+ spin_lock_irqsave(>->closed_lock, flags);
+ list_add(&vma->closed_link, >->closed_vma);
+ spin_unlock_irqrestore(>->closed_lock, flags);
}
static void __i915_vma_remove_closed(struct i915_vma *vma)
{
- struct drm_i915_private *i915 = vma->vm->i915;
+ struct intel_gt *gt = vma->vm->gt;
- spin_lock_irq(&i915->gt.closed_lock);
+ spin_lock_irq(>->closed_lock);
list_del_init(&vma->closed_link);
- spin_unlock_irq(&i915->gt.closed_lock);
+ spin_unlock_irq(>->closed_lock);
}
void i915_vma_reopen(struct i915_vma *vma)
@@ -1009,12 +1009,12 @@ void i915_vma_destroy(struct i915_vma *vma)
i915_vma_free(vma);
}
-void i915_vma_parked(struct drm_i915_private *i915)
+void i915_vma_parked(struct intel_gt *gt)
{
struct i915_vma *vma, *next;
- spin_lock_irq(&i915->gt.closed_lock);
- list_for_each_entry_safe(vma, next, &i915->gt.closed_vma, closed_link) {
+ spin_lock_irq(>->closed_lock);
+ list_for_each_entry_safe(vma, next, >->closed_vma, closed_link) {
struct drm_i915_gem_object *obj = vma->obj;
struct i915_address_space *vm = vma->vm;
@@ -1028,7 +1028,7 @@ void i915_vma_parked(struct drm_i915_private *i915)
obj = NULL;
}
- spin_unlock_irq(&i915->gt.closed_lock);
+ spin_unlock_irq(>->closed_lock);
if (obj) {
i915_vma_destroy(vma);
@@ -1038,11 +1038,11 @@ void i915_vma_parked(struct drm_i915_private *i915)
i915_vm_close(vm);
/* Restart after dropping lock */
- spin_lock_irq(&i915->gt.closed_lock);
- next = list_first_entry(&i915->gt.closed_vma,
+ spin_lock_irq(>->closed_lock);
+
Re: [Intel-gfx] [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, October 14, 2019 10:42 PM
> To: Lin, Wayne
> Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
>
> On Mon, Oct 14, 2019 at 09:27:07AM +, Lin, Wayne wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjala
> > > Sent: Friday, October 4, 2019 10:19 PM
> > > To: dri-de...@lists.freedesktop.org
> > > Cc: intel-gfx@lists.freedesktop.org; Lin, Wayne
> > > Subject: [PATCH 4/4] drm/edid: Prep for HDMI VIC aspect ratio (WIP)
> > >
> > > From: Ville Syrjälä
> > >
> > > I think this should provide most of necessary logic for adding
> > > aspecr ratios to the HDMI 4k modes.
> > >
> > > Cc: Wayne Lin
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 37
> > > +++--
> > > 1 file changed, 31 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index
> > > c7f9f7ca75a2..c76814edc784 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3210,6 +3210,11 @@ static enum hdmi_picture_aspect
> > > drm_get_cea_aspect_ratio(const u8 video_code)
> > > return edid_cea_modes[video_code].picture_aspect_ratio;
> > > }
> > >
> > > +static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8
> > > +video_code) {
> > > + return edid_4k_modes[video_code].picture_aspect_ratio;
> > > +}
> > > +
> >
> > There are no picture_aspect_ratio attributes defined for modes in
> > edid_4k_modes[] now. Should add on those definitions.
> >
> > > /*
> > > * Calculate the alternate clock for HDMI modes (those from the
> > > HDMI vendor
> > > * specific block).
> > > @@ -3236,6 +3241,9 @@ static u8
> > > drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode
> *to_
> > > if (!to_match->clock)
> > > return 0;
> > >
> > > + if (to_match->picture_aspect_ratio)
> > > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > > +
> > > for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > > const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
> > > unsigned int clock1, clock2;
> > > @@ -3271,6 +3279,9 @@ static u8 drm_match_hdmi_mode(const struct
> > > drm_display_mode *to_match)
> > > if (!to_match->clock)
> > > return 0;
> > >
> > > + if (to_match->picture_aspect_ratio)
> > > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > > +
> > > for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
> > > const struct drm_display_mode *hdmi_mode =
> &edid_4k_modes[vic];
> > > unsigned int clock1, clock2;
> >
> > Current code in drm_match_hdmi_mdoe() &
> > drm_match_hdmi_mode_clock_tolerance()
> > use hdmi_mode_alternate_clock() to find alternate clocks.
> > In hdmi_mode_alternate_clock(), it adds an exception for VIC 4 mode
> > (4096x2160@24) due to there is no alternate clock defined for that
> > mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode. Maybe we
> should also revise that part.
>
> I'm tempted to just remove that exception. I have a hard time imagining it
> causing serious problems.
Thanks for your time.
I've run smoke test and CTS to verify these patches (with adding the aspect
ratio
attribute to edid_4k_modes[] and removing the exception for23.98Hz). So far it
looks good on my environment. Is there any further modification should be done
on these patches?
>
> >
> > > @@ -5218,6 +5229,7 @@
> > > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > > *frame,
> > >const struct drm_display_mode *mode) {
> > > enum hdmi_picture_aspect picture_aspect;
> > > + u8 vic, hdmi_vic;
> > > int err;
> > >
> > > if (!frame || !mode)
> > > @@ -5230,7 +5242,8 @@
> > > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > > *frame,
> > > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > > frame->pixel_repeat = 1;
> > >
> > > - frame->video_code = drm_mode_cea_vic(connector, mode);
> > > + vic = drm_mode_cea_vic(connector, mode);
> > > + hdmi_vic = drm_mode_hdmi_vic(connector, mode);
> > >
> > > frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> > >
> > > @@ -5244,11 +5257,15 @@
> > > drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe
> > > *frame,
> > >
> > > /*
> > >* Populate picture aspect ratio from either
> > > - * user input (if specified) or from the CEA mode list.
> > > + * user input (if specified) or from the CEA/HDMI mode lists.
> > >*/
> > > picture_aspect = mode->picture_aspect_ratio;
> > > - if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
> > > - picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
> > > + if (picture_aspect == HDMI_PICTURE_ASPECT_NONE) {
> > > + if (vic)
> > > + picture_aspect = drm_get_cea_aspect_ratio(v
[Intel-gfx] [PATCH 4/4] drm/amdgpu: add independent DMA-buf import v8
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface
v4: split out from unpinned DMA-buf work
v5: rebased and cleanup on new DMA-buf interface
v6: squash with invalidation callback change,
stop using _(map|unmap)_locked
v7: drop invalidations when the BO is already in system domain
v8: rebase on new DMA-buf patch and drop move notification
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 38 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 4 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 ++---
4 files changed, 50 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index f14b52cc7205..c22d11df013e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -370,31 +370,28 @@ struct dma_buf *amdgpu_gem_prime_export(struct
drm_gem_object *gobj,
}
/**
- * amdgpu_gem_prime_import_sg_table - &drm_driver.gem_prime_import_sg_table
- * implementation
+ * amdgpu_dma_buf_create_obj - create BO for DMA-buf import
+ *
* @dev: DRM device
- * @attach: DMA-buf attachment
- * @sg: Scatter/gather table
+ * @dma_buf: DMA-buf
*
- * Imports shared DMA buffer memory exported by another device.
+ * Creates an empty SG BO for DMA-buf import.
*
* Returns:
* A new GEM BO of the given DRM device, representing the memory
* described by the given DMA-buf attachment and scatter/gather table.
*/
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
{
- struct dma_resv *resv = attach->dmabuf->resv;
+ struct dma_resv *resv = dma_buf->resv;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_bo *bo;
struct amdgpu_bo_param bp;
int ret;
memset(&bp, 0, sizeof(bp));
- bp.size = attach->dmabuf->size;
+ bp.size = dma_buf->size;
bp.byte_align = PAGE_SIZE;
bp.domain = AMDGPU_GEM_DOMAIN_CPU;
bp.flags = 0;
@@ -405,11 +402,9 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
if (ret)
goto error;
- bo->tbo.sg = sg;
- bo->tbo.ttm->sg = sg;
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
- if (attach->dmabuf->ops != &amdgpu_dmabuf_ops)
+ if (dma_buf->ops != &amdgpu_dmabuf_ops)
bo->prime_shared_count = 1;
dma_resv_unlock(resv);
@@ -434,6 +429,7 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
{
+ struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
if (dma_buf->ops == &amdgpu_dmabuf_ops) {
@@ -448,5 +444,17 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
}
}
- return drm_gem_prime_import(dev, dma_buf);
+ obj = amdgpu_dma_buf_create_obj(dev, dma_buf);
+ if (IS_ERR(obj))
+ return obj;
+
+ attach = dma_buf_dynamic_attach(dma_buf, dev->dev, true);
+ if (IS_ERR(attach)) {
+ drm_gem_object_put(obj);
+ return ERR_CAST(attach);
+ }
+
+ get_dma_buf(dma_buf);
+ obj->import_attach = attach;
+ return obj;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
index ce1b3f017451..ec447a7b6b28 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
@@ -25,10 +25,6 @@
#include
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg);
struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
int flags);
struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bf5bf15b12e3..7acca058510c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1409,7 +1409,6 @@ static struct drm_driver kms_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle
[Intel-gfx] [PATCH 1/4] dma-buf: change DMA-buf locking convention v2
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
It adds a dynamic flag for both importers as well as exporters
so that drivers can choose if they want the reservation object
locked or unlocked during mapping of attachments.
For compatibility between drivers we cache the DMA-buf mapping
during attaching an importer as soon as exporter/importer
disagree on the dynamic handling.
This change has gone through a lengthy discussion on dri-devel
and other mailing lists with at least 3-4 different attempts and
dead-ends until we settled on this solution. Please refer to the
mailing lists archives for full background on the history of
this change.
v2: cleanup set_name merge, improve kerneldoc
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 102 +-
include/linux/dma-buf.h | 57 +++--
2 files changed, 143 insertions(+), 16 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 433d91d710e4..753be84b5fd6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry *dentry, char
*buffer, int buflen)
size_t ret = 0;
dmabuf = dentry->d_fsdata;
- mutex_lock(&dmabuf->lock);
+ dma_resv_lock(dmabuf->resv, NULL);
if (dmabuf->name)
ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
- mutex_unlock(&dmabuf->lock);
+ dma_resv_unlock(dmabuf->resv);
return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
dentry->d_name.name, ret > 0 ? name : "");
@@ -334,7 +334,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const
char __user *buf)
if (IS_ERR(name))
return PTR_ERR(name);
- mutex_lock(&dmabuf->lock);
+ dma_resv_lock(dmabuf->resv, NULL);
if (!list_empty(&dmabuf->attachments)) {
ret = -EBUSY;
kfree(name);
@@ -344,7 +344,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const
char __user *buf)
dmabuf->name = name;
out_unlock:
- mutex_unlock(&dmabuf->lock);
+ dma_resv_unlock(dmabuf->resv);
return ret;
}
@@ -403,10 +403,10 @@ static void dma_buf_show_fdinfo(struct seq_file *m,
struct file *file)
/* Don't count the temporary reference taken inside procfs seq_show */
seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
- mutex_lock(&dmabuf->lock);
+ dma_resv_lock(dmabuf->resv, NULL);
if (dmabuf->name)
seq_printf(m, "name:\t%s\n", dmabuf->name);
- mutex_unlock(&dmabuf->lock);
+ dma_resv_unlock(dmabuf->resv);
}
static const struct file_operations dma_buf_fops = {
@@ -525,6 +525,10 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
+ exp_info->ops->dynamic_mapping))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -645,10 +649,11 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
- * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
optionally,
* calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev: [in]device to be attached.
+ * @dmabuf:[in]buffer to attach device to.
+ * @dev: [in]device to be attached.
+ * @dynamic_mapping: [in]calling convention for map/unmap
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -662,8 +667,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* accessible to @dev, and cannot be moved to a more suitable place. This is
* indicated with the error code -EBUSY.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *
+dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
+ bool dynamic_mapping)
{
struct dma_buf_attachment *attach;
int ret;
@@ -677,6 +683,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
attach->dev = dev;
attach->dmabuf = dmabuf;
+ attach->dynamic_mapping = dynamic_mapping;
mutex_lock(&dmabuf->lock);
@@ -685,16 +692,64 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
if (ret)
goto err_attach;
}
+ dma_resv_lock(dmabuf->resv, NULL);
[Intel-gfx] [PATCH 2/4] dma-buf: stop using the dmabuf->lock so much
The attachment list is now protected by the dma_resv object.
So we can drop holding this lock to allow concurrent attach
and detach operations.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 753be84b5fd6..c736e67ae1a1 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -685,8 +685,6 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
attach->dmabuf = dmabuf;
attach->dynamic_mapping = dynamic_mapping;
- mutex_lock(&dmabuf->lock);
-
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, attach);
if (ret)
@@ -696,8 +694,6 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
list_add(&attach->node, &dmabuf->attachments);
dma_resv_unlock(dmabuf->resv);
- mutex_unlock(&dmabuf->lock);
-
/* When either the importer or the exporter can't handle dynamic
* mappings we cache the mapping here to avoid issues with the
* reservation object lock.
@@ -726,7 +722,6 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
err_attach:
kfree(attach);
- mutex_unlock(&dmabuf->lock);
return ERR_PTR(ret);
err_unlock:
@@ -776,14 +771,12 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
dma_resv_unlock(attach->dmabuf->resv);
}
- mutex_lock(&dmabuf->lock);
dma_resv_lock(dmabuf->resv, NULL);
list_del(&attach->node);
dma_resv_unlock(dmabuf->resv);
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
- mutex_unlock(&dmabuf->lock);
kfree(attach);
}
EXPORT_SYMBOL_GPL(dma_buf_detach);
@@ -1247,14 +1240,6 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
"size", "flags", "mode", "count", "ino");
list_for_each_entry(buf_obj, &db_list.head, list_node) {
- ret = mutex_lock_interruptible(&buf_obj->lock);
-
- if (ret) {
- seq_puts(s,
-"\tERROR locking buffer object: skipping\n");
- continue;
- }
-
seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n",
buf_obj->size,
buf_obj->file->f_flags, buf_obj->file->f_mode,
@@ -1307,7 +1292,6 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
count++;
size += buf_obj->size;
- mutex_unlock(&buf_obj->lock);
}
seq_printf(s, "\nTotal %d objects, %zu bytes\n", count, size);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V4 2/6] modpost: add support for mdev class id
> -Original Message-
> From: Jason Wang
> Sent: Thursday, October 17, 2019 5:49 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh...@nvidia.com; alex.william...@redhat.com; m...@redhat.com;
> tiwei@intel.com
> Cc: virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> coh...@redhat.com; maxime.coque...@redhat.com;
> cunming.li...@intel.com; zhihong.w...@intel.com;
> rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> lingshan@intel.com; Ido Shamay ;
> epere...@redhat.com; l...@redhat.com; Parav Pandit
> ; christophe.de.dinec...@gmail.com;
> kevin.t...@intel.com; stefa...@redhat.com; Jason Wang
>
> Subject: [PATCH V4 2/6] modpost: add support for mdev class id
>
> Add support to parse mdev class id table.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/vfio_mdev.c | 2 ++
> scripts/mod/devicetable-offsets.c | 3 +++
> scripts/mod/file2alias.c | 10 ++
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
> index 7b24ee9cb8dd..cb701cd646f0 100644
> --- a/drivers/vfio/mdev/vfio_mdev.c
> +++ b/drivers/vfio/mdev/vfio_mdev.c
> @@ -125,6 +125,8 @@ static const struct mdev_class_id id_table[] = {
> { 0 },
> };
>
> +MODULE_DEVICE_TABLE(mdev, id_table);
> +
> static struct mdev_driver vfio_mdev_driver = {
> .name = "vfio_mdev",
> .probe = vfio_mdev_probe,
> diff --git a/scripts/mod/devicetable-offsets.c b/scripts/mod/devicetable-
> offsets.c
> index 054405b90ba4..6cbb1062488a 100644
> --- a/scripts/mod/devicetable-offsets.c
> +++ b/scripts/mod/devicetable-offsets.c
> @@ -231,5 +231,8 @@ int main(void)
> DEVID(wmi_device_id);
> DEVID_FIELD(wmi_device_id, guid_string);
>
> + DEVID(mdev_class_id);
> + DEVID_FIELD(mdev_class_id, id);
> +
> return 0;
> }
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c index
> c91eba751804..d365dfe7c718 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -1335,6 +1335,15 @@ static int do_wmi_entry(const char *filename,
> void *symval, char *alias)
> return 1;
> }
>
> +/* looks like: "mdev:cN" */
> +static int do_mdev_entry(const char *filename, void *symval, char
> +*alias) {
> + DEF_FIELD(symval, mdev_class_id, id);
> +
> + sprintf(alias, "mdev:c%02X", id);
> + return 1;
> +}
> +
> /* Does namelen bytes of name exactly match the symbol? */ static bool
> sym_is(const char *name, unsigned namelen, const char *symbol) { @@ -
> 1407,6 +1416,7 @@ static const struct devtable devtable[] = {
> {"typec", SIZE_typec_device_id, do_typec_entry},
> {"tee", SIZE_tee_client_device_id, do_tee_entry},
> {"wmi", SIZE_wmi_device_id, do_wmi_entry},
> + {"mdev", SIZE_mdev_class_id, do_mdev_entry},
> };
>
> /* Create MODULE_ALIAS() statements.
> --
> 2.19.1
Reviewed-by: Parav Pandit
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/amdgpu: add independent DMA-buf export v7
Add an DMA-buf export implementation independent of the DRM helpers.
This not only avoids the caching of DMA-buf mappings, but also
allows us to use the new dynamic locking approach.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftovers
v3: split out from unpinned DMA-buf work
v4: rebase on top of new no_sgt_cache flag
v5: fix some warnings by including amdgpu_dma_buf.h
v6: fix locking for non amdgpu exports
v7: rebased on new DMA-buf locking patch
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 172 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
4 files changed, 97 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 61f108ec2b5c..f14b52cc7205 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -34,26 +34,11 @@
#include "amdgpu.h"
#include "amdgpu_display.h"
#include "amdgpu_gem.h"
+#include "amdgpu_dma_buf.h"
#include
#include
#include
-/**
- * amdgpu_gem_prime_get_sg_table - &drm_driver.gem_prime_get_sg_table
- * implementation
- * @obj: GEM buffer object (BO)
- *
- * Returns:
- * A scatter/gather table for the pinned pages of the BO's memory.
- */
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- int npages = bo->tbo.num_pages;
-
- return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
/**
* amdgpu_gem_prime_vmap - &dma_buf_ops.vmap implementation
* @obj: GEM BO
@@ -179,92 +164,126 @@ __dma_resv_make_exclusive(struct dma_resv *obj)
}
/**
- * amdgpu_dma_buf_map_attach - &dma_buf_ops.attach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_dma_buf_attach - &dma_buf_ops.attach implementation
+ *
+ * @dmabuf: DMA-buf where we attach to
+ * @attach: attachment to add
+ *
+ * Add the attachment as user to the exported DMA-buf.
+ */
+static int amdgpu_dma_buf_attach(struct dma_buf *dmabuf,
+struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ int r;
+
+ if (attach->dev->driver == adev->dev->driver)
+ return 0;
+
+ r = amdgpu_bo_reserve(bo, false);
+ if (unlikely(r != 0))
+ return r;
+
+ /*
+* We only create shared fences for internal use, but importers
+* of the dmabuf rely on exclusive fences for implicitly
+* tracking write hazards. As any of the current fences may
+* correspond to a write, we need to convert all existing
+* fences on the reservation object into a single exclusive
+* fence.
+*/
+ r = __dma_resv_make_exclusive(bo->tbo.base.resv);
+ if (r)
+ return r;
+
+ bo->prime_shared_count++;
+ amdgpu_bo_unreserve(bo);
+ return 0;
+}
+
+/**
+ * amdgpu_dma_buf_detach - &dma_buf_ops.detach implementation
+ *
+ * @dmabuf: DMA-buf where we remove the attachment from
+ * @attach: the attachment to remove
+ *
+ * Called when an attachment is removed from the DMA-buf.
+ */
+static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+
+ if (attach->dev->driver != adev->dev->driver && bo->prime_shared_count)
+ bo->prime_shared_count--;
+}
+
+/**
+ * amdgpu_dma_buf_map - &dma_buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
+ * @dir: DMA direction
*
* Makes sure that the shared DMA buffer can be accessed by the target device.
* For now, simply pins it to the GTT domain, where it should be accessible by
* all DMA devices.
*
* Returns:
- * 0 on success or a negative error code on failure.
+ * sg_table filled with the DMA addresses to use or ERR_PRT with negative error
+ * code.
*/
-static int amdgpu_dma_buf_map_attach(struct dma_buf *dma_buf,
-struct dma_buf_attachment *attach)
+static struct sg_table *amdgpu_dma_buf_map(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
{
+ struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
- struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct sg_table *sgt;
long r;
- r = drm_gem_map_attach(dma_buf, attach);
Re: [Intel-gfx] [PATCH V4 3/6] mdev: introduce device specific ops
> -Original Message- > From: Jason Wang > Sent: Thursday, October 17, 2019 5:49 AM > To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel- > g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; > kwankh...@nvidia.com; alex.william...@redhat.com; m...@redhat.com; > tiwei@intel.com > Cc: virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org; > coh...@redhat.com; maxime.coque...@redhat.com; > cunming.li...@intel.com; zhihong.w...@intel.com; > rob.mil...@broadcom.com; xiao.w.w...@intel.com; > haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com; > jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; > rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch; > far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com; > ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com; > borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com; > lingshan@intel.com; Ido Shamay ; > epere...@redhat.com; l...@redhat.com; Parav Pandit > ; christophe.de.dinec...@gmail.com; > kevin.t...@intel.com; stefa...@redhat.com; Jason Wang > > Subject: [PATCH V4 3/6] mdev: introduce device specific ops > > Currently, except for the create and remove, the rest of mdev_parent_ops is > designed for vfio-mdev driver only and may not help for kernel mdev driver. > With the help of class id, this patch introduces device specific callbacks > inside mdev_device structure. This allows different set of callback to be used > by vfio-mdev and virtio-mdev. > > Signed-off-by: Jason Wang > --- > .../driver-api/vfio-mediated-device.rst | 25 + > MAINTAINERS | 1 + > drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --- > drivers/s390/cio/vfio_ccw_ops.c | 18 --- > drivers/s390/crypto/vfio_ap_ops.c | 14 +++-- > drivers/vfio/mdev/mdev_core.c | 18 +-- > drivers/vfio/mdev/mdev_private.h | 1 + > drivers/vfio/mdev/vfio_mdev.c | 37 ++--- > include/linux/mdev.h | 45 > include/linux/vfio_mdev.h | 52 +++ > samples/vfio-mdev/mbochs.c| 20 --- > samples/vfio-mdev/mdpy.c | 20 --- > samples/vfio-mdev/mtty.c | 18 --- > 13 files changed, 184 insertions(+), 103 deletions(-) create mode 100644 > include/linux/vfio_mdev.h > > diff --git a/Documentation/driver-api/vfio-mediated-device.rst > b/Documentation/driver-api/vfio-mediated-device.rst > index f9a78d75a67a..0cca84d19603 100644 > --- a/Documentation/driver-api/vfio-mediated-device.rst > +++ b/Documentation/driver-api/vfio-mediated-device.rst > @@ -152,11 +152,22 @@ callbacks per mdev parent device, per mdev type, > or any other categorization. > Vendor drivers are expected to be fully asynchronous in this respect or > provide their own internal resource protection.) > > -The callbacks in the mdev_parent_ops structure are as follows: > - > -* open: open callback of mediated device > -* close: close callback of mediated device > -* ioctl: ioctl callback of mediated device > +As multiple types of mediated devices may be supported, the device must > +set up the class id and the device specific callbacks in create() > +callback. E.g for vfio-mdev device it needs to be done through: > + > +int mdev_set_vfio_ops(struct mdev_device *mdev, > + const struct vfio_mdev_ops *vfio_ops); > + > +The class id (set to MDEV_CLASS_ID_VFIO) is used to match a device with > +an mdev driver via its id table. The device specific callbacks > +(specified in *ops) are obtainable via mdev_get_dev_ops() (for use by > +the mdev bus driver). A vfio-mdev device (class id MDEV_CLASS_ID_VFIO) > +uses the following device-specific ops: > + > +* open: open callback of vfio mediated device > +* close: close callback of vfio mediated device > +* ioctl: ioctl callback of vfio mediated device > * read : read emulation callback > * write: write emulation callback > * mmap: mmap emulation callback > @@ -167,10 +178,6 @@ register itself with the mdev core driver:: > extern int mdev_register_device(struct device *dev, >const struct mdev_parent_ops *ops); > > -It is also required to specify the class_id in create() callback through:: > - > - int mdev_set_class(struct mdev_device *mdev, u16 id); > - > However, the mdev_parent_ops structure is not required in the function call > that a driver should use to unregister itself with the mdev core driver:: > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8824f61cd2c0..3d196a023b5e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17127,6 +17127,7 @@ S:Maintained > F: Documentation/driver-api/vfio-mediated-device.rst > F: drivers/vfio/mdev/ >
Re: [Intel-gfx] [PATCH V4 1/6] mdev: class id support
> -Original Message-
> From: kvm-ow...@vger.kernel.org On Behalf
> Of Jason Wang
> Sent: Thursday, October 17, 2019 5:49 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh...@nvidia.com; alex.william...@redhat.com; m...@redhat.com;
> tiwei@intel.com
> Cc: virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> coh...@redhat.com; maxime.coque...@redhat.com;
> cunming.li...@intel.com; zhihong.w...@intel.com;
> rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> lingshan@intel.com; Ido Shamay ;
> epere...@redhat.com; l...@redhat.com; Parav Pandit
> ; christophe.de.dinec...@gmail.com;
> kevin.t...@intel.com; stefa...@redhat.com; Jason Wang
>
> Subject: [PATCH V4 1/6] mdev: class id support
>
> Mdev bus only supports vfio driver right now, so it doesn't implement match
> method. But in the future, we may add drivers other than vfio, the first
> driver could be virtio-mdev. This means we need to add device class id
> support in bus match method to pair the mdev device and mdev driver
> correctly.
>
> So this patch adds id_table to mdev_driver and class_id for mdev device
> with the match method for mdev bus.
>
> Signed-off-by: Jason Wang
> ---
> .../driver-api/vfio-mediated-device.rst | 7 +-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
> drivers/s390/cio/vfio_ccw_ops.c | 1 +
> drivers/s390/crypto/vfio_ap_ops.c | 1 +
> drivers/vfio/mdev/mdev_core.c | 18 +++
> drivers/vfio/mdev/mdev_driver.c | 22 +++
> drivers/vfio/mdev/mdev_private.h | 1 +
> drivers/vfio/mdev/vfio_mdev.c | 6 +
> include/linux/mdev.h | 8 +++
> include/linux/mod_devicetable.h | 8 +++
> samples/vfio-mdev/mbochs.c| 1 +
> samples/vfio-mdev/mdpy.c | 1 +
> samples/vfio-mdev/mtty.c | 1 +
> 13 files changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 25eb7d5b834b..f9a78d75a67a 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
>* @probe: called when new device created
>* @remove: called when device removed
>* @driver: device driver structure
> + * @id_table: the ids serviced by this driver
>*/
> struct mdev_driver {
>const char *name;
>int (*probe) (struct device *dev);
>void (*remove) (struct device *dev);
>struct device_driverdriver;
> + const struct mdev_class_id *id_table;
> };
>
> A mediated bus driver for mdev should use this structure in the function
> calls @@ -165,12 +167,15 @@ register itself with the mdev core driver::
> extern int mdev_register_device(struct device *dev,
>const struct mdev_parent_ops *ops);
>
> +It is also required to specify the class_id in create() callback through::
> +
> + int mdev_set_class(struct mdev_device *mdev, u16 id);
> +
> However, the mdev_parent_ops structure is not required in the function call
> that a driver should use to unregister itself with the mdev core driver::
>
> extern void mdev_unregister_device(struct device *dev);
>
> -
> Mediated Device Management Interface Through sysfs
> ==
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 343d79c1cb7e..6420f0dbd31b 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj,
> struct mdev_device *mdev)
>dev_name(mdev_dev(mdev)));
> ret = 0;
>
> + mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
> out:
> return ret;
> }
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c
> b/drivers/s390/cio/vfio_ccw_ops.c index f0d71ab77c50..cf2c013ae32f 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj,
> struct mdev_device *mdev)
> p
[Intel-gfx] [PATCH 1/2] drm/i915: Lift i915_vma_parked() onto the gt
Currently even though i915_vma_parked() operates on a per-gt struct, it
is called from a global pm notify. This oddity was only because the long
term plan is to decouple the vma cache from the pm notification, but
right now the oddity stands out like a sore thumb!
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 1 -
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
drivers/gpu/drm/i915/i915_vma.c| 32 +-
drivers/gpu/drm/i915/i915_vma.h| 2 +-
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 7987b54fb1f5..2aa7e9be088f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -23,7 +23,6 @@ static int pm_notifier(struct notifier_block *nb,
break;
case INTEL_GT_PARK:
- i915_vma_parked(i915);
break;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index b866d5b1eee0..fde5112b6650 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -71,6 +71,7 @@ static int __gt_park(struct intel_wakeref *wf)
pm_notify(gt, INTEL_GT_PARK);
intel_gt_park_requests(gt);
+ i915_vma_parked(gt);
i915_pmu_gt_parked(i915);
if (INTEL_GEN(i915) >= 6)
gen6_rps_idle(i915);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index e90c4d0af8fd..d733bcf262f0 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -106,7 +106,7 @@ vma_create(struct drm_i915_gem_object *obj,
struct rb_node *rb, **p;
/* The aliasing_ppgtt should never be used directly! */
- GEM_BUG_ON(vm == &vm->i915->ggtt.alias->vm);
+ GEM_BUG_ON(vm == &vm->gt->ggtt->alias->vm);
vma = i915_vma_alloc();
if (vma == NULL)
@@ -412,7 +412,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
int err;
/* Access through the GTT requires the device to be awake. */
- assert_rpm_wakelock_held(&vma->vm->i915->runtime_pm);
+ assert_rpm_wakelock_held(vma->vm->gt->uncore->rpm);
if (GEM_WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
err = -ENODEV;
goto err;
@@ -945,7 +945,7 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
void i915_vma_close(struct i915_vma *vma)
{
- struct drm_i915_private *i915 = vma->vm->i915;
+ struct intel_gt *gt = vma->vm->gt;
unsigned long flags;
GEM_BUG_ON(i915_vma_is_closed(vma));
@@ -962,18 +962,18 @@ void i915_vma_close(struct i915_vma *vma)
* causing us to rebind the VMA once more. This ends up being a lot
* of wasted work for the steady state.
*/
- spin_lock_irqsave(&i915->gt.closed_lock, flags);
- list_add(&vma->closed_link, &i915->gt.closed_vma);
- spin_unlock_irqrestore(&i915->gt.closed_lock, flags);
+ spin_lock_irqsave(>->closed_lock, flags);
+ list_add(&vma->closed_link, >->closed_vma);
+ spin_unlock_irqrestore(>->closed_lock, flags);
}
static void __i915_vma_remove_closed(struct i915_vma *vma)
{
- struct drm_i915_private *i915 = vma->vm->i915;
+ struct intel_gt *gt = vma->vm->gt;
- spin_lock_irq(&i915->gt.closed_lock);
+ spin_lock_irq(>->closed_lock);
list_del_init(&vma->closed_link);
- spin_unlock_irq(&i915->gt.closed_lock);
+ spin_unlock_irq(>->closed_lock);
}
void i915_vma_reopen(struct i915_vma *vma)
@@ -1009,12 +1009,12 @@ void i915_vma_destroy(struct i915_vma *vma)
i915_vma_free(vma);
}
-void i915_vma_parked(struct drm_i915_private *i915)
+void i915_vma_parked(struct intel_gt *gt)
{
struct i915_vma *vma, *next;
- spin_lock_irq(&i915->gt.closed_lock);
- list_for_each_entry_safe(vma, next, &i915->gt.closed_vma, closed_link) {
+ spin_lock_irq(>->closed_lock);
+ list_for_each_entry_safe(vma, next, >->closed_vma, closed_link) {
struct drm_i915_gem_object *obj = vma->obj;
struct i915_address_space *vm = vma->vm;
@@ -1028,7 +1028,7 @@ void i915_vma_parked(struct drm_i915_private *i915)
obj = NULL;
}
- spin_unlock_irq(&i915->gt.closed_lock);
+ spin_unlock_irq(>->closed_lock);
if (obj) {
i915_vma_destroy(vma);
@@ -1038,11 +1038,11 @@ void i915_vma_parked(struct drm_i915_private *i915)
i915_vm_close(vm);
/* Restart after dropping lock */
- spin_lock_irq(&i915->gt.closed_lock);
- next = list_first_entry(&i915->gt.closed_vma,
+ spin_lock_irq(>->closed_lock);
+ nex
[Intel-gfx] [PATCH 2/2] drm/i915: Remove pm park/unpark notifications
With the last user, i915_vma_parked(), retired, there are no more users
of the per-gt pm notifications and we can remove the unused
infrastructure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 25
drivers/gpu/drm/i915/gem/i915_gem_pm.h | 2 --
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 10 --
drivers/gpu/drm/i915/gt/intel_gt_pm.h| 5 -
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 --
drivers/gpu/drm/i915/i915_gem.c | 1 -
6 files changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 2aa7e9be088f..ee3279c76566 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -11,24 +11,6 @@
#include "i915_drv.h"
-static int pm_notifier(struct notifier_block *nb,
- unsigned long action,
- void *data)
-{
- struct drm_i915_private *i915 =
- container_of(nb, typeof(*i915), gem.pm_notifier);
-
- switch (action) {
- case INTEL_GT_UNPARK:
- break;
-
- case INTEL_GT_PARK:
- break;
- }
-
- return NOTIFY_OK;
-}
-
static bool switch_to_kernel_context_sync(struct intel_gt *gt)
{
bool result = !intel_gt_is_wedged(gt);
@@ -206,10 +188,3 @@ void i915_gem_resume(struct drm_i915_private *i915)
}
goto out_unlock;
}
-
-void i915_gem_init__pm(struct drm_i915_private *i915)
-{
- i915->gem.pm_notifier.notifier_call = pm_notifier;
- blocking_notifier_chain_register(&i915->gt.pm_notifications,
-&i915->gem.pm_notifier);
-}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.h
b/drivers/gpu/drm/i915/gem/i915_gem_pm.h
index 6f7d5d11ac3b..a017572778d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.h
@@ -12,8 +12,6 @@
struct drm_i915_private;
struct work_struct;
-void i915_gem_init__pm(struct drm_i915_private *i915);
-
bool i915_gem_load_power_context(struct drm_i915_private *i915);
void i915_gem_resume(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index fde5112b6650..427aded512f2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -16,11 +16,6 @@
#include "intel_rc6.h"
#include "intel_wakeref.h"
-static void pm_notify(struct intel_gt *gt, int state)
-{
- blocking_notifier_call_chain(>->pm_notifications, state, gt->i915);
-}
-
static int __gt_unpark(struct intel_wakeref *wf)
{
struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
@@ -55,8 +50,6 @@ static int __gt_unpark(struct intel_wakeref *wf)
intel_gt_queue_hangcheck(gt);
intel_gt_unpark_requests(gt);
- pm_notify(gt, INTEL_GT_UNPARK);
-
return 0;
}
@@ -68,7 +61,6 @@ static int __gt_park(struct intel_wakeref *wf)
GEM_TRACE("\n");
- pm_notify(gt, INTEL_GT_PARK);
intel_gt_park_requests(gt);
i915_vma_parked(gt);
@@ -96,8 +88,6 @@ static const struct intel_wakeref_ops wf_ops = {
void intel_gt_pm_init_early(struct intel_gt *gt)
{
intel_wakeref_init(>->wakeref, gt->uncore->rpm, &wf_ops);
-
- BLOCKING_INIT_NOTIFIER_HEAD(>->pm_notifications);
}
void intel_gt_pm_init(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 997770d3a968..0ed87da4bb68 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -12,11 +12,6 @@
#include "intel_gt_types.h"
#include "intel_wakeref.h"
-enum {
- INTEL_GT_UNPARK,
- INTEL_GT_PARK,
-};
-
static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
{
return intel_wakeref_is_active(>->wakeref);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index ae4aaf75ac78..980973e66e7f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -83,8 +83,6 @@ struct intel_gt {
struct intel_llc llc;
struct intel_rc6 rc6;
- struct blocking_notifier_head pm_notifications;
-
ktime_t last_init_time;
struct i915_vma *scratch;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2ba123f7b31..39cb0e246a88 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1435,7 +1435,6 @@ static void i915_gem_init__mm(struct drm_i915_private
*i915)
void i915_gem_init_early(struct drm_i915_private *dev_priv)
{
i915_gem_init__mm(dev_priv);
- i915_gem_init__pm(dev_priv);
spin_lock_init(&dev_priv->fb_tracking.lock);
}
--
2.24.0.rc0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
[Intel-gfx] [PULL] drm-intel-next
SAGV block time to dev_priv (James) - Avoid polluting the i915_oa_config with error pointers (Chris) - Squelch display kerneldoc warnings (Chris) - Assert tasklet is locked for process_csb() (Chris) - Switch to using DP_MSA_MISC_* defines (Ville) - Stop using drm_atomic_helper_check_planes() (Ville) - Make .modeset_calc_cdclk() mandatory (Ville) - Use drm_rect_translate_to()/drm_rect_init() (Ville) - Refactor timestamping constants update (Ville) - Switch intel_legacy_cursor_update() to intel_ types (Ville) - Prepare the connector/encoder mask readout for hw vs. uapi state split (Ville) - Prepare the mode readout for hw vs. uapi state split (Ville) - Move swizzle_bit under i915_ggtt (Chris) - Improve microcontrollers documentation (Daniele) - Move the cursor rotation handling into intel_cursor_check_surface() (Ville) - Cleanups to pipe code (Ville) - Shrink eDRAM ways/sets arrays for code size (Ville) - Cleanups to HDCP2 timeout code (Ville) - Restore full symmetry in i915_driver_modeset_probe/remove (Janusz) - Simplify setting of ddi_io_power_domain (Lucas) - Add pipe id/name to pipe mismatch logs (Lucas) - Prettify MST debug message (Lucas) - Extract GT ring management to separate files (Andi) The following changes since commit 7ed093602e0e1b60a0fc074a9692687e7d2b723d: Merge tag 'drm-misc-next-2019-10-09-2' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-10-11 09:30:53 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-10-21 for you to fetch changes up to ce53908bba6fa6e905d8fe81da4591d3e7a65878: drm/i915: Update DRIVER_DATE to 20191021 (2019-10-21 12:56:07 +0300) UAPI Changes: - Introduce a versioning of the i915-perf uapi (Lionel) - Add support for perf configuration queries (Lionel) Allow listing perf configurations with IOCTL in addition to sysfs. This is useful in container usecases. - Allow dynamic reconfiguration of the OA stream (Chris) Allows the OA stream to be reconfigured between batch buffers, giving greater flexibility in sampling. - Allow holding preemption on filtered perf ctx Allow CAP_ADMIN to block pre-emption of a context to query performance counters without disturbances. Mesa changes: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/932 Cross-subsystem Changes: - drm-next backmerge for HDR DP changes https://lists.freedesktop.org/archives/dri-devel/2019-September/236453.html Driver Changes: - Add DC3CO sleep state for Tigerlake (Anshuman) - Tigerlake BCS engine support engine relative MMIO (Daniele) - Simplify the Tigerlake LRC register list for !RCS (Daniele) - Read SAGV block time from PCODE on Tigerlake (James) - Add 12 missing Tigerlake workarounds (Mika) - Enable DDI/Port G for Tigerlake (Khaled) - Avoid hang in tsg,vfe units by keeping l3 clocks ICL+(Mika) - Fix Bugzilla #111966: Favor last VBT child device (Ville) - Fix blue/black screen on boot due to broken gamma (Swati) - Add support of BT.2020 Colorimetry to DP MSA (Gwan-gyeong) - Attach colorspace property to DP connector (Gwan-gyeong) - Attach HDR metadata property to DP connector (Gwan-gyeong) - Base intel_memory_region support prep for local memory (Matt A) - Introduce Jasper Lake PCH (Matt R) - Support multiple GPUs in PMU (Tvrtko) - Fix MST oops due to MSA changes (Ville) - Refuse modes with hdisplay==4096 on pre-HSW DP (Ville) - Correct the PCH type in irq postinstall for JSP (Vivek) - Save Master transcoder in slave's crtc_state for Transcoder Port Sync (Manasi) - Enable TRANSCODER PORT SYNC for tiled displays across separate ports (Manasi) - HW state readout for transcoder port sync config (Manasi) - Enable master-slaves in trans port sync (Manasi) - In port sync mode disable slaves first then master (Manasi) - Fix port checks for MST support on gen >= 11 (Lucas) - Flush submission tasklet before waiting/retiring (Chris) - Flush tasklet submission before sleeping on i915_request_wait (Chris) - Object pin reference counting fixes (Chris, Matt A) - Clear semaphore immediately upon ELSP promotion (Chris) - Child device size remains unchanged through VBT 229 (Matt R) - Restore dropped 'interruptible' flag on retiring requests (Chris) - Treat a busy timeline as 'active' while waiting (Chris) - Clean up struct_mutex from perf (Chris) - Update locking around execlists->active (Chris) - Mark up expected execlist state during reset (Chris) - Remove cursor use of properties for coordinates (Maarten) - Only mark incomplete requests as -EIO on cancelling (Chris) - Add an rcu_barrier option to i915_drop_caches (Chris) - Replace perf global wakeref tracking with engine-pm (Chris) - Prevent merging requests with conflicting flags (Chris) - Allow for CS OA configs to be created lazily (Lionel) - Implement active wait for noa configurations (Lionel) - Execute OA configuration from command str
[Intel-gfx] [CI] drm/i915/gt: Introduce barrier pulses along engines
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushed, as part of a context cancellation mechanism, or as
part of a heartbeat mechanism to detect and reset a stuck GPU.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 3 +-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 77 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 15 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
.../drm/i915/gt/selftest_engine_heartbeat.c | 159 ++
drivers/gpu/drm/i915/i915_active.c| 1 +
drivers/gpu/drm/i915/i915_priolist_types.h| 1 +
.../drm/i915/selftests/i915_live_selftests.h | 1 +
8 files changed, 257 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
create mode 100644 drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a16a2daef977..2fd4bed188e5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,8 +78,9 @@ gt-y += \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
gt/intel_engine_cs.o \
- gt/intel_engine_pool.o \
+ gt/intel_engine_heartbeat.o \
gt/intel_engine_pm.o \
+ gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_gt.o \
gt/intel_gt_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
new file mode 100644
index ..4b9ab7813d54
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -0,0 +1,77 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_request.h"
+
+#include "intel_context.h"
+#include "intel_engine_heartbeat.h"
+#include "intel_engine_pm.h"
+#include "intel_engine.h"
+#include "intel_gt.h"
+
+static void idle_pulse(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
+ i915_request_add_active_barriers(rq);
+}
+
+int intel_engine_pulse(struct intel_engine_cs *engine)
+{
+ struct i915_sched_attr attr = { .priority = I915_PRIORITY_BARRIER };
+ struct intel_context *ce = engine->kernel_context;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (!intel_engine_has_preemption(engine))
+ return -ENODEV;
+
+ if (!intel_engine_pm_get_if_awake(engine))
+ return 0;
+
+ if (mutex_lock_interruptible(&ce->timeline->mutex))
+ goto out_rpm;
+
+ intel_context_enter(ce);
+ rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
+ intel_context_exit(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_unlock;
+ }
+
+ rq->flags |= I915_REQUEST_SENTINEL;
+ idle_pulse(engine, rq);
+
+ __i915_request_commit(rq);
+ __i915_request_queue(rq, &attr);
+
+out_unlock:
+ mutex_unlock(&ce->timeline->mutex);
+out_rpm:
+ intel_engine_pm_put(engine);
+ return err;
+}
+
+int intel_engine_flush_barriers(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ if (llist_empty(&engine->barrier_tasks))
+ return 0;
+
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ idle_pulse(engine, rq);
+ i915_request_add(rq);
+
+ return 0;
+}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_engine_heartbeat.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
new file mode 100644
index ..b334e5aaf78d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -0,0 +1,15 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef INTEL_ENGINE_HEARTBEAT_H
+#define INTEL_ENGINE_HEARTBEAT_H
+
+struct intel_engine_cs;
+
+int intel_engine_pulse(struct intel_engine_cs *engine);
+int intel_engine_flush_barriers(struct intel_engine_cs *engine);
+
+#endif /* INTEL_ENGINE_HEARTBEAT_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 67eb6183648a..7d76611d9df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -111,7 +111,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
i915_request_add_active_barriers(rq);
/* Install ourselves as a preemption barrier */
-
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Refactor intel_can_enable_sagv
On Fri, Oct 18, 2019 at 01:34:35AM -0700, Lisovskiy, Stanislav wrote:
> On Thu, 2019-10-17 at 14:53 -0700, James Ausmus wrote:
> > On Tue, Oct 15, 2019 at 04:50:12PM +0300, Stanislav Lisovskiy wrote:
> > > Currently intel_can_enable_sagv function contains
> > > a mix of workarounds for different platforms
> > > some of them are not valid for gens >= 11 already,
> > > so lets split it into separate functions.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > Cc: Ville Syrjälä
> > > Cc: James Ausmus
> > > ---
> > > drivers/gpu/drm/i915/intel_pm.c | 73
> > > +++--
> > > 1 file changed, 70 insertions(+), 3 deletions(-)
> > >
> > > +bool icl_can_enable_sagv(struct intel_atomic_state *state)
> > > +{
> > > + struct drm_device *dev = state->base.dev;
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > + struct intel_crtc *crtc;
> > > + struct intel_crtc_state *new_crtc_state;
> > > + int level, latency;
> > > + int i;
> > > + int plane_id;
> > > +
> > > + if (!intel_has_sagv(dev_priv))
> > > + return false;
> > > +
> > > + /*
> > > + * If there are no active CRTCs, no additional checks need be
> > > performed
> > > + */
> > > + if (hweight8(state->active_pipes) == 0)
> > > + return true;
> > > +
> > > + for_each_new_intel_crtc_in_state(state, crtc,
> > > + new_crtc_state, i) {
> > > +
> > > + if (crtc->base.state->adjusted_mode.flags &
> > > DRM_MODE_FLAG_INTERLACE)
> > > + return false;
> > > +
> > > + if (!new_crtc_state->base.enable)
> > > + continue;
> > > +
> > > + for_each_plane_id_on_crtc(crtc, plane_id) {
> > > + struct skl_plane_wm *wm =
> > > + &new_crtc_state-
> > > >wm.skl.optimal.planes[plane_id];
> > > +
> > > + /* Skip this plane if it's not enabled */
> > > + if (!wm->wm[0].plane_en)
> > > + continue;
> > > +
> > > + /* Find the highest enabled wm level for this
> > > plane */
> > > + for (level = ilk_wm_max_level(dev_priv);
> > > + !wm->wm[level].plane_en; --level)
> > > + { }
> > > +
> > > + latency = dev_priv->wm.skl_latency[level];
> >
> > This isn't exactly the same for TGL. From BSpec 49325, "Calculate
> > watermark level 0 with level 0 latency + SAGV block time. If the
> > result
> > can be supported (does not exceed maximum), then the plane can
> > tolerate
> > SAGV", so I think it can be simplified for Gen12+ by not having to
> > loop
> > through all the wm levels.
> >
> > -James
>
> Yes, we discussed that with Ville as I understood, properly doing
> that for TGL requires changes to watermark/ddb allocation algorithm,
> so that we check if dbuf can fit Level 0 watermark increased by SAGV
> block time. I was not sure whether should I add this patch to this
> series or proceed with that separately, probably this is worth adding
> here - however then it would require changes to watermark algorithm,
> as we need to recalculate min_ddb_alloc for Level 0 latency + SAGV
> and then check if we fit into DBuf again.
> So basically we'll have to calculate watermark level 0 twice - once for
> SAGV enabled and once for SAGV disabled case, I would probably do it
> already during watermark calculations not when checking bandwidth and
> then set some "SAGV can enable" flag, which will be then used by
> intel_can_enable_sagv, so that we act accordingly when
> bandwidth check and restricting qgv points happens. For pre-gen 12 it
> will otherwise use the old algorithm.
OK, that works then. With the whitespace fix added:
Reviewed-by: James Ausmus
>
> >
> > > +
> > > + /*
> > > + * If any of the planes on this pipe don't
> > > enable wm levels that
> > > + * incur memory latencies higher than
> > > sagv_block_time_us we
> > > + * can't enable SAGV.
> > > + */
> > > + if (latency < dev_priv->sagv_block_time_us)
> > > + return false;
> > > + }
> > > + }
> > > +
> > > + return true;
> > > +}
> > > +
> > > +bool intel_can_enable_sagv(struct intel_atomic_state *state)
> > > +{
> > > + struct drm_device *dev = state->base.dev;
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > +
> > > + if (INTEL_GEN(dev_priv) >= 11)
> > > + return icl_can_enable_sagv(state);
> > > +
> > > + return skl_can_enable_sagv(state);
> > > +}
> > > +
> > > static u16 intel_get_ddb_size(struct drm_i915_private *dev_priv,
> > > const struct intel_crtc_state
> > > *crtc_state,
> > > const u64 total_data_rate,
> > > --
> > > 2.17.1
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gf
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Use all physical engines for i915_active
== Series Details ==
Series: drm/i915/selftests: Use all physical engines for i915_active
URL : https://patchwork.freedesktop.org/series/68322/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14905
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/index.html
Known issues
Here are the changes found in Patchwork_14905 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@flink-lifetime:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
Possible fixes
* igt@gem_ctx_switch@rcs0:
- {fi-icl-guc}: [INCOMPLETE][3] ([fdo#107713]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
* igt@gem_exec_parallel@basic:
- {fi-tgl-u}: [INCOMPLETE][5] ([fdo#111887]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-tgl-u/igt@gem_exec_paral...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/fi-tgl-u/igt@gem_exec_paral...@basic.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: [DMESG-WARN][7] ([fdo#105128] / [fdo#107139]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8109u: [DMESG-FAIL][11] ([fdo#112050 ]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][13] ([fdo#102614]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111887]: https://bugs.freedesktop.org/show_bug.cgi?id=111887
[fdo#112050 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112050
Participating hosts (53 -> 45)
--
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-cfl-8700k fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7141 -> Patchwork_14905
CI-20190529: 20190529
CI_DRM_7141: a109221528d0b9d4f24065aed372c6b45e251bd6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14905: 364eb0da67500bc797f0bafe85d497f1db7b2982 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
364eb0da6750 drm/i915/selftests: Use all physical engines for i915_active
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14905/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Use all physical engines for i915_active
On 21/10/2019 17:21, Chris Wilson wrote:
i915_active must track over any engine, so expand the selftest to
iterate over all uabi engines.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/i915_active.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 268192b5613b..96513a7d4739 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -79,7 +79,6 @@ __live_active_setup(struct drm_i915_private *i915)
struct intel_engine_cs *engine;
struct i915_sw_fence *submit;
struct live_active *active;
- enum intel_engine_id id;
unsigned int count = 0;
int err = 0;
@@ -97,7 +96,7 @@ __live_active_setup(struct drm_i915_private *i915)
if (err)
goto out;
- for_each_engine(engine, i915, id) {
+ for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
rq = i915_request_create(engine->kernel_context);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/aml: Allow SPT PCH for all AML devices (rev2)
On Fri, Oct 18, 2019 at 08:20:44AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/aml: Allow SPT PCH for all AML devices (rev2)
> URL : https://patchwork.freedesktop.org/series/68176/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7125_full -> Patchwork_14872_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
Anyone mind merging? :)
Thanks!
-James
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_14872_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@gem_render_copy@yf-tiled-ccs-to-x-tiled:
> - {shard-tglb}: NOTRUN -> [INCOMPLETE][1] +1 similar issue
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-tglb2/igt@gem_render_c...@yf-tiled-ccs-to-x-tiled.html
>
> * igt@kms_color@pipe-d-ctm-0-25:
> - {shard-tglb}: NOTRUN -> [FAIL][2]
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-tglb6/igt@kms_co...@pipe-d-ctm-0-25.html
>
> * {igt@kms_cursor_crc@pipe-d-cursor-512x512-onscreen}:
> - {shard-tglb}: NOTRUN -> [SKIP][3] +3 similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-tglb2/igt@kms_cursor_...@pipe-d-cursor-512x512-onscreen.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_14872_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_schedule@preemptive-hang-bsd:
> - shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#111325]) +3 similar
> issues
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html
>
> * igt@gem_exec_schedule@promotion-bsd1:
> - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109276]) +5 similar
> issues
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-iclb6/igt@gem_exec_sched...@promotion-bsd1.html
>
> * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup:
> - shard-snb: [PASS][8] -> [DMESG-WARN][9] ([fdo#111870])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html
>
> * igt@gem_workarounds@suspend-resume:
> - shard-skl: [PASS][10] -> [INCOMPLETE][11] ([fdo#104108])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-skl7/igt@gem_workarou...@suspend-resume.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-skl6/igt@gem_workarou...@suspend-resume.html
>
> * igt@gem_workarounds@suspend-resume-context:
> - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([fdo#108566]) +3
> similar issues
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-apl8/igt@gem_workarou...@suspend-resume-context.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-apl6/igt@gem_workarou...@suspend-resume-context.html
>
> * igt@i915_pm_rc6_residency@rc6-accuracy:
> - shard-kbl: [PASS][14] -> [SKIP][15] ([fdo#109271])
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-kbl3/igt@i915_pm_rc6_reside...@rc6-accuracy.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-kbl7/igt@i915_pm_rc6_reside...@rc6-accuracy.html
>
> * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding:
> - shard-iclb: [PASS][16] -> [INCOMPLETE][17] ([fdo#107713])
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-iclb1/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-iclb7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html
>
> * igt@kms_flip@flip-vs-expired-vblank-interruptible:
> - shard-glk: [PASS][18] -> [FAIL][19] ([fdo#105363])
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7125/shard-glk7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14872/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
>
> * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
> - shard-iclb: [PASS][20] -> [FAIL][21] ([fdo#103167]) +5 similar
Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
On 10/21/19 4:50 PM, Daniel Vetter wrote: > Full audit of everyone: > > - i915, radeon, amdgpu should be clean per their maintainers. > > - vram helpers should be fine, they don't do command submission, so > really no business holding struct_mutex while doing copy_*_user. But > I haven't checked them all. > > - panfrost seems to dma_resv_lock only in panfrost_job_push, which > looks clean. > > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(), > copying from/to userspace happens all in v3d_lookup_bos which is > outside of the critical section. > > - vmwgfx has a bunch of ioctls that do their own copy_*_user: > - vmw_execbuf_process: First this does some copies in > vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself. > Then comes the usual ttm reserve/validate sequence, then actual > submission/fencing, then unreserving, and finally some more > copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of > details, but looks all safe. > - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be > seen, seems to only create a fence and copy it out. > - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be > found there. > Summary: vmwgfx seems to be fine too. > > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the > copying from userspace before even looking up objects through their > handles, so safe. Plus the getparam/getcaps ioctl, also both safe. > > - qxl only has qxl_execbuffer_ioctl, which calls into > qxl_process_single_command. There's a lovely comment before the > __copy_from_user_inatomic that the slowpath should be copied from > i915, but I guess that never happened. Try not to be unlucky and get > your CS data evicted between when it's written and the kernel tries > to read it. The only other copy_from_user is for relocs, but those > are done before qxl_release_reserve_list(), which seems to be the > only thing reserving buffers (in the ttm/dma_resv sense) in that > code. So looks safe. > > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in > usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this > everywhere and needs to be fixed up. > > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a > dma_resv lock of a different object already. Christian mentioned that > ttm core does this too for ghost objects. intel-gfx-ci highlighted > that i915 has similar issues. > > Unfortunately we can't do this in the usual module init functions, > because kernel threads don't have an ->mm - we have to wait around for > some user thread to do this. > > Solution is to spawn a worker (but only once). It's horrible, but it > works. > > v3: We can allocate mm! (Chris). Horrible worker hack out, clean > initcall solution in. > > v4: Annotate with __init (Rob Herring) > > Cc: Rob Herring > Cc: Alex Deucher > Cc: Christian König > Cc: Chris Wilson > Cc: Thomas Zimmermann > Cc: Rob Herring > Cc: Tomeu Vizoso > Cc: Eric Anholt > Cc: Dave Airlie > Cc: Gerd Hoffmann > Cc: Ben Skeggs > Cc: "VMware Graphics" > Cc: Thomas Hellstrom > Reviewed-by: Christian König > Reviewed-by: Chris Wilson > Tested-by: Chris Wilson > Signed-off-by: Daniel Vetter Including the vmwgfx audit, Reviewed-by: Thomas Hellstrom Thanks, Thomas ___ 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/gt: Introduce barrier pulses along engines (rev3)
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines (rev3)
URL : https://patchwork.freedesktop.org/series/68309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14904
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14904 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14904, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14904:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_active:
- fi-byt-n2820: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-byt-n2820/igt@i915_selftest@live_active.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-byt-n2820/igt@i915_selftest@live_active.html
* igt@i915_selftest@live_coherency:
- fi-snb-2600:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-snb-2600/igt@i915_selftest@live_coherency.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-snb-2600/igt@i915_selftest@live_coherency.html
* igt@i915_selftest@live_dmabuf:
- fi-ivb-3770:[PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-ivb-3770/igt@i915_selftest@live_dmabuf.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-ivb-3770/igt@i915_selftest@live_dmabuf.html
* {igt@i915_selftest@live_gt_heartbeat} (NEW):
- fi-kbl-x1275: NOTRUN -> [DMESG-FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-kbl-x1275/igt@i915_selftest@live_gt_heartbeat.html
- fi-bsw-kefka: NOTRUN -> [DMESG-FAIL][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-bsw-kefka/igt@i915_selftest@live_gt_heartbeat.html
- {fi-icl-dsi}: NOTRUN -> [DMESG-FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
- fi-cfl-8700k: NOTRUN -> [DMESG-FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-cfl-8700k/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-6600u: NOTRUN -> [DMESG-FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-skl-6600u/igt@i915_selftest@live_gt_heartbeat.html
- fi-kbl-8809g: NOTRUN -> [DMESG-FAIL][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
- {fi-icl-u4}:NOTRUN -> [DMESG-FAIL][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-icl-u4/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-lmem:NOTRUN -> [DMESG-FAIL][14]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-skl-lmem/igt@i915_selftest@live_gt_heartbeat.html
- fi-apl-guc: NOTRUN -> [DMESG-FAIL][15]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-apl-guc/igt@i915_selftest@live_gt_heartbeat.html
- fi-kbl-r: NOTRUN -> [DMESG-FAIL][16]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-kbl-r/igt@i915_selftest@live_gt_heartbeat.html
- fi-bdw-5557u: NOTRUN -> [DMESG-FAIL][17]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-bdw-5557u/igt@i915_selftest@live_gt_heartbeat.html
- fi-bwr-2160:NOTRUN -> [DMESG-FAIL][18]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-bwr-2160/igt@i915_selftest@live_gt_heartbeat.html
- fi-byt-n2820: NOTRUN -> [DMESG-FAIL][19]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-byt-n2820/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-6770hq: NOTRUN -> [DMESG-FAIL][20]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-skl-6770hq/igt@i915_selftest@live_gt_heartbeat.html
- fi-kbl-guc: NOTRUN -> [DMESG-FAIL][21]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-kbl-guc/igt@i915_selftest@live_gt_heartbeat.html
- fi-snb-2600:NOTRUN -> [DMESG-FAIL][22]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-snb-2600/igt@i915_selftest@live_gt_heartbeat.html
- fi-elk-e7500: NOTRUN -> [DMESG-FAIL][23]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-elk-e7500/igt@i915_selftest@live_gt_heartbeat.html
- {fi-tgl-u2}:NOTRUN -> [DMESG-FAIL][24]
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14904/fi-tgl-u2/igt@i915_selftest@live_gt
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Introduce barrier pulses along engines (rev3)
== Series Details == Series: drm/i915/gt: Introduce barrier pulses along engines (rev3) URL : https://patchwork.freedesktop.org/series/68309/ State : warning == Summary == $ dim checkpatch origin/drm-tip 420dc8e008a2 drm/i915/gt: Introduce barrier pulses along engines -:32: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #32: new file mode 100644 -:37: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #37: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:1: +/* -:38: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #38: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:2: + * SPDX-License-Identifier: MIT -:120: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #120: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:1: +/* -:121: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #121: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:2: + * SPDX-License-Identifier: MIT -:154: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #154: FILE: drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c:1: +/* -:155: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #155: FILE: drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c:2: + * SPDX-License-Identifier: MIT total: 0 errors, 7 warnings, 0 checks, 274 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Use all physical engines for i915_active
i915_active must track over any engine, so expand the selftest to
iterate over all uabi engines.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/i915_active.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 268192b5613b..96513a7d4739 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -79,7 +79,6 @@ __live_active_setup(struct drm_i915_private *i915)
struct intel_engine_cs *engine;
struct i915_sw_fence *submit;
struct live_active *active;
- enum intel_engine_id id;
unsigned int count = 0;
int err = 0;
@@ -97,7 +96,7 @@ __live_active_setup(struct drm_i915_private *i915)
if (err)
goto out;
- for_each_engine(engine, i915, id) {
+ for_each_uabi_engine(engine, i915) {
struct i915_request *rq;
rq = i915_request_create(engine->kernel_context);
--
2.24.0.rc0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gt: Introduce barrier pulses along engines
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushed, as part of a context cancellation mechanism, or as
part of a heartbeat mechanism to detect and reset a stuck GPU.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 3 +-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 77 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 15 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
.../drm/i915/gt/selftest_engine_heartbeat.c | 150 ++
drivers/gpu/drm/i915/i915_priolist_types.h| 1 +
.../drm/i915/selftests/i915_live_selftests.h | 1 +
7 files changed, 247 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
create mode 100644 drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a16a2daef977..2fd4bed188e5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,8 +78,9 @@ gt-y += \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
gt/intel_engine_cs.o \
- gt/intel_engine_pool.o \
+ gt/intel_engine_heartbeat.o \
gt/intel_engine_pm.o \
+ gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_gt.o \
gt/intel_gt_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
new file mode 100644
index ..4b9ab7813d54
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -0,0 +1,77 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_request.h"
+
+#include "intel_context.h"
+#include "intel_engine_heartbeat.h"
+#include "intel_engine_pm.h"
+#include "intel_engine.h"
+#include "intel_gt.h"
+
+static void idle_pulse(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
+ i915_request_add_active_barriers(rq);
+}
+
+int intel_engine_pulse(struct intel_engine_cs *engine)
+{
+ struct i915_sched_attr attr = { .priority = I915_PRIORITY_BARRIER };
+ struct intel_context *ce = engine->kernel_context;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (!intel_engine_has_preemption(engine))
+ return -ENODEV;
+
+ if (!intel_engine_pm_get_if_awake(engine))
+ return 0;
+
+ if (mutex_lock_interruptible(&ce->timeline->mutex))
+ goto out_rpm;
+
+ intel_context_enter(ce);
+ rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
+ intel_context_exit(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_unlock;
+ }
+
+ rq->flags |= I915_REQUEST_SENTINEL;
+ idle_pulse(engine, rq);
+
+ __i915_request_commit(rq);
+ __i915_request_queue(rq, &attr);
+
+out_unlock:
+ mutex_unlock(&ce->timeline->mutex);
+out_rpm:
+ intel_engine_pm_put(engine);
+ return err;
+}
+
+int intel_engine_flush_barriers(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ if (llist_empty(&engine->barrier_tasks))
+ return 0;
+
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ idle_pulse(engine, rq);
+ i915_request_add(rq);
+
+ return 0;
+}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_engine_heartbeat.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
new file mode 100644
index ..b334e5aaf78d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -0,0 +1,15 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef INTEL_ENGINE_HEARTBEAT_H
+#define INTEL_ENGINE_HEARTBEAT_H
+
+struct intel_engine_cs;
+
+int intel_engine_pulse(struct intel_engine_cs *engine);
+int intel_engine_flush_barriers(struct intel_engine_cs *engine);
+
+#endif /* INTEL_ENGINE_HEARTBEAT_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 67eb6183648a..7d76611d9df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -111,7 +111,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
i915_request_add_active_barriers(rq);
/* Install ourselves as a preemption barrier */
- rq->sched.attr.priority = I915_PRIORITY_UNPREEMPTABLE;
[Intel-gfx] [CI] drm/i915/gt: Introduce barrier pulses along engines
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushed, as part of a context cancellation mechanism, or as
part of a heartbeat mechanism to detect and reset a stuck GPU.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 3 +-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 77 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 15 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
.../drm/i915/gt/selftest_engine_heartbeat.c | 154 ++
drivers/gpu/drm/i915/i915_priolist_types.h| 1 +
.../drm/i915/selftests/i915_live_selftests.h | 1 +
7 files changed, 251 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
create mode 100644 drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a16a2daef977..2fd4bed188e5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,8 +78,9 @@ gt-y += \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
gt/intel_engine_cs.o \
- gt/intel_engine_pool.o \
+ gt/intel_engine_heartbeat.o \
gt/intel_engine_pm.o \
+ gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_gt.o \
gt/intel_gt_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
new file mode 100644
index ..4b9ab7813d54
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -0,0 +1,77 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_request.h"
+
+#include "intel_context.h"
+#include "intel_engine_heartbeat.h"
+#include "intel_engine_pm.h"
+#include "intel_engine.h"
+#include "intel_gt.h"
+
+static void idle_pulse(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
+ i915_request_add_active_barriers(rq);
+}
+
+int intel_engine_pulse(struct intel_engine_cs *engine)
+{
+ struct i915_sched_attr attr = { .priority = I915_PRIORITY_BARRIER };
+ struct intel_context *ce = engine->kernel_context;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (!intel_engine_has_preemption(engine))
+ return -ENODEV;
+
+ if (!intel_engine_pm_get_if_awake(engine))
+ return 0;
+
+ if (mutex_lock_interruptible(&ce->timeline->mutex))
+ goto out_rpm;
+
+ intel_context_enter(ce);
+ rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
+ intel_context_exit(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_unlock;
+ }
+
+ rq->flags |= I915_REQUEST_SENTINEL;
+ idle_pulse(engine, rq);
+
+ __i915_request_commit(rq);
+ __i915_request_queue(rq, &attr);
+
+out_unlock:
+ mutex_unlock(&ce->timeline->mutex);
+out_rpm:
+ intel_engine_pm_put(engine);
+ return err;
+}
+
+int intel_engine_flush_barriers(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ if (llist_empty(&engine->barrier_tasks))
+ return 0;
+
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ idle_pulse(engine, rq);
+ i915_request_add(rq);
+
+ return 0;
+}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_engine_heartbeat.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
new file mode 100644
index ..b334e5aaf78d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -0,0 +1,15 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef INTEL_ENGINE_HEARTBEAT_H
+#define INTEL_ENGINE_HEARTBEAT_H
+
+struct intel_engine_cs;
+
+int intel_engine_pulse(struct intel_engine_cs *engine);
+int intel_engine_flush_barriers(struct intel_engine_cs *engine);
+
+#endif /* INTEL_ENGINE_HEARTBEAT_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 67eb6183648a..7d76611d9df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -111,7 +111,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
i915_request_add_active_barriers(rq);
/* Install ourselves as a preemption barrier */
- rq->sched.attr.priority = I915_PRIORITY_UNPREEMPTABLE;
[Intel-gfx] ✓ Fi.CI.BAT: success for dma_resv lockdep annotations/priming
== Series Details ==
Series: dma_resv lockdep annotations/priming
URL : https://patchwork.freedesktop.org/series/68312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14903
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/index.html
Known issues
Here are the changes found in Patchwork_14903 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2] ([fdo#107807])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-skl-6600u/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/fi-skl-6600u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [PASS][3] -> [DMESG-FAIL][4] ([fdo#111678])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111045] / [fdo#111096])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-icl-dsi}: [INCOMPLETE][7] ([fdo#107713] / [fdo#109100]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u: [DMESG-WARN][9] ([fdo#105128] / [fdo#107139]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8109u: [DMESG-FAIL][11] ([fdo#112050 ]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/fi-cfl-8109u/igt@i915_selftest@live_gem_contexts.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][13] ([fdo#102614]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#105128]: https://bugs.freedesktop.org/show_bug.cgi?id=105128
[fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
[fdo#111678]: https://bugs.freedesktop.org/show_bug.cgi?id=111678
[fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
[fdo#112050 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112050
Participating hosts (53 -> 43)
--
Missing(10): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-u3 fi-pnv-d510 fi-icl-y fi-icl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7141 -> Patchwork_14903
CI-20190529: 20190529
CI_DRM_7141: a109221528d0b9d4f24065aed372c6b45e251bd6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5235: da9abbab69be80dd00812a4607a4ea2dffcc4544 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14903: 02fe220bfcb51fa3f79fa5e36950762382d2a29e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
02fe220bfcb5 drm/ttm: remove ttm_bo_wait_unreserved
d8744a28f0bd drm/nouveau: slowpath for pushbuf ioctl
a1051ffcc702 dma_resv: prime lockdep annotations
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14903/index.html
___
Intel-gfx mailing list
Intel-gfx@
Re: [Intel-gfx] [PULL] drm-misc-next
On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen wrote: > > Hi, > > On 18/10/2019 23:11, Sean Paul wrote: > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen > > wrote: > >> > >> Hi Sean, > >> > >> On 17/10/2019 22:26, Sean Paul wrote: > >> > >>> concern for those. The omap OMAP_BO_MEM_* changes though I don't think > >>> have > >>> really reached non-TI eyes. There's no link in the commit message to a > >>> UAPI > >>> implementation and the only reference I could find is libkmsxx which can > >>> set > >>> them through the python bindings. Since this is TI-specific gunk in > >>> TI-specific > >>> headers I'm inclined to let it pass, but I would have liked to have this > >>> conversation upfront. I figured I'd call this out so you have final say. > >> > >> There was some discussion about that a few years back when I initially > >> sent the patches, but now that I look, the discussion died before really > >> even starting. > >> > >> This is what I said about userspace implementation: > >> > >>> Yes, unfortunately that is not going to happen. I don't see how this > >>> could be used in a generic system like Weston or X. It's meant for very > >>> specific use cases, where you know exactly the requirements of your > >>> application and the capabilities of the whole system, and optimize based > >>> on that. > > > > Thanks for the context, Tomi. > > > > Indeed it looks like the discussion died, but Laurent still brought up > > the u/s requirement and the patch was effectively dead until Daniel or > > Dave weighed in. I'd expect at least some outreach before pushing the > > patch directly 2+ years later. Has anything changed since then? > > There were new review rounds for the series this summer & autumn, but > no, nothing else. I haven't specifically pinged anyone about the UAPI > changes. > > This series introduces three new flags to an already existing UAPI, and, > for whatever reason, this didn't register to me as a new UAPI, even if > Laurent asked about it some years back. > > So, my mistake. > > The flags are added in a single patch, so I can easily push a revert for > that if this patch is not acceptable. The rest of the series is cleanup. > I'll wait for Dave or Daniel to weigh in on whether they want to take this, otherwise I'll revert before sending the next pull and we can have this conversation on the review. > >> I know this feature is used by customers, but I don't have access to > >> their applications. > > > > Unfortunately, and as you know, that is insufficient/irrelevant for > > introducing new UAPI. So the question is if the libkmsxx bindings > > constitute opensource userspace, it's really thin IMO. > > Ok. Well, I know and understand the general rule here. But perhaps I > haven't taken it as strictly as needed. > > I have to say I don't quite understand why this rule would be always > strictly held, though. > It's strictly held because once you start accepting the harmless/isolated features every driver has, you end up with untestable bloat sprinkled everywhere. > These flags, for example, what should we do with them? > - They provide a proven, real use-case benefit. > - They are specific to SoCs with OMAP DSS and DMM IPs. > - They are relatively simple. > - All the details, including the details about the HW, are public. > - Using them makes sense only in cases where you are tuning your system > to your application, and you must know the resource needs of all the > apps in your system. So they cannot really be used in any generic setup, > or at least I have no idea how. > > Does the history and experience say that such specific case as above > cases don't really exist, and we can always have a generic UAPI (or, in > worst case, a device specific UAPI) which can be used from X/Weston/or-such? > We don't need generic userspace to be able to make use of it, but at least some oss project should find it useful. Otherwise why are we maintaining code that no one in the open source community cares about? How do we test it when the closed source implementations have been abandoned? > Or do things like above exist, but they need to carried in vendors' kernels? That's really the problem. _Everybody_ has features they would describe as above, so where do we draw the line? Sean > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma_resv lockdep annotations/priming
== Series Details == Series: dma_resv lockdep annotations/priming URL : https://patchwork.freedesktop.org/series/68312/ State : warning == Summary == $ dim checkpatch origin/drm-tip a1051ffcc702 dma_resv: prime lockdep annotations -:77: WARNING:BAD_SIGN_OFF: Duplicate signature #77: Cc: Rob Herring -:83: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" ' might be better as 'VMware Graphics ' #83: Cc: "VMware Graphics" -:123: ERROR:TRAILING_WHITESPACE: trailing whitespace #123: FILE: drivers/dma-buf/dma-resv.c:116: +^I$ -:131: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 1 errors, 3 warnings, 0 checks, 36 lines checked d8744a28f0bd drm/nouveau: slowpath for pushbuf ioctl -:155: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 122 lines checked 02fe220bfcb5 drm/ttm: remove ttm_bo_wait_unreserved -:25: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" ' might be better as 'VMware Graphics ' #25: Cc: "VMware Graphics" -:166: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 81 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Introduce barrier pulses along engines
== Series Details ==
Series: drm/i915/gt: Introduce barrier pulses along engines
URL : https://patchwork.freedesktop.org/series/68309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7141 -> Patchwork_14902
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14902 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14902, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14902:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7141/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* {igt@i915_selftest@live_gt_heartbeat} (NEW):
- fi-kbl-x1275: NOTRUN -> [DMESG-WARN][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-kbl-x1275/igt@i915_selftest@live_gt_heartbeat.html
- {fi-icl-dsi}: NOTRUN -> [DMESG-WARN][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-icl-dsi/igt@i915_selftest@live_gt_heartbeat.html
- fi-cfl-8700k: NOTRUN -> [DMESG-WARN][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-cfl-8700k/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-6600u: NOTRUN -> [DMESG-WARN][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-skl-6600u/igt@i915_selftest@live_gt_heartbeat.html
- fi-kbl-8809g: NOTRUN -> [DMESG-FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-kbl-8809g/igt@i915_selftest@live_gt_heartbeat.html
- {fi-icl-u4}:NOTRUN -> [DMESG-WARN][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-icl-u4/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-lmem:NOTRUN -> [DMESG-FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-skl-lmem/igt@i915_selftest@live_gt_heartbeat.html
- fi-apl-guc: NOTRUN -> [DMESG-WARN][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-apl-guc/igt@i915_selftest@live_gt_heartbeat.html
- fi-kbl-r: NOTRUN -> [DMESG-WARN][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-kbl-r/igt@i915_selftest@live_gt_heartbeat.html
- fi-bdw-5557u: NOTRUN -> [DMESG-WARN][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-bdw-5557u/igt@i915_selftest@live_gt_heartbeat.html
- fi-bwr-2160:NOTRUN -> [DMESG-WARN][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-bwr-2160/igt@i915_selftest@live_gt_heartbeat.html
- fi-byt-n2820: NOTRUN -> [DMESG-WARN][14]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-byt-n2820/igt@i915_selftest@live_gt_heartbeat.html
- fi-skl-6770hq: NOTRUN -> [DMESG-WARN][15]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-skl-6770hq/igt@i915_selftest@live_gt_heartbeat.html
- fi-kbl-guc: NOTRUN -> [DMESG-WARN][16]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-kbl-guc/igt@i915_selftest@live_gt_heartbeat.html
- fi-snb-2600:NOTRUN -> [DMESG-WARN][17]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-snb-2600/igt@i915_selftest@live_gt_heartbeat.html
- fi-elk-e7500: NOTRUN -> [DMESG-WARN][18]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-elk-e7500/igt@i915_selftest@live_gt_heartbeat.html
- {fi-tgl-u2}:NOTRUN -> [DMESG-WARN][19]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-tgl-u2/igt@i915_selftest@live_gt_heartbeat.html
- fi-ilk-650: NOTRUN -> [DMESG-WARN][20]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-ilk-650/igt@i915_selftest@live_gt_heartbeat.html
- fi-pnv-d510:NOTRUN -> [DMESG-WARN][21]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-pnv-d510/igt@i915_selftest@live_gt_heartbeat.html
- fi-bdw-gvtdvm: NOTRUN -> [DMESG-WARN][22]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-bdw-gvtdvm/igt@i915_selftest@live_gt_heartbeat.html
- fi-cfl-8109u: NOTRUN -> [DMESG-WARN][23]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14902/fi-cfl-8109u/igt@i915_selftest@live_gt_heartbeat.html
- fi-hsw-peppy: NOTRUN -> [DMESG-WARN][24]
[24]:
https://intel-gfx-ci.01.org/tree/drm
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Introduce barrier pulses along engines
== Series Details == Series: drm/i915/gt: Introduce barrier pulses along engines URL : https://patchwork.freedesktop.org/series/68309/ State : warning == Summary == $ dim checkpatch origin/drm-tip df6dba3e1726 drm/i915/gt: Introduce barrier pulses along engines -:32: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #32: new file mode 100644 -:37: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #37: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:1: +/* -:38: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #38: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c:2: + * SPDX-License-Identifier: MIT -:120: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #120: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:1: +/* -:121: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #121: FILE: drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h:2: + * SPDX-License-Identifier: MIT -:154: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #154: FILE: drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c:1: +/* -:155: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #155: FILE: drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c:2: + * SPDX-License-Identifier: MIT total: 0 errors, 7 warnings, 0 checks, 234 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.
Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.
Aside from "it compiles" entirely untested unfortunately.
Signed-off-by: Daniel Vetter
Cc: Ilia Mirkin
Cc: Maarten Lankhorst
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++-
1 file changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 1324c19f4e5c..05ec8edd6a8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct
drm_file *file_priv,
static int
validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
- struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
- uint64_t user_pbbo_ptr)
+ struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
{
struct nouveau_drm *drm = chan->drm;
- struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
- (void __force __user *)(uintptr_t)user_pbbo_ptr;
struct nouveau_bo *nvbo;
int ret, relocs = 0;
@@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct
nouveau_cli *cli,
b->presumed.offset = nvbo->bo.offset;
b->presumed.valid = 0;
relocs++;
-
- if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
-&b->presumed, sizeof(b->presumed)))
- return -EFAULT;
}
}
@@ -547,8 +540,8 @@ static int
nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
struct drm_file *file_priv,
struct drm_nouveau_gem_pushbuf_bo *pbbo,
-uint64_t user_buffers, int nr_buffers,
-struct validate_op *op, int *apply_relocs)
+int nr_buffers,
+struct validate_op *op, bool *apply_relocs)
{
struct nouveau_cli *cli = nouveau_cli(file_priv);
int ret;
@@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
return ret;
}
- ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
+ ret = validate_list(chan, cli, &op->list, pbbo);
if (unlikely(ret < 0)) {
if (ret != -ERESTARTSYS)
NV_PRINTK(err, cli, "validating bo list\n");
@@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
static int
nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf *req,
+ struct drm_nouveau_gem_pushbuf_reloc *reloc,
struct drm_nouveau_gem_pushbuf_bo *bo)
{
- struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
int ret = 0;
unsigned i;
- reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
- if (IS_ERR(reloc))
- return PTR_ERR(reloc);
-
for (i = 0; i < req->nr_relocs; i++) {
struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
struct drm_nouveau_gem_pushbuf_bo *b;
@@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_nouveau_gem_pushbuf *req = data;
struct drm_nouveau_gem_pushbuf_push *push;
+ struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
struct drm_nouveau_gem_pushbuf_bo *bo;
struct nouveau_channel *chan = NULL;
struct validate_op op;
struct nouveau_fence *fence = NULL;
- int i, j, ret = 0, do_reloc = 0;
+ int i, j, ret = 0;
+ bool do_reloc = false;
if (unlikely(!abi16))
return -ENOMEM;
@@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
}
/* Validate buffer list */
- ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
+revalidate:
+ ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
req->nr_buffers, &op, &do_reloc);
if (ret) {
if (ret != -ERESTARTSYS)
@@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
/* Apply any relocations that are required */
if (do_reloc) {
- ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
+ if (!reloc) {
+ validate_fini(&op
[Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_interruptible to be good citizens (Thomas)
Reviewed-by: Christian König
Reviewed-by: Thomas Hellström
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
Cc: Gerd Hoffmann
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 36 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_bo_vm.c | 18 +---
include/drm/ttm/ttm_bo_api.h | 4
4 files changed, 5 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f00b2e79882f..7a9b01aeaa3f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -162,7 +162,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
dma_resv_fini(&bo->base._resv);
- mutex_destroy(&bo->wu_mutex);
bo->destroy(bo);
ttm_mem_global_free(bdev->glob->mem_glob, acc_size);
}
@@ -1320,7 +1319,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(&bo->ddestroy);
INIT_LIST_HEAD(&bo->swap);
INIT_LIST_HEAD(&bo->io_reserve_lru);
- mutex_init(&bo->wu_mutex);
bo->bdev = bdev;
bo->type = type;
bo->num_pages = num_pages;
@@ -1955,37 +1953,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
;
}
EXPORT_SYMBOL(ttm_bo_swapout_all);
-
-/**
- * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
- * unreserved
- *
- * @bo: Pointer to buffer
- */
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
-{
- int ret;
-
- /*
-* In the absense of a wait_unlocked API,
-* Use the bo::wu_mutex to avoid triggering livelocks due to
-* concurrent use of this function. Note that this use of
-* bo::wu_mutex can go away if we change locking order to
-* mmap_sem -> bo::reserve.
-*/
- ret = mutex_lock_interruptible(&bo->wu_mutex);
- if (unlikely(ret != 0))
- return -ERESTARTSYS;
- if (!dma_resv_is_locked(bo->base.resv))
- goto out_unlock;
- ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
- if (ret == -EINTR)
- ret = -ERESTARTSYS;
- if (unlikely(ret != 0))
- goto out_unlock;
- dma_resv_unlock(bo->base.resv);
-
-out_unlock:
- mutex_unlock(&bo->wu_mutex);
- return ret;
-}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fe81c565e7ef..82ea26a49959 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -508,7 +508,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
INIT_LIST_HEAD(&fbo->base.lru);
INIT_LIST_HEAD(&fbo->base.swap);
INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
- mutex_init(&fbo->base.wu_mutex);
fbo->base.moving = NULL;
drm_vma_node_reset(&fbo->base.base.vma_node);
atomic_set(&fbo->base.cpu_writers, 0);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 79f01c5ff65e..28d73ef17073 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -125,30 +125,22 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
&bdev->man[bo->mem.mem_type];
struct vm_area_struct cvma;
- /*
-* Work around locking order reversal in fault / nopfn
-* between mmap_sem and bo_reserve: Perform a trylock operation
-* for reserve, and if it fails, retry the fault after waiting
-* for the buffer to become unreserved.
-*/
if (unlikely(!dma_resv_trylock(bo->base.resv))) {
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
ttm_bo_get(bo);
up_read(&vmf->vma->vm_mm->mmap_sem);
- (void) ttm_bo_wait_unreserved(bo);
+ if (!dma_resv_lock_interruptible(bo->base.resv,
+NULL))
+ dma_resv_unlock(bo->base.resv);
ttm_bo_put(bo);
}
return VM_FAULT_RETRY;
}
- /*
-* If we'd want to change locking order to
-* mmap_sem -> bo::reserve, we'd use a blocking reserve here
-* instead of retrying the fault...
-
[Intel-gfx] [PATCH 0/3] dma_resv lockdep annotations/priming
Hi all, Essentially just a resend of the latest revision, since the series is stuck on the nouveau patch. Ilia tried it on an nv5 and it didn't explode, but he noticed some instability. No call yet on whether that was just the kernel upgrade of a few versions, or my patch. So yeah I need to get some review/testing on that patch to land the other two, and I'd really like to land these to make sure all the locking rework in i915 doesn't miss one of these details. Thanks, Daniel Daniel Vetter (3): dma_resv: prime lockdep annotations drm/nouveau: slowpath for pushbuf ioctl drm/ttm: remove ttm_bo_wait_unreserved drivers/dma-buf/dma-resv.c| 24 +++ drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++- drivers/gpu/drm/ttm/ttm_bo.c | 36 - drivers/gpu/drm/ttm/ttm_bo_util.c | 1 - drivers/gpu/drm/ttm/ttm_bo_vm.c | 18 +++-- include/drm/ttm/ttm_bo_api.h | 4 -- 6 files changed, 67 insertions(+), 73 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring
Cc: Alex Deucher
Cc: Christian König
Cc: Chris Wilson
Cc: Thomas Zimmermann
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Eric Anholt
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Ben Skeggs
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Reviewed-by: Christian König
Reviewed-by: Chris Wilson
Tested-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/dma-buf/dma-resv.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 709002515550..a05ff542be22 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
#include
#include
+#include
/**
* DOC: Reservation Object Overview
@@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
kfree_rcu(list, rcu);
}
+#if IS_ENABLED(CONFIG_LOCKDEP)
+static void __init dma_resv_lockdep(void)
+{
+ struct mm_struct *mm = mm_alloc();
+ struct dma_resv obj;
+
+ if (!mm)
+ return;
+
+ dma_resv_init(&obj);
+
+ down_read(&mm->mmap_sem);
+ ww_mutex_lock(&obj.lock, NULL);
+ fs_reclaim_acquire(GFP_KERNEL);
+ fs_reclaim_release(GFP_KERNEL);
+ ww_mutex_unlock(&obj.lock);
+ up_read(&mm->mmap_sem);
+
+ mmput(mm);
+}
+subsys_initcall(dma_resv_lockdep);
+#endif
+
/**
* dma_resv_init - initialize a reservation object
* @obj: the reservation object
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Program LUT before intel_color_commit() if LUT was not previously set
On Sun, Oct 20, 2019 at 08:19:33PM +0200, Hans de Goede wrote:
> Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
> vblank waits"), I am seeing an ugly colored flash of the first few display
> lines on 2 Cherry Trail devices when the gamma table gets set for the first
> time. A blue flash on a GPD win and a yellow flash on an Asus T100HA.
>
> The problem is that since this change, the LUT is programmed after the
> write *and latching* of the double-buffered register which causes the LUT
> to be used starting at the next frame. This means that the old LUT is still
> used for the first couple of lines of the display. If no LUT was in use
> before then the LUT registers may contain bogus values. This leads to
> messed up colors until the new LUT values are written. At least on CHT DSI
> panels this causes messed up colors on the first few lines.
>
> This commit fixes this by adding a load_lut_before_commit boolean,
> modifying intel_begin_crtc_commit to load the luts earlier if this is set,
> and setting this from intel_color_check when a LUT table was not in use
> before (and thus may contain bogus values), or when the table size
> changes.
The real solution is vblank workers, which I have somewhat implemented
here:
git://github.com/vsyrjala/linux.git vblank_worker_8_kthread
Though even with the qos tricks there we still probably can't quite make
it in time. Essentially we have a bit less than one scanline after start
of vblank to do the work before pixels start to flow through the pipe.
We might be extend that to almost four scanlines but that partocular
thing is documeted as debug feature so not sure we should really use it.
Also I don't think four scanlines is always enough either. So it's still
very much possible that we get the first 100 or so pixels with the old LUT.
>
> Fixes: 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after vblank
> waits")
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_color.c| 26 +++
> drivers/gpu/drm/i915/display/intel_display.c | 7 +
> .../drm/i915/display/intel_display_types.h| 3 +++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 71a0201437a9..0da6dcc5bebd 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1052,6 +1052,32 @@ intel_color_add_affected_planes(struct
> intel_crtc_state *new_crtc_state)
> new_crtc_state->update_planes |= BIT(plane->id);
> }
>
> + /*
> + * Normally we load the LUTs after vblank / after the double-buffer
> + * registers written by commit have been latched, this avoids a
> + * gamma change mid-way the screen. This does mean that the first
> + * few lines of the display will (sometimes) still use the old
> + * table. This is fine when changing an existing LUT, but if this
> + * is the first time the LUT gets loaded, then the hw may contain
> + * random values, causing the first lines to have funky colors.
> + *
> + * So if were enabling a LUT for the first time or changing the table
> + * size, then we must do this before the commit to avoid corrupting
> + * the first lines of the display.
> + */
> + if (!old_crtc_state->base.gamma_lut && new_crtc_state->base.gamma_lut)
> + new_crtc_state->load_lut_before_commit = true;
> + else if (!old_crtc_state->base.degamma_lut &&
> + new_crtc_state->base.degamma_lut)
> + new_crtc_state->load_lut_before_commit = true;
> + else if (old_crtc_state->base.gamma_lut &&
> + new_crtc_state->base.gamma_lut &&
> + lut_is_legacy(old_crtc_state->base.gamma_lut) !=
> + lut_is_legacy(new_crtc_state->base.gamma_lut))
> + new_crtc_state->load_lut_before_commit = true;
> + else
> + new_crtc_state->load_lut_before_commit = false;
The 'no gamma -> yes gamma' thing I might be willing to accept. The rest
not so much. I was already pondering about such optimizations for the
plane gamma/csc stuff in my vblank branch.
But for the fastboot case I think what we could do is just sanitize
the LUT(s) after readout if gamma wasn't enabled by the BIOS.
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index aa54bb22796d..21442b0dd134 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14033,6 +14033,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> if (new_crtc_state->base.active &&
> !needs_modeset(new_crtc_state) &&
> + !new_crtc_state->load_lut_before_
[Intel-gfx] [CI] drm/i915/gt: Introduce barrier pulses along engines
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to ensure idle barriers are
immediately flushed, as part of a context cancellation mechanism, or as
part of a heartbeat mechanism to detect and reset a stuck GPU.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 3 +-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 77
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 15 +++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
.../drm/i915/gt/selftest_engine_heartbeat.c | 110 ++
drivers/gpu/drm/i915/i915_priolist_types.h| 1 +
.../drm/i915/selftests/i915_live_selftests.h | 1 +
7 files changed, 207 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
create mode 100644 drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a16a2daef977..2fd4bed188e5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,8 +78,9 @@ gt-y += \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
gt/intel_engine_cs.o \
- gt/intel_engine_pool.o \
+ gt/intel_engine_heartbeat.o \
gt/intel_engine_pm.o \
+ gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_gt.o \
gt/intel_gt_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
new file mode 100644
index ..4b9ab7813d54
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -0,0 +1,77 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_request.h"
+
+#include "intel_context.h"
+#include "intel_engine_heartbeat.h"
+#include "intel_engine_pm.h"
+#include "intel_engine.h"
+#include "intel_gt.h"
+
+static void idle_pulse(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ engine->wakeref_serial = READ_ONCE(engine->serial) + 1;
+ i915_request_add_active_barriers(rq);
+}
+
+int intel_engine_pulse(struct intel_engine_cs *engine)
+{
+ struct i915_sched_attr attr = { .priority = I915_PRIORITY_BARRIER };
+ struct intel_context *ce = engine->kernel_context;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (!intel_engine_has_preemption(engine))
+ return -ENODEV;
+
+ if (!intel_engine_pm_get_if_awake(engine))
+ return 0;
+
+ if (mutex_lock_interruptible(&ce->timeline->mutex))
+ goto out_rpm;
+
+ intel_context_enter(ce);
+ rq = __i915_request_create(ce, GFP_NOWAIT | __GFP_NOWARN);
+ intel_context_exit(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_unlock;
+ }
+
+ rq->flags |= I915_REQUEST_SENTINEL;
+ idle_pulse(engine, rq);
+
+ __i915_request_commit(rq);
+ __i915_request_queue(rq, &attr);
+
+out_unlock:
+ mutex_unlock(&ce->timeline->mutex);
+out_rpm:
+ intel_engine_pm_put(engine);
+ return err;
+}
+
+int intel_engine_flush_barriers(struct intel_engine_cs *engine)
+{
+ struct i915_request *rq;
+
+ if (llist_empty(&engine->barrier_tasks))
+ return 0;
+
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ idle_pulse(engine, rq);
+ i915_request_add(rq);
+
+ return 0;
+}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_engine_heartbeat.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
new file mode 100644
index ..b334e5aaf78d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -0,0 +1,15 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef INTEL_ENGINE_HEARTBEAT_H
+#define INTEL_ENGINE_HEARTBEAT_H
+
+struct intel_engine_cs;
+
+int intel_engine_pulse(struct intel_engine_cs *engine);
+int intel_engine_flush_barriers(struct intel_engine_cs *engine);
+
+#endif /* INTEL_ENGINE_HEARTBEAT_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 67eb6183648a..7d76611d9df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -111,7 +111,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
i915_request_add_active_barriers(rq);
/* Install ourselves as a preemption barrier */
- rq->sched.attr.priority = I915_PRIORITY_UNPREEMPTA
Re: [Intel-gfx] [PATCH 02/13] drm/i915/selftests: Add coverage of mocs registers
On Sat, Oct 19, 2019 at 12:20:18AM +0100, Chris Wilson wrote:
> Quoting Kumar Valsan, Prathap (2019-10-19 00:24:13)
> > On Fri, Oct 18, 2019 at 11:14:39PM +0100, Chris Wilson wrote:
> > > +static int check_l3cc_table(struct intel_engine_cs *engine,
> > > + const struct drm_i915_mocs_table *table,
> > > + const u32 *vaddr, int *offset)
> > > +{
> > > + u16 unused_value = table->table[I915_MOCS_PTE].l3cc_value;
> > > + unsigned int i;
> > > + u32 expect;
> > > +
> > > + if (1) { /* XXX skip MCR read back */
> > > + *offset += table->n_entries / 2;
> > > + return 0;
> > > + }
> >
> > I think l3cc reset test is valid only from Gen12+. Before that since its
> > loaded from the golden context, table stays the same between reset.
>
> That doesn't affect the validity of actually checking that the values
> don't change. The problem as I understand it is that they lie inside the
> magic 0xb00 region that is broadcast across the slices and not
> accessible from CS, see engine_wa_list_verify() and mcr_range. Sadly
> using the GPU is the cleanest way to emulate userspace interaction with
> the *GPU*.
> -Chris
Hmmm.. But from igt test we are submiting a secure BB to read the L3
MOCS. Not quite clear how that works then.
Thanks,
Prathap
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: cpu-map based dumb buffers
Quoting Abdiel Janulgue (2019-10-21 11:48:10)
> +int
> +i915_gem_mmap_dumb(struct drm_file *file,
> + struct drm_device *dev,
> + u32 handle,
> + u64 *offset)
> +{
> + return __assign_gem_object_mmap_data(file, handle, I915_MMAP_TYPE_WC,
It still needs to do boot_cpu_has(PAT), but it looks like
kms_frontbuffer is not doing enough dirtyfb for its dumb buffer usage.
Bad IGT (it's either a bug in the test for not adhering to the uabi
for dumb buffers, or we have some tracking bug intel_frontbuffer).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
