[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Daniel, Here's this week drm-misc-fixes PR Maxime drm-misc-fixes-2022-06-23: Multiple fixes in sun4i for suspend, DDC, DMA setup; A rework of vc4 to properly split the driver between hardware capabilities that wasn't done properly causing multiple crashes; and a panel quirk for Aya Neo Next The following changes since commit 0f9cd1ea10d307cad221d6693b648a8956e812b0: drm/ttm: fix bulk move handling v2 (2022-06-14 11:15:19 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-06-23 for you to fetch changes up to 85016f66af8506cb601fd4f4fde23ed327a266be: drm/sun4i: Return if frontend is not present (2022-06-22 16:42:25 +0200) Multiple fixes in sun4i for suspend, DDC, DMA setup; A rework of vc4 to properly split the driver between hardware capabilities that wasn't done properly causing multiple crashes; and a panel quirk for Aya Neo Next Dan Carpenter (1): drm/vc4: fix error code in vc4_check_tex_size() Jernej Skrabec (1): drm/sun4i: Add DMA mask and segment size Maxime Ripard (14): drm/vc4: plane: Prevent async update if we don't have a dlist drm/vc4: Consolidate Hardware Revision Check drm/vc4: bo: Rename vc4_dumb_create drm/vc4: bo: Split out Dumb buffers fixup drm/vc4: drv: Register a different driver on BCM2711 drm/vc4: kms: Register a different drm_mode_config_funcs on BCM2711 drm/vc4: plane: Register a different drm_plane_helper_funcs on BCM2711 drm/vc4: drv: Skip BO Backend Initialization on BCM2711 drm/vc4: crtc: Use an union to store the page flip callback drm/vc4: crtc: Move the BO handling out of common page-flip callback drm/vc4: crtc: Move the BO Handling out of Common Page-Flip Handler drm/vc4: crtc: Don't call into BO Handling on Async Page-Flips on BCM2711 drm/vc4: crtc: Fix out of order frames during asynchronous page flips drm/vc4: Warn if some v3d code is run on BCM2711 Maya Matuszczyk (1): drm: panel-orientation-quirks: Add quirk for Aya Neo Next Samuel Holland (2): drm/sun4i: dw-hdmi: Fix ddc-en GPIO consumer conflict drm/sun4i: Fix crash during suspend after component bind failure Saud Farooqui (2): drm/vc4: hdmi: Fixed possible integer overflow drm/sun4i: Return if frontend is not present drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 + drivers/gpu/drm/sun4i/sun4i_drv.c | 12 +- drivers/gpu/drm/sun4i/sun4i_layer.c| 2 +- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 +-- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 - drivers/gpu/drm/vc4/vc4_bo.c | 62 +++- drivers/gpu/drm/vc4/vc4_crtc.c | 200 ++--- drivers/gpu/drm/vc4/vc4_drv.c | 97 ++-- drivers/gpu/drm/vc4/vc4_drv.h | 19 ++- drivers/gpu/drm/vc4/vc4_gem.c | 40 + drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- drivers/gpu/drm/vc4/vc4_hvs.c | 18 +-- drivers/gpu/drm/vc4/vc4_irq.c | 16 ++ drivers/gpu/drm/vc4/vc4_kms.c | 24 ++- drivers/gpu/drm/vc4/vc4_perfmon.c | 47 +- drivers/gpu/drm/vc4/vc4_plane.c| 29 +++- drivers/gpu/drm/vc4/vc4_render_cl.c| 4 + drivers/gpu/drm/vc4/vc4_v3d.c | 15 ++ drivers/gpu/drm/vc4/vc4_validate.c | 16 ++ drivers/gpu/drm/vc4/vc4_validate_shaders.c | 4 + 20 files changed, 505 insertions(+), 164 deletions(-) signature.asc Description: PGP signature
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't update engine busyness stats too frequently
== Series Details == Series: drm/i915/guc: Don't update engine busyness stats too frequently URL : https://patchwork.freedesktop.org/series/105525/ State : success == Summary == CI Bug Log - changes from CI_DRM_11795 -> Patchwork_105525v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/index.html Participating hosts (39 -> 40) -- Additional (1): fi-icl-u2 Known issues Here are the changes found in Patchwork_105525v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][1] ([i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@random-engines: - fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html * igt@i915_selftest@live: - fi-cfl-8109u: NOTRUN -> [INCOMPLETE][3] ([i915#6114]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-cfl-8109u/igt@i915_selft...@live.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s3-without-i915: - fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#5903]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-snb-2600:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#4103]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1: - fi-tgl-u2: [PASS][10] -> [DMESG-WARN][11] ([i915#402]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html * igt@kms_force_connector_basic@force-connector-state: - fi-icl-u2: NOTRUN -> [WARN][12] ([i915#6008]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109285]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [PASS][14] -> [DMESG-FAIL][15] ([i915#62]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html * igt@kms_setmode@basic-clone-single-crtc: - fi-icl-u2: NOTRUN -> [SKIP][16] ([i915#3555]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-flip: - fi-cfl-8109u: [PASS][17] -> [DMESG-WARN][18] ([i915#62]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-cfl-8109u/igt@prime_v...@basic-fence-flip.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-cfl-8109u/igt@prime_v...@basic-fence-flip.html * igt@prime_vgem@basic-userptr: - fi-icl-u2: NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3301]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-icl-u2/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][20] ([fdo#109271] / [i915#4312] / [i915#5594] / [i915#6246]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105525v1/fi-hsw-4770/igt@run...@aborted.html - fi-cfl-8109u: NOTRUN -> [FAIL][21] ([i915#43
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Don't update engine busyness stats too frequently
== Series Details == Series: drm/i915/guc: Don't update engine busyness stats too frequently URL : https://patchwork.freedesktop.org/series/105525/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc/slpc: Use non-blocking H2G for waitboost (rev3)
== Series Details ==
Series: drm/i915/guc/slpc: Use non-blocking H2G for waitboost (rev3)
URL : https://patchwork.freedesktop.org/series/103598/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11795 -> Patchwork_103598v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/index.html
Participating hosts (39 -> 38)
--
Missing(1): fi-rkl-11600
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103598v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
*
{igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size}:
- fi-bsw-kefka: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Known issues
Here are the changes found in Patchwork_103598v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][3] -> [INCOMPLETE][4] ([i915#2940])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#3428] /
[i915#4312])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/fi-bsw-nick/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][7] ([i915#3921]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [DMESG-FAIL][9] ([i915#4494] / [i915#4957]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@modeset:
- {bat-adlp-6}: [DMESG-WARN][11] ([i915#3576]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/bat-adlp-6/igt@kms_busy@ba...@modeset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/bat-adlp-6/igt@kms_busy@ba...@modeset.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- fi-tgl-u2: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-tgl-u2/igt@kms_flip@basic-plain-f...@a-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103598v3/fi-tgl-u2/igt@kms_flip@basic-plain-f...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
[i915#5885]: https://gitlab.freedesktop.org/drm/intel/issues/5885
Build changes
-
* Linux: CI_DRM_11795 -> Patchwork_103598v3
CI-20190529: 20190529
CI_DRM_11795: 5a84eaf663caab407f4baf1cd854f1ebd5980d61 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6541: 02153f109bd422d93cfce7f5aa9d7b0e22
[Intel-gfx] [PATCH v4 1/1] drm/i915/guc: Don't update engine busyness stats too frequently
Using two different types of workoads, it was observed that
guc_update_engine_gt_clks was being called too frequently and/or
causing a CPU-to-lmem bandwidth hit over PCIE. Details on
the workloads and numbers are in the notes below.
Background: At the moment, guc_update_engine_gt_clks can be invoked
via one of 3 ways. #1 and #2 are infrequent under normal operating
conditions:
1.When a predefined "ping_delay" timer expires so that GuC-
busyness can sample the GTPM clock counter to ensure it
doesn't miss a wrap-around of the 32-bits of the HW counter.
(The ping_delay is calculated based on 1/8th the time taken
for the counter go from 0x0 to 0x based on the
GT frequency. This comes to about once every 28 seconds at a
GT frequency of 19.2Mhz).
2.In preparation for a gt reset.
3.In response to __gt_park events (as the gt power management
puts the gt into a lower power state when there is no work
being done).
Root-cause: For both the workloads described farther below, it was
observed that when user space calls IOCTLs that unparks the
gt momentarily and repeats such calls many times in quick succession,
it triggers calling guc_update_engine_gt_clks as many times. However,
the primary purpose of guc_update_engine_gt_clks is to ensure we don't
miss the wraparound while the counter is ticking. Thus, the solution
is to ensure we skip that check if gt_park is calling this function
earlier than necessary.
Solution: Snapshot jiffies when we do actually update the busyness
stats. Then get the new jiffies every time intel_guc_busyness_park
is called and bail if we are being called too soon. Use half of the
ping_delay as a safe threshold.
NOTE1: Workload1: IGTs' gem_create was modified to create a file handle,
allocate memory with sizes that range from a min of 4K to the max supported
(in power of two step-sizes). Its maps, modifies and reads back the
memory. Allocations and modification is repeated until total memory
allocation reaches the max. Then the file handle is closed. With this
workload, guc_update_engine_gt_clks was called over 188 thousand times
in the span of 15 seconds while this test ran three times. With this patch,
the number of calls reduced to 14.
NOTE2: Workload2: 30 transcode sessions are created in quick succession.
While these sessions are created, pcm-iio tool was used to measure I/O
read operation bandwidth consumption sampled at 100 milisecond intervals
over the course of 20 seconds. The total bandwidth consumed over 20 seconds
without this patch was measured at average at 311KBps per sample. With this
patch, the number went down to about 175Kbps which is about a 43% savings.
Signed-off-by: Alan Previn
Reviewed-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 966e69a8b1c1..d0d99f178f2d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -230,6 +230,14 @@ struct intel_guc {
* @shift: Right shift value for the gpm timestamp
*/
u32 shift;
+
+ /**
+* @last_stat_jiffies: jiffies at last actual stats collection
time
+* We use this timestamp to ensure we don't oversample the
+* stats because runtime power management events can trigger
+* stats collection at much higher rates than required.
+*/
+ unsigned long last_stat_jiffies;
} timestamp;
#ifdef CONFIG_DRM_I915_SELFTEST
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e62ea35513ea..c9f167b80910 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1314,6 +1314,8 @@ static void __update_guc_busyness_stats(struct intel_guc
*guc)
unsigned long flags;
ktime_t unused;
+ guc->timestamp.last_stat_jiffies = jiffies;
+
spin_lock_irqsave(&guc->timestamp.lock, flags);
guc_update_pm_timestamp(guc, &unused);
@@ -1386,6 +1388,17 @@ void intel_guc_busyness_park(struct intel_gt *gt)
return;
cancel_delayed_work(&guc->timestamp.work);
+
+ /*
+* Before parking, we should sample engine busyness stats if we need to.
+* We can skip it if we are less than half a ping from the last time we
+* sampled the busyness stats.
+*/
+ if (guc->timestamp.last_stat_jiffies &&
+ !time_after(jiffies, guc->timestamp.last_stat_jiffies +
+ (guc->timestamp.ping_delay / 2)))
+ return;
+
__update_guc_busyness_stats(guc);
}
--
2.25.1
[Intel-gfx] [Intel-gfx v4 0/1] drm/i915/guc: Don't update engine busyness stats too frequently
This change ensures we don't resample GuC busyness stat counters too soon after the last sample. Prior receipts of rvb's: Umesh Nerlige Ramappa Changes from prior revs: v3: - Added Umesh's Rvb into patch v2: - Align the name of last_stat_jiffies (Tvrtko) - Use 32-bit jiffes (Tvrtko) - use time_after() macro (Tvrtko) - change from ">> 1" to "/ 2" for ping delay halving (Tvrtko) v1: - Move the location of the new logic to higher up the callstack in intel_guc_busyness_park (Umesh). - Fix typo threshold of jiffies-since-last from double to half of ping_delay (Umesh) Alan Previn (1): drm/i915/guc: Don't update engine busyness stats too frequently drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 + 2 files changed, 21 insertions(+) base-commit: ac17a5249380aaabe5d1eaebd9b3a2eedc08ccdc -- 2.25.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/doc/rfc: i915 VM_BIND feature design + uapi
== Series Details == Series: drm/doc/rfc: i915 VM_BIND feature design + uapi URL : https://patchwork.freedesktop.org/series/105513/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_driver.o In file included from ./drivers/gpu/drm/i915/i915_pmu.h:13, from ./drivers/gpu/drm/i915/gt/intel_engine_types.h:21, from ./drivers/gpu/drm/i915/gt/intel_context_types.h:18, from ./drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20, from ./drivers/gpu/drm/i915/i915_request.h:34, from ./drivers/gpu/drm/i915/i915_active.h:13, from ./drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h:12, from ./drivers/gpu/drm/i915/i915_vma.h:33, from drivers/gpu/drm/i915/display/intel_display_types.h:49, from drivers/gpu/drm/i915/i915_driver.c:52: ./include/uapi/drm/i915_drm.h:1934:2: error: "/*" within comment [-Werror=comment] /** @param: Parameter to set or query */ cc1: all warnings being treated as errors scripts/Makefile.build:249: recipe for target 'drivers/gpu/drm/i915/i915_driver.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_driver.o] Error 1 scripts/Makefile.build:466: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:466: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:466: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1843: recipe for target 'drivers' failed make: *** [drivers] Error 2
[Intel-gfx] [Intel-gfx v3 0/1] drm/i915/guc: Don't update engine busyness stats too frequently
This change ensures we don't resample GuC busyness stat counters too soon after the last sample. Changes from prior revs: v2: - Align the name of last_stat_jiffies (Tvrtko) - Use 32-bit jiffes (Tvrtko) - use time_after() macro (Tvrtko) - change from ">> 1" to "/ 2" for ping delay halving (Tvrtko) v1: - Move the location of the new logic to higher up the callstack in intel_guc_busyness_park (Umesh). - Fix typo threshold of jiffies-since-last from double to half of ping_delay (Umesh) Alan Previn (1): drm/i915/guc: Don't update engine busyness stats too frequently drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 + 2 files changed, 21 insertions(+) base-commit: ac17a5249380aaabe5d1eaebd9b3a2eedc08ccdc -- 2.25.1
[Intel-gfx] [PATCH v3 1/1] drm/i915/guc: Don't update engine busyness stats too frequently
Using two different types of workoads, it was observed that
guc_update_engine_gt_clks was being called too frequently and/or
causing a CPU-to-lmem bandwidth hit over PCIE. Details on
the workloads and numbers are in the notes below.
Background: At the moment, guc_update_engine_gt_clks can be invoked
via one of 3 ways. #1 and #2 are infrequent under normal operating
conditions:
1.When a predefined "ping_delay" timer expires so that GuC-
busyness can sample the GTPM clock counter to ensure it
doesn't miss a wrap-around of the 32-bits of the HW counter.
(The ping_delay is calculated based on 1/8th the time taken
for the counter go from 0x0 to 0x based on the
GT frequency. This comes to about once every 28 seconds at a
GT frequency of 19.2Mhz).
2.In preparation for a gt reset.
3.In response to __gt_park events (as the gt power management
puts the gt into a lower power state when there is no work
being done).
Root-cause: For both the workloads described farther below, it was
observed that when user space calls IOCTLs that unparks the
gt momentarily and repeats such calls many times in quick succession,
it triggers calling guc_update_engine_gt_clks as many times. However,
the primary purpose of guc_update_engine_gt_clks is to ensure we don't
miss the wraparound while the counter is ticking. Thus, the solution
is to ensure we skip that check if gt_park is calling this function
earlier than necessary.
Solution: Snapshot jiffies when we do actually update the busyness
stats. Then get the new jiffies every time intel_guc_busyness_park
is called and bail if we are being called too soon. Use half of the
ping_delay as a safe threshold.
NOTE1: Workload1: IGTs' gem_create was modified to create a file handle,
allocate memory with sizes that range from a min of 4K to the max supported
(in power of two step-sizes). Its maps, modifies and reads back the
memory. Allocations and modification is repeated until total memory
allocation reaches the max. Then the file handle is closed. With this
workload, guc_update_engine_gt_clks was called over 188 thousand times
in the span of 15 seconds while this test ran three times. With this patch,
the number of calls reduced to 14.
NOTE2: Workload2: 30 transcode sessions are created in quick succession.
While these sessions are created, pcm-iio tool was used to measure I/O
read operation bandwidth consumption sampled at 100 milisecond intervals
over the course of 20 seconds. The total bandwidth consumed over 20 seconds
without this patch was measured at average at 311KBps per sample. With this
patch, the number went down to about 175Kbps which is about a 43% savings.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 966e69a8b1c1..d0d99f178f2d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -230,6 +230,14 @@ struct intel_guc {
* @shift: Right shift value for the gpm timestamp
*/
u32 shift;
+
+ /**
+* @last_stat_jiffies: jiffies at last actual stats collection
time
+* We use this timestamp to ensure we don't oversample the
+* stats because runtime power management events can trigger
+* stats collection at much higher rates than required.
+*/
+ unsigned long last_stat_jiffies;
} timestamp;
#ifdef CONFIG_DRM_I915_SELFTEST
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e62ea35513ea..c9f167b80910 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1314,6 +1314,8 @@ static void __update_guc_busyness_stats(struct intel_guc
*guc)
unsigned long flags;
ktime_t unused;
+ guc->timestamp.last_stat_jiffies = jiffies;
+
spin_lock_irqsave(&guc->timestamp.lock, flags);
guc_update_pm_timestamp(guc, &unused);
@@ -1386,6 +1388,17 @@ void intel_guc_busyness_park(struct intel_gt *gt)
return;
cancel_delayed_work(&guc->timestamp.work);
+
+ /*
+* Before parking, we should sample engine busyness stats if we need to.
+* We can skip it if we are less than half a ping from the last time we
+* sampled the busyness stats.
+*/
+ if (guc->timestamp.last_stat_jiffies &&
+ !time_after(jiffies, guc->timestamp.last_stat_jiffies +
+ (guc->timestamp.ping_delay / 2)))
+ return;
+
__update_guc_busyness_stats(guc);
}
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Add performance workaround 18019455067
== Series Details ==
Series: drm/i915/dg2: Add performance workaround 18019455067
URL : https://patchwork.freedesktop.org/series/105512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11795 -> Patchwork_105512v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/index.html
Participating hosts (39 -> 38)
--
Additional (1): fi-icl-u2
Missing(2): fi-kbl-soraka bat-dg2-8
Known issues
Here are the changes found in Patchwork_105512v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#5903])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][5] ([fdo#111827]) +8 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#4103])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-icl-u2: NOTRUN -> [WARN][7] ([i915#6008])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][8] ([fdo#109285])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#3555])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][10] ([fdo#109295] / [i915#3301])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-icl-u2/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][11] ([i915#5122]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][13] ([i915#3921]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][15] ([i915#3576]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- fi-tgl-u2: [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11795/fi-tgl-u2/igt@kms_flip@basic-plain-f...@a-edp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105512v1/fi-tgl-u2/igt@kms_flip@basic-plain-f...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1982
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg2: Add performance workaround 18019455067
== Series Details == Series: drm/i915/dg2: Add performance workaround 18019455067 URL : https://patchwork.freedesktop.org/series/105512/ State : warning == Summary == Error: dim checkpatch failed aaa694cf2d6b drm/i915/dg2: Add performance workaround 18019455067 -:33: ERROR:CODE_INDENT: code indent should use tabs where possible #33: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:2110: +/* Wa_18019455067:dg2 / BSpec 68331/54402 */$ -:34: ERROR:CODE_INDENT: code indent should use tabs where possible #34: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:2111: +wa_write_or(wal, RT_CTRL, NUMBER_OF_STACKIDS_512);$ -:34: WARNING:LEADING_SPACE: please, no spaces at the start of a line #34: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:2111: +wa_write_or(wal, RT_CTRL, NUMBER_OF_STACKIDS_512);$ total: 2 errors, 1 warnings, 0 checks, 18 lines checked
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Use non-blocking H2G for waitboost
On Wed, 22 Jun 2022 17:32:25 -0700, Vinay Belgaumkar wrote:
>
> @@ -208,12 +232,14 @@ static int slpc_force_min_freq(struct intel_guc_slpc
> *slpc, u32 freq)
>*/
>
> with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> - ret = slpc_set_param(slpc,
> - SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
> - freq);
> + /* Non-blocking request will avoid stalls */
> + ret = slpc_set_param_nb(slpc,
> +
> SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
> + freq);
> if (ret)
> - i915_probe_error(i915, "Unable to force min freq to %u:
> %d",
> - freq, ret);
> + drm_notice(&i915->drm,
> +"Failed to send set_param for min freq(%d):
> (%d)\n",
> +freq, ret);
I am still thinking if we should replace drm_notice() by i915_probe_error()
since drm_notice() will basically hide any issues of boost/de-boost's
getting dropped.
Another idea here might be to maintain a counter, say "slpc->failed_boosts"
which we increment each time slpc_set_param_nb() fails and dump that
counter via intel_guc_slpc_print_info().
Anyway for now this is:
Reviewed-by: Ashutosh Dixit
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: tweak the ordering in cpu_write_needs_clflush
== Series Details == Series: drm/i915: tweak the ordering in cpu_write_needs_clflush URL : https://patchwork.freedesktop.org/series/105503/ State : success == Summary == CI Bug Log - changes from CI_DRM_11795 -> Patchwork_105503v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105503v1/index.html Participating hosts (39 -> 41) -- Additional (2): fi-icl-u2 bat-dg2-9 New tests - New tests have been introduced between CI_DRM_11795 and Patchwork_105503v1: ### New IGT tests (24) ### * igt@kms_pipe_crc_basic@compare-crc-sanitycheck@pipe-a-dp-3: - Statuses : 1 pass(s) - Exec time: [0.51] s * igt@kms_pipe_crc_basic@compare-crc-sanitycheck@pipe-b-dp-3: - Statuses : 1 pass(s) - Exec time: [0.39] s * igt@kms_pipe_crc_basic@compare-crc-sanitycheck@pipe-c-dp-3: - Statuses : 1 pass(s) - Exec time: [0.40] s * igt@kms_pipe_crc_basic@compare-crc-sanitycheck@pipe-d-dp-3: - Statuses : 1 pass(s) - Exec time: [0.39] s * igt@kms_pipe_crc_basic@hang-read-crc@pipe-a-dp-3: - Statuses : 1 pass(s) - Exec time: [1.59] s * igt@kms_pipe_crc_basic@hang-read-crc@pipe-b-dp-3: - Statuses : 1 pass(s) - Exec time: [1.42] s * igt@kms_pipe_crc_basic@hang-read-crc@pipe-c-dp-3: - Statuses : 1 pass(s) - Exec time: [1.52] s * igt@kms_pipe_crc_basic@hang-read-crc@pipe-d-dp-3: - Statuses : 1 pass(s) - Exec time: [1.48] s * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-a-dp-3: - Statuses : 1 pass(s) - Exec time: [0.69] s * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-b-dp-3: - Statuses : 1 pass(s) - Exec time: [0.55] s * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-3: - Statuses : 1 pass(s) - Exec time: [0.58] s * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-3: - Statuses : 1 pass(s) - Exec time: [0.54] s * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-a-dp-3: - Statuses : 1 pass(s) - Exec time: [0.70] s * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-b-dp-3: - Statuses : 1 pass(s) - Exec time: [0.54] s * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-3: - Statuses : 1 pass(s) - Exec time: [0.55] s * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-3: - Statuses : 1 pass(s) - Exec time: [0.57] s * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-dp-3: - Statuses : 1 pass(s) - Exec time: [0.64] s * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-b-dp-3: - Statuses : 1 pass(s) - Exec time: [0.48] s * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-3: - Statuses : 1 pass(s) - Exec time: [0.48] s * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-3: - Statuses : 1 pass(s) - Exec time: [0.48] s * igt@kms_pipe_crc_basic@read-crc@pipe-a-dp-3: - Statuses : 1 pass(s) - Exec time: [0.64] s * igt@kms_pipe_crc_basic@read-crc@pipe-b-dp-3: - Statuses : 1 pass(s) - Exec time: [0.50] s * igt@kms_pipe_crc_basic@read-crc@pipe-c-dp-3: - Statuses : 1 pass(s) - Exec time: [0.48] s * igt@kms_pipe_crc_basic@read-crc@pipe-d-dp-3: - Statuses : 1 pass(s) - Exec time: [0.52] s Known issues Here are the changes found in Patchwork_105503v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][1] ([i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105503v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@random-engines: - fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105503v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html * igt@i915_suspend@basic-s3-without-i915: - fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#5903]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105503v1/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][4] ([fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105503v1/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#4103]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105503v1/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-connector-state: - fi-icl-u2: NOTRUN -> [WARN][6] ([i915#6008]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105503v1/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html * igt@kms_force_connector_basic@fo
[Intel-gfx] [PATCH] drm/i915/guc/slpc: Use non-blocking H2G for waitboost
SLPC min/max frequency updates require H2G calls. We are seeing
timeouts when GuC channel is backed up and it is unable to respond
in a timely fashion causing warnings and affecting CI.
This is seen when waitboosting happens during a stress test.
this patch updates the waitboost path to use a non-blocking
H2G call instead, which returns as soon as the message is
successfully transmitted.
v2: Use drm_notice to report any errors that might occur while
sending the waitboost H2G request (Tvrtko)
v3: Add drm_notice inside force_min_freq (Ashutosh)
Cc: Ashutosh Dixit
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 42 +
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 2df31af70d63..ec9c4ca0f615 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -98,6 +98,30 @@ static u32 slpc_get_state(struct intel_guc_slpc *slpc)
return data->header.global_state;
}
+static int guc_action_slpc_set_param_nb(struct intel_guc *guc, u8 id, u32
value)
+{
+ u32 request[] = {
+ GUC_ACTION_HOST2GUC_PC_SLPC_REQUEST,
+ SLPC_EVENT(SLPC_EVENT_PARAMETER_SET, 2),
+ id,
+ value,
+ };
+ int ret;
+
+ ret = intel_guc_send_nb(guc, request, ARRAY_SIZE(request), 0);
+
+ return ret > 0 ? -EPROTO : ret;
+}
+
+static int slpc_set_param_nb(struct intel_guc_slpc *slpc, u8 id, u32 value)
+{
+ struct intel_guc *guc = slpc_to_guc(slpc);
+
+ GEM_BUG_ON(id >= SLPC_MAX_PARAM);
+
+ return guc_action_slpc_set_param_nb(guc, id, value);
+}
+
static int guc_action_slpc_set_param(struct intel_guc *guc, u8 id, u32 value)
{
u32 request[] = {
@@ -208,12 +232,14 @@ static int slpc_force_min_freq(struct intel_guc_slpc
*slpc, u32 freq)
*/
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
- ret = slpc_set_param(slpc,
-SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
-freq);
+ /* Non-blocking request will avoid stalls */
+ ret = slpc_set_param_nb(slpc,
+
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+ freq);
if (ret)
- i915_probe_error(i915, "Unable to force min freq to %u:
%d",
-freq, ret);
+ drm_notice(&i915->drm,
+ "Failed to send set_param for min freq(%d):
(%d)\n",
+ freq, ret);
}
return ret;
@@ -222,6 +248,7 @@ static int slpc_force_min_freq(struct intel_guc_slpc *slpc,
u32 freq)
static void slpc_boost_work(struct work_struct *work)
{
struct intel_guc_slpc *slpc = container_of(work, typeof(*slpc),
boost_work);
+ int err;
/*
* Raise min freq to boost. It's possible that
@@ -231,8 +258,9 @@ static void slpc_boost_work(struct work_struct *work)
*/
mutex_lock(&slpc->lock);
if (atomic_read(&slpc->num_waiters)) {
- slpc_force_min_freq(slpc, slpc->boost_freq);
- slpc->num_boosts++;
+ err = slpc_force_min_freq(slpc, slpc->boost_freq);
+ if (!err)
+ slpc->num_boosts++;
}
mutex_unlock(&slpc->lock);
}
--
2.35.1
Re: [Intel-gfx] [Intel-gfx v2 1/1] drm/i915/guc: Don't update engine busyness stats too frequently
> > + /** > > +* @last_jiffies: jiffies at last actual stats collection time > > +* We use this timestamp to ensure we don't oversample the > > +* stats because runtime power management events can trigger > > +* stats collection at much higher rates than required. > > +*/ > > + u64 last_stat_jiffs; > > Why the new "jiffs" naming and not the usual jiffies? > > Otherwise a good comment - just align the member name with the kerneldoc > name. > my mistake - will align the names. > > unsigned long flags; > > ktime_t unused; > > > > + guc->timestamp.last_stat_jiffs = get_jiffies_64(); > > Why the 64 bit flavour? It's a first in i915 but it doesn't feel so special. > sure - will use the regular jiffies > > + > > spin_lock_irqsave(&guc->timestamp.lock, flags); > > > > guc_update_pm_timestamp(guc, &unused); > > @@ -1386,6 +1388,16 @@ void intel_guc_busyness_park(struct intel_gt *gt) > > return; > > > > cancel_delayed_work(&guc->timestamp.work); > > + > > + /* > > +* Before parking, we should sample engine busyness stats if we need to. > > +* We can skip it if we are less than half a ping from the last time we > > +* sampled the business stats. > > busyness yup. > > > +*/ > > + if (guc->timestamp.last_stat_jiffs && (get_jiffies_64() - > > guc->timestamp.last_stat_jiffs < > > + (guc->timestamp.ping_delay >> 1))) > > + return; > > 1) > Recommend a division instead of a shift. ok > > 2) > Is there a time_after() macro for this? > yes there is - will do. > 3) > Should the logic be contained/consolidated in __update_guc_busyness_stats? As Umesh mentioned, __update_guc_busyness_stats is called from the non __gt_park callers and in those cases we don't want it to skip. I wanted avoid adding additional unnecessary params to signal if the caller would be okay with skipping - so rather just make that decision at the caller's level. However, for the updating of the latest last_stat_jiffies, i wanted to ensure that it got updated for all callers so we ensure the absolute minimal required busyness updates are made when gt_park is called while other callers also got called in between. > > There is cancel_delayed_work in there - is it okay for that to be > bypassed from here? > I believe Umesh addressed this. > Regards, > > Tvrtko > > > + > > __update_guc_busyness_stats(guc); > > } > >
Re: [Intel-gfx] [Intel-gfx v2 1/1] drm/i915/guc: Don't update engine busyness stats too frequently
Thanks Umesh. As per offline - i will address Tvrtko's comments too.
...alan
On Wed, 2022-06-22 at 16:00 -0700, Nerlige Ramappa, Umesh wrote:
> On Fri, Jun 17, 2022 at 10:43:45PM -0700, Alan Previn wrote:
> > Using igt's gem-create and with additional patches to track object
> > creation time, it was measured that guc_update_engine_gt_clks was
> > getting called over 188 thousand times in the span of 15 seconds
> > (running the test three times).
> >
> > Get a jiffies sample on every trigger and ensure we skip sampling
> > if we are being called too soon. Use half of the ping_delay as a
> > safe threshold.
> >
> > NOTE: with this change, the number of calls went down to just 14
> > over the same span of time (matching the original intent of running
> > about once every 24 seconds, at 19.2Mhz GT freq, per engine).
> >
> > Signed-off-by: Alan Previn
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 966e69a8b1c1..26f3e4403de7 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -230,6 +230,14 @@ struct intel_guc {
> > * @shift: Right shift value for the gpm timestamp
> > */
> > u32 shift;
> > +
> > + /**
> > +* @last_jiffies: jiffies at last actual stats collection time
> > +* We use this timestamp to ensure we don't oversample the
> > +* stats because runtime power management events can trigger
> > +* stats collection at much higher rates than required.
> > +*/
> > + u64 last_stat_jiffs;
> > } timestamp;
> >
> > #ifdef CONFIG_DRM_I915_SELFTEST
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index e62ea35513ea..05c945f14ef5 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -1314,6 +1314,8 @@ static void __update_guc_busyness_stats(struct
> > intel_guc *guc)
> > unsigned long flags;
> > ktime_t unused;
> >
> > + guc->timestamp.last_stat_jiffs = get_jiffies_64();
> > +
> > spin_lock_irqsave(&guc->timestamp.lock, flags);
> >
> > guc_update_pm_timestamp(guc, &unused);
> > @@ -1386,6 +1388,16 @@ void intel_guc_busyness_park(struct intel_gt *gt)
> > return;
> >
> > cancel_delayed_work(&guc->timestamp.work);
> > +
> > + /*
> > +* Before parking, we should sample engine busyness stats if we need to.
> > +* We can skip it if we are less than half a ping from the last time we
> > +* sampled the business stats.
> > +*/
> > + if (guc->timestamp.last_stat_jiffs && (get_jiffies_64() -
> > guc->timestamp.last_stat_jiffs <
> > + (guc->timestamp.ping_delay >> 1)))
> > + return;
> > +
>
> I would just sample the jiffies here instead of inside
> __update_guc_busyness_stats(), so all the logic is within this function
> and easy to read.
>
> Either ways, this should work too, so this is
>
> Reviewed-by: Umesh Nerlige Ramappa
>
> Regards,
> Umesh
>
> > __update_guc_busyness_stats(guc);
> > }
> >
> > --
> > 2.25.1
> >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev3)
== Series Details ==
Series: drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups (rev3)
URL : https://patchwork.freedesktop.org/series/90164/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11794 -> Patchwork_90164v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/index.html
Participating hosts (42 -> 40)
--
Missing(2): fi-cml-u2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_90164v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][1] ([i915#4528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][2] -> [INCOMPLETE][3] ([i915#3921])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: NOTRUN -> [DMESG-FAIL][4] ([i915#4494] / [i915#4957])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][5] ([i915#6011])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2: [PASS][6] -> [DMESG-WARN][7] ([i915#402])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][8] ([i915#5122]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [INCOMPLETE][10] ([i915#4418]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][12] ([i915#4528]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy:
- fi-kbl-soraka: [INCOMPLETE][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
*
{igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size}:
- fi-bsw-kefka: [FAIL][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
*
igt@kms_cursor_legacy@basic-flip-before-cursor@atomic-transitions-varying-size:
- fi-elk-e7500: [SKIP][18] ([fdo#109271]) -> [PASS][19] +9 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-elk-e7500/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-elk-e7500/igt@kms_cursor_legacy@basic-flip-before-cur...@atomic-transitions-varying-size.html
Warnings
* igt@kms_chamelium@hdmi-edid-read:
- fi-elk-e7500: [SKIP][20] ([fdo#109271]) -> [SKIP][21] ([fdo#109271]
/ [fdo#111827]) +8 similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-elk-e7500/igt@kms_chamel...@hdmi-edid-read.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_90164v3/fi-elk-e7500/igt@kms_chamel...@hdmi-edid-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WA
Re: [Intel-gfx] [Intel-gfx v2 1/1] drm/i915/guc: Don't update engine busyness stats too frequently
On Fri, Jun 17, 2022 at 10:43:45PM -0700, Alan Previn wrote:
Using igt's gem-create and with additional patches to track object
creation time, it was measured that guc_update_engine_gt_clks was
getting called over 188 thousand times in the span of 15 seconds
(running the test three times).
Get a jiffies sample on every trigger and ensure we skip sampling
if we are being called too soon. Use half of the ping_delay as a
safe threshold.
NOTE: with this change, the number of calls went down to just 14
over the same span of time (matching the original intent of running
about once every 24 seconds, at 19.2Mhz GT freq, per engine).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 966e69a8b1c1..26f3e4403de7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -230,6 +230,14 @@ struct intel_guc {
* @shift: Right shift value for the gpm timestamp
*/
u32 shift;
+
+ /**
+* @last_jiffies: jiffies at last actual stats collection time
+* We use this timestamp to ensure we don't oversample the
+* stats because runtime power management events can trigger
+* stats collection at much higher rates than required.
+*/
+ u64 last_stat_jiffs;
} timestamp;
#ifdef CONFIG_DRM_I915_SELFTEST
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e62ea35513ea..05c945f14ef5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1314,6 +1314,8 @@ static void __update_guc_busyness_stats(struct intel_guc
*guc)
unsigned long flags;
ktime_t unused;
+ guc->timestamp.last_stat_jiffs = get_jiffies_64();
+
spin_lock_irqsave(&guc->timestamp.lock, flags);
guc_update_pm_timestamp(guc, &unused);
@@ -1386,6 +1388,16 @@ void intel_guc_busyness_park(struct intel_gt *gt)
return;
cancel_delayed_work(&guc->timestamp.work);
+
+ /*
+* Before parking, we should sample engine busyness stats if we need to.
+* We can skip it if we are less than half a ping from the last time we
+* sampled the business stats.
+*/
+ if (guc->timestamp.last_stat_jiffs && (get_jiffies_64() -
guc->timestamp.last_stat_jiffs <
+ (guc->timestamp.ping_delay >> 1)))
+ return;
+
I would just sample the jiffies here instead of inside
__update_guc_busyness_stats(), so all the logic is within this function
and easy to read.
Either ways, this should work too, so this is
Reviewed-by: Umesh Nerlige Ramappa
Regards,
Umesh
__update_guc_busyness_stats(guc);
}
--
2.25.1
Re: [Intel-gfx] [PATCH v2 1/2] agp/intel: Rename intel-gtt symbols
On Fri, Jun 17, 2022 at 04:05:58PM -0700, Lucas De Marchi wrote:
Exporting the symbols like intel_gtt_* creates some confusion inside
i915 that has symbols named similarly. In an attempt to isolate
platforms needing intel-gtt.ko, commit 7a5c922377b4 ("drm/i915/gt: Split
intel-gtt functions by arch") moved way too much
inside gt/intel_gt_gmch.c, even the functions that don't callout to this
module. Rename the symbols to make the separation clear.
Signed-off-by: Lucas De Marchi
Reviewed-by: Tvrtko Ursulin
I was in doubt if drm-intel-gt-next would be the most appropriate to push this
patch to, but after checking the last 20 commits (which goes back to
2015) touching drivers/char/agp/intel-gtt.c, 17 of them came from
drm-intel-next/drm-intel-gt-next/drm-intel-next-queued
Applied both patches to drm-intel-gt-next.
thanks
Lucas De Marchi
Re: [Intel-gfx] [Intel-gfx v2 1/1] drm/i915/guc: Don't update engine busyness stats too frequently
On Mon, Jun 20, 2022 at 09:46:30AM +0100, Tvrtko Ursulin wrote:
On 18/06/2022 06:43, Alan Previn wrote:
Using igt's gem-create and with additional patches to track object
creation time, it was measured that guc_update_engine_gt_clks was
getting called over 188 thousand times in the span of 15 seconds
(running the test three times).
Get a jiffies sample on every trigger and ensure we skip sampling
if we are being called too soon. Use half of the ping_delay as a
safe threshold.
NOTE: with this change, the number of calls went down to just 14
over the same span of time (matching the original intent of running
about once every 24 seconds, at 19.2Mhz GT freq, per engine).
It would be beneficial to record the root cause. Both frequency of
parking/unparking caused by and lmem access cost.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 966e69a8b1c1..26f3e4403de7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -230,6 +230,14 @@ struct intel_guc {
* @shift: Right shift value for the gpm timestamp
*/
u32 shift;
+
+ /**
+* @last_jiffies: jiffies at last actual stats collection time
+* We use this timestamp to ensure we don't oversample the
+* stats because runtime power management events can trigger
+* stats collection at much higher rates than required.
+*/
+ u64 last_stat_jiffs;
Why the new "jiffs" naming and not the usual jiffies?
Otherwise a good comment - just align the member name with the
kerneldoc name.
} timestamp;
#ifdef CONFIG_DRM_I915_SELFTEST
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e62ea35513ea..05c945f14ef5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1314,6 +1314,8 @@ static void __update_guc_busyness_stats(struct intel_guc
*guc)
unsigned long flags;
ktime_t unused;
+ guc->timestamp.last_stat_jiffs = get_jiffies_64();
Why the 64 bit flavour? It's a first in i915 but it doesn't feel so special.
+
spin_lock_irqsave(&guc->timestamp.lock, flags);
guc_update_pm_timestamp(guc, &unused);
@@ -1386,6 +1388,16 @@ void intel_guc_busyness_park(struct intel_gt *gt)
return;
cancel_delayed_work(&guc->timestamp.work);
+
+ /*
+* Before parking, we should sample engine busyness stats if we need to.
+* We can skip it if we are less than half a ping from the last time we
+* sampled the business stats.
busyness
+*/
+ if (guc->timestamp.last_stat_jiffs && (get_jiffies_64() -
guc->timestamp.last_stat_jiffs <
+ (guc->timestamp.ping_delay >> 1)))
+ return;
1)
Recommend a division instead of a shift.
2)
Is there a time_after() macro for this?
3)
Should the logic be contained/consolidated in __update_guc_busyness_stats?
It wouldn't hurt to have it in __update_guc_busyness_stats, but
__update_guc_busyness_stats is also called from the ping worker. Since
this is targeted for gt_park/gt_unpark events, I would leave it here.
There is cancel_delayed_work in there - is it okay for that to be
bypassed from here?
I don't see it being bypassed. cancel_delayed_work is called before the
jiffies logic here.
Regards,
Umesh
Regards,
Tvrtko
+
__update_guc_busyness_stats(guc);
}
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Increase timeout for live_parallel_switch
== Series Details ==
Series: drm/i915/selftests: Increase timeout for live_parallel_switch
URL : https://patchwork.freedesktop.org/series/105490/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11794 -> Patchwork_105490v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/index.html
Participating hosts (42 -> 37)
--
Missing(5): fi-cml-u2 fi-rkl-11600 bat-dg2-8 fi-icl-u2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_105490v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][1] -> [INCOMPLETE][2] ([i915#5847])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][3] ([i915#4528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][4] ([i915#6011])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- fi-tgl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#402])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-tgl-u2/igt@kms_flip@basic-plain-f...@a-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/fi-tgl-u2/igt@kms_flip@basic-plain-f...@a-edp1.html
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][7] ([fdo#109271] / [i915#3428] /
[i915#4312])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/fi-bsw-n3050/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [INCOMPLETE][8] ([i915#4418]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][10] ([i915#4494] / [i915#4957]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][12] ([i915#4528]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy:
- fi-kbl-soraka: [INCOMPLETE][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][16] ([i915#3576]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-adlp-6/igt@kms_busy@ba...@flip.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/bat-adlp-6/igt@kms_busy@ba...@flip.html
*
{igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size}:
- fi-bsw-kefka: [FAIL][18] -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105490v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4528]: https:
Re: [Intel-gfx] [PATCH] drm/i915: Call i915_gem_suspend() only after display is turned off
On Tue, Jun 21, 2022 at 10:03:04AM -0700, Souza, Jose wrote:
> On Fri, 2022-06-17 at 12:28 -0700, Matt Roper wrote:
> > On Fri, Jun 17, 2022 at 12:06:29PM -0700, José Roberto de Souza wrote:
> > > Gem buffers could still be in use by display after i915_gem_suspend()
> > > is executed so there is chances that i915_gem_flush_free_objects()
> > > will be being executed at the same time that
> > > intel_runtime_pm_driver_release() is executed printing warnings about
> > > wakerefs will being held.
> >
> > By the same logic do we need to adjust i915_driver_remove() too?
>
> Nope, all display buffers are freed in i915_driver_unregister() call chain:
>
>
> i915_driver_remove()
> i915_driver_unregister()
> intel_display_driver_unregister()
> drm_atomic_helper_shutdown()
> i915_gem_suspend()
> i915_gem_drain_freed_objects()
>
>
> Only FBC compressed framebuffer is freed after that but that will not cause
> any warnings as it is allocated from stolen memory.
Okay sounds good; thanks for checking.
I'm still having a bit of trouble understanding your description of the
issue in the commit message though:
"...so there is chances that i915_gem_flush_free_objects() will
be being executed at the same time that
intel_runtime_pm_driver_release()..."
I'm not super familiar with the driver teardown paths, or the memory
management cleanup details. Intuitively it makes sense that we should
clean up memory management (GEM) only after we've torn down display so
that all objects that were used by framebuffers are out of circulation.
But from a cursory view, it looks like i915_gem_suspend() is mostly
concerned with quiescing the GT and cleaning up PPGTT (which doesn't
impact display since all of its buffers are in the GGTT).
Is the problem arising from i915->mm.free_work still doing asynchronous
work to actually release the unused objects at the same time we're
tearing down runtime PM later? If so does swapping the order of the
gem_suspend and display disable here actually prevent that from
happening or does it just make the race less likely by helping some
objects free up earlier?
Matt
>
> >
> >
> > Matt
> >
> > >
> > > So here only calling i915_gem_suspend() and by consequence
> > > i915_gem_drain_freed_objects() only after display is down making
> > > sure all buffers are freed.
> > >
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/i915_driver.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > b/drivers/gpu/drm/i915/i915_driver.c
> > > index d26dcca7e654a..4227675dd1cfe 100644
> > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > @@ -1067,8 +1067,6 @@ void i915_driver_shutdown(struct drm_i915_private
> > > *i915)
> > > intel_runtime_pm_disable(&i915->runtime_pm);
> > > intel_power_domains_disable(i915);
> > >
> > > - i915_gem_suspend(i915);
> > > -
> > > if (HAS_DISPLAY(i915)) {
> > > drm_kms_helper_poll_disable(&i915->drm);
> > >
> > > @@ -1085,6 +1083,8 @@ void i915_driver_shutdown(struct drm_i915_private
> > > *i915)
> > >
> > > intel_dmc_ucode_suspend(i915);
> > >
> > > + i915_gem_suspend(i915);
> > > +
> > > /*
> > >* The only requirement is to reboot with display DC states disabled,
> > >* for now leaving all display power wells in the INIT power domain
> > > --
> > > 2.36.1
> > >
> >
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: expand on struct drm_edid usage (rev4)
== Series Details ==
Series: drm/edid: expand on struct drm_edid usage (rev4)
URL : https://patchwork.freedesktop.org/series/104309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11794 -> Patchwork_104309v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/index.html
Participating hosts (42 -> 39)
--
Missing(3): fi-cml-u2 fi-bdw-samus bat-dg2-8
Known issues
Here are the changes found in Patchwork_104309v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([i915#4890])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-icl-u2/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-icl-u2/igt@i915_pm_...@module-reload.html
- fi-cfl-8109u: [PASS][3] -> [DMESG-WARN][4] ([i915#62]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][5] ([i915#4528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: NOTRUN -> [DMESG-FAIL][6] ([i915#4494] / [i915#4957])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u: [PASS][7] -> [DMESG-WARN][8] ([i915#5904]) +34
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#5904] /
[i915#62]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
- bat-dg1-6: NOTRUN -> [INCOMPLETE][11] ([i915#6011])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#402])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_flip@basic-plain-flip@c-dp2:
- fi-cfl-8109u: [PASS][15] -> [DMESG-WARN][16] ([i915#165])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp2.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp2.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [PASS][17] -> [DMESG-WARN][18] ([i915#165] /
[i915#62]) +6 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][19] ([fdo#109295] / [i915#3301])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-icl-u2: NOTRUN -> [FAIL][20] ([i915#3690] / [i915#4312])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-icl-u2/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][21] ([i915#5122]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104309v4/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [INCOMPLETE][23] ([i915#4418]) -> [PASS
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: add payload receiving code (rev6)
== Series Details ==
Series: drm/i915/dsi: add payload receiving code (rev6)
URL : https://patchwork.freedesktop.org/series/105096/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11794 -> Patchwork_105096v6
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/index.html
Participating hosts (42 -> 38)
--
Missing(4): fi-cml-u2 fi-bdw-samus fi-icl-u2 fi-apl-guc
Known issues
Here are the changes found in Patchwork_105096v6 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][1] ([i915#4528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@requests:
- fi-kbl-soraka: [PASS][2] -> [INCOMPLETE][3] ([i915#4116])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-dpms@a-edp1:
- fi-tgl-u2: [PASS][4] -> [DMESG-WARN][5] ([i915#402])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-tgl-u2/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-tgl-u2/igt@kms_flip@basic-flip-vs-d...@a-edp1.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][6] ([fdo#109295] / [i915#3301])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][7] ([i915#4312] / [i915#5257])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-kbl-soraka/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][8] ([i915#4494] / [i915#4957]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][10] ([i915#4528]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy:
- fi-kbl-soraka: [INCOMPLETE][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
* igt@kms_busy@basic@flip:
- fi-tgl-u2: [DMESG-WARN][14] ([i915#402]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-tgl-u2/igt@kms_busy@ba...@flip.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-tgl-u2/igt@kms_busy@ba...@flip.html
*
{igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size}:
- fi-bsw-kefka: [FAIL][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][18] ([i915#3576]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105096v6/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#4116]: https://gitlab.freedesktop.org/drm/intel/issues/4116
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Use non-blocking H2G for waitboost
On Wed, 22 Jun 2022 13:30:23 -0700, Belgaumkar, Vinay wrote:
> On 6/21/2022 5:26 PM, Dixit, Ashutosh wrote:
> > On Sat, 14 May 2022 23:05:06 -0700, Vinay Belgaumkar wrote:
> > The issue I have is what happens when we de-boost (restore min freq to its
> > previous value in intel_guc_slpc_dec_waiters()). It would seem that that
> > call is fairly important to get the min freq down when there are no pending
> > requests. Therefore what do we do in that case?
> >
> > This is the function:
> >
> > void intel_guc_slpc_dec_waiters(struct intel_guc_slpc *slpc)
> > {
> > mutex_lock(&slpc->lock);
> > if (atomic_dec_and_test(&slpc->num_waiters))
> > slpc_force_min_freq(slpc, slpc->min_freq_softlimit);
> > mutex_unlock(&slpc->lock);
> > }
> >
> >
> > 1. First it would seem that at the minimum we need a similar drm_notice()
> > in intel_guc_slpc_dec_waiters(). That would mean we need to put the
> > drm_notice() back in slpc_force_min_freq() (replacing
> > i915_probe_error()) rather than in slpc_boost_work() above?
> Sure.
> >
> > 2. Further, if de-boosting is important then maybe as was being discussed
> > in v1 of this patch (see the bottom of
> > https://patchwork.freedesktop.org/patch/485004/?series=103598&rev=1) do
> > we need to use intel_guc_send_busy_loop() in the
> > intel_guc_slpc_dec_waiters() code path?
>
> Using a busy_loop here would essentially be the same as blocking, right?
Well blocking waits for a response from GuC (so all previous requests need
to be processed by GuC) whereas busy_loop() just waits for space to be
available at the back of the queue (so just a few, or maybe just one,
request have to be processed by GuC).
> And it could still fail/timeout with blocking as well (which is the problem
> we are trying to solve here).
intel_guc_send_busy_loop() has an infinite wait without a drm_err()!! :)
> De-boosting is important, but in the worst case scenario, lets say this
> request was not processed by GuC. This would happen only if the system
> were really busy, which would mean there is a high likelihood we would
> boost/de-boost again anyways and it would probably go through at that
> point.
Not sure of this. The system was busy but now might have gone idle which is
why we are trying to de-boost. But GuC queue might still be full so we may
drop the de-boost request. Or if the system has gone really idle there will
be space in the GuC queue.
Also the problem with intel_guc_send_busy_loop() is that it just has a
sleep in it, so others might be adding requests in the GuC queue while
busy_loop() was sleeping (to avoid such situations we'd need a SW queue in
front of the real GuC queue).
So I am ok if we don't want to add intel_guc_send_busy_loop() for now and
"wait and watch". Unless John suggests otherwise since I don't have any
idea how likely is this to happen. If we change drm_notice to drm_err the
CI will quick tell us if this happening.
Anyway, so at least let's move drm_notice (or drm_err) into
slpc_force_min_freq() and I can ok the patch. Thanks.
> > At least we need to do 1. But for 2. we might as well just put
> > intel_guc_send_busy_loop() in guc_action_slpc_set_param_nb()? In both cases
> > (boost and de-boost) intel_guc_send_busy_loop() would be called from a work
> > item so looks doable (the way we were previously doing the blocking call
> > from the two places). Thoughts?
> >
> > Thanks.
> > --
> > Ashutosh
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: expand on struct drm_edid usage (rev4)
== Series Details == Series: drm/edid: expand on struct drm_edid usage (rev4) URL : https://patchwork.freedesktop.org/series/104309/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: expand on struct drm_edid usage (rev4)
== Series Details == Series: drm/edid: expand on struct drm_edid usage (rev4) URL : https://patchwork.freedesktop.org/series/104309/ State : warning == Summary == Error: dim checkpatch failed 7563c369133d drm/edid: move drm_connector_update_edid_property() to drm_edid.c 2f2c0140ebb5 drm/edid: convert drm_connector_update_edid_property() to struct drm_edid 5cd4b0d72224 drm/edid: clean up connector update error handling and debug logging 9df34db5e761 drm/edid: abstract debugfs override EDID set/reset 073125be92f4 drm/edid: add drm_edid_connector_update() 8ab102eda175 drm/probe-helper: add drm_connector_helper_get_modes() cee7d6612c1c drm/edid: add drm_edid_raw() to access the raw EDID data 90d0961df1d4 drm/i915/edid: convert DP, HDMI and LVDS to drm_edid -:264: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "drm_edid" #264: FILE: drivers/gpu/drm/i915/display/intel_hdmi.c:2429: + intel_hdmi_dp_dual_mode_detect(connector, drm_edid != NULL); total: 0 errors, 0 warnings, 1 checks, 310 lines checked 9a373480eb45 drm/i915/bios: convert intel_bios_init_panel() to drm_edid 993e8f0a44f8 drm/edid: do invalid block filtering in-place 6e5b921c8fcd drm/edid: add HF-EEODB support to EDID read and allocation c2e4fa6ecfb0 drm/edid: take HF-EEODB extension count into account e191fe578219 drm/todo: add entry for converting the subsystem to struct drm_edid
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Add performance workaround 18019455067
On Wed, Jun 22, 2022 at 09:38:36PM +0300, Lionel Landwerlin wrote: This is the recommended value for optimal performance. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 07ef111947b8c..a50b5790e434e 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -1112,6 +1112,9 @@ #define GEN12_PUSH_CONST_DEREF_HOLD_DIS REG_BIT(8) #define RT_CTRL _MMIO(0xe530) +#define NUMBER_OF_STACKIDS_512 (2 << 5) +#define NUMBER_OF_STACKIDS_1024 (1 << 5) +#define NUMBER_OF_STACKIDS_2048 (0 << 5) Should be using REG_BIT / REG_FIELD_PREP #define DIS_NULL_QUERYREG_BIT(10) #define EU_PERF_CNTL1 _MMIO(0xe558) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 3213c593a55f4..a8a389d36986c 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2106,6 +2106,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) * performance guide section. */ wa_write_or(wal, XEHP_L3SCQREG7, BLEND_FILL_CACHING_OPT_DIS); + +/* Wa_18019455067:dg2 / BSpec 68331/54402 */ +wa_write_or(wal, RT_CTRL, NUMBER_OF_STACKIDS_512); this is not a workaround, it's a tuning value. See functions with "tuning" in the name. Do not keep bspec reference in comment. If at all, this should be in the commit message. This is also not setting the correct value if it was previously programmed with NUMBER_OF_STACKIDS_1024 since it will just OR the bits. Use wa_write_clr_set(). Lucas De Marchi
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Add performance workaround 18019455067
On Wed, Jun 22, 2022 at 09:38:36PM +0300, Lionel Landwerlin wrote:
> This is the recommended value for optimal performance.
>
> Signed-off-by: Lionel Landwerlin
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 07ef111947b8c..a50b5790e434e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1112,6 +1112,9 @@
> #define GEN12_PUSH_CONST_DEREF_HOLD_DISREG_BIT(8)
>
> #define RT_CTRL _MMIO(0xe530)
> +#define NUMBER_OF_STACKIDS_512 (2 << 5)
> +#define NUMBER_OF_STACKIDS_1024(1 << 5)
> +#define NUMBER_OF_STACKIDS_2048(0 << 5)
Preferred notation these days would be to use REG_* macros. I.e.,
#define NUMBER_OF_STACKIDSREG_GENMASK(6, 5)
#define NUMBER_OF_STACKIDS_512REG_FIELD_PREP(NUMBER_OF_STACKIDS, 0x2)
It's also probably not worth defining the other values that we're not
using. If we wind up needing one of them on a future platform, we'll
want to double check at that point anyway to make sure the meaning
hasn't changed.
> #define DIS_NULL_QUERY REG_BIT(10)
>
> #define EU_PERF_CNTL1_MMIO(0xe558)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3213c593a55f4..a8a389d36986c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2106,6 +2106,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>* performance guide section.
>*/
> wa_write_or(wal, XEHP_L3SCQREG7, BLEND_FILL_CACHING_OPT_DIS);
> +
> +/* Wa_18019455067:dg2 / BSpec 68331/54402 */
Generally we just stick the bspec page numbers in the commit message
above the Signed-off-by line and don't put them in the code itself.
> +wa_write_or(wal, RT_CTRL, NUMBER_OF_STACKIDS_512);
This will bit-wise OR the STACKIDS_512 into register's existing value.
Since the hardware default for the field is 0 that would probably work
out okay in this case, but in general when we need to change the value
of a multi-bit field we want to define the workaround in a way that will
clear all bits of the field before OR'ing in the new value so that you
don't wind up with any leftover garbage. You can do that with
wa_write_clr_set(wal, RT_CTRL, NUMBER_OF_STACKIDS,
NUMBER_OF_STACKIDS_512);
Looks like there might be some whitespace issues here too (spaces
where we should have tabs according to the kernel coding style).
Matt
> }
>
> if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_B0)) {
> --
> 2.32.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsi: add payload receiving code (rev6)
== Series Details ==
Series: drm/i915/dsi: add payload receiving code (rev6)
URL : https://patchwork.freedesktop.org/series/105096/
State : warning
== Summary ==
Error: dim checkpatch failed
b22f538d9671 drm/i915/dsi: add payload receiving code
-:111: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#111: FILE: drivers/gpu/drm/i915/display/icl_dsi.c:263:
+ for (i = 0; i < payld_dw; i++) {
+
total: 0 errors, 0 warnings, 1 checks, 113 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: i915_irq - drop unexpected word "the" in the comments
== Series Details ==
Series: drm/i915: i915_irq - drop unexpected word "the" in the comments
URL : https://patchwork.freedesktop.org/series/105477/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11794 -> Patchwork_105477v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/index.html
Participating hosts (42 -> 38)
--
Missing(4): fi-cml-u2 fi-rkl-11600 fi-icl-u2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_105477v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([i915#3921])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][3] ([i915#6011])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- fi-tgl-u2: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +1 similar
issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
Possible fixes
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [INCOMPLETE][6] ([i915#4418]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy:
- fi-kbl-soraka: [INCOMPLETE][8] -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
* igt@kms_busy@basic@flip:
- fi-tgl-u2: [DMESG-WARN][10] ([i915#402]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-tgl-u2/igt@kms_busy@ba...@flip.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/fi-tgl-u2/igt@kms_busy@ba...@flip.html
*
{igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size}:
- fi-bsw-kefka: [FAIL][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105477v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418
[i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
[i915#5270]: https://gitlab.freedesktop.org/drm/intel/issues/5270
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
[i915#5885]: https://gitlab.freedesktop.org/drm/intel/issues/5885
[i915#5903]: https://gitlab.freedesktop.org/drm/intel/issues/5903
[i915#6011]: https://gitlab.freedesktop.org/drm/intel/issues/6011
Build changes
-
* Linux: CI_DRM_11794 -> Patchwork_105477v1
CI-20190529: 20190529
CI_DRM_11794: 529f44f159dbe70ba69b6f730280d5db9b7338bc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6539: c39caed3b207e058409f5e2b548a4f940b6283c6 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_105477v1: 529f44f159dbe70ba69b6f73
Re: [Intel-gfx] i915: crash with 5.19-rc2
Hi Zdenek, On Wed, Jun 22, 2022 at 01:18:42PM +0200, Zdenek Kabelac wrote: > Hello > > While somewhat oldish hw (T61, 4G, C2D) - I've now witnessed new crash with > Xorg: > > (happened while reopening iconified Firefox window - running 'standard' > rawhide -nodebug kernel 5.19.0-0.rc2.21.fc37.x86_64) any bisect possible? if possible, could you please file a bug? https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs I know I know, the account requirement :/ also on main kernel bugzilla is probably better than the email here. Thanks, Rodrigo > > page:577758b3 refcount:0 mapcount:0 mapping: > index:0x1 pfn:0x1192cc > flags: 0x17c000(node=0|zone=2|lastcpupid=0x1f) > raw: 0017c000 e683c47171c8 8fa3f79377a8 > raw: 0001 > page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio)) > [ cut here ] > kernel BUG at mm/shmem.c:708! > invalid opcode: [#1] PREEMPT SMP NOPTI > CPU: 1 PID: 42896 Comm: Xorg Not tainted 5.19.0-0.rc2.21.fc37.x86_64 #1 > Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011 > RIP: 0010:shmem_add_to_page_cache+0x48e/0x500 > Code: 01 0f 84 0a fc ff ff 48 8d 4a ff 31 d2 48 39 cb 0f 85 ff fb ff ff e9 > f6 fb ff ff 48 c7 c6 70 01 64 bb 48 89 df e8 f2 99 01 00 <0f> 0b 48 c7 c6 a0 > 1b 64 bb 48 89 df e8 e1 99 01 00 0f 0b 48 8b 13 > RSP: 0018:9ce7c047f6b0 EFLAGS: 00010286 > RAX: 003f RBX: e683c464b300 RCX: > RDX: 0001 RSI: bb67b8e8 RDI: > RBP: 00023f97 R08: bca122a0 R09: 64656b636f6c5f74 > R10: 747365745f6f696c R11: 6f6621284f494c4f R12: 001120d4 > R13: 8fa2c6ae7890 R14: e683c464b300 R15: 0001 > FS: 7fc1cea31380() GS:8fa3f790() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f6972e228c8 CR3: 000104ba8000 CR4: 06e0 > Call Trace: > > shmem_swapin_folio+0x274/0x980 > shmem_getpage_gfp+0x234/0x990 > shmem_read_mapping_page_gfp+0x36/0xf0 > shmem_sg_alloc_table+0x11b/0x250 [i915] > shmem_get_pages+0xaa/0x310 [i915] > __i915_gem_object_get_pages+0x31/0x40 [i915] > i915_vma_pin_ww+0x69d/0x920 [i915] > eb_validate_vmas+0x17d/0x7a0 [i915] > ? eb_pin_engine+0x262/0x2d0 [i915] > i915_gem_do_execbuffer+0xd43/0x2c00 [i915] > ? refill_obj_stock+0x102/0x1a0 > ? unix_stream_read_generic+0x1ea/0xa60 > ? unix_stream_read_generic+0x1ea/0xa60 > ? _raw_spin_lock_irqsave+0x23/0x50 > ? _atomic_dec_and_lock_irqsave+0x38/0x60 > ? __active_retire+0xb7/0x100 [i915] > ? _raw_spin_unlock_irqrestore+0x23/0x40 > ? dma_fence_signal+0x39/0x50 > ? dma_resv_iter_walk_unlocked.part.0+0x164/0x170 > i915_gem_execbuffer2_ioctl+0x115/0x270 [i915] > ? i915_gem_do_execbuffer+0x2c00/0x2c00 [i915] > drm_ioctl_kernel+0x9b/0x140 > ? __check_object_size+0x47/0x260 > drm_ioctl+0x21c/0x410 > ? i915_gem_do_execbuffer+0x2c00/0x2c00 [i915] > ? exit_to_user_mode_prepare+0x17d/0x1f0 > __x64_sys_ioctl+0x8a/0xc0 > do_syscall_64+0x58/0x80 > ? syscall_exit_to_user_mode+0x17/0x40 > ? do_syscall_64+0x67/0x80 > entry_SYSCALL_64_after_hwframe+0x46/0xb0 > RIP: 0033:0x7fc1cf28da9f > Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 > 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff > ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 > RSP: 002b:7ffe5f52e1c0 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7ffe5f52e250 RCX: 7fc1cf28da9f > RDX: 7ffe5f52e250 RSI: 40406469 RDI: 000d > RBP: 000d R08: 7fc1ce938410 R09: 7fc1cf2fa4c0 > R10: R11: 0246 R12: 55e2dde0d340 > R13: 0114 R14: 7ffe5f52e250 R15: 7fc1cdc49000 > > Modules linked in: tls rfcomm snd_seq_dummy snd_hrtimer xt_CHECKSUM > xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 ip6table_mangle > ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat > nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables bridge > stp llc bnep binfmt_misc btusb btrtl btbcm btintel btmtk bluetooth > ecdh_generic snd_hda_codec_analog snd_hda_codec_generic iwl3945 iwlegacy > coretemp kvm_intel mac80211 snd_hda_intel snd_intel_dspcfg > snd_intel_sdw_acpi libarc4 kvm iTCO_wdt snd_hda_codec intel_pmc_bxt > iTCO_vendor_support snd_hda_core snd_hwdep snd_seq snd_seq_device cfg80211 > irqbypass snd_pcm thinkpad_acpi pcspkr joydev i2c_i801 snd_timer i2c_smbus > ledtrig_audio wmi_bmof r592 platform_profile snd memstick rfkill lpc_ich > soundcore acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse zram > i915 sdhci_pci cqhci sdhci drm_buddy drm_display_helper e1000e mmc_core cec > serio_raw yenta_socket ttm wmi video ata_generic pata_acpi > scsi_dh_rda
Re: [Intel-gfx] [PATCH 04/11] drm/i915: Added is_intel_rpm_allowed helper
On Wed, Jun 22, 2022 at 03:55:03PM +0300, Jani Nikula wrote:
> On Tue, 21 Jun 2022, "Tangudu, Tilak" wrote:
> >> -Original Message-
> >> From: Gupta, Anshuman
> >> Sent: Tuesday, June 21, 2022 7:47 PM
> >> To: Tangudu, Tilak ;
> >> intel-gfx@lists.freedesktop.org;
> >> Ewins, Jon ; Vivi, Rodrigo ;
> >> Belgaumkar, Vinay ; Wilson, Chris P
> >> ; Dixit, Ashutosh ;
> >> Nilawar, Badal ; Roper, Matthew D
> >> ; Gupta, saurabhg
> >> ; Iddamsetty, Aravind
> >> ; Sundaresan, Sujaritha
> >>
> >> Subject: RE: [PATCH 04/11] drm/i915: Added is_intel_rpm_allowed helper
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: Tangudu, Tilak
> >> > Sent: Tuesday, June 21, 2022 6:05 PM
> >> > To: intel-gfx@lists.freedesktop.org; Ewins, Jon ;
> >> > Vivi, Rodrigo ; Belgaumkar, Vinay
> >> > ; Wilson, Chris P
> >> > ; Dixit, Ashutosh
> >> > ; Nilawar, Badal ;
> >> > Gupta, Anshuman ; Tangudu, Tilak
> >> > ; Roper, Matthew D
> >> > ; Gupta, saurabhg
> >> > ; Iddamsetty, Aravind
> >> > ; Sundaresan, Sujaritha
> >> >
> >> > Subject: [PATCH 04/11] drm/i915: Added is_intel_rpm_allowed helper
> >> >
> >> > Added is_intel_rpm_allowed function to query the runtime_pm status and
> >> > disllow during suspending and resuming.
> >> This seems a hack,
> >> Not sure if we have better way to handle it.
> >> May be check this in intel_pm_runtime_{get,put} to keep entire code simple
> >> ?
> > Yes, that would be simple without code refactoring.
> > Checked the same with Chris, he suggested unbalancing of wakeref might popup
> > If used at intel_pm_runtime_{get,put} . So used like this,
> > @Wilson, Chris P , Please comment .
> > @Vivi, Rodrigo , Any suggestion ?
>
> One option would be to track this in intel_wakeref_t, i.e. _get flags
> the case in the returned wakeref and _put skips in that case.
yeap, this seems to be the quick path at this moment...
Imre, do you see any other quick option?
In general I don't like much the big wakeref infra we end up
creating here because all of the historical unbalanced cases we got.
We should be able to get something cleaner and use the rpm infra as
other drivers are using, or improve in the rpm side itself whatever
we feel that we are missing to deal with these cases.
But back to this specific case/usage here we might need to duplicate
some functions to be called just from the inside the resuming/suspending
path... and/or moving the gets & puts upper on the stack...
The quick hacks will solve our short term problems and continue bloating
our rpm infra.
>
> BR,
> Jani.
>
>
> >
> >> >
> >> > Signed-off-by: Tilak Tangudu
> >> > ---
> >> > drivers/gpu/drm/i915/intel_runtime_pm.c | 15 +++
> >> > drivers/gpu/drm/i915/intel_runtime_pm.h | 1 +
> >> > 2 files changed, 16 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> > index 6ed5786bcd29..3759a8596084 100644
> >> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >> > @@ -320,6 +320,21 @@ untrack_all_intel_runtime_pm_wakerefs(struct
> >> > intel_runtime_pm *rpm) }
> >> >
> >> > #endif
> >> > +static int intel_runtime_pm_status(struct intel_runtime_pm *rpm) {
> >> > +return rpm->kdev->power.runtime_status; }
> >> This is racy in principal, we need a kdev->power lock here.
> >> Regards,
> >> Anshuman Gupta.
> >> > +
> >> > +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm) { int
> >> > +rpm_status;
> >> > +
> >> > +rpm_status = intel_runtime_pm_status(rpm); if (rpm_status ==
> >> > +RPM_RESUMING || rpm_status ==
> >> > RPM_SUSPENDING)
> >> > +return false;
> >> > +else
> >> > +return true;
> >> > +}
> >> >
> >> > static void
> >> > intel_runtime_pm_acquire(struct intel_runtime_pm *rpm, bool wakelock)
> >> > diff -- git a/drivers/gpu/drm/i915/intel_runtime_pm.h
> >> > b/drivers/gpu/drm/i915/intel_runtime_pm.h
> >> > index d9160e3ff4af..99418c3a934a 100644
> >> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.h
> >> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
> >> > @@ -173,6 +173,7 @@ void intel_runtime_pm_init_early(struct
> >> > intel_runtime_pm *rpm); void intel_runtime_pm_enable(struct
> >> > intel_runtime_pm *rpm); void intel_runtime_pm_disable(struct
> >> > intel_runtime_pm *rpm); void intel_runtime_pm_driver_release(struct
> >> > intel_runtime_pm *rpm);
> >> > +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm);
> >> >
> >> > intel_wakeref_t intel_runtime_pm_get(struct intel_runtime_pm *rpm);
> >> > intel_wakeref_t intel_runtime_pm_get_if_in_use(struct intel_runtime_pm
> >> > *rpm);
> >> > --
> >> > 2.25.1
> >>
> >
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: i915_irq - drop unexpected word "the" in the comments
== Series Details == Series: drm/i915: i915_irq - drop unexpected word "the" in the comments URL : https://patchwork.freedesktop.org/series/105477/ State : warning == Summary == Error: dim checkpatch failed d92af542e2e9 drm/i915: i915_irq - drop unexpected word "the" in the comments -:11: WARNING:REPEATED_WORD: Possible repeated word: 'the' #11: * interrupt originated from the the GPU so interrupts from a device which total: 0 errors, 1 warnings, 0 checks, 8 lines checked
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Add a new SLPC selftest
On Fri, 10 Jun 2022 16:47:12 -0700, Vinay Belgaumkar wrote:
>
> This test will validate we can achieve actual frequency of RP0. Pcode
> grants frequencies based on what GuC is requesting. However, thermal
> throttling can limit what is being granted. Add a test to request for
> max, but don't fail the test if RP0 is not granted due to throttle
> reasons.
>
> Also optimize the selftest by using a common run_test function to avoid
> code duplication.
The refactoring does change the order of operations (changing the freq vs
spawning the spinner) but should be fine I think.
> Rename the "clamp" tests to vary_max_freq and vary_min_freq.
Either is ok, but maybe "clamp" names were ok I think since they verify req
freq is clamped at min/max.
>
> v2: Fix compile warning
>
> Fixes 8ee2c227822e ("drm/i915/guc/slpc: Add SLPC selftest")
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/gt/selftest_slpc.c | 323
> 1 file changed, 158 insertions(+), 165 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c
> b/drivers/gpu/drm/i915/gt/selftest_slpc.c
> index b768cea5943d..099129aae9a5 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
> @@ -8,6 +8,11 @@
> #define delay_for_h2g() usleep_range(H2G_DELAY, H2G_DELAY + 1)
> #define FREQUENCY_REQ_UNIT DIV_ROUND_CLOSEST(GT_FREQUENCY_MULTIPLIER, \
> GEN9_FREQ_SCALER)
> +enum test_type {
> + VARY_MIN,
> + VARY_MAX,
> + MAX_GRANTED
> +};
>
> static int slpc_set_min_freq(struct intel_guc_slpc *slpc, u32 freq)
> {
> @@ -36,147 +41,120 @@ static int slpc_set_max_freq(struct intel_guc_slpc
> *slpc, u32 freq)
> return ret;
> }
>
> -static int live_slpc_clamp_min(void *arg)
> +static int vary_max_freq(struct intel_guc_slpc *slpc, struct intel_rps *rps,
> + u32 *max_act_freq)
Please run checkpatch, indentation seems off.
> {
> - struct drm_i915_private *i915 = arg;
> - struct intel_gt *gt = to_gt(i915);
> - struct intel_guc_slpc *slpc = >->uc.guc.slpc;
> - struct intel_rps *rps = >->rps;
> - struct intel_engine_cs *engine;
> - enum intel_engine_id id;
> - struct igt_spinner spin;
> + u32 step, max_freq, req_freq;
> + u32 act_freq;
> u32 slpc_min_freq, slpc_max_freq;
> int err = 0;
>
> - if (!intel_uc_uses_guc_slpc(>->uc))
> - return 0;
> -
> - if (igt_spinner_init(&spin, gt))
> - return -ENOMEM;
> + slpc_min_freq = slpc->min_freq;
> + slpc_max_freq = slpc->rp0_freq;
nit but we don't really need such variables since we don't change their
values, we should just use slpc->min_freq, slpc->rp0_freq directly. I'd
change this in all places in this patch.
>
> - if (intel_guc_slpc_get_max_freq(slpc, &slpc_max_freq)) {
> - pr_err("Could not get SLPC max freq\n");
> - return -EIO;
> - }
> -
> - if (intel_guc_slpc_get_min_freq(slpc, &slpc_min_freq)) {
> - pr_err("Could not get SLPC min freq\n");
> - return -EIO;
Why do we need these two function calls? Can't we just use slpc->rp0_freq
and slpc->min_freq as we are doing in the vary_min/max_freq() functions
above?
Also, as mentioned below I think here we should just do:
slpc_set_max_freq(slpc, slpc->rp0_freq);
slpc_set_min_freq(slpc, slpc->min_freq);
to restore freq to a known state before starting the test (just in case a
previous test changed the values).
> - }
> -
> - if (slpc_min_freq == slpc_max_freq) {
> - pr_err("Min/Max are fused to the same value\n");
> - return -EINVAL;
What if they are actually equal? I think basically the max/min freq test
loops will just not be entered (so effectively the tests will just
skip). The granted freq test will be fine. So I think we can just delete
this if statement?
(It is showing deleted above in the patch but is in the new code somewhere
too).
> - }
> -
> - intel_gt_pm_wait_for_idle(gt);
> - intel_gt_pm_get(gt);
> - for_each_engine(engine, gt, id) {
> - struct i915_request *rq;
> - u32 step, min_freq, req_freq;
> - u32 act_freq, max_act_freq;
> -
> - if (!intel_engine_can_store_dword(engine))
> - continue;
> + /* Go from max to min in 5 steps */
> + step = (slpc_max_freq - slpc_min_freq) / NUM_STEPS;
> + *max_act_freq = slpc_min_freq;
> + for (max_freq = slpc_max_freq; max_freq > slpc_min_freq;
> + max_freq -= step) {
> + err = slpc_set_max_freq(slpc, max_freq);
> + if (err)
> + break;
>
> - /* Go from min to max in 5 steps */
> - step = (slpc_max_freq - slpc_min_freq) / NUM_STEPS;
> - max_act_freq = slpc_min_freq;
> - for (min_freq = slpc_min_freq; min_freq < slpc_max_freq;
> -
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Use non-blocking H2G for waitboost
On 6/21/2022 5:26 PM, Dixit, Ashutosh wrote:
On Sat, 14 May 2022 23:05:06 -0700, Vinay Belgaumkar wrote:
SLPC min/max frequency updates require H2G calls. We are seeing
timeouts when GuC channel is backed up and it is unable to respond
in a timely fashion causing warnings and affecting CI.
This is seen when waitboosting happens during a stress test.
this patch updates the waitboost path to use a non-blocking
H2G call instead, which returns as soon as the message is
successfully transmitted.
Overall I am ok moving waitboost to use the non-blocking H2G. We can
consider increasing the timeout in wait_for_ct_request_update() to be a
separate issue for blocking cases and we can handle that separately.
Still there a couple of issues with this patch mentioned below.
v2: Use drm_notice to report any errors that might occur while
sending the waitboost H2G request (Tvrtko)
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 44 +
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 1db833da42df..e5e869c96262 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -98,6 +98,30 @@ static u32 slpc_get_state(struct intel_guc_slpc *slpc)
return data->header.global_state;
}
+static int guc_action_slpc_set_param_nb(struct intel_guc *guc, u8 id, u32
value)
+{
+ u32 request[] = {
+ GUC_ACTION_HOST2GUC_PC_SLPC_REQUEST,
+ SLPC_EVENT(SLPC_EVENT_PARAMETER_SET, 2),
+ id,
+ value,
+ };
+ int ret;
+
+ ret = intel_guc_send_nb(guc, request, ARRAY_SIZE(request), 0);
+
+ return ret > 0 ? -EPROTO : ret;
+}
+
+static int slpc_set_param_nb(struct intel_guc_slpc *slpc, u8 id, u32 value)
+{
+ struct intel_guc *guc = slpc_to_guc(slpc);
+
+ GEM_BUG_ON(id >= SLPC_MAX_PARAM);
+
+ return guc_action_slpc_set_param_nb(guc, id, value);
+}
+
static int guc_action_slpc_set_param(struct intel_guc *guc, u8 id, u32 value)
{
u32 request[] = {
@@ -208,12 +232,10 @@ static int slpc_force_min_freq(struct intel_guc_slpc
*slpc, u32 freq)
*/
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
- ret = slpc_set_param(slpc,
-SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
-freq);
- if (ret)
- i915_probe_error(i915, "Unable to force min freq to %u:
%d",
-freq, ret);
+ /* Non-blocking request will avoid stalls */
+ ret = slpc_set_param_nb(slpc,
+
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+ freq);
}
return ret;
@@ -222,6 +244,8 @@ static int slpc_force_min_freq(struct intel_guc_slpc *slpc,
u32 freq)
static void slpc_boost_work(struct work_struct *work)
{
struct intel_guc_slpc *slpc = container_of(work, typeof(*slpc),
boost_work);
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
+ int err;
/*
* Raise min freq to boost. It's possible that
@@ -231,8 +255,12 @@ static void slpc_boost_work(struct work_struct *work)
*/
mutex_lock(&slpc->lock);
if (atomic_read(&slpc->num_waiters)) {
- slpc_force_min_freq(slpc, slpc->boost_freq);
- slpc->num_boosts++;
+ err = slpc_force_min_freq(slpc, slpc->boost_freq);
+ if (!err)
+ slpc->num_boosts++;
+ else
+ drm_notice(&i915->drm, "Failed to send waitboost request
(%d)\n",
+ err);
The issue I have is what happens when we de-boost (restore min freq to its
previous value in intel_guc_slpc_dec_waiters()). It would seem that that
call is fairly important to get the min freq down when there are no pending
requests. Therefore what do we do in that case?
This is the function:
void intel_guc_slpc_dec_waiters(struct intel_guc_slpc *slpc)
{
mutex_lock(&slpc->lock);
if (atomic_dec_and_test(&slpc->num_waiters))
slpc_force_min_freq(slpc, slpc->min_freq_softlimit);
mutex_unlock(&slpc->lock);
}
1. First it would seem that at the minimum we need a similar drm_notice()
in intel_guc_slpc_dec_waiters(). That would mean we need to put the
drm_notice() back in slpc_force_min_freq() (replacing
i915_probe_error()) rather than in slpc_boost_work() above?
Sure.
2. Further, if de-boosting is important then maybe as was being discussed
in v1 of this patch (see the bottom of
https://patchwork.freedesktop.org/patch/485004/?series=103598&rev=1) do
we need to use intel_guc_send_busy_loop() in the
intel_guc_slpc_dec_waiters() code
[Intel-gfx] ✗ Fi.CI.BAT: failure for small BAR uapi bits (rev3)
== Series Details == Series: small BAR uapi bits (rev3) URL : https://patchwork.freedesktop.org/series/104369/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11794 -> Patchwork_104369v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104369v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104369v3, 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_104369v3/index.html Participating hosts (42 -> 42) -- Additional (3): fi-bxt-dsi bat-dg2-9 bat-adlp-4 Missing(3): fi-cml-u2 fi-rkl-11600 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104369v3: ### IGT changes ### Possible regressions * igt@i915_selftest@live@mman: - bat-dg1-5: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-5/igt@i915_selftest@l...@mman.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-dg1-5/igt@i915_selftest@l...@mman.html - bat-dg1-6: NOTRUN -> [DMESG-FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-dg1-6/igt@i915_selftest@l...@mman.html Known issues Here are the changes found in Patchwork_104369v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html - fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_blits@basic: - fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271]) +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-adlp-4: NOTRUN -> [SKIP][8] ([i915#3282]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-adlp-4/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live@hangcheck: - fi-hsw-g3258: [PASS][9] -> [INCOMPLETE][10] ([i915#3303] / [i915#4785]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html - bat-dg1-6: NOTRUN -> [DMESG-FAIL][11] ([i915#4494] / [i915#4957]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-dg1-6: NOTRUN -> [INCOMPLETE][12] ([i915#6011]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - bat-adlp-4: NOTRUN -> [SKIP][13] ([i915#5903]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-adlp-4/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@dp-crc-fast: - bat-adlp-4: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-bxt-dsi: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-rkl-guc: NOTRUN -> [SKIP][16] ([i915#4103]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/fi-rkl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-skl-guc: NOTRUN -> [SKIP][17] ([fdo#109271]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-kbl-soraka: NOTRUN -> [SKIP][18] ([fdo#109271]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104369v3/f
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for small BAR uapi bits (rev3)
== Series Details == Series: small BAR uapi bits (rev3) URL : https://patchwork.freedesktop.org/series/104369/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for small BAR uapi bits (rev3)
== Series Details == Series: small BAR uapi bits (rev3) URL : https://patchwork.freedesktop.org/series/104369/ State : warning == Summary == Error: dim checkpatch failed 1f41c0228c1d drm/doc: add rfc section for small BAR uapi -:46: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #46: new file mode 100644 -:51: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #51: FILE: Documentation/gpu/rfc/i915_small_bar.h:1: +/** -:246: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #246: FILE: Documentation/gpu/rfc/i915_small_bar.rst:1: +== total: 0 errors, 3 warnings, 0 checks, 243 lines checked 5f7da6952e10 drm/i915/uapi: add probed_cpu_visible_size 5e5b302e3bf8 drm/i915/uapi: expose the avail tracking -:114: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #114: FILE: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c:373: +void i915_ttm_buddy_man_avail(struct ttm_resource_manager *man, +u64 *avail, u64 *visible_avail) total: 0 errors, 0 warnings, 1 checks, 162 lines checked c7111ae11afa drm/i915: remove intel_memory_region avail d2e415d29035 drm/i915/uapi: apply ALLOC_GPU_ONLY by default effd9dff6f8f drm/i915/uapi: add NEEDS_CPU_ACCESS hint -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: (i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the total: 0 errors, 1 warnings, 0 checks, 142 lines checked 58e91a5ec753 drm/i915/error: skip non-mappable pages 936cb7407d7f drm/i915/uapi: tweak error capture on recoverable contexts 42ab24c9888a drm/i915/selftests: ensure we reserve a fence slot 161954553290 drm/i915/ttm: handle blitter failure on DG2 7767d2136a46 drm/i915: turn on small BAR support 73361b71675e HAX: force small BAR on dg2
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: ADL-N should use the same GuC FW as ADL-S
== Series Details ==
Series: drm/i915/guc: ADL-N should use the same GuC FW as ADL-S
URL : https://patchwork.freedesktop.org/series/105444/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11794 -> Patchwork_105444v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_105444v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_105444v1, 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_105444v1/index.html
Participating hosts (42 -> 40)
--
Missing(2): fi-cml-u2 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_105444v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@vma:
- fi-bdw-5557u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-bdw-5557u/igt@i915_selftest@l...@vma.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/fi-bdw-5557u/igt@i915_selftest@l...@vma.html
Known issues
Here are the changes found in Patchwork_105444v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][3] -> [INCOMPLETE][4] ([i915#4418])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][5] -> [INCOMPLETE][6] ([i915#3303] /
[i915#4785])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][9] ([i915#6011])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/bat-dg1-6/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][10] ([fdo#109295] / [i915#3301])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][11] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [INCOMPLETE][12] ([i915#4418]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy:
- fi-kbl-soraka: [INCOMPLETE][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/fi-kbl-soraka/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html
*
{igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size}:
- fi-bsw-kefka: [FAIL][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][18] ([i915#3576]) -> [PASS][19] +1
similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11794/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105444v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https:/
[Intel-gfx] [PULL] drm-intel-next
Hi Dave and Daniel, Here goes the first pull request targeting 5.20. Kudos to Jani and Ville for a good driver clean-up. And many other fixes and improvements from the team. drm-intel-next-2022-06-22: - General driver clean-up (Jani, Ville, Julia) - DG2 enabling (Anusha, Vandita) - Fix sparse warnings (Imre, Jani) - DMC MMIO range checks (Anusha) - Audio related fixes (Jani) - Runtime PM fixes (Anshuman) - PSR fixes (Jouni, Jose) - Media freq factor and per-gt enhancements (Ashutosh, Dale) - DSI fixes for ICL+ (Jani) - Disable DMC flip queue handlers (Imre) - ADL_P voltage swing updates (Balasubramani) - Use more the VBT for panel information (Ville, Animesh) - Fix on Type-C ports with TBT mode (Vivek) - Improve fastset and allow seamless M/N changes (Ville) - Accept more fixed modes with VRR/DMRRS panels (Ville) - FBC fix (Jose) - Remove noise logs (Luca) - Disable connector polling for a headless SKU (Jouni) - Sanitize display underrun reporting (Ville) - ADL-S display PLL w/a (Ville) Thanks, Rodrigo. The following changes since commit 949665a6e237a6fd49ff207e3876d71b20b7e9f2: drm/i915: Respect VBT seamless DRRS min refresh rate (2022-05-05 18:27:53 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2022-06-22 for you to fetch changes up to 6434cf630086eea2d091f122f5802582a05d9d1c: drm/i915/bios: calculate panel type as per child device index in VBT (2022-06-20 19:56:06 +0300) - General driver clean-up (Jani, Ville, Julia) - DG2 enabling (Anusha, Vandita) - Fix sparse warnings (Imre, Jani) - DMC MMIO range checks (Anusha) - Audio related fixes (Jani) - Runtime PM fixes (Anshuman) - PSR fixes (Jouni, Jose) - Media freq factor and per-gt enhancements (Ashutosh, Dale) - DSI fixes for ICL+ (Jani) - Disable DMC flip queue handlers (Imre) - ADL_P voltage swing updates (Balasubramani) - Use more the VBT for panel information (Ville, Animesh) - Fix on Type-C ports with TBT mode (Vivek) - Improve fastset and allow seamless M/N changes (Ville) - Accept more fixed modes with VRR/DMRRS panels (Ville) - FBC fix (Jose) - Remove noise logs (Luca) - Disable connector polling for a headless SKU (Jouni) - Sanitize display underrun reporting (Ville) - ADL-S display PLL w/a (Ville) Animesh Manna (1): drm/i915/bios: calculate panel type as per child device index in VBT Anshuman Gupta (1): drm/i915: Use drm_dbg for rpm logging Anusha Srivatsa (2): drm/i915/dmc: Load DMC on DG2 drm/i915/dmc: Add MMIO range restrictions Ashutosh Dixit (2): drm/i915: Introduce has_media_ratio_mode drm/i915/pcode: Extend pcode functions for multiple gt's Balasubramani Vivekanandan (2): drm/i915/display/adl_p: Updates to HDMI combo PHY voltage swing table drm/i915/display/adlp: More updates to voltage swing table Dale B Stimson (1): drm/i915/pcode: Add a couple of pcode helpers Imre Deak (2): drm/i915: Fix 'mixing different enum types' warnings in intel_display_power.c drm/i915/d12+: Disable DMC firmware flip queue handlers Jani Nikula (26): drm/i915: remove unused GEM_DEBUG_DECL() and GEM_DEBUG_BUG_ON() drm/i915: remove single-use GEM_DEBUG_EXEC() drm/i915/audio: fix audio code enable/disable pipe logging drm/i915/reg: fix undefined behavior due to shift overflowing the constant drm/i915/dsi: fix VBT send packet port selection for ICL+ drm/i915/display: stop using BUG() drm/i915/regs: split out intel audio register definitions drm/i915/tasklet: separate local hacks around struct tasklet_struct drm/i915/drv: drop intel_bios.h include drm/i915/utils: throw out unused stuff drm/i915/pxp: fix sparse warning for not declared symbol drm/i915/overlay: remove redundant GEM_BUG_ON() drm/i915/bios: use dvi and hdmi support helpers drm/i915/bios: no need to pass i915 to parse_ddi_port() drm/i915/bios: split ddi port parsing and debug printing drm/i915/wm: move wm state verification to intel_pm.c drm/i915/dpll: move shared dpll state verification to intel_dpll_mgr.c drm/i915/mpllb: use I915_STATE_WARN() for state mismatch warnings drm/i915/mpllb: move mpllb state check to intel_snps_phy.c drm/i915/display: split out modeset verification code drm/i915/display: split out crtc state dump to a separate file drm/i915/display: change who adds [] around crtc state dump context string drm/i915/display: rename dev_priv -> i915 in crtc state dump drm/i915/display: some struct drm_i915_private *i915 conversions drm/i915/display: split out hw state readout and sanitize drm/i915/display: convert modeset setup to struct drm_i915_private *i915 Jason A. Donenfeld (1): drm/i915/display: Re-add check for low voltage sku for max dp source
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/doc/rfc: i915 VM_BIND feature design + uapi
== Series Details == Series: drm/doc/rfc: i915 VM_BIND feature design + uapi URL : https://patchwork.freedesktop.org/series/105452/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_driver.o In file included from ./drivers/gpu/drm/i915/i915_pmu.h:13, from ./drivers/gpu/drm/i915/gt/intel_engine_types.h:21, from ./drivers/gpu/drm/i915/gt/intel_context_types.h:18, from ./drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20, from ./drivers/gpu/drm/i915/i915_request.h:34, from ./drivers/gpu/drm/i915/i915_active.h:13, from ./drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h:12, from ./drivers/gpu/drm/i915/i915_vma.h:33, from drivers/gpu/drm/i915/display/intel_display_types.h:49, from drivers/gpu/drm/i915/i915_driver.c:52: ./include/uapi/drm/i915_drm.h:1934:2: error: "/*" within comment [-Werror=comment] /** @param: Parameter to set or query */ cc1: all warnings being treated as errors scripts/Makefile.build:249: recipe for target 'drivers/gpu/drm/i915/i915_driver.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_driver.o] Error 1 scripts/Makefile.build:466: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:466: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:466: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1843: recipe for target 'drivers' failed make: *** [drivers] Error 2
Re: [Intel-gfx] [PATCH] drm/i915: Eliminate PIPECONF RMWs from .color_commit()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Thursday, April 14, 2022 12:56 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915: Eliminate PIPECONF RMWs from
> .color_commit()
>
> From: Ville Syrjälä
>
> Eliminate the PIPECONF RMWs from .comit_commit() so that we can finally
> declare
> the whole vblank evade part (and the noarm() part) of the pipe commit free of
> register reads. Or at least I hope that's the last read...
>
> Only the i9xx/ilk codepaths need this for now, but let's add the same thing
> for hsw+
> just in case we want to start calling that during fastsets at some point (eg.
> to change
> dithering settings/etc.).
>
> Should open up the way to start experimenting with different DSB usage
> approaches
> for pipe commits.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 21 --
> drivers/gpu/drm/i915/display/intel_display.c | 30 ++--
> drivers/gpu/drm/i915/display/intel_display.h | 2 ++
> 3 files changed, 29 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 34128c9c635c..60532dd0f9f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -505,30 +505,19 @@ static void ilk_color_commit_noarm(const struct
> intel_crtc_state *crtc_state)
>
> static void i9xx_color_commit_arm(const struct intel_crtc_state *crtc_state)
> {
> - struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe;
> - u32 val;
> -
> - val = intel_de_read(dev_priv, PIPECONF(pipe));
> - val &= ~PIPECONF_GAMMA_MODE_MASK_I9XX;
> - val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> - intel_de_write(dev_priv, PIPECONF(pipe), val);
> + /* update PIPECONF GAMMA_MODE */
> + i9xx_set_pipeconf(crtc_state);
> }
>
> static void ilk_color_commit_arm(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe;
> - u32 val;
>
> - val = intel_de_read(dev_priv, PIPECONF(pipe));
> - val &= ~PIPECONF_GAMMA_MODE_MASK_ILK;
> - val |= PIPECONF_GAMMA_MODE(crtc_state->gamma_mode);
> - intel_de_write(dev_priv, PIPECONF(pipe), val);
> + /* update PIPECONF GAMMA_MODE */
> + ilk_set_pipeconf(crtc_state);
>
> - intel_de_write_fw(dev_priv, PIPE_CSC_MODE(pipe),
> + intel_de_write_fw(dev_priv, PIPE_CSC_MODE(crtc->pipe),
> crtc_state->csc_mode);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 29044cf58b87..aa2814332ad9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -122,8 +122,6 @@
>
> static void intel_set_transcoder_timings(const struct intel_crtc_state
> *crtc_state);
> static void intel_set_pipe_src_size(const struct intel_crtc_state
> *crtc_state); -static
> void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state); -static
> void
> ilk_set_pipeconf(const struct intel_crtc_state *crtc_state); static void
> hsw_set_transconf(const struct intel_crtc_state *crtc_state); static void
> bdw_set_pipemisc(const struct intel_crtc_state *crtc_state); static void
> ilk_pfit_enable(const struct intel_crtc_state *crtc_state); @@ -3205,14
> +3203,18
> @@ static void intel_get_pipe_src_size(struct intel_crtc *crtc,
> intel_bigjoiner_adjust_pipe_src(pipe_config);
> }
>
> -static void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state)
> +void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> u32 pipeconf = 0;
>
> - /* we keep both pipes enabled on 830 */
> - if (IS_I830(dev_priv))
> + /*
> + * - We keep both pipes enabled on 830
> + * - During modeset the pipe is still disabled and must remain so
> + * - During fastset the pipe is already enabled and must remain so
> + */
> + if (IS_I830(dev_priv) || !intel_crtc_needs_modeset(crtc_state))
> pipeconf |= PIPECONF_ENABLE;
>
> if (crtc_state->double_wide)
> @@ -3524,14 +3526,19 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> *crtc,
> return ret;
> }
>
> -static void ilk_set_pipeconf(const struct intel_crtc_state *crtc_state)
> +void ilk_set_pipeconf(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_pr
Re: [Intel-gfx] [PATCH v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Wed, Jun 22, 2022 at 09:44:47AM -0700, Niranjana Vishwanathapura wrote:
On Wed, Jun 22, 2022 at 04:57:17PM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 16:12, Niranjana Vishwanathapura wrote:
On Wed, Jun 22, 2022 at 09:10:07AM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 04:56, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VALID
and I915_GEM_VM_BIND_TLB_FLUSH flags.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 243 +++
1 file changed, 243 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..fa23b2d7ec6f
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,243 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will
not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+
+/**
+ * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
notification.
+ *
+ * A timeline out fence for vm_bind/unbind completion notification.
+ */
+struct drm_i915_gem_vm_bind_fence {
+ /** @handle: User's handle for a drm_syncobj to signal. */
+ __u32 handle;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /**
+ * @value: A point in the timeline.
+ * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+ * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+ * binary one.
+ */
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies
the mapping of GPU
+ * virtual address (VA) range to the section of an object
that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently
bound) and can
+ * be mapped to whole object or a section of the object
(partial binding).
+ * Multiple VA mappings can be created to the same section of
the object
+ * (aliasing).
+ *
+ * The @start, @offset and @length should be 4K page aligned.
However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and
has compact page
+ * table. On those platforms, for binding device local-memory
objects, the
+ * @start should be 2M aligned, @offset and @length should be
64K aligned.
Should some error codes be documented and has the ability to
programmatically probe the alignment restrictions been
considered?
Currently what we have internally is that -EINVAL is returned if
the sart, offset
and length are not aligned. If the specified mapping already
exits, we return
-EEXIST. If there are conflicts in the VA range and VA range can't
be reserved,
then -ENOSPC is returned. I can add this documentation here. But I
am worried
that there will be more suggestions/feedback about error codes
while reviewing
the code patch series, and we have to revisit it again.
I'd still suggest documenting those three. It makes sense to explain
to userspace what behaviour they will see if they get it wrong.
Ok.
I have posted v4 with the fixes. I have simplified the error code a
bit by removing EEXIST which is just a special case of ENOSPC.
Niranjana
+ * Also, on those platforms, it is not allowed to bind an
device local-memory
+ * object and a system memory object in a single 2M section
of VA range.
Text should be clear whether "not allowed" means there will be
an error returned, or it will appear to work but bad things will
happen.
Yah, error returned, will fix.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @
[Intel-gfx] [PATCH v3 3/3] drm/doc/rfc: VM_BIND uapi definition
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VALID
and I915_GEM_VM_BIND_TLB_FLUSH flags.
v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
documentation for vm_bind/unbind.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 252 +++
1 file changed, 252 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..7248791a4513
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,252 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+
+/**
+ * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion notification.
+ *
+ * A timeline out fence for vm_bind/unbind completion notification.
+ */
+struct drm_i915_gem_vm_bind_fence {
+ /** @handle: User's handle for a drm_syncobj to signal. */
+ __u32 handle;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /**
+* @value: A point in the timeline.
+* Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+* timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+* binary one.
+*/
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @start, @offset and @length should be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, error -ENOSPC will be returned if user tries to
+ * bind a device local-memory object and a system memory object in a single 2M
+ * section of VA range.
+ *
+ * Error code -EINVAL will be returned if @start, @offset and @length are not
+ * properly aligned. Error code of -ENOSPC will be returned if the VA range
+ * specified can't be reserved.
+ *
+ * The bind operation can get completed asynchronously and out of submission
+ * order. When I915_GEM_VM_BIND_FENCE_VALID flag is set, the @fence will be
+ * signaled upon completion of bind operation.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 length;
+
+ /**
+* @flags: Supported flags are:
+*
+* I915_GEM_VM_BIND_FENCE_VALID:
+* @fence is valid, needs bind completion notification.
+*
+* I915_GEM_VM_BIND_READONLY:
+* Mapping is read-only.
+*
+* I915_GEM_VM_BIND_CAPTURE:
+* Capture this mapping in the dump upon GPU error.
+*/
+ __u64 flags;
+#define I915_GEM_VM_BIND_FENCE_VALID (1 << 0)
+#define I915_GEM_VM_BIND_READONLY (1 << 1)
+#define I915_GEM_VM_BIND_CAPTURE (1 << 2)
+
+
[Intel-gfx] [PATCH v3 2/3] drm/i915: Update i915 uapi documentation
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Auld
---
include/uapi/drm/i915_drm.h | 205
1 file changed, 160 insertions(+), 45 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index de49b68b4fc8..f5ce34d447b1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -751,14 +751,27 @@ typedef struct drm_i915_irq_wait {
/* Must be kept compact -- no holes and well documented */
-typedef struct drm_i915_getparam {
+/**
+ * struct drm_i915_getparam - Driver parameter query structure.
+ */
+struct drm_i915_getparam {
+ /** @param: Driver parameter to query. */
__s32 param;
- /*
+
+ /**
+* @value: Address of memory where queried value should be put.
+*
* WARNING: Using pointers instead of fixed-size u64 means we need to
write
* compat32 code. Don't repeat this mistake.
*/
int __user *value;
-} drm_i915_getparam_t;
+};
+
+/**
+ * typedef drm_i915_getparam_t - Driver parameter query structure.
+ * See struct drm_i915_getparam.
+ */
+typedef struct drm_i915_getparam drm_i915_getparam_t;
/* Ioctl to set kernel params:
*/
@@ -1239,76 +1252,119 @@ struct drm_i915_gem_exec_object2 {
__u64 rsvd2;
};
+/**
+ * struct drm_i915_gem_exec_fence - An input or output fence for the execbuf
+ * ioctl.
+ *
+ * The request will wait for input fence to signal before submission.
+ *
+ * The returned output fence will be signaled after the completion of the
+ * request.
+ */
struct drm_i915_gem_exec_fence {
- /**
-* User's handle for a drm_syncobj to wait on or signal.
-*/
+ /** @handle: User's handle for a drm_syncobj to wait on or signal. */
__u32 handle;
+ /**
+* @flags: Supported flags are:
+*
+* I915_EXEC_FENCE_WAIT:
+* Wait for the input fence before request submission.
+*
+* I915_EXEC_FENCE_SIGNAL:
+* Return request completion fence as output
+*/
+ __u32 flags;
#define I915_EXEC_FENCE_WAIT(1<<0)
#define I915_EXEC_FENCE_SIGNAL (1<<1)
#define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SIGNAL << 1))
- __u32 flags;
};
-/*
- * See drm_i915_gem_execbuffer_ext_timeline_fences.
- */
-#define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
-
-/*
+/**
+ * struct drm_i915_gem_execbuffer_ext_timeline_fences - Timeline fences
+ * for execbuf ioctl.
+ *
* This structure describes an array of drm_syncobj and associated points for
* timeline variants of drm_syncobj. It is invalid to append this structure to
* the execbuf if I915_EXEC_FENCE_ARRAY is set.
*/
struct drm_i915_gem_execbuffer_ext_timeline_fences {
+#define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
+ /** @base: Extension link. See struct i915_user_extension. */
struct i915_user_extension base;
/**
-* Number of element in the handles_ptr & value_ptr arrays.
+* @fence_count: Number of elements in the @handles_ptr & @value_ptr
+* arrays.
*/
__u64 fence_count;
/**
-* Pointer to an array of struct drm_i915_gem_exec_fence of length
-* fence_count.
+* @handles_ptr: Pointer to an array of struct drm_i915_gem_exec_fence
+* of length @fence_count.
*/
__u64 handles_ptr;
/**
-* Pointer to an array of u64 values of length fence_count. Values
-* must be 0 for a binary drm_syncobj. A Value of 0 for a timeline
-* drm_syncobj is invalid as it turns a drm_syncobj into a binary one.
+* @values_ptr: Pointer to an array of u64 values of length
+* @fence_count.
+* Values must be 0 for a binary drm_syncobj. A Value of 0 for a
+* timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+* binary one.
*/
__u64 values_ptr;
};
+/**
+ * struct drm_i915_gem_execbuffer2 - Structure for DRM_I915_GEM_EXECBUFFER2
+ * ioctl.
+ */
struct drm_i915_gem_execbuffer2 {
- /**
-* List of gem_exec_object2 structs
-*/
+ /** @buffers_ptr: Pointer to a list of gem_exec_object2 structs */
__u64 buffers_ptr;
+
+ /** @buffer_count: Number of elements in @buffers_ptr array */
__u32 buffer_count;
- /** Offset in the batchbuffer to start execution from. */
+ /**
+* @batch_start_offset: Offset in the batchbuffer to start execution
+* from.
+*/
__u32 batch_start_offset;
- /** Bytes used in batchbuffer from batch_start_offset */
+
+ /**
+* @batch_len: Length in bytes of the batch buffer, starting from the
+* @batch_start_offset. If 0, length is assumed to be the batch buffer
+* object size.
+*/
[Intel-gfx] [PATCH v3 1/3] drm/doc/rfc: VM_BIND feature design document
VM_BIND design document with description of intended use cases. v2: Reduce the scope to simple Mesa use case. v3: Expand documentation on dma-resv usage, TLB flushing and execbuf3. v4: Remove vm_bind tlb flush request support. Signed-off-by: Niranjana Vishwanathapura --- Documentation/gpu/rfc/i915_vm_bind.rst | 245 + Documentation/gpu/rfc/index.rst| 4 + 2 files changed, 249 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index ..9b6bd1e8f660 --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,245 @@ +== +I915 VM_BIND feature design and use cases +== + +VM_BIND feature + +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuf calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuf mode). + +The VM_BIND/UNBIND calls allow UMDs to request a timeline fence for signaling +the completion of bind/unbind operation. + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +The bind/unbind operation can get completed asynchronously and out of +submission order. The out fence when specified will be signaled upon +completion of bind/unbind operation. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* TLB is flushed upon unbind completion. +* Support for userptr gem objects (no special uapi is required for this). + +TLB flushing +- +TLB is flushed upon unbind completion. If platforms support selective TLB +invalidation, only the required range is flushed. Otherwise, whole TLB is +flushed and batching the flushes might be useful here. + +Execbuf ioctl in VM_BIND mode +--- +A VM in VM_BIND mode will not support older execbuf mode of binding. +The execbuf ioctl handling in VM_BIND mode differs significantly from the +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any +execlist. Hence, no support for implicit sync. It is expected that the below +work will be able to support requirements of object dependency setting in all +use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) + +The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only +works with execbuf3 ioctl for submission. All BOs mapped on that VM (through +VM_BIND call) at the time of execbuf3 call are deemed required for that +submission. + +The execbuf3 ioctl directly specifies the batch addresses instead of as +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not +support many of the older features like in/out/submit fences, fence array, +default gem context and many more (See struct drm_i915_gem_execbuffer3). + +In VM_BIND mode, VA allocation is completely managed by the user instead of +the i915 driver. Hence all VA assignment, eviction are not applicable in +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not +be using the i915_vma active reference tracking. It will instead use dma-resv +object for that (See `VM_BIND dma_resv usage`_). + +So, a lot of existing code supporting execbuf2 ioctl, like relocations, VA +evictions, vma lookup table, implicit sync, vma active reference tracking etc., +are not applicable for execbuf3 ioctl. Hence, all execbuf3 specific handling +should be in a separate file and only functionalities common to these ioctls +can be the shared code where possible. + +VM_PRIVATE objects +--- +By default, BOs can be mapped on multiple VMs and can also be dma-buf +exported. Hence these BOs are referred to as Shared BOs. +During each execbuf submission, the request fence must be added to the +dma-resv fence list of all shared BOs mapped on the VM. + +VM_BIND feature introduces an optimization where user can create BO which +is private to a specified VM via I915_GEM_CREATE_EXT_VM_PRIVATE flag during +BO creation. Unlike Shared BOs, these VM private BOs can only be mapped on +the VM they are private to and can't be dma-buf e
[Intel-gfx] [PATCH v4 0/3] drm/doc/rfc: i915 VM_BIND feature design + uapi
This is the i915 driver VM_BIND feature design RFC patch series along with the required uapi definition and description of intended use cases. v2: Reduce the scope to simple Mesa use case. Remove all compute related uapi, vm_bind/unbind queue support and only support a timeline out fence instead of an in/out timeline fence array. v3: Expand documentation on dma-resv usage, TLB flushing, execbuf3 and VM_UNBIND. Add FENCE_VALID and TLB_FLUSH flags. v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional uapi documentation for vm_bind/unbind. Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (3): drm/doc/rfc: VM_BIND feature design document drm/i915: Update i915 uapi documentation drm/doc/rfc: VM_BIND uapi definition Documentation/gpu/rfc/i915_vm_bind.h | 252 + Documentation/gpu/rfc/i915_vm_bind.rst | 245 Documentation/gpu/rfc/index.rst| 4 + include/uapi/drm/i915_drm.h| 205 +++- 4 files changed, 661 insertions(+), 45 deletions(-) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst -- 2.21.0.rc0.32.g243a4c7e27
[Intel-gfx] [PATCH] drm/i915/dg2: Add performance workaround 18019455067
This is the recommended value for optimal performance.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 07ef111947b8c..a50b5790e434e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1112,6 +1112,9 @@
#define GEN12_PUSH_CONST_DEREF_HOLD_DIS REG_BIT(8)
#define RT_CTRL_MMIO(0xe530)
+#define NUMBER_OF_STACKIDS_512 (2 << 5)
+#define NUMBER_OF_STACKIDS_1024 (1 << 5)
+#define NUMBER_OF_STACKIDS_2048 (0 << 5)
#define DIS_NULL_QUERY REG_BIT(10)
#define EU_PERF_CNTL1 _MMIO(0xe558)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3213c593a55f4..a8a389d36986c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2106,6 +2106,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
* performance guide section.
*/
wa_write_or(wal, XEHP_L3SCQREG7, BLEND_FILL_CACHING_OPT_DIS);
+
+/* Wa_18019455067:dg2 / BSpec 68331/54402 */
+wa_write_or(wal, RT_CTRL, NUMBER_OF_STACKIDS_512);
}
if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_B0)) {
--
2.32.0
Re: [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2
Reviewed-by: Alan Previn On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote: > The fw name is different and we need to record the fact that the blob is > gsc-loaded, so add a new macro to help. > > Note: A-step DG2 G10 does not support HuC loading via GSC and would > require a separate firmware to be loaded the legacy way, but that's > not a production stepping so we're not going to bother. > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Tony Ye > --- > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 ++-- > 1 file changed, 37 insertions(+), 27 deletions(-) >
Re: [Intel-gfx] [PATCH 14/15] drm/i915/huc: define gsc-compatible HuC fw for DG2
Reviewed-by: Alan Previn On Thu, 2022-06-09 at 16:19 -0700, Ceraolo Spurio, Daniele wrote: > The fw name is different and we need to record the fact that the blob is > gsc-loaded, so add a new macro to help. > > Note: A-step DG2 G10 does not support HuC loading via GSC and would > require a separate firmware to be loaded the legacy way, but that's > not a production stepping so we're not going to bother. > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Tony Ye > --- > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 64 ++-- > 1 file changed, 37 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > index d2c5c9367cc4..fe6be7edbc72 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
Re: [Intel-gfx] [PATCH v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Wed, Jun 22, 2022 at 04:57:17PM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 16:12, Niranjana Vishwanathapura wrote:
On Wed, Jun 22, 2022 at 09:10:07AM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 04:56, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VALID
and I915_GEM_VM_BIND_TLB_FLUSH flags.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 243 +++
1 file changed, 243 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..fa23b2d7ec6f
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,243 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not
accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+
+/**
+ * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
notification.
+ *
+ * A timeline out fence for vm_bind/unbind completion notification.
+ */
+struct drm_i915_gem_vm_bind_fence {
+ /** @handle: User's handle for a drm_syncobj to signal. */
+ __u32 handle;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /**
+ * @value: A point in the timeline.
+ * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+ * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+ * binary one.
+ */
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the
mapping of GPU
+ * virtual address (VA) range to the section of an object that
should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently
bound) and can
+ * be mapped to whole object or a section of the object
(partial binding).
+ * Multiple VA mappings can be created to the same section of
the object
+ * (aliasing).
+ *
+ * The @start, @offset and @length should be 4K page aligned.
However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and
has compact page
+ * table. On those platforms, for binding device local-memory
objects, the
+ * @start should be 2M aligned, @offset and @length should be
64K aligned.
Should some error codes be documented and has the ability to
programmatically probe the alignment restrictions been considered?
Currently what we have internally is that -EINVAL is returned if the
sart, offset
and length are not aligned. If the specified mapping already exits,
we return
-EEXIST. If there are conflicts in the VA range and VA range can't
be reserved,
then -ENOSPC is returned. I can add this documentation here. But I
am worried
that there will be more suggestions/feedback about error codes while
reviewing
the code patch series, and we have to revisit it again.
I'd still suggest documenting those three. It makes sense to explain
to userspace what behaviour they will see if they get it wrong.
Ok.
+ * Also, on those platforms, it is not allowed to bind an
device local-memory
+ * object and a system memory object in a single 2M section of
VA range.
Text should be clear whether "not allowed" means there will be an
error returned, or it will appear to work but bad things will
happen.
Yah, error returned, will fix.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to b
[Intel-gfx] [PATCH] drm/i915: tweak the ordering in cpu_write_needs_clflush
For imported dma-buf objects we leave the object as cache_coherent = 0
across all platforms, which is reasonable given that have no clue what
the memory underneath is, and its not like the driver can ever manually
clflush the pages anyway (like with i915_gem_clflush_object) for such
objects. However on discrete we choose to treat cache_dirty = true as a
programmer error, leading to a warning. The simplest fix looks to be to
just change the ordering in cpu_write_needs_clflush to prevent ever
setting cache_dirty for dma-buf objects on discrete.
Fixes: d028a7690d87 ("drm/i915/dmabuf: Fix prime_mmap to work when using LMEM")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5266
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 3e5d6057b3ef..1674b0c5802b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -35,12 +35,12 @@ bool i915_gem_cpu_write_needs_clflush(struct
drm_i915_gem_object *obj)
if (obj->cache_dirty)
return false;
- if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE))
- return true;
-
if (IS_DGFX(i915))
return false;
+ if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE))
+ return true;
+
/* Currently in use by HW (display engine)? Keep flushed. */
return i915_gem_object_is_framebuffer(obj);
}
--
2.36.1
Re: [Intel-gfx] [PATCH v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On 22/06/2022 16:12, Niranjana Vishwanathapura wrote:
On Wed, Jun 22, 2022 at 09:10:07AM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 04:56, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VALID
and I915_GEM_VM_BIND_TLB_FLUSH flags.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 243 +++
1 file changed, 243 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..fa23b2d7ec6f
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,243 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not
accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE
+ DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct
drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct
drm_i915_gem_execbuffer3)
+
+/**
+ * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
notification.
+ *
+ * A timeline out fence for vm_bind/unbind completion notification.
+ */
+struct drm_i915_gem_vm_bind_fence {
+ /** @handle: User's handle for a drm_syncobj to signal. */
+ __u32 handle;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /**
+ * @value: A point in the timeline.
+ * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+ * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+ * binary one.
+ */
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the
mapping of GPU
+ * virtual address (VA) range to the section of an object that
should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound)
and can
+ * be mapped to whole object or a section of the object (partial
binding).
+ * Multiple VA mappings can be created to the same section of the
object
+ * (aliasing).
+ *
+ * The @start, @offset and @length should be 4K page aligned.
However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has
compact page
+ * table. On those platforms, for binding device local-memory
objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K
aligned.
Should some error codes be documented and has the ability to
programmatically probe the alignment restrictions been considered?
Currently what we have internally is that -EINVAL is returned if the
sart, offset
and length are not aligned. If the specified mapping already exits, we
return
-EEXIST. If there are conflicts in the VA range and VA range can't be
reserved,
then -ENOSPC is returned. I can add this documentation here. But I am
worried
that there will be more suggestions/feedback about error codes while
reviewing
the code patch series, and we have to revisit it again.
I'd still suggest documenting those three. It makes sense to explain to
userspace what behaviour they will see if they get it wrong.
+ * Also, on those platforms, it is not allowed to bind an device
local-memory
+ * object and a system memory object in a single 2M section of VA
range.
Text should be clear whether "not allowed" means there will be an
error returned, or it will appear to work but bad things will happen.
Yah, error returned, will fix.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 length;
+
+ /**
+ * @flags: Supported flags are:
[Intel-gfx] [PATCH v2 9/9] drm/i915: Enable atomic by default on ctg/elk
From: Ville Syrjälä The watermark code for ctg/elk has been atomic ready for a long time so let's just flip the switch now that some of the last CxSR issues have been sorted out (which granted was a problem for vlv/chv as well despite them already having atomic enabled by default). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_driver.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c index 0e224761d0ed..d4e544d6b28f 100644 --- a/drivers/gpu/drm/i915/i915_driver.c +++ b/drivers/gpu/drm/i915/i915_driver.c @@ -841,8 +841,11 @@ int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (IS_ERR(i915)) return PTR_ERR(i915); - /* Disable nuclear pageflip by default on pre-ILK */ - if (!i915->params.nuclear_pageflip && match_info->graphics.ver < 5) + /* Disable nuclear pageflip by default on pre-CTG/ELK */ + if (!i915->params.nuclear_pageflip && + match_info->display.ver < 5 && + match_info->platform != INTEL_G45 && + match_info->platform != INTEL_GM45) i915->drm.driver_features &= ~DRIVER_ATOMIC; ret = pci_enable_device(pdev); -- 2.35.1
[Intel-gfx] [PATCH v2 8/9] drm/i915: Write watermarks for disabled pipes on gmch platforms
From: Ville Syrjälä We've excluded gmch platforms from writing the final watermarks for any disabled pipe. IIRC the reason was perhaps some lingering issue with the watermark merging across the pipes. But I can't really see any reason for this anymore, so let's unify this behaviour. The main benefit being more consistency in register dumps when we don't have stale watermarks hanging around in the registers. Functionally there should be no difference as the hardware just ignore all of it when the pipe is disabled. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 903226e2a626..2c5dadc62c55 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -7192,9 +7192,7 @@ static void intel_old_crtc_state_disables(struct intel_atomic_state *state, intel_fbc_disable(crtc); intel_disable_shared_dpll(old_crtc_state); - /* FIXME unify this for all platforms */ - if (!new_crtc_state->hw.active && - !HAS_GMCH(dev_priv)) + if (!new_crtc_state->hw.active) intel_initial_watermarks(state, crtc); } -- 2.35.1
[Intel-gfx] [PATCH v2 7/9] drm/i915: Fix pipe gamma enable/disable vs. CxSR on gmch platforms
From: Ville Syrjälä Like most other plane control register bits, the pipe gamma enable bit is also blocked by CxSR. So make sure we kick the machine out of CxSR before trying to change that bit. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index a27ce874a9e8..bc01a7d3b0d3 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -1305,6 +1305,10 @@ intel_color_add_affected_planes(struct intel_crtc_state *new_crtc_state) return PTR_ERR(plane_state); new_crtc_state->update_planes |= BIT(plane->id); + + /* plane control register changes blocked by CxSR */ + if (HAS_GMCH(dev_priv)) + new_crtc_state->disable_cxsr = true; } return 0; -- 2.35.1
[Intel-gfx] [PATCH v2 6/9] drm/i915: Fix g4x/vlv/chv CxSR vs. format/tiling/rotation changes
From: Ville Syrjälä
On g4x/vlv/chv the hardware seems incapable of changing the pixel
format, rotation, or YUV->RGB CSC matrix while in CxSR.
Additionally on VLV/CHV the sprites seem incapable of tiling
changes while in CxSR. On g4x CxSR is not even possible with
the sprite enabled. Curiously the primary plane seems perfectly
happy when changing tiling during CxSR.
Pimp up the code to account for these when determining whether
CxSR needs to be disabled. Since it looks like most of the plane
control register bits are affected let's just compare that.
But in the name of efficiency we'll make an exception for the
primary plane tiling changes (avoids some extra vblank waits).
v2: Just use the pre-computed plane control register values
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 53 ---
1 file changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index efe8591619e3..e5ad6a437a97 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -426,6 +426,47 @@ static bool intel_plane_do_async_flip(struct intel_plane
*plane,
return DISPLAY_VER(i915) < 13 || old_crtc_state->uapi.async_flip;
}
+static bool i9xx_must_disable_cxsr(const struct intel_crtc_state
*new_crtc_state,
+ const struct intel_plane_state
*old_plane_state,
+ const struct intel_plane_state
*new_plane_state)
+{
+ struct intel_plane *plane = to_intel_plane(new_plane_state->uapi.plane);
+ bool old_visible = old_plane_state->uapi.visible;
+ bool new_visible = new_plane_state->uapi.visible;
+ u32 old_ctl = old_plane_state->ctl;
+ u32 new_ctl = new_plane_state->ctl;
+ bool modeset, turn_on, turn_off;
+
+ if (plane->id == PLANE_CURSOR)
+ return false;
+
+ modeset = intel_crtc_needs_modeset(new_crtc_state);
+ turn_off = old_visible && (!new_visible || modeset);
+ turn_on = new_visible && (!old_visible || modeset);
+
+ /* Must disable CxSR around plane enable/disable */
+ if (turn_on || turn_off)
+ return true;
+
+ if (!old_visible || !new_visible)
+ return false;
+
+ /*
+* Most plane control register updates are blocked while in CxSR.
+*
+* Tiling mode is one exception where the primary plane can
+* apparently handle it, whereas the sprites can not (the
+* sprite issue being only relevant on VLV/CHV where CxSR
+* is actually possible with a sprite enabled).
+*/
+ if (plane->id == PLANE_PRIMARY) {
+ old_ctl &= ~DISP_TILED;
+ new_ctl &= ~DISP_TILED;
+ }
+
+ return old_ctl != new_ctl;
+}
+
static int intel_plane_atomic_calc_changes(const struct intel_crtc_state
*old_crtc_state,
struct intel_crtc_state
*new_crtc_state,
const struct intel_plane_state
*old_plane_state,
@@ -483,17 +524,9 @@ static int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_cr
if (turn_on) {
if (DISPLAY_VER(dev_priv) < 5 && !IS_G4X(dev_priv))
new_crtc_state->update_wm_pre = true;
-
- /* must disable cxsr around plane enable/disable */
- if (plane->id != PLANE_CURSOR)
- new_crtc_state->disable_cxsr = true;
} else if (turn_off) {
if (DISPLAY_VER(dev_priv) < 5 && !IS_G4X(dev_priv))
new_crtc_state->update_wm_post = true;
-
- /* must disable cxsr around plane enable/disable */
- if (plane->id != PLANE_CURSOR)
- new_crtc_state->disable_cxsr = true;
} else if (intel_wm_need_update(old_plane_state, new_plane_state)) {
if (DISPLAY_VER(dev_priv) < 5 && !IS_G4X(dev_priv)) {
/* FIXME bollocks */
@@ -505,6 +538,10 @@ static int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_cr
if (visible || was_visible)
new_crtc_state->fb_bits |= plane->frontbuffer_bit;
+ if (HAS_GMCH(dev_priv) &&
+ i9xx_must_disable_cxsr(new_crtc_state, old_plane_state,
new_plane_state))
+ new_crtc_state->disable_cxsr = true;
+
/*
* ILK/SNB DVSACNTR/Sprite Enable
* IVB SPR_CTL/Sprite Enable
--
2.35.1
[Intel-gfx] [PATCH v2 5/9] drm/i915: Add missing invalidate to g4x wm readout
From: Ville Syrjälä Let's not forget to mark the unused watermark levels as invalid after the readout. The vlv/chv codepath has this but the g4x didn't for some reason. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 45ec00e2e3c4..734deb0bd867 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6915,6 +6915,8 @@ void g4x_wm_get_hw_state(struct drm_i915_private *dev_priv) plane_id, USHRT_MAX); g4x_raw_fbc_wm_set(crtc_state, level, USHRT_MAX); + g4x_invalidate_wms(crtc, active, level); + crtc_state->wm.g4x.optimal = *active; crtc_state->wm.g4x.intermediate = *active; -- 2.35.1
[Intel-gfx] [PATCH v2 2/9] drm/i915: Split vlv_compute_pipe_wm() into two
From: Ville Syrjälä
Split vlv_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 114 ++--
1 file changed, 64 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 395ed3c832d6..4ea43fa73075 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1904,64 +1904,17 @@ static bool vlv_raw_crtc_wm_is_valid(const struct
intel_crtc_state *crtc_state,
vlv_raw_plane_wm_is_valid(crtc_state, PLANE_CURSOR, level);
}
-static int vlv_compute_pipe_wm(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
+static int _vlv_compute_pipe_wm(struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_state *crtc_state =
- intel_atomic_get_new_crtc_state(state, crtc);
struct vlv_wm_state *wm_state = &crtc_state->wm.vlv.optimal;
const struct vlv_fifo_state *fifo_state =
&crtc_state->wm.vlv.fifo_state;
u8 active_planes = crtc_state->active_planes & ~BIT(PLANE_CURSOR);
int num_active_planes = hweight8(active_planes);
- bool needs_modeset = drm_atomic_crtc_needs_modeset(&crtc_state->uapi);
- const struct intel_plane_state *old_plane_state;
- const struct intel_plane_state *new_plane_state;
- struct intel_plane *plane;
enum plane_id plane_id;
- int level, ret, i;
- unsigned int dirty = 0;
-
- for_each_oldnew_intel_plane_in_state(state, plane,
-old_plane_state,
-new_plane_state, i) {
- if (new_plane_state->hw.crtc != &crtc->base &&
- old_plane_state->hw.crtc != &crtc->base)
- continue;
-
- if (vlv_raw_plane_wm_compute(crtc_state, new_plane_state))
- dirty |= BIT(plane->id);
- }
-
- /*
-* DSPARB registers may have been reset due to the
-* power well being turned off. Make sure we restore
-* them to a consistent state even if no primary/sprite
-* planes are initially active.
-*/
- if (needs_modeset)
- crtc_state->fifo_changed = true;
-
- if (!dirty)
- return 0;
-
- /* cursor changes don't warrant a FIFO recompute */
- if (dirty & ~BIT(PLANE_CURSOR)) {
- const struct intel_crtc_state *old_crtc_state =
- intel_atomic_get_old_crtc_state(state, crtc);
- const struct vlv_fifo_state *old_fifo_state =
- &old_crtc_state->wm.vlv.fifo_state;
-
- ret = vlv_compute_fifo(crtc_state);
- if (ret)
- return ret;
-
- if (needs_modeset ||
- memcmp(old_fifo_state, fifo_state,
- sizeof(*fifo_state)) != 0)
- crtc_state->fifo_changed = true;
- }
+ int level;
/* initially allow all levels */
wm_state->num_levels = intel_wm_num_levels(dev_priv);
@@ -2008,6 +1961,67 @@ static int vlv_compute_pipe_wm(struct intel_atomic_state
*state,
return 0;
}
+static int vlv_compute_pipe_wm(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ bool needs_modeset = drm_atomic_crtc_needs_modeset(&crtc_state->uapi);
+ const struct intel_plane_state *old_plane_state;
+ const struct intel_plane_state *new_plane_state;
+ struct intel_plane *plane;
+ unsigned int dirty = 0;
+ int i;
+
+ for_each_oldnew_intel_plane_in_state(state, plane,
+old_plane_state,
+new_plane_state, i) {
+ if (new_plane_state->hw.crtc != &crtc->base &&
+ old_plane_state->hw.crtc != &crtc->base)
+ continue;
+
+ if (vlv_raw_plane_wm_compute(crtc_state, new_plane_state))
+ dirty |= BIT(plane->id);
+ }
+
+ /*
+* DSPARB registers may have been reset due to the
+* power well being turned off. Make sure we restore
+* them to a consistent state even if no primary/sprite
+* planes are initially active. We also force a FIFO
+* recomputation so that we are sure to sanitize the
+* FIFO setting we took over from
[Intel-gfx] [PATCH v2 4/9] drm/i915: Simplify up vlv watermark sanitation
From: Ville Syrjälä
We can simplify the vlv watermark sanitation by reusing the
second half of vlv_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Also to be consistent with normal watermark computation the sanitized
watermarks should be all 0 for any disabled plane. Previously we
zeroed out the watermarks only up to the level (ie. PM2/5/DVDFS)
that was enabled.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 556fcdfb75f1..45ec00e2e3c4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7100,30 +7100,27 @@ void vlv_wm_sanitize(struct drm_i915_private *dev_priv)
to_intel_crtc_state(crtc->base.state);
struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
- struct vlv_wm_state *wm_state = &crtc_state->wm.vlv.optimal;
- const struct vlv_fifo_state *fifo_state =
- &crtc_state->wm.vlv.fifo_state;
enum plane_id plane_id = plane->id;
- int level;
+ int level, num_levels = intel_wm_num_levels(dev_priv);
if (plane_state->uapi.visible)
continue;
- for (level = 0; level < wm_state->num_levels; level++) {
+ for (level = 0; level < num_levels; level++) {
struct g4x_pipe_wm *raw =
&crtc_state->wm.vlv.raw[level];
raw->plane[plane_id] = 0;
-
- wm_state->wm[level].plane[plane_id] =
- vlv_invert_wm_value(raw->plane[plane_id],
-
fifo_state->plane[plane_id]);
}
}
for_each_intel_crtc(&dev_priv->drm, crtc) {
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
+ int ret;
+
+ ret = _vlv_compute_pipe_wm(crtc_state);
+ drm_WARN_ON(&dev_priv->drm, ret);
crtc_state->wm.vlv.intermediate =
crtc_state->wm.vlv.optimal;
--
2.35.1
[Intel-gfx] [PATCH v2 3/9] drm/i915: Simplify up g4x watermark sanitation
From: Ville Syrjälä
We can simplify the g4x watermark sanitation by reusing the
second half of g4x_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4ea43fa73075..556fcdfb75f1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6951,37 +6951,30 @@ void g4x_wm_sanitize(struct drm_i915_private *dev_priv)
to_intel_crtc_state(crtc->base.state);
struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
- struct g4x_wm_state *wm_state = &crtc_state->wm.g4x.optimal;
enum plane_id plane_id = plane->id;
- int level;
+ int level, num_levels = intel_wm_num_levels(dev_priv);
if (plane_state->uapi.visible)
continue;
- for (level = 0; level < 3; level++) {
+ for (level = 0; level < num_levels; level++) {
struct g4x_pipe_wm *raw =
&crtc_state->wm.g4x.raw[level];
raw->plane[plane_id] = 0;
- wm_state->wm.plane[plane_id] = 0;
- }
- if (plane_id == PLANE_PRIMARY) {
- for (level = 0; level < 3; level++) {
- struct g4x_pipe_wm *raw =
- &crtc_state->wm.g4x.raw[level];
+ if (plane_id == PLANE_PRIMARY)
raw->fbc = 0;
- }
-
- wm_state->sr.fbc = 0;
- wm_state->hpll.fbc = 0;
- wm_state->fbc_en = false;
}
}
for_each_intel_crtc(&dev_priv->drm, crtc) {
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
+ int ret;
+
+ ret = _g4x_compute_pipe_wm(crtc_state);
+ drm_WARN_ON(&dev_priv->drm, ret);
crtc_state->wm.g4x.intermediate =
crtc_state->wm.g4x.optimal;
--
2.35.1
[Intel-gfx] [PATCH v2 1/9] drm/i915: Split g4x_compute_pipe_wm() into two
From: Ville Syrjälä
Split g4x_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Reviewed-by: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 54 +++--
1 file changed, 31 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9b7e93ca1ff9..395ed3c832d6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1376,34 +1376,14 @@ static bool g4x_compute_fbc_en(const struct
g4x_wm_state *wm_state,
return true;
}
-static int g4x_compute_pipe_wm(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
+static int _g4x_compute_pipe_wm(struct intel_crtc_state *crtc_state)
{
- struct intel_crtc_state *crtc_state =
- intel_atomic_get_new_crtc_state(state, crtc);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct g4x_wm_state *wm_state = &crtc_state->wm.g4x.optimal;
u8 active_planes = crtc_state->active_planes & ~BIT(PLANE_CURSOR);
const struct g4x_pipe_wm *raw;
- const struct intel_plane_state *old_plane_state;
- const struct intel_plane_state *new_plane_state;
- struct intel_plane *plane;
enum plane_id plane_id;
- int i, level;
- unsigned int dirty = 0;
-
- for_each_oldnew_intel_plane_in_state(state, plane,
-old_plane_state,
-new_plane_state, i) {
- if (new_plane_state->hw.crtc != &crtc->base &&
- old_plane_state->hw.crtc != &crtc->base)
- continue;
-
- if (g4x_raw_plane_wm_compute(crtc_state, new_plane_state))
- dirty |= BIT(plane->id);
- }
-
- if (!dirty)
- return 0;
+ int level;
level = G4X_WM_LEVEL_NORMAL;
if (!g4x_raw_crtc_wm_is_valid(crtc_state, level))
@@ -1456,6 +1436,34 @@ static int g4x_compute_pipe_wm(struct intel_atomic_state
*state,
return 0;
}
+static int g4x_compute_pipe_wm(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ const struct intel_plane_state *old_plane_state;
+ const struct intel_plane_state *new_plane_state;
+ struct intel_plane *plane;
+ unsigned int dirty = 0;
+ int i;
+
+ for_each_oldnew_intel_plane_in_state(state, plane,
+old_plane_state,
+new_plane_state, i) {
+ if (new_plane_state->hw.crtc != &crtc->base &&
+ old_plane_state->hw.crtc != &crtc->base)
+ continue;
+
+ if (g4x_raw_plane_wm_compute(crtc_state, new_plane_state))
+ dirty |= BIT(plane->id);
+ }
+
+ if (!dirty)
+ return 0;
+
+ return _g4x_compute_pipe_wm(crtc_state);
+}
+
static int g4x_compute_intermediate_wm(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
--
2.35.1
[Intel-gfx] [PATCH v2 0/9] drm/i915: g4x/vlv/chv CxSR/wm fixes/cleanups
From: Ville Syrjälä Fix some remaining issues around plane updates vs. CxSR on gmch platforms. Also throw in a few watermark fixes/cleanups, and finally flip on atomic for g4x since everything is ready. v2: Just rebase from a year ago Ville Syrjälä (9): drm/i915: Split g4x_compute_pipe_wm() into two drm/i915: Split vlv_compute_pipe_wm() into two drm/i915: Simplify up g4x watermark sanitation drm/i915: Simplify up vlv watermark sanitation drm/i915: Add missing invalidate to g4x wm readout drm/i915: Fix g4x/vlv/chv CxSR vs. format/tiling/rotation changes drm/i915: Fix pipe gamma enable/disable vs. CxSR on gmch platforms drm/i915: Write watermarks for disabled pipes on gmch platforms drm/i915: Enable atomic by default on ctg/elk .../gpu/drm/i915/display/intel_atomic_plane.c | 53 - drivers/gpu/drm/i915/display/intel_color.c| 4 + drivers/gpu/drm/i915/display/intel_display.c | 4 +- drivers/gpu/drm/i915/i915_driver.c| 7 +- drivers/gpu/drm/i915/intel_pm.c | 206 ++ 5 files changed, 165 insertions(+), 109 deletions(-) -- 2.35.1
Re: [Intel-gfx] [PATCH v3 05/13] drm/edid: add drm_edid_connector_update()
On Wed, Jun 22, 2022 at 01:59:19PM +0300, Jani Nikula wrote:
> Add a new function drm_edid_connector_update() to replace the
> combination of calls drm_connector_update_edid_property() and
> drm_add_edid_modes(). Usually they are called in the drivers in this
> order, however the former needs information from the latter.
>
> Since the new drm_edid_read*() functions no longer call the connector
> updates directly, and the read and update are separated, we'll need this
> new function for the connector update.
>
> This is all in drm_edid.c simply to keep struct drm_edid opaque.
>
> v2:
> - Share code with drm_connector_update_edid_property() (Ville)
> - Add comment about override EDID handling
>
> Signed-off-by: Jani Nikula
Had to take notes to figure who did/does what. But it does look
like non-static stuff should end up doing the same thing before
and after this patch, apart from the new function that is.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 103 -
> include/drm/drm_edid.h | 2 +
> 2 files changed, 81 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c3f0f0a5a8a9..41b3de52b8f1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6160,8 +6160,8 @@ static int add_displayid_detailed_modes(struct
> drm_connector *connector,
> return num_modes;
> }
>
> -static int drm_edid_connector_update(struct drm_connector *connector,
> - const struct drm_edid *drm_edid)
> +static int _drm_edid_connector_update(struct drm_connector *connector,
> + const struct drm_edid *drm_edid)
> {
> int num_modes = 0;
> u32 quirks;
> @@ -6227,31 +6227,12 @@ static int drm_edid_connector_update(struct
> drm_connector *connector,
> static void _drm_update_tile_info(struct drm_connector *connector,
> const struct drm_edid *drm_edid);
>
> -static int _drm_connector_update_edid_property(struct drm_connector
> *connector,
> +static int _drm_edid_connector_property_update(struct drm_connector
> *connector,
> const struct drm_edid *drm_edid)
> {
> struct drm_device *dev = connector->dev;
> int ret;
>
> - /* ignore requests to set edid when overridden */
> - if (connector->override_edid)
> - return 0;
> -
> - /*
> - * Set the display info, using edid if available, otherwise resetting
> - * the values to defaults. This duplicates the work done in
> - * drm_add_edid_modes, but that function is not consistently called
> - * before this one in all drivers and the computation is cheap enough
> - * that it seems better to duplicate it rather than attempt to ensure
> - * some arbitrary ordering of calls.
> - */
> - if (drm_edid)
> - update_display_info(connector, drm_edid);
> - else
> - drm_reset_display_info(connector);
> -
> - _drm_update_tile_info(connector, drm_edid);
> -
> if (connector->edid_blob_ptr) {
> const struct edid *old_edid = connector->edid_blob_ptr->data;
>
> @@ -6297,6 +6278,76 @@ static int _drm_connector_update_edid_property(struct
> drm_connector *connector,
> return ret;
> }
>
> +/**
> + * drm_edid_connector_update - Update connector information from EDID
> + * @connector: Connector
> + * @drm_edid: EDID
> + *
> + * Update the connector mode list, display info, ELD, HDR metadata, relevant
> + * properties, etc. from the passed in EDID.
> + *
> + * If EDID is NULL, reset the information.
> + *
> + * Return: The number of modes added or 0 if we couldn't find any.
> + */
> +int drm_edid_connector_update(struct drm_connector *connector,
> + const struct drm_edid *drm_edid)
> +{
> + int count;
> +
> + /*
> + * FIXME: Reconcile the differences in override_edid handling between
> + * this and drm_connector_update_edid_property().
> + *
> + * If override_edid is set, and the EDID passed in here originates from
> + * drm_edid_read() and friends, it will be the override EDID, and there
> + * are no issues. drm_connector_update_edid_property() ignoring requests
> + * to set the EDID dates back to a time when override EDID was not
> + * handled at the low level EDID read.
> + *
> + * The only way the EDID passed in here can be different from the
> + * override EDID is when a driver passes in an EDID that does *not*
> + * originate from drm_edid_read() and friends, or passes in a stale
> + * cached version. This, in turn, is a question of when an override EDID
> + * set via debugfs should take effect.
> + */
> +
> + count = _drm_edid_connector_update(connector, drm_edid);
> +
> + _drm_update_tile_info(connector, drm_edid);
> +
> + /* Note: Ignore er
Re: [Intel-gfx] [PATCH v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Wed, Jun 22, 2022 at 09:10:07AM +0100, Tvrtko Ursulin wrote:
On 22/06/2022 04:56, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
v3: Expand VM_UNBIND documentation and add
I915_GEM_VM_BIND/UNBIND_FENCE_VALID
and I915_GEM_VM_BIND_TLB_FLUSH flags.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 243 +++
1 file changed, 243 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..fa23b2d7ec6f
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,243 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+
+/**
+ * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion notification.
+ *
+ * A timeline out fence for vm_bind/unbind completion notification.
+ */
+struct drm_i915_gem_vm_bind_fence {
+ /** @handle: User's handle for a drm_syncobj to signal. */
+ __u32 handle;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /**
+* @value: A point in the timeline.
+* Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+* timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+* binary one.
+*/
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @start, @offset and @length should be 4K page aligned. However the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
Should some error codes be documented and has the ability to
programmatically probe the alignment restrictions been considered?
Currently what we have internally is that -EINVAL is returned if the sart,
offset
and length are not aligned. If the specified mapping already exits, we return
-EEXIST. If there are conflicts in the VA range and VA range can't be reserved,
then -ENOSPC is returned. I can add this documentation here. But I am worried
that there will be more suggestions/feedback about error codes while reviewing
the code patch series, and we have to revisit it again.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
Text should be clear whether "not allowed" means there will be an
error returned, or it will appear to work but bad things will happen.
Yah, error returned, will fix.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 length;
+
+ /**
+* @flags: Supported flags are:
+*
+* I915_GEM_VM_BIND_FENCE_VALID:
+* @fence is valid, needs bind completion notification.
+*
+
Re: [Intel-gfx] [PATCH v3 08/13] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
On Wed, Jun 22, 2022 at 01:59:22PM +0300, Jani Nikula wrote:
> @@ -948,27 +948,30 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
>* preferred mode is the right one.
>*/
> mutex_lock(&dev->mode_config.mutex);
> - if (vga_switcheroo_handler_flags() & VGA_SWITCHEROO_CAN_SWITCH_DDC)
> + if (vga_switcheroo_handler_flags() & VGA_SWITCHEROO_CAN_SWITCH_DDC) {
> + const struct edid *edid;
> +
> + /* FIXME: Make drm_get_edid_switcheroo() return drm_edid */
> edid = drm_get_edid_switcheroo(connector,
> - intel_gmbus_get_adapter(dev_priv, pin));
> - else
> - edid = drm_get_edid(connector,
> - intel_gmbus_get_adapter(dev_priv, pin));
> - if (edid) {
> - if (drm_add_edid_modes(connector, edid)) {
> - drm_connector_update_edid_property(connector,
> - edid);
> - } else {
> - kfree(edid);
> - edid = ERR_PTR(-EINVAL);
> +
> intel_gmbus_get_adapter(dev_priv, pin));
> + if (edid)
> + drm_edid = drm_edid_alloc(edid, (edid->extensions + 1)
> * EDID_LENGTH);
This one still seems to leak.
> + } else {
> + drm_edid = drm_edid_read_ddc(connector,
> + intel_gmbus_get_adapter(dev_priv,
> pin));
> + }
> + if (drm_edid) {
> + if (!drm_edid_connector_update(connector, drm_edid)) {
> + drm_edid_free(drm_edid);
> + drm_edid = ERR_PTR(-EINVAL);
> }
> } else {
> - edid = ERR_PTR(-ENOENT);
> + drm_edid = ERR_PTR(-ENOENT);
> }
> - intel_connector->edid = edid;
> + intel_connector->edid = drm_edid;
>
> intel_bios_init_panel(dev_priv, &intel_connector->panel, NULL,
> - IS_ERR(edid) ? NULL : edid);
> + IS_ERR_OR_NULL(drm_edid) ? NULL :
> drm_edid_raw(drm_edid));
>
> /* Try EDID first */
> intel_panel_add_edid_fixed_modes(intel_connector,
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v3 04/13] drm/edid: abstract debugfs override EDID set/reset
On Wed, Jun 22, 2022 at 01:59:18PM +0300, Jani Nikula wrote:
> Add functions drm_edid_override_set() and drm_edid_override_reset() to
> support "edid_override" connector debugfs, and to hide the details about
> it in drm_edid.c. No functional changes at this time.
>
> Also note in the connector.override_edid flag kernel-doc that this is
> only supposed to be modified by the code doing debugfs EDID override
> handling. Currently, it is still being modified by amdgpu in
> create_eml_sink() and handle_edid_mgmt() for reasons unknown. This was
> added in commit 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
> and later moved to amdgpu_dm.c in commit e7b07ceef2a6 ("drm/amd/display:
> Merge amdgpu_dm_types and amdgpu_dm").
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc_internal.h | 2 ++
> drivers/gpu/drm/drm_debugfs.c | 21 +
> drivers/gpu/drm/drm_edid.c | 26 ++
> include/drm/drm_connector.h | 6 +-
> 4 files changed, 38 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index aecab5308bae..56041b604881 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -286,3 +286,5 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>
> /* drm_edid.c */
> void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
> +int drm_edid_override_set(struct drm_connector *connector, const void *edid,
> size_t size);
> +int drm_edid_override_reset(struct drm_connector *connector);
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index fb04b7a984de..493922069c90 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -350,31 +350,20 @@ static ssize_t edid_write(struct file *file, const char
> __user *ubuf,
> struct seq_file *m = file->private_data;
> struct drm_connector *connector = m->private;
> char *buf;
> - struct edid *edid;
> int ret;
>
> buf = memdup_user(ubuf, len);
> if (IS_ERR(buf))
> return PTR_ERR(buf);
>
> - edid = (struct edid *) buf;
> -
> - if (len == 5 && !strncmp(buf, "reset", 5)) {
> - connector->override_edid = false;
> - ret = drm_connector_update_edid_property(connector, NULL);
> - } else if (len < EDID_LENGTH ||
> -EDID_LENGTH * (1 + edid->extensions) > len)
> - ret = -EINVAL;
> - else {
> - connector->override_edid = false;
> - ret = drm_connector_update_edid_property(connector, edid);
> - if (!ret)
> - connector->override_edid = true;
> - }
> + if (len == 5 && !strncmp(buf, "reset", 5))
> + ret = drm_edid_override_reset(connector);
> + else
> + ret = drm_edid_override_set(connector, buf, len);
>
> kfree(buf);
>
> - return (ret) ? ret : len;
> + return ret ? ret : len;
> }
>
> /*
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e360e1a269f4..c3f0f0a5a8a9 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2161,6 +2161,32 @@ static struct edid *drm_get_override_edid(struct
> drm_connector *connector,
> return IS_ERR(override) ? NULL : override;
> }
>
> +/* For debugfs edid_override implementation */
> +int drm_edid_override_set(struct drm_connector *connector, const void *edid,
> + size_t size)
> +{
> + int ret;
> +
> + if (size < EDID_LENGTH || edid_size(edid) > size)
> + return -EINVAL;
> +
> + connector->override_edid = false;
> +
> + ret = drm_connector_update_edid_property(connector, edid);
> + if (!ret)
> + connector->override_edid = true;
> +
> + return ret;
> +}
> +
> +/* For debugfs edid_override implementation */
> +int drm_edid_override_reset(struct drm_connector *connector)
> +{
> + connector->override_edid = false;
> +
> + return drm_connector_update_edid_property(connector, NULL);
> +}
> +
> /**
> * drm_add_override_edid_modes - add modes from override/firmware EDID
> * @connector: connector we're probing
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 94b422b55cc1..a1705d6b3fba 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1527,7 +1527,11 @@ struct drm_connector {
> struct drm_cmdline_mode cmdline_mode;
> /** @force: a DRM_FORCE_ state for forced mode sets */
> enum drm_connector_force force;
> - /** @override_edid: has the EDID been overwritten through debugfs for
> testing? */
> + /**
> + * @override_edid: has the EDID been overwritten through debugfs for
> + * testing? Do not modify outside of drm_edid_override_set() and
> + * drm_edid_override_reset().
> + */
>
Re: [Intel-gfx] [PATCH v3 03/13] drm/edid: clean up connector update error handling and debug logging
On Wed, Jun 22, 2022 at 01:59:17PM +0300, Jani Nikula wrote:
> Bail out on all errors, debug log all errors, and convert to drm device
> based debug logging.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c | 41 ++
> 1 file changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 62967db78139..e360e1a269f4 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6231,29 +6231,44 @@ static int _drm_connector_update_edid_property(struct
> drm_connector *connector,
>
> if (old_edid) {
> if (!drm_edid_are_equal(drm_edid ? drm_edid->edid :
> NULL, old_edid)) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
> changed.\n",
> - connector->base.id,
> connector->name);
> -
> - connector->epoch_counter += 1;
> - DRM_DEBUG_KMS("Updating change counter to
> %llu\n",
> - connector->epoch_counter);
> + connector->epoch_counter++;
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID
> changed, epoch counter %llu\n",
> + connector->base.id, connector->name,
> + connector->epoch_counter);
> }
> }
> }
>
> - drm_object_property_set_value(&connector->base,
> - dev->mode_config.non_desktop_property,
> - connector->display_info.non_desktop);
> -
> ret = drm_property_replace_global_blob(dev,
> &connector->edid_blob_ptr,
> drm_edid ? drm_edid->size : 0,
> drm_edid ? drm_edid->edid : NULL,
> &connector->base,
> dev->mode_config.edid_property);
> - if (ret)
> - return ret;
> - return drm_connector_set_tile_property(connector);
> + if (ret) {
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID property update failed
> (%d)\n",
> + connector->base.id, connector->name, ret);
> + goto out;
> + }
> +
> + ret = drm_object_property_set_value(&connector->base,
> +
> dev->mode_config.non_desktop_property,
> +
> connector->display_info.non_desktop);
> + if (ret) {
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Non-desktop property update
> failed (%d)\n",
> + connector->base.id, connector->name, ret);
> + goto out;
> + }
> +
> + ret = drm_connector_set_tile_property(connector);
> + if (ret) {
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Tile property update failed
> (%d)\n",
> + connector->base.id, connector->name, ret);
> + goto out;
> + }
> +
> +out:
Could just return directly w/o the goto detour.
Or maybe this becomes useful later?
Reviewed-by: Ville Syrjälä
> + return ret;
> }
>
> /**
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v3 02/13] drm/edid: convert drm_connector_update_edid_property() to struct drm_edid
On Wed, Jun 22, 2022 at 01:59:16PM +0300, Jani Nikula wrote:
> Make drm_connector_update_edid_property() a thin wrapper around a struct
> drm_edid based version of the same.
>
> This lets us remove the legacy drm_update_tile_info() and
> drm_add_display_info() functions altogether.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 81 --
> 1 file changed, 35 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 36bf7b0fe8d9..62967db78139 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -6042,14 +6042,6 @@ static u32 update_display_info(struct drm_connector
> *connector,
> return quirks;
> }
>
> -static u32 drm_add_display_info(struct drm_connector *connector, const
> struct edid *edid)
> -{
> - struct drm_edid drm_edid;
> -
> - return update_display_info(connector,
> -drm_edid_legacy_init(&drm_edid, edid));
> -}
> -
> static struct drm_display_mode *drm_mode_displayid_detailed(struct
> drm_device *dev,
> struct
> displayid_detailed_timings_1 *timings,
> bool type_7)
> @@ -6206,38 +6198,19 @@ static int drm_edid_connector_update(struct
> drm_connector *connector,
> return num_modes;
> }
>
> -static void drm_update_tile_info(struct drm_connector *connector,
> - const struct edid *edid);
> +static void _drm_update_tile_info(struct drm_connector *connector,
> + const struct drm_edid *drm_edid);
>
> -/**
> - * drm_connector_update_edid_property - update the edid property of a
> connector
> - * @connector: drm connector
> - * @edid: new value of the edid property
> - *
> - * This function creates a new blob modeset object and assigns its id to the
> - * connector's edid property.
> - * Since we also parse tile information from EDID's displayID block, we also
> - * set the connector's tile property here. See
> drm_connector_set_tile_property()
> - * for more details.
> - *
> - * Returns:
> - * Zero on success, negative errno on failure.
> - */
> -int drm_connector_update_edid_property(struct drm_connector *connector,
> -const struct edid *edid)
> +static int _drm_connector_update_edid_property(struct drm_connector
> *connector,
> +const struct drm_edid *drm_edid)
> {
> struct drm_device *dev = connector->dev;
> - size_t size = 0;
> int ret;
> - const struct edid *old_edid;
>
> /* ignore requests to set edid when overridden */
> if (connector->override_edid)
> return 0;
>
> - if (edid)
> - size = EDID_LENGTH * (1 + edid->extensions);
> -
> /*
>* Set the display info, using edid if available, otherwise resetting
>* the values to defaults. This duplicates the work done in
> @@ -6246,17 +6219,18 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
>* that it seems better to duplicate it rather than attempt to ensure
>* some arbitrary ordering of calls.
>*/
> - if (edid)
> - drm_add_display_info(connector, edid);
> + if (drm_edid)
> + update_display_info(connector, drm_edid);
> else
> drm_reset_display_info(connector);
>
> - drm_update_tile_info(connector, edid);
> + _drm_update_tile_info(connector, drm_edid);
>
> if (connector->edid_blob_ptr) {
> - old_edid = (const struct edid *)connector->edid_blob_ptr->data;
> + const struct edid *old_edid = connector->edid_blob_ptr->data;
> +
> if (old_edid) {
> - if (!drm_edid_are_equal(edid, old_edid)) {
> + if (!drm_edid_are_equal(drm_edid ? drm_edid->edid :
> NULL, old_edid)) {
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
> changed.\n",
> connector->base.id,
> connector->name);
>
> @@ -6273,14 +6247,37 @@ int drm_connector_update_edid_property(struct
> drm_connector *connector,
>
> ret = drm_property_replace_global_blob(dev,
> &connector->edid_blob_ptr,
> -size,
> -edid,
> +drm_edid ? drm_edid->size : 0,
> +drm_edid ? drm_edid->edid : NULL,
> &connector->base,
> dev->mode_config.edid_property);
> if (ret)
> return ret;
> return drm_connector_set_tile_property(connector);
> }
> +
> +/*
Re: [Intel-gfx] [PATCH v3 01/13] drm/edid: move drm_connector_update_edid_property() to drm_edid.c
On Wed, Jun 22, 2022 at 01:59:15PM +0300, Jani Nikula wrote:
> The function needs access to drm_edid.c internals more than
> drm_connector.c. We can make drm_reset_display_info(),
> drm_add_display_info() and drm_update_tile_info() static. There will be
> more benefits with follow-up struct drm_edid refactoring.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_connector.c | 74 -
> drivers/gpu/drm/drm_crtc_internal.h | 3 -
> drivers/gpu/drm/drm_edid.c | 86 +++--
> 3 files changed, 81 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 28ea0f8196b9..2b9a8972eff1 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2078,80 +2078,6 @@ int drm_connector_set_tile_property(struct
> drm_connector *connector)
> }
> EXPORT_SYMBOL(drm_connector_set_tile_property);
>
> -/**
> - * drm_connector_update_edid_property - update the edid property of a
> connector
> - * @connector: drm connector
> - * @edid: new value of the edid property
> - *
> - * This function creates a new blob modeset object and assigns its id to the
> - * connector's edid property.
> - * Since we also parse tile information from EDID's displayID block, we also
> - * set the connector's tile property here. See
> drm_connector_set_tile_property()
> - * for more details.
> - *
> - * Returns:
> - * Zero on success, negative errno on failure.
> - */
> -int drm_connector_update_edid_property(struct drm_connector *connector,
> -const struct edid *edid)
> -{
> - struct drm_device *dev = connector->dev;
> - size_t size = 0;
> - int ret;
> - const struct edid *old_edid;
> -
> - /* ignore requests to set edid when overridden */
> - if (connector->override_edid)
> - return 0;
> -
> - if (edid)
> - size = EDID_LENGTH * (1 + edid->extensions);
> -
> - /* Set the display info, using edid if available, otherwise
> - * resetting the values to defaults. This duplicates the work
> - * done in drm_add_edid_modes, but that function is not
> - * consistently called before this one in all drivers and the
> - * computation is cheap enough that it seems better to
> - * duplicate it rather than attempt to ensure some arbitrary
> - * ordering of calls.
> - */
> - if (edid)
> - drm_add_display_info(connector, edid);
> - else
> - drm_reset_display_info(connector);
> -
> - drm_update_tile_info(connector, edid);
> -
> - if (connector->edid_blob_ptr) {
> - old_edid = (const struct edid *)connector->edid_blob_ptr->data;
> - if (old_edid) {
> - if (!drm_edid_are_equal(edid, old_edid)) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
> changed.\n",
> - connector->base.id,
> connector->name);
> -
> - connector->epoch_counter += 1;
> - DRM_DEBUG_KMS("Updating change counter to
> %llu\n",
> - connector->epoch_counter);
> - }
> - }
> - }
> -
> - drm_object_property_set_value(&connector->base,
> - dev->mode_config.non_desktop_property,
> - connector->display_info.non_desktop);
> -
> - ret = drm_property_replace_global_blob(dev,
> -&connector->edid_blob_ptr,
> -size,
> -edid,
> -&connector->base,
> -dev->mode_config.edid_property);
> - if (ret)
> - return ret;
> - return drm_connector_set_tile_property(connector);
> -}
> -EXPORT_SYMBOL(drm_connector_update_edid_property);
> -
> /**
> * drm_connector_set_link_status_property - Set link status property of a
> connector
> * @connector: drm connector
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 63279e984342..aecab5308bae 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -286,6 +286,3 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>
> /* drm_edid.c */
> void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
> -void drm_reset_display_info(struct drm_connector *connector);
> -u32 drm_add_display_info(struct drm_connector *connector, const struct edid
> *edid);
> -void drm_update_tile_info(struct drm_connector *connector, const struct edid
> *edid);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2bdaf1e34a9d..36bf7b0fe8d9 100644
> --- a/drivers/gpu
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915/selftests: ensure we reserve a fence slot
On Tue, 2022-06-21 at 11:44 +0100, Matthew Auld wrote:
> We should always be explicit and allocate a fence slot before adding
> a
> new fence.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Lionel Landwerlin
> Cc: Tvrtko Ursulin
> Cc: Jon Bloomfield
> Cc: Daniel Vetter
> Cc: Jordan Justen
> Cc: Kenneth Graunke
> Cc: Akeem G Abodunrin
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index 5bc93a1ce3e3..7c95b6768610 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -1221,8 +1221,10 @@ static int __igt_mmap_migrate(struct
> intel_memory_region **placements,
> expand32(POISON_INUSE),
> &rq);
> i915_gem_object_unpin_pages(obj);
> if (rq) {
> - dma_resv_add_fence(obj->base.resv, &rq->fence,
> - DMA_RESV_USAGE_KERNEL);
> + err = dma_resv_reserve_fences(obj->base.resv, 1);
> + if (!err)
> + dma_resv_add_fence(obj->base.resv, &rq-
> >fence,
> + DMA_RESV_USAGE_KERNEL);
> i915_request_put(rq);
> }
> i915_gem_object_unlock(obj);
Re: [Intel-gfx] [PATCH v2 03/12] drm/i915/uapi: expose the avail tracking
On Tue, 2022-06-21 at 11:44 +0100, Matthew Auld wrote:
> Vulkan would like to have a rough measure of how much device memory
> can
> in theory be allocated. Also add unallocated_cpu_visible_size to
> track
> the visible portion, in case the device is using small BAR. Also
> tweak
> the locking so we nice consistent values for both the mm->avail and
> the
> visible tracking.
>
> v2: tweak the locking slightly so we update the mm->avail and visible
> tracking as one atomic operation, such that userspace doesn't get
> strange values when sampling the values.
>
> Testcase: igt@i915_query@query-regions-unallocated
> Testcase: igt@i915_query@query-regions-sanity-check
> Signed-off-by: Matthew Auld
Note the kernel test robot warning for inconsistent kerneldoc and
function name.
With that fixed,
Reviewed-by: Thomas Hellström
> Cc: Thomas Hellström
> Cc: Lionel Landwerlin
> Cc: Tvrtko Ursulin
> Cc: Jon Bloomfield
> Cc: Daniel Vetter
> Cc: Jordan Justen
> Cc: Kenneth Graunke
> Cc: Akeem G Abodunrin
> ---
> drivers/gpu/drm/i915/i915_query.c | 10 +-
> drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 31 ++---
> --
> drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 3 ++
> drivers/gpu/drm/i915/intel_memory_region.c | 14 +
> drivers/gpu/drm/i915/intel_memory_region.h | 3 ++
> include/uapi/drm/i915_drm.h | 31
> ++-
> 6 files changed, 82 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_query.c
> b/drivers/gpu/drm/i915/i915_query.c
> index 9894add651dd..6ec9c9fb7b0d 100644
> --- a/drivers/gpu/drm/i915/i915_query.c
> +++ b/drivers/gpu/drm/i915/i915_query.c
> @@ -504,7 +504,15 @@ static int query_memregion_info(struct
> drm_i915_private *i915,
> else
> info.probed_cpu_visible_size = mr->total;
>
> - info.unallocated_size = mr->avail;
> + if (perfmon_capable()) {
> + intel_memory_region_avail(mr,
> +
> &info.unallocated_size,
> +
> &info.unallocated_cpu_visible_size);
> + } else {
> + info.unallocated_size = info.probed_size;
> + info.unallocated_cpu_visible_size =
> + info.probed_cpu_visible_size;
> + }
>
> if (__copy_to_user(info_ptr, &info, sizeof(info)))
> return -EFAULT;
> diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> index a5109548abc0..864c8f55cacb 100644
> --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> @@ -104,18 +104,15 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> min_page_size,
> &bman_res->blocks,
> bman_res->flags);
> - mutex_unlock(&bman->lock);
> if (unlikely(err))
> goto err_free_blocks;
>
> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
> u64 original_size = (u64)bman_res->base.num_pages <<
> PAGE_SHIFT;
>
> - mutex_lock(&bman->lock);
> drm_buddy_block_trim(mm,
> original_size,
> &bman_res->blocks);
> - mutex_unlock(&bman->lock);
> }
>
> if (lpfn <= bman->visible_size) {
> @@ -137,11 +134,10 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> }
> }
>
> - if (bman_res->used_visible_size) {
> - mutex_lock(&bman->lock);
> + if (bman_res->used_visible_size)
> bman->visible_avail -= bman_res->used_visible_size;
> - mutex_unlock(&bman->lock);
> - }
> +
> + mutex_unlock(&bman->lock);
>
> if (place->lpfn - place->fpfn == n_pages)
> bman_res->base.start = place->fpfn;
> @@ -154,7 +150,6 @@ static int i915_ttm_buddy_man_alloc(struct
> ttm_resource_manager *man,
> return 0;
>
> err_free_blocks:
> - mutex_lock(&bman->lock);
> drm_buddy_free_list(mm, &bman_res->blocks);
> mutex_unlock(&bman->lock);
> err_free_res:
> @@ -365,6 +360,26 @@ u64 i915_ttm_buddy_man_visible_size(struct
> ttm_resource_manager *man)
> return bman->visible_size;
> }
>
> +/**
> + * i915_ttm_buddy_man_visible_size - Query the avail tracking for
> the manager.
> + *
> + * @man: The buddy allocator ttm manager
> + * @avail: The total available memory in pages for the entire
> manager.
> + * @visible_avail: The total available memory in pages for the CPU
> visible
> + * portion. Note that this will always give the same value as @avail
> on
> + * configurations that don'
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Increase timeout for live_parallel_switch
On Wed, 22 Jun 2022 at 15:11, Matthew Auld wrote: > > From: Akeem G Abodunrin > > With GuC submission, it takes a little bit longer switching contexts > among all available engines simultaneously, when running > live_parallel_switch subtest. Increase the timeout. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5885 > Signed-off-by: Akeem G Abodunrin > Cc: Matthew Brost Reviewed-by: Matthew Auld > Signed-off-by: Matthew Auld > --- > drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c > index 93a67422ca3b..c6ad67b90e8a 100644 > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c > @@ -212,7 +212,7 @@ static int __live_parallel_switch1(void *data) > > i915_request_add(rq); > } > - if (i915_request_wait(rq, 0, HZ / 5) < 0) > + if (i915_request_wait(rq, 0, HZ) < 0) > err = -ETIME; > i915_request_put(rq); > if (err) > -- > 2.36.1 >
[Intel-gfx] [PATCH] drm/i915/selftests: Increase timeout for live_parallel_switch
From: Akeem G Abodunrin With GuC submission, it takes a little bit longer switching contexts among all available engines simultaneously, when running live_parallel_switch subtest. Increase the timeout. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5885 Signed-off-by: Akeem G Abodunrin Cc: Matthew Brost Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c index 93a67422ca3b..c6ad67b90e8a 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c @@ -212,7 +212,7 @@ static int __live_parallel_switch1(void *data) i915_request_add(rq); } - if (i915_request_wait(rq, 0, HZ / 5) < 0) + if (i915_request_wait(rq, 0, HZ) < 0) err = -ETIME; i915_request_put(rq); if (err) -- 2.36.1
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
On Wed, Jun 22, 2022 at 11:04:51AM +1000, Stephen Rothwell wrote: > Hi all, > > On Tue, 21 Jun 2022 10:48:17 +0300 Ville Syrjälä > wrote: > > > > On Tue, Jun 21, 2022 at 12:36:56PM +1000, Stephen Rothwell wrote: > > > > > > After merging the drm-misc tree, today's linux-next build (x86_64 > > > allmodconfig) failed like this: > > > > > > drivers/gpu/drm/xlnx/zynqmp_disp.c: In function > > > 'zynqmp_disp_create_planes': > > > drivers/gpu/drm/xlnx/zynqmp_disp.c:1260:17: error: implicit declaration > > > of function 'drm_plane_create_zpos_immutable_property'; did you mean > > > 'drm_plane_create_scaling_filter_property'? > > > [-Werror=implicit-function-declaration] > > > 1260 | > > > drm_plane_create_zpos_immutable_property(&layer->plane, i); > > > | ^~~~ > > > | drm_plane_create_scaling_filter_property > > > drivers/gpu/drm/xlnx/zynqmp_disp.c:1262:25: error: implicit declaration > > > of function 'drm_plane_create_alpha_property'; did you mean > > > 'drm_plane_create_color_properties'? > > > [-Werror=implicit-function-declaration] > > > 1262 | > > > drm_plane_create_alpha_property(&layer->plane); > > > | ^~~ > > > | drm_plane_create_color_properties > > > cc1: all warnings being treated as errors > > > > > > Presumably caused by one of the commits that dropped includes from > > > drm-ctrc.h. > > > > > > I have used the drm-misc tree from next-20220620 for today. > > > > Sorry about that. Looks like my .config was missing some > > dependencies of the zynqmp driver so it wasn't getting built. > > I'll cook up a fix. > > And today, I get these: > > In file included from include/linux/list.h:5, > from include/linux/preempt.h:11, > from include/linux/spinlock.h:55, > from include/linux/mmzone.h:8, > from include/linux/gfp.h:6, > from include/linux/mm.h:7, > from include/linux/hyperv.h:17, > from drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:6: > drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function > 'hyperv_blit_to_vram_rect': > drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:25:48: error: invalid use of > undefined type 'struct drm_framebuffer' > cc1: all warnings being treated as errors > > Please do some allmodconfig builds. Ugh, I really wish kconfig had a reasonable way to enable exactly the things I want rather than having to build absolutely everything... Anyways, someone else beat me to a fix: https://lists.freedesktop.org/archives/dri-devel/2022-June/360608.html Sorry for the continued woes. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 04/11] drm/i915: Added is_intel_rpm_allowed helper
On Tue, 21 Jun 2022, "Tangudu, Tilak" wrote:
>> -Original Message-
>> From: Gupta, Anshuman
>> Sent: Tuesday, June 21, 2022 7:47 PM
>> To: Tangudu, Tilak ;
>> intel-gfx@lists.freedesktop.org;
>> Ewins, Jon ; Vivi, Rodrigo ;
>> Belgaumkar, Vinay ; Wilson, Chris P
>> ; Dixit, Ashutosh ;
>> Nilawar, Badal ; Roper, Matthew D
>> ; Gupta, saurabhg
>> ; Iddamsetty, Aravind
>> ; Sundaresan, Sujaritha
>>
>> Subject: RE: [PATCH 04/11] drm/i915: Added is_intel_rpm_allowed helper
>>
>>
>>
>> > -Original Message-
>> > From: Tangudu, Tilak
>> > Sent: Tuesday, June 21, 2022 6:05 PM
>> > To: intel-gfx@lists.freedesktop.org; Ewins, Jon ;
>> > Vivi, Rodrigo ; Belgaumkar, Vinay
>> > ; Wilson, Chris P
>> > ; Dixit, Ashutosh
>> > ; Nilawar, Badal ;
>> > Gupta, Anshuman ; Tangudu, Tilak
>> > ; Roper, Matthew D
>> > ; Gupta, saurabhg
>> > ; Iddamsetty, Aravind
>> > ; Sundaresan, Sujaritha
>> >
>> > Subject: [PATCH 04/11] drm/i915: Added is_intel_rpm_allowed helper
>> >
>> > Added is_intel_rpm_allowed function to query the runtime_pm status and
>> > disllow during suspending and resuming.
>> This seems a hack,
>> Not sure if we have better way to handle it.
>> May be check this in intel_pm_runtime_{get,put} to keep entire code simple ?
> Yes, that would be simple without code refactoring.
> Checked the same with Chris, he suggested unbalancing of wakeref might popup
> If used at intel_pm_runtime_{get,put} . So used like this,
> @Wilson, Chris P , Please comment .
> @Vivi, Rodrigo , Any suggestion ?
One option would be to track this in intel_wakeref_t, i.e. _get flags
the case in the returned wakeref and _put skips in that case.
BR,
Jani.
>
>> >
>> > Signed-off-by: Tilak Tangudu
>> > ---
>> > drivers/gpu/drm/i915/intel_runtime_pm.c | 15 +++
>> > drivers/gpu/drm/i915/intel_runtime_pm.h | 1 +
>> > 2 files changed, 16 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> > index 6ed5786bcd29..3759a8596084 100644
>> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> > @@ -320,6 +320,21 @@ untrack_all_intel_runtime_pm_wakerefs(struct
>> > intel_runtime_pm *rpm) }
>> >
>> > #endif
>> > +static int intel_runtime_pm_status(struct intel_runtime_pm *rpm) {
>> > +return rpm->kdev->power.runtime_status; }
>> This is racy in principal, we need a kdev->power lock here.
>> Regards,
>> Anshuman Gupta.
>> > +
>> > +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm) { int
>> > +rpm_status;
>> > +
>> > +rpm_status = intel_runtime_pm_status(rpm); if (rpm_status ==
>> > +RPM_RESUMING || rpm_status ==
>> > RPM_SUSPENDING)
>> > +return false;
>> > +else
>> > +return true;
>> > +}
>> >
>> > static void
>> > intel_runtime_pm_acquire(struct intel_runtime_pm *rpm, bool wakelock)
>> > diff -- git a/drivers/gpu/drm/i915/intel_runtime_pm.h
>> > b/drivers/gpu/drm/i915/intel_runtime_pm.h
>> > index d9160e3ff4af..99418c3a934a 100644
>> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.h
>> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
>> > @@ -173,6 +173,7 @@ void intel_runtime_pm_init_early(struct
>> > intel_runtime_pm *rpm); void intel_runtime_pm_enable(struct
>> > intel_runtime_pm *rpm); void intel_runtime_pm_disable(struct
>> > intel_runtime_pm *rpm); void intel_runtime_pm_driver_release(struct
>> > intel_runtime_pm *rpm);
>> > +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm);
>> >
>> > intel_wakeref_t intel_runtime_pm_get(struct intel_runtime_pm *rpm);
>> > intel_wakeref_t intel_runtime_pm_get_if_in_use(struct intel_runtime_pm
>> > *rpm);
>> > --
>> > 2.25.1
>>
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Guard rpm helpers in gt helpers functions
On Tue, 21 Jun 2022, Tilak Tangudu wrote:
> Guard rpm helpers in gt_sanitize and intel_gt_set_wedged
> with is_intel_rpm_allowed
>
> Acquire rpm wakeref for higherlevel function i915_gem_resume
>
> Signed-off-by: Tilak Tangudu
> ---
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 ++--
> drivers/gpu/drm/i915/gt/intel_reset.c | 10 +++---
> drivers/gpu/drm/i915/i915_driver.c| 4 +++-
> 3 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index be99b01a0984..9857b91194b7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -163,12 +163,14 @@ static void gt_sanitize(struct intel_gt *gt, bool force)
> {
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
> - intel_wakeref_t wakeref;
> + intel_wakeref_t wakeref = 0;
We've got intel_wakeref_t to hide what it actually is. You shouldn't
assume you can assign 0 to it or use wakeref in an if condition. You
should treat it as opaque. You should assume the typedef could be
switched to a struct and you shouldn't have to change the code using it.
BR,
Jani.
>
> GT_TRACE(gt, "force:%s", str_yes_no(force));
>
> /* Use a raw wakeref to avoid calling intel_display_power_get early */
> - wakeref = intel_runtime_pm_get(gt->uncore->rpm);
> + if (is_intel_rpm_allowed(gt->uncore->rpm))
> + wakeref = intel_runtime_pm_get(gt->uncore->rpm);
> +
> intel_uncore_forcewake_get(gt->uncore, FORCEWAKE_ALL);
>
> intel_gt_check_clock_frequency(gt);
> @@ -207,7 +209,8 @@ static void gt_sanitize(struct intel_gt *gt, bool force)
> intel_rps_sanitize(>->rps);
>
> intel_uncore_forcewake_put(gt->uncore, FORCEWAKE_ALL);
> - intel_runtime_pm_put(gt->uncore->rpm, wakeref);
> + if (wakeref)
> + intel_runtime_pm_put(gt->uncore->rpm, wakeref);
> }
>
> void intel_gt_pm_fini(struct intel_gt *gt)
> @@ -226,7 +229,6 @@ int intel_gt_resume(struct intel_gt *gt)
> return err;
>
> GT_TRACE(gt, "\n");
> -
> /*
>* After resume, we may need to poke into the pinned kernel
>* contexts to paper over any damage caused by the sudden suspend.
> @@ -259,10 +261,8 @@ int intel_gt_resume(struct intel_gt *gt)
>
> for_each_engine(engine, gt, id) {
> intel_engine_pm_get(engine);
> -
> engine->serial++; /* kernel context lost */
> err = intel_engine_resume(engine);
> -
> intel_engine_pm_put(engine);
> if (err) {
> drm_err(>->i915->drm,
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index c8e05b48c14f..55a1fd38c7c4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -901,12 +901,14 @@ static void __intel_gt_set_wedged(struct intel_gt *gt)
>
> void intel_gt_set_wedged(struct intel_gt *gt)
> {
> - intel_wakeref_t wakeref;
> + intel_wakeref_t wakeref = 0;
>
> if (test_bit(I915_WEDGED, >->reset.flags))
> return;
>
> - wakeref = intel_runtime_pm_get(gt->uncore->rpm);
> + if (is_intel_rpm_allowed(gt->uncore->rpm))
> + wakeref = intel_runtime_pm_get(gt->uncore->rpm);
> +
> mutex_lock(>->reset.mutex);
>
> if (GEM_SHOW_DEBUG()) {
> @@ -926,7 +928,9 @@ void intel_gt_set_wedged(struct intel_gt *gt)
> __intel_gt_set_wedged(gt);
>
> mutex_unlock(>->reset.mutex);
> - intel_runtime_pm_put(gt->uncore->rpm, wakeref);
> +
> + if (wakeref)
> + intel_runtime_pm_put(gt->uncore->rpm, wakeref);
> }
>
> static bool __intel_gt_unset_wedged(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index d26dcca7e654..60f6fcc6b71d 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1263,6 +1263,7 @@ int i915_driver_suspend_switcheroo(struct
> drm_i915_private *i915,
> static int i915_drm_resume(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> + intel_wakeref_t wakeref;
> int ret;
>
> disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> @@ -1303,7 +1304,8 @@ static int i915_drm_resume(struct drm_device *dev)
> if (HAS_DISPLAY(dev_priv))
> drm_mode_config_reset(dev);
>
> - i915_gem_resume(dev_priv);
> + with_intel_runtime_pm(&dev_priv->runtime_pm, wakeref)
> + i915_gem_resume(dev_priv);
>
> intel_modeset_init_hw(dev_priv);
> intel_init_clock_gating(dev_priv);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v8 08/10] drm/i915: allow memory region creators to alloc and free the region
Hi, Bob,
On Tue, 2022-06-21 at 20:00 +, Robert Beckett wrote:
> add callbacks for alloc and free.
> this allows region creators to allocate any extra storage they may
> require.
>
> Signed-off-by: Robert Beckett
I think the correct solution here would be to, similar to ttm, export
an alloc_reserved() or alloc_locked() interface, that simply skips the
unlock at bo alloc time.
Then the stolen alloc wrapper could simply pin as/if needed under the
lock.
/Thomas
> ---
> drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
> drivers/gpu/drm/i915/intel_memory_region.h | 2 ++
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
> b/drivers/gpu/drm/i915/intel_memory_region.c
> index e38d2db1c3e3..3da07a712f90 100644
> --- a/drivers/gpu/drm/i915/intel_memory_region.c
> +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> @@ -231,7 +231,10 @@ intel_memory_region_create(struct
> drm_i915_private *i915,
> struct intel_memory_region *mem;
> int err;
>
> - mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> + if (ops->alloc)
> + mem = ops->alloc();
> + else
> + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
> if (!mem)
> return ERR_PTR(-ENOMEM);
>
> @@ -265,7 +268,10 @@ intel_memory_region_create(struct
> drm_i915_private *i915,
> if (mem->ops->release)
> mem->ops->release(mem);
> err_free:
> - kfree(mem);
> + if (mem->ops->free)
> + mem->ops->free(mem);
> + else
> + kfree(mem);
> return ERR_PTR(err);
> }
>
> @@ -288,7 +294,11 @@ void intel_memory_region_destroy(struct
> intel_memory_region *mem)
>
> GEM_WARN_ON(!list_empty_careful(&mem->objects.list));
> mutex_destroy(&mem->objects.lock);
> - if (!ret)
> + if (ret)
> + return;
> + if (mem->ops->free)
> + mem->ops->free(mem);
> + else
> kfree(mem);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
> b/drivers/gpu/drm/i915/intel_memory_region.h
> index 3d8378c1b447..048955b5429f 100644
> --- a/drivers/gpu/drm/i915/intel_memory_region.h
> +++ b/drivers/gpu/drm/i915/intel_memory_region.h
> @@ -61,6 +61,8 @@ struct intel_memory_region_ops {
> resource_size_t size,
> resource_size_t page_size,
> unsigned int flags);
> + struct intel_memory_region *(*alloc)(void);
> + void (*free)(struct intel_memory_region *mem);
> };
>
> struct intel_memory_region {
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2022-06-22: drm/i915 fixes for v5.19-rc4: - Revert low voltage SKU check removal to fix display issues - Apply PLL DCO fraction workaround for ADL-S - Don't show engine classes not present in client fdinfo BR, Jani. The following changes since commit a111daf0c53ae91e71fd2bfe7497862d14132e3e: Linux 5.19-rc3 (2022-06-19 15:06:47 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-06-22 for you to fetch changes up to c7b28f52f406bc89d15ca0ccbc47994f979f2fcd: drm/i915/display: Re-add check for low voltage sku for max dp source rate (2022-06-20 19:39:00 +0300) drm/i915 fixes for v5.19-rc4: - Revert low voltage SKU check removal to fix display issues - Apply PLL DCO fraction workaround for ADL-S - Don't show engine classes not present in client fdinfo Jason A. Donenfeld (1): drm/i915/display: Re-add check for low voltage sku for max dp source rate Tvrtko Ursulin (1): drm/i915/fdinfo: Don't show engine classes not present Ville Syrjälä (1): drm/i915: Implement w/a 22010492432 for adl-s drivers/gpu/drm/i915/display/intel_dp.c | 32 --- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 4 ++-- drivers/gpu/drm/i915/i915_drm_client.c| 5 +++-- 3 files changed, 34 insertions(+), 7 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v8 04/10] drm/i915/gem: selftest should not attempt mmap of private regions
On Tue, 2022-06-21 at 20:00 +, Robert Beckett wrote: > During testing make can_mmap consider whether the region is private. > > Signed-off-by: Robert Beckett LGTM. Reviewed-by: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > index 5bc93a1ce3e3..76181e28c75e 100644 > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > @@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object > *obj, enum i915_mmap_type type) > struct drm_i915_private *i915 = to_i915(obj->base.dev); > bool no_map; > > + if (obj->mm.region && obj->mm.region->private) > + return false; > + > if (obj->ops->mmap_offset) > return type == I915_MMAP_TYPE_FIXED; > else if (type == I915_MMAP_TYPE_FIXED)
[Intel-gfx] i915: crash with 5.19-rc2
Hello While somewhat oldish hw (T61, 4G, C2D) - I've now witnessed new crash with Xorg: (happened while reopening iconified Firefox window - running 'standard' rawhide -nodebug kernel 5.19.0-0.rc2.21.fc37.x86_64) page:577758b3 refcount:0 mapcount:0 mapping: index:0x1 pfn:0x1192cc flags: 0x17c000(node=0|zone=2|lastcpupid=0x1f) raw: 0017c000 e683c47171c8 8fa3f79377a8 raw: 0001 page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio)) [ cut here ] kernel BUG at mm/shmem.c:708! invalid opcode: [#1] PREEMPT SMP NOPTI CPU: 1 PID: 42896 Comm: Xorg Not tainted 5.19.0-0.rc2.21.fc37.x86_64 #1 Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011 RIP: 0010:shmem_add_to_page_cache+0x48e/0x500 Code: 01 0f 84 0a fc ff ff 48 8d 4a ff 31 d2 48 39 cb 0f 85 ff fb ff ff e9 f6 fb ff ff 48 c7 c6 70 01 64 bb 48 89 df e8 f2 99 01 00 <0f> 0b 48 c7 c6 a0 1b 64 bb 48 89 df e8 e1 99 01 00 0f 0b 48 8b 13 RSP: 0018:9ce7c047f6b0 EFLAGS: 00010286 RAX: 003f RBX: e683c464b300 RCX: RDX: 0001 RSI: bb67b8e8 RDI: RBP: 00023f97 R08: bca122a0 R09: 64656b636f6c5f74 R10: 747365745f6f696c R11: 6f6621284f494c4f R12: 001120d4 R13: 8fa2c6ae7890 R14: e683c464b300 R15: 0001 FS: 7fc1cea31380() GS:8fa3f790() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f6972e228c8 CR3: 000104ba8000 CR4: 06e0 Call Trace: shmem_swapin_folio+0x274/0x980 shmem_getpage_gfp+0x234/0x990 shmem_read_mapping_page_gfp+0x36/0xf0 shmem_sg_alloc_table+0x11b/0x250 [i915] shmem_get_pages+0xaa/0x310 [i915] __i915_gem_object_get_pages+0x31/0x40 [i915] i915_vma_pin_ww+0x69d/0x920 [i915] eb_validate_vmas+0x17d/0x7a0 [i915] ? eb_pin_engine+0x262/0x2d0 [i915] i915_gem_do_execbuffer+0xd43/0x2c00 [i915] ? refill_obj_stock+0x102/0x1a0 ? unix_stream_read_generic+0x1ea/0xa60 ? unix_stream_read_generic+0x1ea/0xa60 ? _raw_spin_lock_irqsave+0x23/0x50 ? _atomic_dec_and_lock_irqsave+0x38/0x60 ? __active_retire+0xb7/0x100 [i915] ? _raw_spin_unlock_irqrestore+0x23/0x40 ? dma_fence_signal+0x39/0x50 ? dma_resv_iter_walk_unlocked.part.0+0x164/0x170 i915_gem_execbuffer2_ioctl+0x115/0x270 [i915] ? i915_gem_do_execbuffer+0x2c00/0x2c00 [i915] drm_ioctl_kernel+0x9b/0x140 ? __check_object_size+0x47/0x260 drm_ioctl+0x21c/0x410 ? i915_gem_do_execbuffer+0x2c00/0x2c00 [i915] ? exit_to_user_mode_prepare+0x17d/0x1f0 __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x58/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fc1cf28da9f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:7ffe5f52e1c0 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7ffe5f52e250 RCX: 7fc1cf28da9f RDX: 7ffe5f52e250 RSI: 40406469 RDI: 000d RBP: 000d R08: 7fc1ce938410 R09: 7fc1cf2fa4c0 R10: R11: 0246 R12: 55e2dde0d340 R13: 0114 R14: 7ffe5f52e250 R15: 7fc1cdc49000 Modules linked in: tls rfcomm snd_seq_dummy snd_hrtimer xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter ip_tables bridge stp llc bnep binfmt_misc btusb btrtl btbcm btintel btmtk bluetooth ecdh_generic snd_hda_codec_analog snd_hda_codec_generic iwl3945 iwlegacy coretemp kvm_intel mac80211 snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi libarc4 kvm iTCO_wdt snd_hda_codec intel_pmc_bxt iTCO_vendor_support snd_hda_core snd_hwdep snd_seq snd_seq_device cfg80211 irqbypass snd_pcm thinkpad_acpi pcspkr joydev i2c_i801 snd_timer i2c_smbus ledtrig_audio wmi_bmof r592 platform_profile snd memstick rfkill lpc_ich soundcore acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse zram i915 sdhci_pci cqhci sdhci drm_buddy drm_display_helper e1000e mmc_core cec serio_raw yenta_socket ttm wmi video ata_generic pata_acpi scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_multipath ---[ end trace ]--- RIP: 0010:shmem_add_to_page_cache+0x48e/0x500 Code: 01 0f 84 0a fc ff ff 48 8d 4a ff 31 d2 48 39 cb 0f 85 ff fb ff ff e9 f6 fb ff ff 48 c7 c6 70 01 64 bb 48 89 df e8 f2 99 01 00 <0f> 0b 48 c7 c6 a0 1b 64 bb 48 89 df e8 e1 99 01 00 0f 0b 48 8b 13 RSP: 0018:9ce7c047f6b0 EFLAGS: 00010286 RAX: 003f RBX: e683c464b300 RCX: RDX: 0001 RSI: bb67b8e8 RDI: ff
[Intel-gfx] [PATCH v3 13/13] drm/todo: add entry for converting the subsystem to struct drm_edid
We need to stop duplicating EDID validation and parsing all over the
subsystem in various broken ways.
v2: Update to reflect drm_connector_helper_get_modes()
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Jani Nikula
---
Documentation/gpu/todo.rst | 25 +
1 file changed, 25 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 513b20ccef1e..04ef31e3405f 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -480,6 +480,31 @@ Contact: Thomas Zimmermann
Level: Starter
+Convert core and drivers from struct edid to struct drm_edid
+
+
+Go through all drivers and drm core KMS code to convert all raw struct edid
+usage to the opaque struct drm_edid. See commit e4ccf9a777d3 ("drm/edid: add
+struct drm_edid container") for rationale.
+
+Convert drm_get_edid() and drm_do_get_edid() usage to drm_edid_read(),
+drm_edid_read_ddc(), or drm_edid_read_custom().
+
+Convert drm_add_edid_modes() and drm_connector_update_edid_property() to
+drm_edid_connector_update(). See drm_connector_helper_get_modes() for reference
+for converting the ->get_modes() hooks.
+
+Convert decentralized, direct struct edid parsing to centralized parsing in
+drm_edid.c. Prefer one-time parsing as part of drm_edid_connector_update() and
+storing the result in drm_connector->display_info over adding individual,
+exported parser functions.
+
+During the transition period, it may be necessary to use drm_edid_raw(), but do
+use it sparingly. Eventually, all of them need to go.
+
+Contact: Jani Nikula
+
+Level: Intermediate
Core refactorings
=
--
2.30.2
[Intel-gfx] [PATCH v3 12/13] drm/edid: take HF-EEODB extension count into account
Take the HF-EEODB extension count override into account.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fa3a3e294560..bbc25e3b7220 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1629,6 +1629,19 @@ static int drm_edid_block_count(const struct drm_edid
*drm_edid)
/* Starting point */
num_blocks = edid_block_count(drm_edid->edid);
+ /* HF-EEODB override */
+ if (drm_edid->size >= edid_size_by_blocks(2)) {
+ int eeodb;
+
+ /*
+* Note: HF-EEODB may specify a smaller extension count than the
+* regular one. Unlike in buffer allocation, here we can use it.
+*/
+ eeodb = edid_hfeeodb_block_count(drm_edid->edid);
+ if (eeodb)
+ num_blocks = eeodb;
+ }
+
/* Limit by allocated size */
num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
--
2.30.2
[Intel-gfx] [PATCH v3 11/13] drm/edid: add HF-EEODB support to EDID read and allocation
HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
Data Block, which may contain a different extension count than the base
block claims. Add support for reading more EDID data if available. The
extra blocks aren't parsed yet, though.
Hard-coding the EEODB parsing instead of using the iterators we have is
a bit of a bummer, but we have to be able to do this on a partially
allocated EDID while reading it.
v2:
- Check for CEA Data Block Collection size (Ville)
- Amend commit message and comment about hard-coded parsing
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 89 --
1 file changed, 86 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a80ea0aa7b32..fa3a3e294560 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1581,6 +1581,15 @@ static bool version_greater(const struct drm_edid
*drm_edid,
(edid->version == version && edid->revision > revision);
}
+static int edid_hfeeodb_extension_block_count(const struct edid *edid);
+
+static int edid_hfeeodb_block_count(const struct edid *edid)
+{
+ int eeodb = edid_hfeeodb_extension_block_count(edid);
+
+ return eeodb ? eeodb + 1 : 0;
+}
+
static int edid_extension_block_count(const struct edid *edid)
{
return edid->extensions;
@@ -2026,6 +2035,11 @@ static struct edid *edid_filter_invalid_blocks(struct
edid *edid,
struct edid *new;
int i, valid_blocks = 0;
+ /*
+* Note: If the EDID uses HF-EEODB, but has invalid blocks, we'll revert
+* back to regular extension count here. We don't want to start
+* modifying the HF-EEODB extension too.
+*/
for (i = 0; i < edid_block_count(edid); i++) {
const void *src_block = edid_block_data(edid, i);
@@ -2261,7 +2275,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
size_t *size)
{
enum edid_block_status status;
- int i, invalid_blocks = 0;
+ int i, num_blocks, invalid_blocks = 0;
struct edid *edid, *new;
size_t alloc_size = EDID_LENGTH;
@@ -2303,7 +2317,8 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
goto fail;
edid = new;
- for (i = 1; i < edid_block_count(edid); i++) {
+ num_blocks = edid_block_count(edid);
+ for (i = 1; i < num_blocks; i++) {
void *block = (void *)edid_block_data(edid, i);
status = edid_block_read(block, i, read_block, context);
@@ -2314,11 +2329,31 @@ static struct edid *_drm_do_get_edid(struct
drm_connector *connector,
if (status == EDID_BLOCK_READ_FAIL)
goto fail;
invalid_blocks++;
+ } else if (i == 1) {
+ /*
+* If the first EDID extension is a CTA extension, and
+* the first Data Block is HF-EEODB, override the
+* extension block count.
+*
+* Note: HF-EEODB could specify a smaller extension
+* count too, but we can't risk allocating a smaller
+* amount.
+*/
+ int eeodb = edid_hfeeodb_block_count(edid);
+
+ if (eeodb > num_blocks) {
+ num_blocks = eeodb;
+ alloc_size = edid_size_by_blocks(num_blocks);
+ new = krealloc(edid, alloc_size, GFP_KERNEL);
+ if (!new)
+ goto fail;
+ edid = new;
+ }
}
}
if (invalid_blocks) {
- connector_bad_edid(connector, edid, edid_block_count(edid));
+ connector_bad_edid(connector, edid, num_blocks);
edid = edid_filter_invalid_blocks(edid, &alloc_size);
}
@@ -3851,6 +3886,7 @@ static int add_detailed_modes(struct drm_connector
*connector,
#define CTA_EXT_DB_HDR_STATIC_METADATA 6
#define CTA_EXT_DB_420_VIDEO_DATA 14
#define CTA_EXT_DB_420_VIDEO_CAP_MAP 15
+#define CTA_EXT_DB_HF_EEODB0x78
#define CTA_EXT_DB_HF_SCDB 0x79
#define EDID_BASIC_AUDIO (1 << 6)
@@ -4910,6 +4946,12 @@ static bool cea_db_is_hdmi_forum_vsdb(const struct
cea_db *db)
cea_db_payload_len(db) >= 7;
}
+static bool cea_db_is_hdmi_forum_eeodb(const void *db)
+{
+ return cea_db_is_extended_tag(db, CTA_EXT_DB_HF_EEODB) &&
+ cea_db_payload_len(db) >= 2;
+}
+
static bool cea_db_is_microsoft_vsdb(const struct cea_db *db)
{
return cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
@@ -4944,6
[Intel-gfx] [PATCH v3 10/13] drm/edid: do invalid block filtering in-place
Rewrite edid_filter_invalid_blocks() to filter invalid blocks
in-place. The main motivation is to not rely on passed in information on
invalid block count or the allocation size, which will be helpful in
follow-up work on HF-EEODB.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 43 --
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1c761e12820e..a80ea0aa7b32 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2020,33 +2020,37 @@ bool drm_edid_is_valid(struct edid *edid)
}
EXPORT_SYMBOL(drm_edid_is_valid);
-static struct edid *edid_filter_invalid_blocks(const struct edid *edid,
- int invalid_blocks,
+static struct edid *edid_filter_invalid_blocks(struct edid *edid,
size_t *alloc_size)
{
- struct edid *new, *dest_block;
- int valid_extensions = edid->extensions - invalid_blocks;
- int i;
+ struct edid *new;
+ int i, valid_blocks = 0;
- *alloc_size = edid_size_by_blocks(valid_extensions + 1);
+ for (i = 0; i < edid_block_count(edid); i++) {
+ const void *src_block = edid_block_data(edid, i);
- new = kmalloc(*alloc_size, GFP_KERNEL);
- if (!new)
- goto out;
+ if (edid_block_valid(src_block, i == 0)) {
+ void *dst_block = (void *)edid_block_data(edid,
valid_blocks);
- dest_block = new;
- for (i = 0; i < edid_block_count(edid); i++) {
- const void *block = edid_block_data(edid, i);
+ memmove(dst_block, src_block, EDID_LENGTH);
+ valid_blocks++;
+ }
+ }
- if (edid_block_valid(block, i == 0))
- memcpy(dest_block++, block, EDID_LENGTH);
+ /* We already trusted the base block to be valid here... */
+ if (WARN_ON(!valid_blocks)) {
+ kfree(edid);
+ return NULL;
}
- new->extensions = valid_extensions;
- new->checksum = edid_block_compute_checksum(new);
+ edid->extensions = valid_blocks - 1;
+ edid->checksum = edid_block_compute_checksum(edid);
-out:
- kfree(edid);
+ *alloc_size = edid_size_by_blocks(valid_blocks);
+
+ new = krealloc(edid, *alloc_size, GFP_KERNEL);
+ if (!new)
+ kfree(edid);
return new;
}
@@ -2316,8 +2320,7 @@ static struct edid *_drm_do_get_edid(struct drm_connector
*connector,
if (invalid_blocks) {
connector_bad_edid(connector, edid, edid_block_count(edid));
- edid = edid_filter_invalid_blocks(edid, invalid_blocks,
- &alloc_size);
+ edid = edid_filter_invalid_blocks(edid, &alloc_size);
}
ok:
--
2.30.2
[Intel-gfx] [PATCH v3 09/13] drm/i915/bios: convert intel_bios_init_panel() to drm_edid
Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 19 ++-
drivers/gpu/drm/i915/display/intel_bios.h | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_lvds.c | 2 +-
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index ab23324c0402..553fdb3a4be7 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -606,14 +606,14 @@ get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
static int opregion_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
return intel_opregion_get_panel_type(i915);
}
static int vbt_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
const struct bdb_lvds_options *lvds_options;
@@ -638,12 +638,13 @@ static int vbt_get_panel_type(struct drm_i915_private
*i915,
static int pnpid_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
const struct bdb_lvds_lfp_data *data;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
const struct lvds_pnp_id *edid_id;
struct lvds_pnp_id edid_id_nodate;
+ const struct edid *edid = drm_edid_raw(drm_edid); /* FIXME */
int i, best = -1;
if (!edid)
@@ -685,7 +686,7 @@ static int pnpid_get_panel_type(struct drm_i915_private
*i915,
static int fallback_get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
return 0;
}
@@ -699,13 +700,13 @@ enum panel_type {
static int get_panel_type(struct drm_i915_private *i915,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
struct {
const char *name;
int (*get_panel_type)(struct drm_i915_private *i915,
const struct intel_bios_encoder_data
*devdata,
- const struct edid *edid);
+ const struct drm_edid *drm_edid);
int panel_type;
} panel_types[] = {
[PANEL_TYPE_OPREGION] = {
@@ -728,7 +729,7 @@ static int get_panel_type(struct drm_i915_private *i915,
int i;
for (i = 0; i < ARRAY_SIZE(panel_types); i++) {
- panel_types[i].panel_type = panel_types[i].get_panel_type(i915,
devdata, edid);
+ panel_types[i].panel_type = panel_types[i].get_panel_type(i915,
devdata, drm_edid);
drm_WARN_ON(&i915->drm, panel_types[i].panel_type > 0xf &&
panel_types[i].panel_type != 0xff);
@@ -3140,11 +3141,11 @@ void intel_bios_init(struct drm_i915_private *i915)
void intel_bios_init_panel(struct drm_i915_private *i915,
struct intel_panel *panel,
const struct intel_bios_encoder_data *devdata,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
init_vbt_panel_defaults(panel);
- panel->vbt.panel_type = get_panel_type(i915, devdata, edid);
+ panel->vbt.panel_type = get_panel_type(i915, devdata, drm_edid);
parse_panel_options(i915, panel);
parse_generic_dtd(i915, panel);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index e47582b0de0a..defea578a768 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -32,8 +32,8 @@
#include
+struct drm_edid;
struct drm_i915_private;
-struct edid;
struct intel_bios_encoder_data;
struct intel_crtc_state;
struct intel_encoder;
@@ -235,7 +235,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv);
void intel_bios_init_panel(struct drm_i915_private *dev_priv,
struct intel_panel *panel,
const struct int
[Intel-gfx] [PATCH v3 08/13] drm/i915/edid: convert DP, HDMI and LVDS to drm_edid
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
v2: Don't leak opregion fallback EDID (Ville)
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_connector.c| 4 +-
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 77 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 26 ---
drivers/gpu/drm/i915/display/intel_lvds.c | 37 +
5 files changed, 81 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 1dcc268927a2..d83b2a64f618 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -95,12 +95,12 @@ void intel_connector_destroy(struct drm_connector
*connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
- kfree(intel_connector->detect_edid);
+ drm_edid_free(intel_connector->detect_edid);
intel_hdcp_cleanup(intel_connector);
if (!IS_ERR_OR_NULL(intel_connector->edid))
- kfree(intel_connector->edid);
+ drm_edid_free(intel_connector->edid);
intel_panel_fini(intel_connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..d476df0ac9df 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -592,8 +592,8 @@ struct intel_connector {
struct intel_panel panel;
/* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
- struct edid *edid;
- struct edid *detect_edid;
+ const struct drm_edid *edid;
+ const struct drm_edid *detect_edid;
/* Number of times hotplug detection was tried after an HPD interrupt */
int hotplug_retries;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 32292c0be2bd..4ee35317cf2a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3577,12 +3577,11 @@ static u8 intel_dp_autotest_edid(struct intel_dp
*intel_dp)
intel_dp->aux.i2c_defer_count);
intel_dp->compliance.test_data.edid =
INTEL_DP_RESOLUTION_FAILSAFE;
} else {
- struct edid *block = intel_connector->detect_edid;
+ /* FIXME: Get rid of drm_edid_raw() */
+ const struct edid *block =
drm_edid_raw(intel_connector->detect_edid);
- /* We have to write the checksum
-* of the last block read
-*/
- block += intel_connector->detect_edid->extensions;
+ /* We have to write the checksum of the last block read */
+ block += block->extensions;
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_EDID_CHECKSUM,
block->checksum) <= 0)
@@ -4461,7 +4460,7 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
return is_connected;
}
-static struct edid *
+static const struct drm_edid *
intel_dp_get_edid(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
@@ -4472,18 +4471,22 @@ intel_dp_get_edid(struct intel_dp *intel_dp)
if (IS_ERR(intel_connector->edid))
return NULL;
- return drm_edid_duplicate(intel_connector->edid);
+ return drm_edid_dup(intel_connector->edid);
} else
- return drm_get_edid(&intel_connector->base,
- &intel_dp->aux.ddc);
+ return drm_edid_read_ddc(&intel_connector->base,
+&intel_dp->aux.ddc);
}
static void
intel_dp_update_dfp(struct intel_dp *intel_dp,
- const struct edid *edid)
+ const struct drm_edid *drm_edid)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
+ const struct edid *edid;
+
+ /* FIXME: Get rid of drm_edid_raw() */
+ edid = drm_edid_raw(drm_edid);
intel_dp->dfp.max_bpc =
drm_dp_downstream_max_bpc(intel_dp->dpcd,
@@ -4583,21 +4586,24 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
+ const struct edid *edid;
bool vrr_capable;
intel_dp_unset_edid(intel_dp);
- edid = intel_dp_get_edid(intel_dp);
- connector->detect_edid = edid;
+ drm_edid = intel_dp_get_edid(intel_dp);
+ conn
[Intel-gfx] [PATCH v3 07/13] drm/edid: add drm_edid_raw() to access the raw EDID data
Unfortunately, there are still plenty of interfaces around that require
a struct edid pointer, and it's impossible to change them all at
once. Add an accessor to the raw EDID data to help the transition.
While there are no such cases now, be defensive against raw EDID
extension count indicating bigger EDID than is actually allocated.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 26 ++
include/drm/drm_edid.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 41b3de52b8f1..1c761e12820e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2359,6 +2359,32 @@ struct edid *drm_do_get_edid(struct drm_connector
*connector,
}
EXPORT_SYMBOL_GPL(drm_do_get_edid);
+/**
+ * drm_edid_raw - Get a pointer to the raw EDID data.
+ * @drm_edid: drm_edid container
+ *
+ * Get a pointer to the raw EDID data.
+ *
+ * This is for transition only. Avoid using this like the plague.
+ *
+ * Return: Pointer to raw EDID data.
+ */
+const struct edid *drm_edid_raw(const struct drm_edid *drm_edid)
+{
+ if (!drm_edid || !drm_edid->size)
+ return NULL;
+
+ /*
+* Do not return pointers where relying on EDID extension count would
+* lead to buffer overflow.
+*/
+ if (WARN_ON(edid_size(drm_edid->edid) > drm_edid->size))
+ return NULL;
+
+ return drm_edid->edid;
+}
+EXPORT_SYMBOL(drm_edid_raw);
+
/* Allocate struct drm_edid container *without* duplicating the edid data */
static const struct drm_edid *_drm_edid_alloc(const void *edid, size_t size)
{
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index aeb2fa95bc04..2181977ae683 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -597,6 +597,7 @@ drm_display_mode_from_cea_vic(struct drm_device *dev,
const struct drm_edid *drm_edid_alloc(const void *edid, size_t size);
const struct drm_edid *drm_edid_dup(const struct drm_edid *drm_edid);
void drm_edid_free(const struct drm_edid *drm_edid);
+const struct edid *drm_edid_raw(const struct drm_edid *drm_edid);
const struct drm_edid *drm_edid_read(struct drm_connector *connector);
const struct drm_edid *drm_edid_read_ddc(struct drm_connector *connector,
struct i2c_adapter *adapter);
--
2.30.2
[Intel-gfx] [PATCH v3 06/13] drm/probe-helper: add drm_connector_helper_get_modes()
Add a helper function to be used as the "default" .get_modes()
hook. This also works as an example of what the driver .get_modes()
hooks are supposed to do regarding the new drm_edid_read*() and
drm_edid_connector_update() calls.
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_probe_helper.c | 34 ++
include/drm/drm_probe_helper.h | 1 +
2 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index a8d26b29bfa0..bb427c5a4f1f 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -1049,3 +1049,37 @@ int drm_connector_helper_get_modes_from_ddc(struct
drm_connector *connector)
return count;
}
EXPORT_SYMBOL(drm_connector_helper_get_modes_from_ddc);
+
+/**
+ * drm_connector_helper_get_modes - Read EDID and update connector.
+ * @connector: The connector
+ *
+ * Read the EDID using drm_edid_read() (which requires that connector->ddc is
+ * set), and update the connector using the EDID.
+ *
+ * This can be used as the "default" connector helper .get_modes() hook if the
+ * driver does not need any special processing. This is sets the example what
+ * custom .get_modes() hooks should do regarding EDID read and connector
update.
+ *
+ * Returns: Number of modes.
+ */
+int drm_connector_helper_get_modes(struct drm_connector *connector)
+{
+ const struct drm_edid *drm_edid;
+ int count;
+
+ drm_edid = drm_edid_read(connector);
+
+ /*
+* Unconditionally update the connector. If the EDID was read
+* successfully, fill in the connector information derived from the
+* EDID. Otherwise, if the EDID is NULL, clear the connector
+* information.
+*/
+ count = drm_edid_connector_update(connector, drm_edid);
+
+ drm_edid_free(drm_edid);
+
+ return count;
+}
+EXPORT_SYMBOL(drm_connector_helper_get_modes);
diff --git a/include/drm/drm_probe_helper.h b/include/drm/drm_probe_helper.h
index c80cab7a53b7..8075e02aa865 100644
--- a/include/drm/drm_probe_helper.h
+++ b/include/drm/drm_probe_helper.h
@@ -27,5 +27,6 @@ void drm_kms_helper_poll_enable(struct drm_device *dev);
bool drm_kms_helper_is_poll_worker(void);
int drm_connector_helper_get_modes_from_ddc(struct drm_connector *connector);
+int drm_connector_helper_get_modes(struct drm_connector *connector);
#endif
--
2.30.2
[Intel-gfx] [PATCH v3 05/13] drm/edid: add drm_edid_connector_update()
Add a new function drm_edid_connector_update() to replace the
combination of calls drm_connector_update_edid_property() and
drm_add_edid_modes(). Usually they are called in the drivers in this
order, however the former needs information from the latter.
Since the new drm_edid_read*() functions no longer call the connector
updates directly, and the read and update are separated, we'll need this
new function for the connector update.
This is all in drm_edid.c simply to keep struct drm_edid opaque.
v2:
- Share code with drm_connector_update_edid_property() (Ville)
- Add comment about override EDID handling
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 103 -
include/drm/drm_edid.h | 2 +
2 files changed, 81 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c3f0f0a5a8a9..41b3de52b8f1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6160,8 +6160,8 @@ static int add_displayid_detailed_modes(struct
drm_connector *connector,
return num_modes;
}
-static int drm_edid_connector_update(struct drm_connector *connector,
-const struct drm_edid *drm_edid)
+static int _drm_edid_connector_update(struct drm_connector *connector,
+ const struct drm_edid *drm_edid)
{
int num_modes = 0;
u32 quirks;
@@ -6227,31 +6227,12 @@ static int drm_edid_connector_update(struct
drm_connector *connector,
static void _drm_update_tile_info(struct drm_connector *connector,
const struct drm_edid *drm_edid);
-static int _drm_connector_update_edid_property(struct drm_connector *connector,
+static int _drm_edid_connector_property_update(struct drm_connector *connector,
const struct drm_edid *drm_edid)
{
struct drm_device *dev = connector->dev;
int ret;
- /* ignore requests to set edid when overridden */
- if (connector->override_edid)
- return 0;
-
- /*
-* Set the display info, using edid if available, otherwise resetting
-* the values to defaults. This duplicates the work done in
-* drm_add_edid_modes, but that function is not consistently called
-* before this one in all drivers and the computation is cheap enough
-* that it seems better to duplicate it rather than attempt to ensure
-* some arbitrary ordering of calls.
-*/
- if (drm_edid)
- update_display_info(connector, drm_edid);
- else
- drm_reset_display_info(connector);
-
- _drm_update_tile_info(connector, drm_edid);
-
if (connector->edid_blob_ptr) {
const struct edid *old_edid = connector->edid_blob_ptr->data;
@@ -6297,6 +6278,76 @@ static int _drm_connector_update_edid_property(struct
drm_connector *connector,
return ret;
}
+/**
+ * drm_edid_connector_update - Update connector information from EDID
+ * @connector: Connector
+ * @drm_edid: EDID
+ *
+ * Update the connector mode list, display info, ELD, HDR metadata, relevant
+ * properties, etc. from the passed in EDID.
+ *
+ * If EDID is NULL, reset the information.
+ *
+ * Return: The number of modes added or 0 if we couldn't find any.
+ */
+int drm_edid_connector_update(struct drm_connector *connector,
+ const struct drm_edid *drm_edid)
+{
+ int count;
+
+ /*
+* FIXME: Reconcile the differences in override_edid handling between
+* this and drm_connector_update_edid_property().
+*
+* If override_edid is set, and the EDID passed in here originates from
+* drm_edid_read() and friends, it will be the override EDID, and there
+* are no issues. drm_connector_update_edid_property() ignoring requests
+* to set the EDID dates back to a time when override EDID was not
+* handled at the low level EDID read.
+*
+* The only way the EDID passed in here can be different from the
+* override EDID is when a driver passes in an EDID that does *not*
+* originate from drm_edid_read() and friends, or passes in a stale
+* cached version. This, in turn, is a question of when an override EDID
+* set via debugfs should take effect.
+*/
+
+ count = _drm_edid_connector_update(connector, drm_edid);
+
+ _drm_update_tile_info(connector, drm_edid);
+
+ /* Note: Ignore errors for now. */
+ _drm_edid_connector_property_update(connector, drm_edid);
+
+ return count;
+}
+EXPORT_SYMBOL(drm_edid_connector_update);
+
+static int _drm_connector_update_edid_property(struct drm_connector *connector,
+ const struct drm_edid *drm_edid)
+{
+ /* ignore requests to set edid when overridden */
+ if (connector->override_edid)
+
[Intel-gfx] [PATCH v3 04/13] drm/edid: abstract debugfs override EDID set/reset
Add functions drm_edid_override_set() and drm_edid_override_reset() to
support "edid_override" connector debugfs, and to hide the details about
it in drm_edid.c. No functional changes at this time.
Also note in the connector.override_edid flag kernel-doc that this is
only supposed to be modified by the code doing debugfs EDID override
handling. Currently, it is still being modified by amdgpu in
create_eml_sink() and handle_edid_mgmt() for reasons unknown. This was
added in commit 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
and later moved to amdgpu_dm.c in commit e7b07ceef2a6 ("drm/amd/display:
Merge amdgpu_dm_types and amdgpu_dm").
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
drivers/gpu/drm/drm_debugfs.c | 21 +
drivers/gpu/drm/drm_edid.c | 26 ++
include/drm/drm_connector.h | 6 +-
4 files changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index aecab5308bae..56041b604881 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -286,3 +286,5 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
/* drm_edid.c */
void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
+int drm_edid_override_set(struct drm_connector *connector, const void *edid,
size_t size);
+int drm_edid_override_reset(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index fb04b7a984de..493922069c90 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -350,31 +350,20 @@ static ssize_t edid_write(struct file *file, const char
__user *ubuf,
struct seq_file *m = file->private_data;
struct drm_connector *connector = m->private;
char *buf;
- struct edid *edid;
int ret;
buf = memdup_user(ubuf, len);
if (IS_ERR(buf))
return PTR_ERR(buf);
- edid = (struct edid *) buf;
-
- if (len == 5 && !strncmp(buf, "reset", 5)) {
- connector->override_edid = false;
- ret = drm_connector_update_edid_property(connector, NULL);
- } else if (len < EDID_LENGTH ||
- EDID_LENGTH * (1 + edid->extensions) > len)
- ret = -EINVAL;
- else {
- connector->override_edid = false;
- ret = drm_connector_update_edid_property(connector, edid);
- if (!ret)
- connector->override_edid = true;
- }
+ if (len == 5 && !strncmp(buf, "reset", 5))
+ ret = drm_edid_override_reset(connector);
+ else
+ ret = drm_edid_override_set(connector, buf, len);
kfree(buf);
- return (ret) ? ret : len;
+ return ret ? ret : len;
}
/*
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e360e1a269f4..c3f0f0a5a8a9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2161,6 +2161,32 @@ static struct edid *drm_get_override_edid(struct
drm_connector *connector,
return IS_ERR(override) ? NULL : override;
}
+/* For debugfs edid_override implementation */
+int drm_edid_override_set(struct drm_connector *connector, const void *edid,
+ size_t size)
+{
+ int ret;
+
+ if (size < EDID_LENGTH || edid_size(edid) > size)
+ return -EINVAL;
+
+ connector->override_edid = false;
+
+ ret = drm_connector_update_edid_property(connector, edid);
+ if (!ret)
+ connector->override_edid = true;
+
+ return ret;
+}
+
+/* For debugfs edid_override implementation */
+int drm_edid_override_reset(struct drm_connector *connector)
+{
+ connector->override_edid = false;
+
+ return drm_connector_update_edid_property(connector, NULL);
+}
+
/**
* drm_add_override_edid_modes - add modes from override/firmware EDID
* @connector: connector we're probing
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 94b422b55cc1..a1705d6b3fba 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1527,7 +1527,11 @@ struct drm_connector {
struct drm_cmdline_mode cmdline_mode;
/** @force: a DRM_FORCE_ state for forced mode sets */
enum drm_connector_force force;
- /** @override_edid: has the EDID been overwritten through debugfs for
testing? */
+ /**
+* @override_edid: has the EDID been overwritten through debugfs for
+* testing? Do not modify outside of drm_edid_override_set() and
+* drm_edid_override_reset().
+*/
bool override_edid;
/** @epoch_counter: used to detect any other changes in connector,
besides status */
u64 epoch_counter;
--
2.30.2
[Intel-gfx] [PATCH v3 03/13] drm/edid: clean up connector update error handling and debug logging
Bail out on all errors, debug log all errors, and convert to drm device
based debug logging.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 41 ++
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 62967db78139..e360e1a269f4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6231,29 +6231,44 @@ static int _drm_connector_update_edid_property(struct
drm_connector *connector,
if (old_edid) {
if (!drm_edid_are_equal(drm_edid ? drm_edid->edid :
NULL, old_edid)) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
changed.\n",
- connector->base.id,
connector->name);
-
- connector->epoch_counter += 1;
- DRM_DEBUG_KMS("Updating change counter to
%llu\n",
- connector->epoch_counter);
+ connector->epoch_counter++;
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID
changed, epoch counter %llu\n",
+ connector->base.id, connector->name,
+ connector->epoch_counter);
}
}
}
- drm_object_property_set_value(&connector->base,
- dev->mode_config.non_desktop_property,
- connector->display_info.non_desktop);
-
ret = drm_property_replace_global_blob(dev,
&connector->edid_blob_ptr,
drm_edid ? drm_edid->size : 0,
drm_edid ? drm_edid->edid : NULL,
&connector->base,
dev->mode_config.edid_property);
- if (ret)
- return ret;
- return drm_connector_set_tile_property(connector);
+ if (ret) {
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] EDID property update failed
(%d)\n",
+ connector->base.id, connector->name, ret);
+ goto out;
+ }
+
+ ret = drm_object_property_set_value(&connector->base,
+
dev->mode_config.non_desktop_property,
+
connector->display_info.non_desktop);
+ if (ret) {
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Non-desktop property update
failed (%d)\n",
+ connector->base.id, connector->name, ret);
+ goto out;
+ }
+
+ ret = drm_connector_set_tile_property(connector);
+ if (ret) {
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Tile property update failed
(%d)\n",
+ connector->base.id, connector->name, ret);
+ goto out;
+ }
+
+out:
+ return ret;
}
/**
--
2.30.2
[Intel-gfx] [PATCH v3 02/13] drm/edid: convert drm_connector_update_edid_property() to struct drm_edid
Make drm_connector_update_edid_property() a thin wrapper around a struct
drm_edid based version of the same.
This lets us remove the legacy drm_update_tile_info() and
drm_add_display_info() functions altogether.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 81 --
1 file changed, 35 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 36bf7b0fe8d9..62967db78139 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6042,14 +6042,6 @@ static u32 update_display_info(struct drm_connector
*connector,
return quirks;
}
-static u32 drm_add_display_info(struct drm_connector *connector, const struct
edid *edid)
-{
- struct drm_edid drm_edid;
-
- return update_display_info(connector,
- drm_edid_legacy_init(&drm_edid, edid));
-}
-
static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device
*dev,
struct
displayid_detailed_timings_1 *timings,
bool type_7)
@@ -6206,38 +6198,19 @@ static int drm_edid_connector_update(struct
drm_connector *connector,
return num_modes;
}
-static void drm_update_tile_info(struct drm_connector *connector,
-const struct edid *edid);
+static void _drm_update_tile_info(struct drm_connector *connector,
+ const struct drm_edid *drm_edid);
-/**
- * drm_connector_update_edid_property - update the edid property of a connector
- * @connector: drm connector
- * @edid: new value of the edid property
- *
- * This function creates a new blob modeset object and assigns its id to the
- * connector's edid property.
- * Since we also parse tile information from EDID's displayID block, we also
- * set the connector's tile property here. See
drm_connector_set_tile_property()
- * for more details.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_update_edid_property(struct drm_connector *connector,
- const struct edid *edid)
+static int _drm_connector_update_edid_property(struct drm_connector *connector,
+ const struct drm_edid *drm_edid)
{
struct drm_device *dev = connector->dev;
- size_t size = 0;
int ret;
- const struct edid *old_edid;
/* ignore requests to set edid when overridden */
if (connector->override_edid)
return 0;
- if (edid)
- size = EDID_LENGTH * (1 + edid->extensions);
-
/*
* Set the display info, using edid if available, otherwise resetting
* the values to defaults. This duplicates the work done in
@@ -6246,17 +6219,18 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
* that it seems better to duplicate it rather than attempt to ensure
* some arbitrary ordering of calls.
*/
- if (edid)
- drm_add_display_info(connector, edid);
+ if (drm_edid)
+ update_display_info(connector, drm_edid);
else
drm_reset_display_info(connector);
- drm_update_tile_info(connector, edid);
+ _drm_update_tile_info(connector, drm_edid);
if (connector->edid_blob_ptr) {
- old_edid = (const struct edid *)connector->edid_blob_ptr->data;
+ const struct edid *old_edid = connector->edid_blob_ptr->data;
+
if (old_edid) {
- if (!drm_edid_are_equal(edid, old_edid)) {
+ if (!drm_edid_are_equal(drm_edid ? drm_edid->edid :
NULL, old_edid)) {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
changed.\n",
connector->base.id,
connector->name);
@@ -6273,14 +6247,37 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
ret = drm_property_replace_global_blob(dev,
&connector->edid_blob_ptr,
- size,
- edid,
+ drm_edid ? drm_edid->size : 0,
+ drm_edid ? drm_edid->edid : NULL,
&connector->base,
dev->mode_config.edid_property);
if (ret)
return ret;
return drm_connector_set_tile_property(connector);
}
+
+/**
+ * drm_connector_update_edid_property - update the edid property of a connector
+ * @connector: drm connector
+ * @edid: new value of the edid property
+ *
+ * This function creates a new blob modeset object and assigns its id to the
+
[Intel-gfx] [PATCH v3 01/13] drm/edid: move drm_connector_update_edid_property() to drm_edid.c
The function needs access to drm_edid.c internals more than
drm_connector.c. We can make drm_reset_display_info(),
drm_add_display_info() and drm_update_tile_info() static. There will be
more benefits with follow-up struct drm_edid refactoring.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_connector.c | 74 -
drivers/gpu/drm/drm_crtc_internal.h | 3 -
drivers/gpu/drm/drm_edid.c | 86 +++--
3 files changed, 81 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 28ea0f8196b9..2b9a8972eff1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2078,80 +2078,6 @@ int drm_connector_set_tile_property(struct drm_connector
*connector)
}
EXPORT_SYMBOL(drm_connector_set_tile_property);
-/**
- * drm_connector_update_edid_property - update the edid property of a connector
- * @connector: drm connector
- * @edid: new value of the edid property
- *
- * This function creates a new blob modeset object and assigns its id to the
- * connector's edid property.
- * Since we also parse tile information from EDID's displayID block, we also
- * set the connector's tile property here. See
drm_connector_set_tile_property()
- * for more details.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_update_edid_property(struct drm_connector *connector,
- const struct edid *edid)
-{
- struct drm_device *dev = connector->dev;
- size_t size = 0;
- int ret;
- const struct edid *old_edid;
-
- /* ignore requests to set edid when overridden */
- if (connector->override_edid)
- return 0;
-
- if (edid)
- size = EDID_LENGTH * (1 + edid->extensions);
-
- /* Set the display info, using edid if available, otherwise
-* resetting the values to defaults. This duplicates the work
-* done in drm_add_edid_modes, but that function is not
-* consistently called before this one in all drivers and the
-* computation is cheap enough that it seems better to
-* duplicate it rather than attempt to ensure some arbitrary
-* ordering of calls.
-*/
- if (edid)
- drm_add_display_info(connector, edid);
- else
- drm_reset_display_info(connector);
-
- drm_update_tile_info(connector, edid);
-
- if (connector->edid_blob_ptr) {
- old_edid = (const struct edid *)connector->edid_blob_ptr->data;
- if (old_edid) {
- if (!drm_edid_are_equal(edid, old_edid)) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Edid was
changed.\n",
- connector->base.id,
connector->name);
-
- connector->epoch_counter += 1;
- DRM_DEBUG_KMS("Updating change counter to
%llu\n",
- connector->epoch_counter);
- }
- }
- }
-
- drm_object_property_set_value(&connector->base,
- dev->mode_config.non_desktop_property,
- connector->display_info.non_desktop);
-
- ret = drm_property_replace_global_blob(dev,
- &connector->edid_blob_ptr,
- size,
- edid,
- &connector->base,
- dev->mode_config.edid_property);
- if (ret)
- return ret;
- return drm_connector_set_tile_property(connector);
-}
-EXPORT_SYMBOL(drm_connector_update_edid_property);
-
/**
* drm_connector_set_link_status_property - Set link status property of a
connector
* @connector: drm connector
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 63279e984342..aecab5308bae 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -286,6 +286,3 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
/* drm_edid.c */
void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
-void drm_reset_display_info(struct drm_connector *connector);
-u32 drm_add_display_info(struct drm_connector *connector, const struct edid
*edid);
-void drm_update_tile_info(struct drm_connector *connector, const struct edid
*edid);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2bdaf1e34a9d..36bf7b0fe8d9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5928,8 +5928,7 @@ static void drm_update_mso(struct drm_connector
*connector,
/* A connector has no EDID information, so we've got no EDID to compute quirks
from. Reset
* all of the
[Intel-gfx] [PATCH v3 00/13] drm/edid: expand on struct drm_edid usage
v3 of [1], addressing review comments. I'm adding some code movement and refactoring in the beginning to reuse code between drm_connector_update_edid_property() and drm_edid_connector_update() which was a concern Ville raised [2]. BR, Jani. [1] https://patchwork.freedesktop.org/series/104309/ [2] https://lore.kernel.org/r/yqoyojtsboqho...@intel.com Jani Nikula (13): drm/edid: move drm_connector_update_edid_property() to drm_edid.c drm/edid: convert drm_connector_update_edid_property() to struct drm_edid drm/edid: clean up connector update error handling and debug logging drm/edid: abstract debugfs override EDID set/reset drm/edid: add drm_edid_connector_update() drm/probe-helper: add drm_connector_helper_get_modes() drm/edid: add drm_edid_raw() to access the raw EDID data drm/i915/edid: convert DP, HDMI and LVDS to drm_edid drm/i915/bios: convert intel_bios_init_panel() to drm_edid drm/edid: do invalid block filtering in-place drm/edid: add HF-EEODB support to EDID read and allocation drm/edid: take HF-EEODB extension count into account drm/todo: add entry for converting the subsystem to struct drm_edid Documentation/gpu/todo.rst| 25 ++ drivers/gpu/drm/drm_connector.c | 74 drivers/gpu/drm/drm_crtc_internal.h | 5 +- drivers/gpu/drm/drm_debugfs.c | 21 +- drivers/gpu/drm/drm_edid.c| 376 +++--- drivers/gpu/drm/drm_probe_helper.c| 34 ++ drivers/gpu/drm/i915/display/intel_bios.c | 19 +- drivers/gpu/drm/i915/display/intel_bios.h | 4 +- .../gpu/drm/i915/display/intel_connector.c| 4 +- .../drm/i915/display/intel_display_types.h| 4 +- drivers/gpu/drm/i915/display/intel_dp.c | 77 ++-- drivers/gpu/drm/i915/display/intel_hdmi.c | 26 +- drivers/gpu/drm/i915/display/intel_lvds.c | 37 +- include/drm/drm_connector.h | 6 +- include/drm/drm_edid.h| 3 + include/drm/drm_probe_helper.h| 1 + 16 files changed, 499 insertions(+), 217 deletions(-) -- 2.30.2
Re: [Intel-gfx] [PATCH v8 03/10] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level
On 6/21/22 22:00, Robert Beckett wrote:
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.
Yeah, IIRC Matthew mentioned that HAS_SNOOP() can be overridden in
various ways, but not on DGFX, (at least not for DG1). So this looks
correct to me.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 4c1de0b4a10f..40249fa28a7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -46,7 +46,9 @@ static enum i915_cache_level
i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
struct ttm_tt *ttm)
{
- return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+ bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+ return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
Re: [Intel-gfx] [PATCH v8 02/10] drm/i915: limit ttm to dma32 for i965G[M]
On 6/21/22 22:00, Robert Beckett wrote:
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
LGTM.
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..fd2ecfdd8fa1 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
{
struct drm_device *drm = &dev_priv->drm;
+ bool use_dma32 = false;
+
+ /* i965g[m] cannot relocate objects above 4GiB. */
+ if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+ use_dma32 = true;
return ttm_device_init(&dev_priv->bdev, i915_ttm_driver(),
drm->dev, drm->anon_inode->i_mapping,
- drm->vma_offset_manager, false, false);
+ drm->vma_offset_manager, false, use_dma32);
}
/**
Re: [Intel-gfx] [PATCH v8 01/10] drm/i915/ttm: dont trample cache_level overrides during ttm move
On 6/21/22 22:00, Robert Beckett wrote:
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.
Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.
Signed-off-by: Robert Beckett
LGTM.
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 06b1b188ce5a..519887769c08 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
obj->cache_level = cache_level;
+ obj->ttm.cache_level_override = true;
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
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 2c88bdb8ff7c..6632ed52e919 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -605,6 +605,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+ bool cache_level_override:1;
} ttm;
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..27d59639177f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1241,6 +1241,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+ obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..4c1de0b4a10f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -123,9 +123,12 @@ void i915_ttm_adjust_gem_after_move(struct
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ?
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
- cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
- bo->ttm);
- i915_gem_object_set_cache_coherency(obj, cache_level);
+ if (!obj->ttm.cache_level_override) {
+ cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+ bo->resource, bo->ttm);
+ i915_gem_object_set_cache_coherency(obj, cache_level);
+ obj->ttm.cache_level_override = false;
+ }
}
/**
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix i915_vma_pin_iomap()
On Tue, 21 Jun 2022 at 19:38, Juha-Pekka Heikkila wrote: > > On 21.6.2022 13.53, Matthew Auld wrote: > > On Mon, 20 Jun 2022 at 10:38, Juha-Pekka Heikkila > > wrote: > >> > >> On 10.6.2022 20.43, Matthew Auld wrote: > >>> On Fri, 10 Jun 2022 at 15:53, Matthew Auld > >>> wrote: > > On Fri, 10 Jun 2022 at 13:12, Juha-Pekka Heikkila > wrote: > > > > From: CQ Tang > > > > Display might allocate a smem object and call > > i915_vma_pin_iomap(), the existing code will fail. > > > > This fix was suggested by Chris P Wilson, that we pin > > the smem with i915_gem_object_pin_map_unlocked(). > > > > v2 (jheikkil): Change i915_gem_object_pin_map_unlocked to > > i915_gem_object_pin_map > > > > Signed-off-by: CQ Tang > > Signed-off-by: Juha-Pekka Heikkila > > Cc: Chris Wilson > > Cc: Jari Tahvanainen > Reviewed-by: Matthew Auld > >>> > >>> Although maybe consider putting this as patch 1, and then reword the > >>> commit title/message to be more like "drm/i915: extend > >>> i915_vma_iomap()" or so, which then becomes a prep patch for > >>> supporting the dpt fallback to smem. Otherwise it looks like this > >>> patch is basically just fixing the first patch to not trigger the > >>> WARN_ON(), which seems iffy IMO. Each patch by itself should ideally > >>> be functional. > >> > >> Probably easiest is to put patch 1 in as last, it's the final customer > >> for these two other patches. This way if someone will end up doing > >> bisecting there would be nothing interesting to see with these. > >> > >> I did finally get ci to look all green after last weeks outages. I'd > >> guess these patches are ready to be pushed but I don't have commit > >> rights to drm-tip. Are you able to help with these or I'll go bother > >> Imre or Jani to get them into tip? > > > > Ok, if no objections I will go ahead and push this to > > drm-intel-gt-next, with the tweaked patch ordering. > > No objections. I had this set yet on test run on Imre's wish on try-bot > with forcing adlp (on bat) to use smem and results were all clean. And pushed. Thanks for the patches. > > /Juha-Pekka
