[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
== Series Details ==
Series: drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
URL : https://patchwork.freedesktop.org/series/74100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8035 -> Patchwork_16772
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/index.html
Known issues
Here are the changes found in Patchwork_16772 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@basic:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402])
+1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-tgl-y/igt@gem_flink_ba...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_selftest@live@gem_contexts:
- fi-cml-s: [PASS][3] -> [DMESG-FAIL][4] ([i915#877])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][5] ([CI#94]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8]
+1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-tgl-y/igt@gem_mmap_...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][9] ([i915#424]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [DMESG-FAIL][11] ([i915#541]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [FAIL][14] ([fdo#111096]
/ [i915#323])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#998]: https://gitlab.freedesktop.org/drm/intel/issues/998
Participating hosts (48 -> 36)
--
Additional (3): fi-cfl-8109u fi-bwr-2160 fi-kbl-r
Missing(15): fi-tgl-dsi fi-bsw-n3050 fi-glk-dsi fi-byt-squawks
fi-bsw-cyan fi-snb-2520m fi-ilk-650 fi-ctg-p8600 fi-gdg-551 fi-skl-lmem
fi-bdw-samus fi-byt-clapper fi-bsw-nick fi-skl-6600u fi-snb-2600
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8035 -> Patchwork_16772
CI-20190529: 20190529
CI_DRM_8035: cacad502dcd40516c6a9be38ca3ef0c1288f4cf4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16772: 983ed114d770b6d3f542ca959c02450ff64faf9d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
983ed114d770 drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16772/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
== Series Details ==
Series: drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
URL : https://patchwork.freedesktop.org/series/74100/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
983ed114d770 drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
-:43: WARNING:LONG_LINE: line over 100 characters
#43: FILE: drivers/gpu/drm/drm_dp_helper.c:1242:
+ { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
-:57: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#57: FILE: drivers/gpu/drm/i915/display/intel_dp.c:178:
+ if (drm_dp_has_quirk(_dp->desc,
+ DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
total: 0 errors, 1 warnings, 1 checks, 34 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
This fixes a problem found on the MacBookPro 2017 Retina panel.
The panel reports 10 bpc color depth in its EDID, and the
firmware chooses link settings at boot which support enough
bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
but the DP_MAX_LINK_RATE dpcd register only reports
2.7 Gbps (multiplier value 0xa) as possible, in direct
contradiction of what the firmware successfully set up.
This restricts the panel to 8 bpc, not providing the full
color depth of the panel.
This patch adds a quirk specific to the MBP 2017 15" Retina
panel to add the additiional 324000 kbps link rate during
edp setup.
Link to previous discussion of a different attempted fix
with Ville and Jani:
https://patchwork.kernel.org/patch/11325935/
Signed-off-by: Mario Kleiner
Cc: Ville Syrjälä
Cc: Jani Nikula
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp.c | 7 +++
include/drm/drm_dp_helper.h | 7 +++
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5a103e9b3c86..36a371c016cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1179,6 +1179,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
/* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
+ /* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
DP_MAX_LINK_RATE */
+ { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
};
#undef OUI
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4074d83b1a5f..1f6bd659ad41 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -178,6 +178,13 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
}
intel_dp->num_sink_rates = i;
+
+ if (drm_dp_has_quirk(_dp->desc,
+ DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
+ /* Needed for Apple MBP 2017, 15 inch eDP Retina panel */
+ intel_dp->sink_rates[i] = 324000;
+ intel_dp->num_sink_rates++;
+ }
}
/* Get length of rates array potentially limited by max_rate. */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 262faf9e5e94..4b86a1f2a559 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1532,6 +1532,13 @@ enum drm_dp_quirk {
* The DSC caps can be read from the physical aux instead.
*/
DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
+ /**
+* @DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS:
+*
+* The device supports a link rate of 3.24 Gbps (multiplier 0xc) despite
+* the DP_MAX_LINK_RATE register reporting a lower max multiplier.
+*/
+ DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
};
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm managed resources, v3
== Series Details == Series: drm managed resources, v3 URL : https://patchwork.freedesktop.org/series/74035/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8022_full -> Patchwork_16742_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16742_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16742_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16742_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@requests: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-iclb7/igt@i915_selftest@m...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-iclb6/igt@i915_selftest@m...@requests.html * igt@i915_selftest@mock@timelines: - shard-skl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-skl1/igt@i915_selftest@m...@timelines.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-skl3/igt@i915_selftest@m...@timelines.html - shard-tglb: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-tglb8/igt@i915_selftest@m...@timelines.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-tglb2/igt@i915_selftest@m...@timelines.html * igt@runner@aborted: - shard-tglb: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-tglb2/igt@run...@aborted.html New tests - New tests have been introduced between CI_DRM_8022_full and Patchwork_16742_full: ### New IGT tests (3) ### * igt@i915_selftest@mock: - Statuses : - Exec time: [None] s * igt@i915_selftest@perf: - Statuses : - Exec time: [None] s * igt@kms_selftest@all: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_16742_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][8] -> [INCOMPLETE][9] ([fdo#103665]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-kbl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_isolation@vcs1-dirty-create: - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#112080]) +14 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-iclb2/igt@gem_ctx_isolat...@vcs1-dirty-create.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-iclb5/igt@gem_ctx_isolat...@vcs1-dirty-create.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#110841]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#1277]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-tglb5/igt@gem_exec_balan...@hang.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-tglb7/igt@gem_exec_balan...@hang.html * igt@gem_exec_schedule@implicit-both-bsd2: - shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109276] / [i915#677]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd2.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd2.html * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#109276]) +20 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-iclb2/igt@gem_exec_sched...@out-order-bsd2.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-iclb5/igt@gem_exec_sched...@out-order-bsd2.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][20] -> [SKIP][21] ([i915#677]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8022/shard-iclb5/igt@gem_exec_sched...@pi-shared-iova-bsd.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16742/shard-iclb2/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@preempt-hang-bsd: - shard-iclb:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix kbuild test robot build error (rev2)
== Series Details == Series: drm/i915: Fix kbuild test robot build error (rev2) URL : https://patchwork.freedesktop.org/series/73990/ State : success == Summary == CI Bug Log - changes from CI_DRM_8021_full -> Patchwork_16741_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16741_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [i915#677]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb7/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb5/igt@gem_exec_sched...@reorder-wide-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-iclb1/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#413]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb2/igt@i915_pm_...@waitboost.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-iclb6/igt@i915_pm_...@waitboost.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#52] / [i915#54]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-skl7/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-skl1/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-apl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-apl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#34]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-skl3/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-skl3/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-skl7/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#899]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-glk5/igt@kms_plane_low...@pipe-a-tiling-x.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16741/shard-iclb6/igt@kms_psr@psr2_primary_page_flip.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-apl2/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Proper dbuf global state (rev3)
== Series Details == Series: drm/i915: Proper dbuf global state (rev3) URL : https://patchwork.freedesktop.org/series/73421/ State : success == Summary == CI Bug Log - changes from CI_DRM_8021_full -> Patchwork_16739_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8021_full and Patchwork_16739_full: ### New IGT tests (1) ### * igt@i915_selftest@mock: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_16739_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@bcs0: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([i915#1197] / [i915#1239]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-skl3/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#679]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-skl3/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb4/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_parallel@vcs1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112080]) +7 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb1/igt@gem_exec_paral...@vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-iclb3/igt@gem_exec_paral...@vcs1.html * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-iclb1/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-bsd2: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +10 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb4/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-iclb7/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb5/igt@gem_exec_sched...@reorder-wide-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-iclb1/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_exec_whisper@basic-queues-forked: - shard-glk: [PASS][19] -> [INCOMPLETE][20] ([i915#58] / [k.org#198133]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-glk3/igt@gem_exec_whis...@basic-queues-forked.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-glk5/igt@gem_exec_whis...@basic-queues-forked.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16739/shard-glk4/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#413]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8021/shard-iclb2/igt@i915_pm_...@waitboost.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/huc: update TGL HuC to v7.0.12
== Series Details == Series: series starting with [CI,1/2] drm/i915/huc: update TGL HuC to v7.0.12 URL : https://patchwork.freedesktop.org/series/74099/ State : success == Summary == CI Bug Log - changes from CI_DRM_8035 -> Patchwork_16771 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/index.html Known issues Here are the changes found in Patchwork_16771 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [PASS][1] -> [DMESG-FAIL][2] ([i915#877]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-cml-s/igt@i915_selftest@live@gem_contexts.html - fi-cfl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#106070] / [i915#424]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@hangcheck: - fi-icl-u2: [PASS][5] -> [INCOMPLETE][6] ([fdo#108569]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8] ([i915#44]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html * igt@prime_self_import@basic-llseek-bad: - fi-tgl-y: [PASS][9] -> [DMESG-WARN][10] ([CI#94] / [i915#402]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html Possible fixes * igt@gem_mmap_gtt@basic: - fi-tgl-y: [DMESG-WARN][11] ([CI#94] / [i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-tgl-y/igt@gem_mmap_...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-tgl-y/igt@gem_mmap_...@basic.html * igt@i915_selftest@live@gem_contexts: - fi-cfl-8700k: [INCOMPLETE][13] ([i915#424]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@gt_heartbeat: - fi-bxt-dsi: [DMESG-FAIL][15] ([i915#541]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [FAIL][18] ([fdo#111096] / [i915#323]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16771/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (48 -> 42) -- Additional (2): fi-bwr-2160 fi-kbl-r Missing(8): fi-tgl-dsi fi-byt-squawks fi-bsw-cyan fi-snb-2520m fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8035 -> Patchwork_16771 CI-20190529: 20190529 CI_DRM_8035: cacad502dcd40516c6a9be38ca3ef0c1288f4cf4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @
Re: [Intel-gfx] [PATCH 37/51] drm/rockchip: Drop explicit drm_mode_config_cleanup call
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20200228]
[cannot apply to drm-intel/for-linux-next linus/master
pinchartl-media/drm/du/next v5.6-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-managed-resources-v3/20200229-005817
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
949134e2fefd34a38ed71de90dffe2300e2e1139)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.c:147:8: error: use of undeclared
>> label 'err_mode_config_cleanup'
goto err_mode_config_cleanup;
^
1 error generated.
vim +/err_mode_config_cleanup +147 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
2048e3286f347d Mark Yao 2014-08-22 110
f706974a69b6e2 Tomeu Vizoso 2016-06-10 111 static int
rockchip_drm_bind(struct device *dev)
2048e3286f347d Mark Yao 2014-08-22 112 {
f706974a69b6e2 Tomeu Vizoso 2016-06-10 113struct drm_device
*drm_dev;
2048e3286f347d Mark Yao 2014-08-22 114struct
rockchip_drm_private *private;
2048e3286f347d Mark Yao 2014-08-22 115int ret;
2048e3286f347d Mark Yao 2014-08-22 116
f706974a69b6e2 Tomeu Vizoso 2016-06-10 117drm_dev =
drm_dev_alloc(_drm_driver, dev);
0f2886057be322 Tom Gundersen 2016-09-21 118if (IS_ERR(drm_dev))
0f2886057be322 Tom Gundersen 2016-09-21 119return
PTR_ERR(drm_dev);
2048e3286f347d Mark Yao 2014-08-22 120
f706974a69b6e2 Tomeu Vizoso 2016-06-10 121dev_set_drvdata(dev,
drm_dev);
f706974a69b6e2 Tomeu Vizoso 2016-06-10 122
f706974a69b6e2 Tomeu Vizoso 2016-06-10 123private =
devm_kzalloc(drm_dev->dev, sizeof(*private), GFP_KERNEL);
f706974a69b6e2 Tomeu Vizoso 2016-06-10 124if (!private) {
f706974a69b6e2 Tomeu Vizoso 2016-06-10 125ret = -ENOMEM;
9127f99c4801f3 Tomasz Figa 2016-06-21 126goto err_free;
f706974a69b6e2 Tomeu Vizoso 2016-06-10 127}
f706974a69b6e2 Tomeu Vizoso 2016-06-10 128
2048e3286f347d Mark Yao 2014-08-22 129drm_dev->dev_private =
private;
2048e3286f347d Mark Yao 2014-08-22 130
5182c1a556d7ff Yakir Yang2016-07-24 131
INIT_LIST_HEAD(>psr_list);
60beeccc72cabe Sean Paul 2018-03-05 132
mutex_init(>psr_list_lock);
5182c1a556d7ff Yakir Yang2016-07-24 133
ccea91998c8f14 Jeffy Chen2017-04-06 134ret =
rockchip_drm_init_iommu(drm_dev);
ccea91998c8f14 Jeffy Chen2017-04-06 135if (ret)
ccea91998c8f14 Jeffy Chen2017-04-06 136goto err_free;
ccea91998c8f14 Jeffy Chen2017-04-06 137
7db42e97bb41bd Daniel Vetter 2020-02-27 138ret =
drm_mode_config_init(drm_dev);
7db42e97bb41bd Daniel Vetter 2020-02-27 139if (ret)
7db42e97bb41bd Daniel Vetter 2020-02-27 140goto
err_iommu_cleanup;
2048e3286f347d Mark Yao 2014-08-22 141
2048e3286f347d Mark Yao 2014-08-22 142
rockchip_drm_mode_config_init(drm_dev);
2048e3286f347d Mark Yao 2014-08-22 143
2048e3286f347d Mark Yao 2014-08-22 144/* Try to bind all sub
drivers. */
2048e3286f347d Mark Yao 2014-08-22 145ret =
component_bind_all(dev, drm_dev);
2048e3286f347d Mark Yao 2014-08-22 146if (ret)
ccea91998c8f14 Jeffy Chen2017-04-06 @147goto
err_mode_config_cleanup;
2048e3286f347d Mark Yao 2014-08-22 148
ccea91998c8f14 Jeffy Chen2017-04-06 149ret =
drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
ccea91998c8f14 Jeffy Chen2017-04-06 150if (ret)
ccea91998c8f14 Jeffy Chen2017-04-06 151goto
err_unbind_all;
ccea91998c8f14 Jeffy Chen2017-04-06 152
ccea91998c8f14 Jeffy Chen2017-04-06 153
drm_mode_config_reset(drm_dev);
2048e3286f347d Mark Yao 2014-08-22 154
2048e3286f347d Mark Yao 2014-08-22 155/*
2048e3286f347d Mark Yao 2014-08-22 156 * enable drm irq mode.
2048e3286f347d Mark Yao 2014-08-22 157 * - with irq_enabled =
true, we can use the vblank feature.
2048e3286f347d Mark Yao 2014-08-22 158
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev5)
== Series Details ==
Series: drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (rev5)
URL : https://patchwork.freedesktop.org/series/72747/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8035 -> Patchwork_16770
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16770/index.html
Known issues
Here are the changes found in Patchwork_16770 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402])
+1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16770/fi-tgl-y/igt@kms_addfb_ba...@addfb25-framebuffer-vs-set-tiling.html
Possible fixes
* igt@gem_mmap_gtt@basic:
- fi-tgl-y: [DMESG-WARN][3] ([CI#94] / [i915#402]) -> [PASS][4]
+1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-tgl-y/igt@gem_mmap_...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16770/fi-tgl-y/igt@gem_mmap_...@basic.html
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][5] ([i915#424]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16770/fi-cfl-8700k/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [DMESG-FAIL][7] ([i915#541]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16770/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111407]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8035/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16770/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
[i915#596]: https://gitlab.freedesktop.org/drm/intel/issues/596
[i915#998]: https://gitlab.freedesktop.org/drm/intel/issues/998
Participating hosts (48 -> 42)
--
Additional (2): fi-cfl-8109u fi-kbl-r
Missing(8): fi-kbl-soraka fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus fi-byt-clapper fi-skl-6600u
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8035 -> Patchwork_16770
CI-20190529: 20190529
CI_DRM_8035: cacad502dcd40516c6a9be38ca3ef0c1288f4cf4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16770: 7516430abf77fec39ca51e1d466e98a6b20c14a9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7516430abf77 drm/i915/hotplug: Use phy to get the hpd_pin instead of the port
(v4)
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16770/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] HAX: drm/i915: default to enable_guc=2
To enable GuC and HuC loading on all gen9+ CI machines. Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 45323732f099..7b5d32c990bc 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -56,7 +56,7 @@ struct drm_printer; param(int, disable_power_well, -1, 0400) \ param(int, enable_ips, 1, 0600) \ param(int, invert_brightness, 0, 0600) \ - param(int, enable_guc, 0, 0400) \ + param(int, enable_guc, 2, 0400) \ param(int, guc_log_level, -1, 0400) \ param(char *, guc_firmware_path, NULL, 0400) \ param(char *, huc_firmware_path, NULL, 0400) \ -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915/huc: update TGL HuC to v7.0.12
Update to the latest available TGL HuC, which includes changes required by the media team. Signed-off-by: Daniele Ceraolo Spurio Cc: Tony Ye Cc: Michal Wajdeczko Cc: Anusha Srivatsa Reviewed-by: José Roberto de Souza --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 5434c07aefa1..18c755203688 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -43,7 +43,7 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw, * features. */ #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \ - fw_def(TIGERLAKE, 0, guc_def(tgl, 35, 2, 0), huc_def(tgl, 7, 0, 3)) \ + fw_def(TIGERLAKE, 0, guc_def(tgl, 35, 2, 0), huc_def(tgl, 7, 0, 12)) \ fw_def(ELKHARTLAKE, 0, guc_def(ehl, 33, 0, 4), huc_def(ehl, 9, 0, 0)) \ fw_def(ICELAKE, 0, guc_def(icl, 33, 0, 0), huc_def(icl, 9, 0, 0)) \ fw_def(COFFEELAKE, 5, guc_def(cml, 33, 0, 0), huc_def(cml, 4, 0, 0)) \ -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/11] drm/i915/tgl: Restrict Wa_1408615072 to A0 stepping
On Fri, Feb 28, 2020 at 04:45:43PM -0800, Souza, Jose wrote: > On Fri, 2020-02-28 at 16:29 -0800, Matt Roper wrote: > > On Fri, Feb 28, 2020 at 04:04:17PM -0800, Souza, Jose wrote: > > > On Fri, 2020-02-28 at 13:25 -0800, Matt Roper wrote: > > > > On Thu, Feb 27, 2020 at 02:00:59PM -0800, José Roberto de Souza > > > > wrote: > > > > > It is fixed in B0 stepping. > > > > > > > > > > Signed-off-by: José Roberto de Souza > > > > > --- > > > > > drivers/gpu/drm/i915/intel_pm.c | 5 +++-- > > > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > > > b/drivers/gpu/drm/i915/intel_pm.c > > > > > index 22aa205793e5..a101d8072b5b 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > > > @@ -6838,8 +6838,9 @@ static void tgl_init_clock_gating(struct > > > > > drm_i915_private *dev_priv) > > > > > unsigned int i; > > > > > > > > > > /* Wa_1408615072:tgl */ > > > > > - intel_uncore_rmw(_priv->uncore, > > > > > UNSLICE_UNIT_LEVEL_CLKGATE2, > > > > > - 0, VSUNIT_CLKGATE_DIS_TGL); > > > > > + if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0)) > > > > > + intel_uncore_rmw(_priv->uncore, > > > > > UNSLICE_UNIT_LEVEL_CLKGATE2, > > > > > + 0, VSUNIT_CLKGATE_DIS_TGL); > > > > > > > > I think this workaround is also implemented in the wrong > > > > location. This > > > > is a render engine register (part of the 94D0-951C render > > > > forcewake > > > > range on bspec 52078) and part of the MCR range (bspec 52079), so > > > > we > > > > should program this in the engine_wa_init rather than the clock > > > > gating > > > > function. > > > > > > > > The ICL/EHL version (which we based the TGL WA on) is also in the > > > > wrong > > > > place for the same reasons. > > > > > > > > At some point we should probably audit all the other > > > > GT/engine/MCR > > > > registers we're dealing with in the init_clock_gating functions > > > > and > > > > move > > > > them out to more appropriate places. > > > > > > What about this note in BSpec 52078: > > > * Note: Some CP registers (0x9400-0x97FF) are replicated in all > > > domains, thus both render and media domains must be awake. > > > > Well, the uncore functions will still take care of grabbing both > > forcewakes for registers like these (so that the register writes are > > applied to all the multicast register instances that live behind that > > register offset), so everything that needs to be will be powered up. > > Based on the information about the workaround, it sounds like it's > > only > > actually the render engine it really matters for though. > > The WA explicity says to set 0x94E4 so other engines would need it too. xcs_engine_wa_init() is the equivalent for other engines if we want to make sure the multicast register is also re-written when we do a single-engine reset on the media engines. Although I see that just yesterday one of the architects filed bspec issue 23662 which also relates to this register range...we may want to wait and see how the bspec winds up getting clarified there before moving this workaround around. > > > > > If we do this change in init_clock_gating, I don't believe it gets > > re-applied on single-engine resets, so we lose the workaround. If we > > do > > this in the rcs engine's WA function, then those will be re-applied > > For what I checked if display is not involved in the reset it would not > be applied, so a better and easier sollution would be make it be > executed when display is not involved. > > CCing some GT folks. Although init_clock_gating is part of the display vtable, it has a mix of GT and display stuff today. It's not really the right place to be doing GT stuff, but since we haven't moved various workarounds out to more correct places, we have a somewhat hacky workaround today of also calling intel_init_clock_gating() in: * intel_finish_reset() * i915_drm_resume() * i915_gem_init() (comment here admits we need to fix this) to try to make sure that the GT-related stuff gets re-applied at some of the points where it would otherwise be lost (GPU resets and system power management). But the intel_finish_reset() in the list above is dealing with full GPU resets, not single-engine resets. intel_engine_apply_workarounds() on the other hand gets called from intel_engine_resume(), and that's called during intel_engine_reset() so the workarounds applied by it (i.e., the stuff in rcs_engine_wa_init and xcs_engine_wa_init) will be re-applied when you just reset a single engine in isolation. Matt > > > > > > Otherwise we have a huge problem, doing just a quick search I found > > > this 2 registers bellow that we are programing from > > > init_clock_gating() > > > in the same range. > > > > > > #define GEN8_UCGCTL6 _MMIO(0x9430) > > > #define GEN7_MISCCPCTL
[Intel-gfx] [PATCH] drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v4)
On some platforms such as Elkhart Lake, although we may use DDI D
to drive a connector, we have to use PHY A (Combo Phy PORT A) to
detect the hotplug interrupts as per the spec because there is no
one-to-one mapping between DDIs and PHYs. Therefore, use the
function intel_port_to_phy() which contains the logic for such
mapping(s) to find the correct hpd_pin.
This change should not affect other platforms as there is always
a one-to-one mapping between DDIs and PHYs.
v2:
- Convert the case statements to use PHYs instead of PORTs (Jani)
v3:
- Refactor the function to reduce the number of return statements by
lumping all the case statements together except PHY_F which needs
special handling (Jose)
v4:
- Add a comment describing how the HPD pin value associated with any
port can be retrieved using port or phy enum value. (Jani)
Cc: Jani Nikula
Cc: Matt Roper
Cc: José Roberto de Souza
Signed-off-by: Vivek Kasireddy
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 37
drivers/gpu/drm/i915/i915_drv.h | 6
2 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 4a6208857488..e1ddccc2ce97 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -87,29 +87,22 @@
enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
enum port port)
{
- switch (port) {
- case PORT_A:
- return HPD_PORT_A;
- case PORT_B:
- return HPD_PORT_B;
- case PORT_C:
- return HPD_PORT_C;
- case PORT_D:
- return HPD_PORT_D;
- case PORT_E:
- return HPD_PORT_E;
- case PORT_F:
- if (IS_CNL_WITH_PORT_F(dev_priv))
- return HPD_PORT_E;
- return HPD_PORT_F;
- case PORT_G:
- return HPD_PORT_G;
- case PORT_H:
- return HPD_PORT_H;
- case PORT_I:
- return HPD_PORT_I;
+ enum phy phy = intel_port_to_phy(dev_priv, port);
+
+ switch (phy) {
+ case PHY_F:
+ return IS_CNL_WITH_PORT_F(dev_priv) ? HPD_PORT_E : HPD_PORT_F;
+ case PHY_A:
+ case PHY_B:
+ case PHY_C:
+ case PHY_D:
+ case PHY_E:
+ case PHY_G:
+ case PHY_H:
+ case PHY_I:
+ return HPD_PORT_A + phy;
default:
- MISSING_CASE(port);
+ MISSING_CASE(phy);
return HPD_NONE;
}
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b621df933212..c9d7b9127b6e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -117,6 +117,12 @@
struct drm_i915_gem_object;
+/*
+ * The code assumes that the hpd_pins below have consecutive values and
+ * starting with HPD_PORT_A, the HPD pin associated with any port can be
+ * retrieved by adding the corresponding port (or phy) enum value to
+ * HPD_PORT_A. For example, HPD_PORT_C = HPD_PORT_A + PORT_C/PHY_C.
+ */
enum hpd_pin {
HPD_NONE = 0,
HPD_TV = HPD_NONE, /* TV is known to be unreliable */
--
2.21.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/crc: move pipe_crc from drm_i915_private to intel_crtc
== Series Details == Series: drm/i915/crc: move pipe_crc from drm_i915_private to intel_crtc URL : https://patchwork.freedesktop.org/series/74031/ State : success == Summary == CI Bug Log - changes from CI_DRM_8020_full -> Patchwork_16738_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16738_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@default: - shard-glk: [PASS][1] -> [FAIL][2] ([i915#679]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@default.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-glk2/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@default.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@render: - shard-glk: [PASS][3] -> [INCOMPLETE][4] ([i915#1239] / [i915#58] / [k.org#198133]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-glk2/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html * igt@gem_ctx_shared@exec-shared-gtt-bsd1: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#616]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-kbl1/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-kbl2/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@deep-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb8/igt@gem_exec_sched...@deep-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-iclb2/igt@gem_exec_sched...@deep-bsd.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-iclb3/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@preempt-queue-blt: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([i915#58] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk2/igt@gem_exec_sched...@preempt-queue-blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-glk3/igt@gem_exec_sched...@preempt-queue-blt.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#52] / [i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-skl6/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-skl2/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-skl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-apl2/igt@kms_f...@flip-vs-suspend-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-apl4/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16738/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]:
Re: [Intel-gfx] [PATCH v3 09/11] drm/i915/tgl: Restrict Wa_1408615072 to A0 stepping
On Fri, 2020-02-28 at 16:29 -0800, Matt Roper wrote:
> On Fri, Feb 28, 2020 at 04:04:17PM -0800, Souza, Jose wrote:
> > On Fri, 2020-02-28 at 13:25 -0800, Matt Roper wrote:
> > > On Thu, Feb 27, 2020 at 02:00:59PM -0800, José Roberto de Souza
> > > wrote:
> > > > It is fixed in B0 stepping.
> > > >
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 22aa205793e5..a101d8072b5b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -6838,8 +6838,9 @@ static void tgl_init_clock_gating(struct
> > > > drm_i915_private *dev_priv)
> > > > unsigned int i;
> > > >
> > > > /* Wa_1408615072:tgl */
> > > > - intel_uncore_rmw(_priv->uncore,
> > > > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > > > -0, VSUNIT_CLKGATE_DIS_TGL);
> > > > + if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
> > > > + intel_uncore_rmw(_priv->uncore,
> > > > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > > > +0, VSUNIT_CLKGATE_DIS_TGL);
> > >
> > > I think this workaround is also implemented in the wrong
> > > location. This
> > > is a render engine register (part of the 94D0-951C render
> > > forcewake
> > > range on bspec 52078) and part of the MCR range (bspec 52079), so
> > > we
> > > should program this in the engine_wa_init rather than the clock
> > > gating
> > > function.
> > >
> > > The ICL/EHL version (which we based the TGL WA on) is also in the
> > > wrong
> > > place for the same reasons.
> > >
> > > At some point we should probably audit all the other
> > > GT/engine/MCR
> > > registers we're dealing with in the init_clock_gating functions
> > > and
> > > move
> > > them out to more appropriate places.
> >
> > What about this note in BSpec 52078:
> > * Note: Some CP registers (0x9400-0x97FF) are replicated in all
> > domains, thus both render and media domains must be awake.
>
> Well, the uncore functions will still take care of grabbing both
> forcewakes for registers like these (so that the register writes are
> applied to all the multicast register instances that live behind that
> register offset), so everything that needs to be will be powered up.
> Based on the information about the workaround, it sounds like it's
> only
> actually the render engine it really matters for though.
The WA explicity says to set 0x94E4 so other engines would need it too.
>
> If we do this change in init_clock_gating, I don't believe it gets
> re-applied on single-engine resets, so we lose the workaround. If we
> do
> this in the rcs engine's WA function, then those will be re-applied
For what I checked if display is not involved in the reset it would not
be applied, so a better and easier sollution would be make it be
executed when display is not involved.
CCing some GT folks.
>
> > Otherwise we have a huge problem, doing just a quick search I found
> > this 2 registers bellow that we are programing from
> > init_clock_gating()
> > in the same range.
> >
> > #define GEN8_UCGCTL6_MMIO(0x9430)
> > #define GEN7_MISCCPCTL _MMIO(0x9424)
>
> Yeah, I suspect there are multiple workarounds we're not actually
> handling properly today (but as long as you don't suffer an engine
> hang
> & reset, you'll probably never notice).
>
> IIRC, there's a fixme comment somewhere in the code saying we should
> move all
> the non-display stuff our of init_clock_gating to move appropriate
> locations too.
>
>
>
> Matt
>
> > >
> > > Matt
> > >
> > > >
> > > > /* This is not a WA. Enable VD HCP & MFX_ENC powergate
> > > > */
> > > > for (i = 0; i < I915_MAX_VCS; i++) {
> > > > --
> > > > 2.25.1
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/11] drm/i915/tgl: Restrict Wa_1408615072 to A0 stepping
On Fri, Feb 28, 2020 at 04:04:17PM -0800, Souza, Jose wrote:
> On Fri, 2020-02-28 at 13:25 -0800, Matt Roper wrote:
> > On Thu, Feb 27, 2020 at 02:00:59PM -0800, José Roberto de Souza
> > wrote:
> > > It is fixed in B0 stepping.
> > >
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 22aa205793e5..a101d8072b5b 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -6838,8 +6838,9 @@ static void tgl_init_clock_gating(struct
> > > drm_i915_private *dev_priv)
> > > unsigned int i;
> > >
> > > /* Wa_1408615072:tgl */
> > > - intel_uncore_rmw(_priv->uncore,
> > > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > > - 0, VSUNIT_CLKGATE_DIS_TGL);
> > > + if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
> > > + intel_uncore_rmw(_priv->uncore,
> > > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > > + 0, VSUNIT_CLKGATE_DIS_TGL);
> >
> > I think this workaround is also implemented in the wrong
> > location. This
> > is a render engine register (part of the 94D0-951C render forcewake
> > range on bspec 52078) and part of the MCR range (bspec 52079), so we
> > should program this in the engine_wa_init rather than the clock
> > gating
> > function.
> >
> > The ICL/EHL version (which we based the TGL WA on) is also in the
> > wrong
> > place for the same reasons.
> >
> > At some point we should probably audit all the other GT/engine/MCR
> > registers we're dealing with in the init_clock_gating functions and
> > move
> > them out to more appropriate places.
>
> What about this note in BSpec 52078:
> * Note: Some CP registers (0x9400-0x97FF) are replicated in all
> domains, thus both render and media domains must be awake.
Well, the uncore functions will still take care of grabbing both
forcewakes for registers like these (so that the register writes are
applied to all the multicast register instances that live behind that
register offset), so everything that needs to be will be powered up.
Based on the information about the workaround, it sounds like it's only
actually the render engine it really matters for though.
If we do this change in init_clock_gating, I don't believe it gets
re-applied on single-engine resets, so we lose the workaround. If we do
this in the rcs engine's WA function, then those will be re-applied
>
> Otherwise we have a huge problem, doing just a quick search I found
> this 2 registers bellow that we are programing from init_clock_gating()
> in the same range.
>
> #define GEN8_UCGCTL6 _MMIO(0x9430)
> #define GEN7_MISCCPCTL_MMIO(0x9424)
Yeah, I suspect there are multiple workarounds we're not actually
handling properly today (but as long as you don't suffer an engine hang
& reset, you'll probably never notice).
IIRC, there's a fixme comment somewhere in the code saying we should move all
the non-display stuff our of init_clock_gating to move appropriate
locations too.
Matt
>
> >
> >
> > Matt
> >
> > >
> > > /* This is not a WA. Enable VD HCP & MFX_ENC powergate */
> > > for (i = 0; i < I915_MAX_VCS; i++) {
> > > --
> > > 2.25.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls
On Fri, Feb 28, 2020 at 10:43:39AM +, Chris Wilson wrote: > We [will] expose various per-engine scheduling controls. One of which, > 'heartbeat_duration_ms', defines how often we send a heartbeat down the > engine to check upon the health of the engine. If a heartbeat does not > complete within the interval (or two), the engine is declared hung. > > Signed-off-by: Chris Wilson Someone with not a good eye might swear to have read this patch once, and at patch 5/5 he will ask again the same question. Why don't we put together in a library the things that patch 3/4/5 have in common? Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915/uc: mark structure passed to checker functions as const
On 2/28/20 1:18 AM, Jani Nikula wrote:
On Thu, 27 Feb 2020, Daniele Ceraolo Spurio
wrote:
Follow-up patches will pass const objects from debugfs to some those
functions, so we need to be ready.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_gt.h | 6 +++---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 6 +++---
drivers/gpu/drm/i915/gt/uc/intel_huc.h | 8
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 18 +-
7 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 4fac043750aa..f9fbe645478d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -18,17 +18,17 @@ struct drm_i915_private;
##__VA_ARGS__); \
} while (0)
-static inline struct intel_gt *uc_to_gt(struct intel_uc *uc)
+static inline struct intel_gt *uc_to_gt(const struct intel_uc *uc)
{
return container_of(uc, struct intel_gt, uc);
}
-static inline struct intel_gt *guc_to_gt(struct intel_guc *guc)
+static inline struct intel_gt *guc_to_gt(const struct intel_guc *guc)
{
return container_of(guc, struct intel_gt, uc.guc);
}
-static inline struct intel_gt *huc_to_gt(struct intel_huc *huc)
+static inline struct intel_gt *huc_to_gt(const struct intel_huc *huc)
{
return container_of(huc, struct intel_gt, uc.huc);
}
Not fond of the fact that these cast the const away. If you can return
const also, fine, but const in, non-const out is not fine.
fair point. We usually use those functions for non-const->non-const
conversions, but in debugfs the objects are marked as const hence why
the need to add it here (the output in that case can also be marked as
const).
What's the favorite alternative, add a guc_to_gt_const() variant, do a
straight container_of in the debugfs function or simply avoid marking
the objects as const to begin with, even if they're treated as such?
Thanks,
Daniele
BR,
Jani.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs
> > > +void dyn_sysfs_engines(int i915, int engines, const char *file,
> > > +void (*test)(int, int))
> > > +{
> > > + char buf[512];
> > > + int len;
> > > +
> > > + lseek(engines, 0, SEEK_SET);
> > > + while ((len = syscall(SYS_getdents64, engines, buf, sizeof(buf))) >
> > > 0) {
> > > + void *ptr = buf;
> > > +
> > > + while (len) {
> > > + struct linux_dirent64 {
> > > + ino64_td_ino;
> > > + off64_td_off;
> > > + unsigned short d_reclen;
> > > + unsigned char d_type;
> > > + char d_name[];
> > > + } *de = ptr;
> >
> > what is the need for having your own linux_dirent64?
>
> fdopendir() takes ownership of the fd, preventing reuse. And
> fdopendir(dup()) is getting ridiculous.
why not using dirent64?
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/11] drm/i915/tgl: Restrict Wa_1408615072 to A0 stepping
On Fri, 2020-02-28 at 13:25 -0800, Matt Roper wrote:
> On Thu, Feb 27, 2020 at 02:00:59PM -0800, José Roberto de Souza
> wrote:
> > It is fixed in B0 stepping.
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 22aa205793e5..a101d8072b5b 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6838,8 +6838,9 @@ static void tgl_init_clock_gating(struct
> > drm_i915_private *dev_priv)
> > unsigned int i;
> >
> > /* Wa_1408615072:tgl */
> > - intel_uncore_rmw(_priv->uncore,
> > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > -0, VSUNIT_CLKGATE_DIS_TGL);
> > + if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
> > + intel_uncore_rmw(_priv->uncore,
> > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > +0, VSUNIT_CLKGATE_DIS_TGL);
>
> I think this workaround is also implemented in the wrong
> location. This
> is a render engine register (part of the 94D0-951C render forcewake
> range on bspec 52078) and part of the MCR range (bspec 52079), so we
> should program this in the engine_wa_init rather than the clock
> gating
> function.
>
> The ICL/EHL version (which we based the TGL WA on) is also in the
> wrong
> place for the same reasons.
>
> At some point we should probably audit all the other GT/engine/MCR
> registers we're dealing with in the init_clock_gating functions and
> move
> them out to more appropriate places.
What about this note in BSpec 52078:
* Note: Some CP registers (0x9400-0x97FF) are replicated in all
domains, thus both render and media domains must be awake.
Otherwise we have a huge problem, doing just a quick search I found
this 2 registers bellow that we are programing from init_clock_gating()
in the same range.
#define GEN8_UCGCTL6_MMIO(0x9430)
#define GEN7_MISCCPCTL _MMIO(0x9424)
>
>
> Matt
>
> >
> > /* This is not a WA. Enable VD HCP & MFX_ENC powergate */
> > for (i = 0; i < I915_MAX_VCS; i++) {
> > --
> > 2.25.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev6)
== Series Details == Series: drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev6) URL : https://patchwork.freedesktop.org/series/73718/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8020_full -> Patchwork_16737_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16737_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16737_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16737_full: ### IGT changes ### Possible regressions * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-iclb: [PASS][1] -> [TIMEOUT][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-iclb8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html New tests - New tests have been introduced between CI_DRM_8020_full and Patchwork_16737_full: ### New IGT tests (4) ### * igt@drm_mm@all: - Statuses : - Exec time: [None] s * igt@i915_selftest@mock: - Statuses : - Exec time: [None] s * igt@i915_selftest@perf: - Statuses : - Exec time: [None] s * igt@kms_selftest@all: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_16737_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +10 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-iclb6/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb5/igt@gem_exec_sched...@preempt-queue-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@i915_pm_rpm@cursor-dpms: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([i915#189]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb6/igt@i915_pm_...@cursor-dpms.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-iclb2/igt@i915_pm_...@cursor-dpms.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-apl2/igt@kms_f...@flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-apl2/igt@kms_f...@flip-vs-suspend-interruptible.html - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-kbl2/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#899]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk8/igt@kms_plane_low...@pipe-a-tiling-x.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16737/shard-glk3/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [20]:
Re: [Intel-gfx] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs
Hi Chris,
> +static int create_ext_ioctl(int i915,
> + struct drm_i915_gem_context_create_ext *arg)
> +{
> + int err;
> +
> + err = 0;
> + if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
> + err = -errno;
> + igt_assume(err);
> + }
> +
> + errno = 0;
> + return err;
> +}
> +
> /**
> * gem_has_contexts:
> * @fd: open i915 drm file descriptor
> @@ -324,17 +339,14 @@ __gem_context_clone(int i915,
> .flags = flags | I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
> .extensions = to_user_pointer(),
> };
> - int err = 0;
> + int err;
>
> - if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, )) {
> - err = -errno;
> - igt_assume(err);
> - }
> + err = create_ext_ioctl(i915, );
> + if (err)
> + return err;
>
> *out = arg.ctx_id;
> -
> - errno = 0;
> - return err;
> + return 0;
> }
>
> static bool __gem_context_has(int i915, uint32_t share, unsigned int flags)
> @@ -382,16 +394,8 @@ bool gem_has_context_clone(int i915)
> .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
> .extensions = to_user_pointer(),
> };
> - int err;
> -
> - err = 0;
> - if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, )) {
> - err = -errno;
> - igt_assume(err);
> - }
> - errno = 0;
>
> - return err == -ENOENT;
> + return create_ext_ioctl(i915, ) == -ENOENT;
> }
I'd like to see the above in a separate patch.
> +void dyn_sysfs_engines(int i915, int engines, const char *file,
> +void (*test)(int, int))
> +{
> + char buf[512];
> + int len;
> +
> + lseek(engines, 0, SEEK_SET);
> + while ((len = syscall(SYS_getdents64, engines, buf, sizeof(buf))) > 0) {
> + void *ptr = buf;
> +
> + while (len) {
> + struct linux_dirent64 {
> + ino64_td_ino;
> + off64_td_off;
> + unsigned short d_reclen;
> + unsigned char d_type;
> + char d_name[];
> + } *de = ptr;
what is the need for having your own linux_dirent64?
All the rest look good.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls
Quoting Andi Shyti (2020-02-28 23:34:48) > On Fri, Feb 28, 2020 at 10:43:39AM +, Chris Wilson wrote: > > We [will] expose various per-engine scheduling controls. One of which, > > 'heartbeat_duration_ms', defines how often we send a heartbeat down the > > engine to check upon the health of the engine. If a heartbeat does not > > complete within the interval (or two), the engine is declared hung. > > > > Signed-off-by: Chris Wilson > > Someone with not a good eye might swear to have read this patch > once, and at patch 5/5 he will ask again the same question. > > Why don't we put together in a library the things that patch > 3/4/5 have in common? They are. It's basically a repeating pattern of testing with local assumptions. For the sole reason that I'm not very inventive. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/51] drm/rockchip: Drop explicit drm_mode_config_cleanup call
Drat I butchered this. Will fix for next round and actually
compile-test arm again :-/
-Daniel
On Fri, Feb 28, 2020 at 10:19 PM kbuild test robot wrote:
>
> Hi Daniel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on drm-tip/drm-tip]
> [also build test ERROR on next-20200228]
> [cannot apply to drm-intel/for-linux-next linus/master
> pinchartl-media/drm/du/next v5.6-rc3]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-managed-resources-v3/20200229-005817
> base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> config: arm64-defconfig (attached as .config)
> compiler: aarch64-linux-gcc (GCC) 7.5.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.5.0 make.cross ARCH=arm64
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu/drm/rockchip/rockchip_drm_drv.c: In function
> 'rockchip_drm_bind':
> >> drivers/gpu/drm/rockchip/rockchip_drm_drv.c:147:3: error: label
> >> 'err_mode_config_cleanup' used but not defined
> goto err_mode_config_cleanup;
> ^~~~
>
> vim +/err_mode_config_cleanup +147 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>
> 2048e3286f347db Mark Yao 2014-08-22 110
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 111 static int
> rockchip_drm_bind(struct device *dev)
> 2048e3286f347db Mark Yao 2014-08-22 112 {
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 113 struct drm_device
> *drm_dev;
> 2048e3286f347db Mark Yao 2014-08-22 114 struct
> rockchip_drm_private *private;
> 2048e3286f347db Mark Yao 2014-08-22 115 int ret;
> 2048e3286f347db Mark Yao 2014-08-22 116
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 117 drm_dev =
> drm_dev_alloc(_drm_driver, dev);
> 0f2886057be322d Tom Gundersen 2016-09-21 118 if (IS_ERR(drm_dev))
> 0f2886057be322d Tom Gundersen 2016-09-21 119 return
> PTR_ERR(drm_dev);
> 2048e3286f347db Mark Yao 2014-08-22 120
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 121 dev_set_drvdata(dev,
> drm_dev);
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 122
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 123 private =
> devm_kzalloc(drm_dev->dev, sizeof(*private), GFP_KERNEL);
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 124 if (!private) {
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 125 ret = -ENOMEM;
> 9127f99c4801f32 Tomasz Figa 2016-06-21 126 goto err_free;
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 127 }
> f706974a69b6e2b Tomeu Vizoso 2016-06-10 128
> 2048e3286f347db Mark Yao 2014-08-22 129 drm_dev->dev_private
> = private;
> 2048e3286f347db Mark Yao 2014-08-22 130
> 5182c1a556d7ff7 Yakir Yang2016-07-24 131
> INIT_LIST_HEAD(>psr_list);
> 60beeccc72cabef Sean Paul 2018-03-05 132
> mutex_init(>psr_list_lock);
> 5182c1a556d7ff7 Yakir Yang2016-07-24 133
> ccea91998c8f140 Jeffy Chen2017-04-06 134 ret =
> rockchip_drm_init_iommu(drm_dev);
> ccea91998c8f140 Jeffy Chen2017-04-06 135 if (ret)
> ccea91998c8f140 Jeffy Chen2017-04-06 136 goto err_free;
> ccea91998c8f140 Jeffy Chen2017-04-06 137
> 7db42e97bb41bd5 Daniel Vetter 2020-02-27 138 ret =
> drm_mode_config_init(drm_dev);
> 7db42e97bb41bd5 Daniel Vetter 2020-02-27 139 if (ret)
> 7db42e97bb41bd5 Daniel Vetter 2020-02-27 140 goto
> err_iommu_cleanup;
> 2048e3286f347db Mark Yao 2014-08-22 141
> 2048e3286f347db Mark Yao 2014-08-22 142
> rockchip_drm_mode_config_init(drm_dev);
> 2048e3286f347db Mark Yao 2014-08-22 143
> 2048e3286f347db Mark Yao 2014-08-22 144 /* Try to bind all
> sub drivers. */
> 2048e3286f347db Mark Yao 2014-08-22 145 ret =
> component_bind_all(dev, drm_dev);
> 2048e3286f347db Mark Yao 2014-08-22 146 if (ret)
> ccea91998c8f140 Jeffy Chen2017-04-06 @147 goto
> err_mode_config_cleanup;
> 2048e3286f347db Mark Yao 2014
Re: [Intel-gfx] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs
Quoting Andi Shyti (2020-02-28 23:27:04)
> Hi Chris,
>
> > +static int create_ext_ioctl(int i915,
> > + struct drm_i915_gem_context_create_ext *arg)
> > +{
> > + int err;
> > +
> > + err = 0;
> > + if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, arg)) {
> > + err = -errno;
> > + igt_assume(err);
> > + }
> > +
> > + errno = 0;
> > + return err;
> > +}
> > +
> > /**
> > * gem_has_contexts:
> > * @fd: open i915 drm file descriptor
> > @@ -324,17 +339,14 @@ __gem_context_clone(int i915,
> > .flags = flags | I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
> > .extensions = to_user_pointer(),
> > };
> > - int err = 0;
> > + int err;
> >
> > - if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, )) {
> > - err = -errno;
> > - igt_assume(err);
> > - }
> > + err = create_ext_ioctl(i915, );
> > + if (err)
> > + return err;
> >
> > *out = arg.ctx_id;
> > -
> > - errno = 0;
> > - return err;
> > + return 0;
> > }
> >
> > static bool __gem_context_has(int i915, uint32_t share, unsigned int flags)
> > @@ -382,16 +394,8 @@ bool gem_has_context_clone(int i915)
> > .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
> > .extensions = to_user_pointer(),
> > };
> > - int err;
> > -
> > - err = 0;
> > - if (igt_ioctl(i915, DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT, )) {
> > - err = -errno;
> > - igt_assume(err);
> > - }
> > - errno = 0;
> >
> > - return err == -ENOENT;
> > + return create_ext_ioctl(i915, ) == -ENOENT;
> > }
>
> I'd like to see the above in a separate patch.
It's part of the test, I can put it back inside each .c if you prefer.
> > +void dyn_sysfs_engines(int i915, int engines, const char *file,
> > +void (*test)(int, int))
> > +{
> > + char buf[512];
> > + int len;
> > +
> > + lseek(engines, 0, SEEK_SET);
> > + while ((len = syscall(SYS_getdents64, engines, buf, sizeof(buf))) >
> > 0) {
> > + void *ptr = buf;
> > +
> > + while (len) {
> > + struct linux_dirent64 {
> > + ino64_td_ino;
> > + off64_td_off;
> > + unsigned short d_reclen;
> > + unsigned char d_type;
> > + char d_name[];
> > + } *de = ptr;
>
> what is the need for having your own linux_dirent64?
fdopendir() takes ownership of the fd, preventing reuse. And
fdopendir(dup()) is getting ridiculous.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/51] drm: add managed resources tied to drm_device
On Fri, Feb 28, 2020 at 11:45 PM Sam Ravnborg wrote: > > Hi Daniel. > > Some nitpicks / bikeshedding below. > > Sam > > On Thu, Feb 27, 2020 at 07:14:34PM +0100, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers use devm_, which > > ties the release action to the underlying struct device, whereas > > all the userspace visible stuff attached to a drm_device can long > > outlive that one (e.g. after a hotunplug while userspace has open > > files and mmap'ed buffers). Give people what they want, but with more > > correctness. > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > a few simplifications - I didn't (yet) copy over everything. Since > > the types don't match code sharing looked like a hopeless endeavour. > > Readability had been increased if the short names was not reused. > > s/dr_/drmres_/ > > But I know, this is in the bikeshedding area. > > > > > For now it's only super simplified, no groups, you can't remove > > actions (but kfree exists, we'll need that soon). Plus all specific to > > drm_device ofc, including the logging. Which I didn't bother to make > > compile-time optional, since none of the other drm logging is compile > > time optional either. > > > > One tricky bit here is the chicken between allocating your > > drm_device structure and initiliazing it with drm_dev_init. For > > perfect onion unwinding we'd need to have the action to kfree the > > allocation registered before drm_dev_init registers any of its own > > release handlers. But drm_dev_init doesn't know where exactly the > > drm_device is emebedded into the overall structure, and by the time it > > returns it'll all be too late. And forcing drivers to be able clean up > > everything except the one kzalloc is silly. > > > > Work around this by having a very special final_kfree pointer. This > > also avoids troubles with the list head possibly disappearing from > > underneath us when we release all resources attached to the > > drm_device. > > > > v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless > > shuffling while getting everything into shape. > > > > v3: Add static to add/del_dr (Neil) > > Move typo fix to the right patch (Neil) > > > > v4: Enforce contract for drmm_add_final_kfree: > > > > Use ksize() to check that the drm_device is indeed contained somewhere > > in the final kfree(). Because we need that or the entire managed > > release logic blows up in a pile of use-after-frees. Motivated by a > > discussion with Laurent. > > > > v5: Review from Laurent: > > - %zu instead of casting size_t > > - header guards > > - sorting of includes > > - guarding of data assignment if we didn't allocate it for a NULL > > pointer > > - delete spurious newline > > - cast void* data parameter correctly in ->release call, no idea how > > this even worked before > > > > Cc: Laurent Pinchart > > Cc: Neil Armstrong > Cc: Greg Kroah-Hartman > > Cc: "Rafael J. Wysocki" > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-internals.rst | 6 + > > drivers/gpu/drm/Makefile| 3 +- > > drivers/gpu/drm/drm_drv.c | 13 ++- > > drivers/gpu/drm/drm_internal.h | 3 + > > drivers/gpu/drm/drm_managed.c | 175 > > include/drm/drm_device.h| 12 ++ > > include/drm/drm_managed.h | 30 + > > include/drm/drm_print.h | 6 + > > 8 files changed, 246 insertions(+), 2 deletions(-) > > create mode 100644 drivers/gpu/drm/drm_managed.c > > create mode 100644 include/drm/drm_managed.h > > > > diff --git a/Documentation/gpu/drm-internals.rst > > b/Documentation/gpu/drm-internals.rst > > index a73320576ca9..a6b6145fda78 100644 > > --- a/Documentation/gpu/drm-internals.rst > > +++ b/Documentation/gpu/drm-internals.rst > > @@ -132,6 +132,12 @@ be unmapped; on many devices, the ROM address decoder > > is shared with > > other BARs, so leaving it mapped could cause undesired behaviour like > > hangs or memory corruption. > > > > +Managed Resources > > +- > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_managed.c > > + :doc: managed resources > > + > > Bus-specific Device Registration and PCI Support > > > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index 7f72ef5e7811..183c60048307 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -17,7 +17,8 @@ drm-y := drm_auth.o drm_cache.o \ > > drm_plane.o drm_color_mgmt.o drm_print.o \ > > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ > > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ > > - drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o > > + drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \ > > +
Re: [Intel-gfx] [PATCH 26/51] drm: Manage drm_mode_config_init with drmm_
On Fri, Feb 28, 2020 at 9:26 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> Some bikeshedding in the following.
> with or with addressing (IMHO valid points) consider the patch:
>
> Reviewed-by: Sam Ravnborg
>
> Sam
>
> On Thu, Feb 27, 2020 at 07:14:57PM +0100, Daniel Vetter wrote:
> > drm_mode_config_cleanup is idempotent, so no harm in calling this
> > twice. This allows us to gradually switch drivers over by removing
> > explicit drm_mode_config_cleanup calls.
> >
>
> > With this step it's not also possible that (at least for simple
> > drivers) automatic resource cleanup can be done correctly without a
> > drm_driver->release hook. Therefore allow this now in
> > devm_drm_dev_init().
> I am not really sure what you try to explain here?
> Should the "not" be deleted?
s/not/now/
somehow that's a typo I do all the time, dunno why.
> > Also with drmm_ explicit drm_driver->release hooks are kinda not the
> > best option, so deprecate that hook to discourage future users.
> The ->release hooks has others uses until everything is moved over to
> drmm_, or so I think. So deprecation seems a lttle too soon.
You can just add a drmm action which calls your release function. The
upshot is that you can be more fine-grained (useful for unwinding when
driver load fails halfway through). That's why I think new drivers
after this patch shouldn't use ->release anymore, it's strictly less
useful than drmm actions. The less unwind code I have to review
carefully to make sure the right stuff gets released (and not more!)
the better.
> > v2: Fixup the example in the kerneldoc too.
> >
> > v3:
> > - For paranoia, double check that minor->dev == dev in the release
> > hook, because I botched the pointer math in the drmm library.
> > - Call drm_mode_config_cleanup when drmm_add_action fails, we'd be
> > missing some mutex_destroy and ida_cleanup otherwise (Laurent)
> >
> > v4: Add a drmm_add_action_or_reset (like devm_ has) to encapsulate this
> > pattern (Noralf).
> >
> > v5: Fix oversight in the new add_action_or_reset macro (Noralf)
>^ drmm_add_action_or_reset
> >
> > Cc: Laurent Pinchart
> > Cc: "Noralf Trønnes"
> > Cc: Sam Ravnborg
> > Cc: Thomas Zimmermann
> > Acked-by: Noralf Trønnes
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 23 +++
> > drivers/gpu/drm/drm_managed.c | 14 ++
> > drivers/gpu/drm/drm_mode_config.c | 13 -
> > include/drm/drm_managed.h | 7 +++
> > include/drm/drm_mode_config.h | 2 +-
> > 5 files changed, 41 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 3cf40864d4a6..bb326b9bcde0 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -98,6 +98,8 @@ static void drm_minor_alloc_release(struct drm_device
> > *dev, void *data)
> > struct drm_minor *minor = data;
> > unsigned long flags;
> >
> > + WARN_ON(dev != minor->dev);
> > +
> > put_device(minor->kdev);
> >
> > spin_lock_irqsave(_minor_lock, flags);
> > @@ -267,8 +269,7 @@ void drm_minor_release(struct drm_minor *minor)
> > *
> > * The following example shows a typical structure of a DRM display driver.
> > * The example focus on the probe() function and the other functions that
> > is
> > - * almost always present and serves as a demonstration of
> > devm_drm_dev_init()
> > - * usage with its accompanying drm_driver->release callback.
> > + * almost always present and serves as a demonstration of
> > devm_drm_dev_init().
> > *
> > * .. code-block:: c
> > *
> > @@ -278,16 +279,8 @@ void drm_minor_release(struct drm_minor *minor)
> > * struct clk *pclk;
> > * };
> > *
> > - * static void driver_drm_release(struct drm_device *drm)
> > - * {
> > - * struct driver_device *priv = container_of(...);
> > - *
> > - * drm_mode_config_cleanup(drm);
> > - * }
> > - *
> > * static struct drm_driver driver_drm_driver = {
> > * [...]
> > - * .release = driver_drm_release,
> > * };
> > *
> > * static int driver_probe(struct platform_device *pdev)
> > @@ -312,7 +305,9 @@ void drm_minor_release(struct drm_minor *minor)
> > * }
> > * drmm_add_final_kfree(drm, priv);
> > *
> > - * drm_mode_config_init(drm);
> > + * ret = drm_mode_config_init(drm);
> > + * if (ret)
> > + * return ret;
> We do not print anything in drm_mode_config_init() - so should
> we do it here?
> Otherwise we only get the more generic error from the driver core.
I can add a printk to drm_mode_config if people feel like. But it's
guaranteed dead code in reality, because of linux' small memory
allocation guarantee. Small mallocs like this one here of just 2
cachelines never fail (at least not with GFP_KERNEL).
> > *
> > *
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dram: hide the dram structs better
== Series Details == Series: drm/i915/dram: hide the dram structs better URL : https://patchwork.freedesktop.org/series/74025/ State : success == Summary == CI Bug Log - changes from CI_DRM_8020_full -> Patchwork_16736_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16736_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#1277]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-tglb3/igt@gem_exec_balan...@hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-tglb7/igt@gem_exec_balan...@hang.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +10 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-iclb5/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb5/igt@gem_exec_sched...@pi-common-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb5/igt@gem_exec_sched...@preemptive-hang-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#454]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb5/igt@i915_pm...@dc6-psr.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rpm@basic-rte: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([i915#189]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb7/igt@i915_pm_...@basic-rte.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-iclb2/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rps@waitboost: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#413]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb2/igt@i915_pm_...@waitboost.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-iclb8/igt@i915_pm_...@waitboost.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#34]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-skl1/igt@kms_f...@plain-flip-ts-check-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-skl8/igt@kms_f...@plain-flip-ts-check-interruptible.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16736/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#899]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk9/igt@kms_plane_low...@pipe-a-tiling-y.html
Re: [Intel-gfx] [PATCH v4 13/14] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
Hey - I've got a good bit of stuff on my plate right now since I just got back
from PTO and am going through my backlog of stuff, but I'll try to get this
reviewed first chance I get
On Tue, 2020-02-18 at 17:02 -0500, Sean Paul wrote:
> From: Sean Paul
>
> Used to query whether an MST stream is encrypted or not.
>
> Cc: Lyude Paul
> Signed-off-by: Sean Paul
>
> Changes in v4:
> -Added to the set
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 117 ++
> include/drm/drm_dp_helper.h | 3 +
> include/drm/drm_dp_mst_helper.h | 44 ++
> 3 files changed, 164 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index a811247cecfef..30b6dc6ce54c2 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -418,6 +419,22 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> memcpy([idx], req->u.i2c_write.bytes, req-
> >u.i2c_write.num_bytes);
> idx += req->u.i2c_write.num_bytes;
> break;
> + case DP_QUERY_STREAM_ENC_STATUS: {
> + const struct drm_dp_query_stream_enc_status *msg;
> +
> + msg = >u.enc_status;
> + buf[idx] = msg->stream_id;
> + idx++;
> + memcpy([idx], msg->client_id, sizeof(msg->client_id));
> + idx += sizeof(msg->client_id);
> + buf[idx] = 0;
> + buf[idx] |= msg->stream_event & GENMASK(1, 0);
> + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> + buf[idx] |= (msg->stream_behavior & GENMASK(1, 0)) << 3;
> + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> + idx++;
> + }
> + break;
> }
> raw->cur_len = idx;
> }
> @@ -926,6 +943,34 @@ static bool
> drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
> return true;
> }
>
> +static bool
> +drm_dp_sideband_parse_query_stream_enc_status(
> + struct drm_dp_sideband_msg_rx *raw,
> + struct drm_dp_sideband_msg_reply_body *repmsg)
> +{
> + struct drm_dp_query_stream_enc_status_ack_reply *reply;
> +
> + reply = >u.enc_status;
> +
> + reply->stream_id = raw->msg[3];
> +
> + reply->reply_signed = raw->msg[2] & BIT(0);
> +
> + reply->hdcp_1x_device_present = raw->msg[2] & BIT(3);
> + reply->hdcp_2x_device_present = raw->msg[2] & BIT(4);
> +
> + reply->query_capable_device_present = raw->msg[2] & BIT(5);
> + reply->legacy_device_present = raw->msg[2] & BIT(6);
> + reply->unauthorizable_device_present = raw->msg[2] & BIT(7);
> +
> + reply->auth_completed = !!(raw->msg[1] & BIT(3));
> + reply->encryption_enabled = !!(raw->msg[1] & BIT(4));
> + reply->repeater_present = !!(raw->msg[1] & BIT(5));
> + reply->state = (raw->msg[1] & GENMASK(7, 6)) >> 6;
> +
> + return true;
> +}
> +
> static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
> struct drm_dp_sideband_msg_reply_body
> *msg)
> {
> @@ -960,6 +1005,8 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
> return drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
> case DP_CLEAR_PAYLOAD_ID_TABLE:
> return true; /* since there's nothing to parse */
> + case DP_QUERY_STREAM_ENC_STATUS:
> + return drm_dp_sideband_parse_query_stream_enc_status(raw,
> msg);
> default:
> DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
> drm_dp_mst_req_type_str(msg->req_type));
> @@ -1113,6 +1160,25 @@ static int build_power_updown_phy(struct
> drm_dp_sideband_msg_tx *msg,
> return 0;
> }
>
> +static int
> +build_query_stream_enc_status(struct drm_dp_sideband_msg_tx *msg, u8
> stream_id,
> + u8 *q_id)
> +{
> + struct drm_dp_sideband_msg_req_body req;
> +
> + req.req_type = DP_QUERY_STREAM_ENC_STATUS;
> + req.u.enc_status.stream_id = stream_id;
> + memcpy(req.u.enc_status.client_id, q_id,
> +sizeof(req.u.enc_status.client_id));
> + req.u.enc_status.stream_event = 0;
> + req.u.enc_status.valid_stream_event = false;
> + req.u.enc_status.stream_behavior = 0;
> + req.u.enc_status.valid_stream_behavior = false;
> +
> + drm_dp_encode_sideband_req(, msg);
> + return 0;
> +}
> +
> static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr
> *mgr,
> struct drm_dp_vcpi *vcpi)
> {
> @@ -3154,6 +3220,57 @@ int drm_dp_send_power_updown_phy(struct
> drm_dp_mst_topology_mgr *mgr,
> }
> EXPORT_SYMBOL(drm_dp_send_power_updown_phy);
>
> +int
Re: [Intel-gfx] [PATCH 03/51] drm: add managed resources tied to drm_device
Hi Daniel. Some nitpicks / bikeshedding below. Sam On Thu, Feb 27, 2020 at 07:14:34PM +0100, Daniel Vetter wrote: > We have lots of these. And the cleanup code tends to be of dubious > quality. The biggest wrong pattern is that developers use devm_, which > ties the release action to the underlying struct device, whereas > all the userspace visible stuff attached to a drm_device can long > outlive that one (e.g. after a hotunplug while userspace has open > files and mmap'ed buffers). Give people what they want, but with more > correctness. > > Mostly copied from devres.c, with types adjusted to fit drm_device and > a few simplifications - I didn't (yet) copy over everything. Since > the types don't match code sharing looked like a hopeless endeavour. Readability had been increased if the short names was not reused. s/dr_/drmres_/ But I know, this is in the bikeshedding area. > > For now it's only super simplified, no groups, you can't remove > actions (but kfree exists, we'll need that soon). Plus all specific to > drm_device ofc, including the logging. Which I didn't bother to make > compile-time optional, since none of the other drm logging is compile > time optional either. > > One tricky bit here is the chicken between allocating your > drm_device structure and initiliazing it with drm_dev_init. For > perfect onion unwinding we'd need to have the action to kfree the > allocation registered before drm_dev_init registers any of its own > release handlers. But drm_dev_init doesn't know where exactly the > drm_device is emebedded into the overall structure, and by the time it > returns it'll all be too late. And forcing drivers to be able clean up > everything except the one kzalloc is silly. > > Work around this by having a very special final_kfree pointer. This > also avoids troubles with the list head possibly disappearing from > underneath us when we release all resources attached to the > drm_device. > > v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless > shuffling while getting everything into shape. > > v3: Add static to add/del_dr (Neil) > Move typo fix to the right patch (Neil) > > v4: Enforce contract for drmm_add_final_kfree: > > Use ksize() to check that the drm_device is indeed contained somewhere > in the final kfree(). Because we need that or the entire managed > release logic blows up in a pile of use-after-frees. Motivated by a > discussion with Laurent. > > v5: Review from Laurent: > - %zu instead of casting size_t > - header guards > - sorting of includes > - guarding of data assignment if we didn't allocate it for a NULL > pointer > - delete spurious newline > - cast void* data parameter correctly in ->release call, no idea how > this even worked before > > Cc: Laurent Pinchart > Cc: Neil Armstrong Cc: Greg Kroah-Hartman > Cc: "Rafael J. Wysocki" > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-internals.rst | 6 + > drivers/gpu/drm/Makefile| 3 +- > drivers/gpu/drm/drm_drv.c | 13 ++- > drivers/gpu/drm/drm_internal.h | 3 + > drivers/gpu/drm/drm_managed.c | 175 > include/drm/drm_device.h| 12 ++ > include/drm/drm_managed.h | 30 + > include/drm/drm_print.h | 6 + > 8 files changed, 246 insertions(+), 2 deletions(-) > create mode 100644 drivers/gpu/drm/drm_managed.c > create mode 100644 include/drm/drm_managed.h > > diff --git a/Documentation/gpu/drm-internals.rst > b/Documentation/gpu/drm-internals.rst > index a73320576ca9..a6b6145fda78 100644 > --- a/Documentation/gpu/drm-internals.rst > +++ b/Documentation/gpu/drm-internals.rst > @@ -132,6 +132,12 @@ be unmapped; on many devices, the ROM address decoder is > shared with > other BARs, so leaving it mapped could cause undesired behaviour like > hangs or memory corruption. > > +Managed Resources > +- > + > +.. kernel-doc:: drivers/gpu/drm/drm_managed.c > + :doc: managed resources > + > Bus-specific Device Registration and PCI Support > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 7f72ef5e7811..183c60048307 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -17,7 +17,8 @@ drm-y := drm_auth.o drm_cache.o \ > drm_plane.o drm_color_mgmt.o drm_print.o \ > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ > - drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o > + drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \ > + drm_managed.o > > drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o > drm_dma.o drm_scatter.o drm_lock.o > drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: nuke skl workaround for pre-production hw (rev3)
== Series Details == Series: drm/i915/display: nuke skl workaround for pre-production hw (rev3) URL : https://patchwork.freedesktop.org/series/71230/ State : success == Summary == CI Bug Log - changes from CI_DRM_8034 -> Patchwork_16769 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16769/index.html Known issues Here are the changes found in Patchwork_16769 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@perf: - fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8034/fi-apl-guc/igt@i915_selftest@l...@perf.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16769/fi-apl-guc/igt@i915_selftest@l...@perf.html Possible fixes * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [DMESG-FAIL][3] ([i915#877]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8034/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16769/fi-cml-s/igt@i915_selftest@live@gem_contexts.html - fi-cfl-guc: [DMESG-FAIL][5] ([i915#623]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8034/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16769/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][7] ([fdo#111096] / [i915#323]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8034/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16769/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][9] ([CI#94]) -> [INCOMPLETE][10] ([CI#94] / [i915#460]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8034/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16769/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#460]: https://gitlab.freedesktop.org/drm/intel/issues/460 [i915#623]: https://gitlab.freedesktop.org/drm/intel/issues/623 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (47 -> 40) -- Additional (2): fi-bsw-kefka fi-glk-dsi Missing(9): fi-ilk-m540 fi-bdw-5557u fi-ctg-p8600 fi-ivb-3770 fi-cfl-8109u fi-bdw-samus fi-byt-clapper fi-skl-6600u fi-kbl-r Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8034 -> Patchwork_16769 CI-20190529: 20190529 CI_DRM_8034: f49e335968bf53de15d8c3e7c79047308ce9155e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16769: 3d35be24f014dbe969c286e01ba347ae8af00389 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3d35be24f014 drm/i915/display: nuke skl workaround for pre-production hw == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16769/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/11] drm/i915/tgl: Implement Wa_1407901919
Can you guys help in this one? Check Matt comment bellow.
On Fri, 2020-02-28 at 14:07 -0800, Matt Roper wrote:
> On Thu, Feb 27, 2020 at 02:01:01PM -0800, José Roberto de Souza
> wrote:
> > This will fix a memory coherence issue.
> >
> > v3: using whitespace to make easy to read WA (Chris)
> >
> > BSpec: 52890
> > Cc: Chris Wilson
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
> > drivers/gpu/drm/i915/i915_reg.h | 20 +++
> > -
> > 2 files changed, 19 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 3e375a3b7714..c59e1a604ab8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -601,6 +601,14 @@ static void tgl_ctx_workarounds_init(struct
> > intel_engine_cs *engine,
> > */
> > wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK,
> >FF_MODE2_TDS_TIMER_128, 0);
> > +
> > + /* Wa_1407901919:tgl */
> > + wa_add(wal, ICL_HDC_MODE,
> > + HDC_COHERENT_ACCESS_L1_CACHE_DIS |
> > + HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W,
>
> I'm not sure if this is what the workaround is asking for. The way I
> understood the workaround, the 2-dword STATE_COMPUTE_MODE instruction
> has a couple bits that must be left at 0. STATE_COMPUTE_MODE is
> basically how we ultimately load the HDC_MODE registers (rather than
> using a simple LRI like we do for a bunch of other registers), but
> the
> workaround isn't asking us to worry about bits 13+14 in the HDC_MODE
> register itself, but rather those flags bits on the instruction that
> manipulates the register.
>
> Every time there's a context switch, the hardware will generate a
> copy
> of this instruction as part of the context image in writes to RAM;
> I'm
> assuming these bits aren't set on those hardware-created
> instructions?
> Assuming that's true, then I think this workaround would just be
> userspace's responsibility --- if they submit an explicit
> STATE_COMPUTE_MODE instruction that isn't just part of the context
> image, they need to follow the workaround guidance here and leave two
> of
> those bits set to 0.
>
>
> Matt
>
> > + 0,
> > + HDC_COHERENT_ACCESS_L1_CACHE_DIS |
> > + HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W);
> > }
> >
> > static void
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 80cf02a6eec1..28822585537b 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7883,15 +7883,17 @@ enum {
> > #define GEN8_LQSC_FLUSH_COHERENT_LINES(1 << 21)
> >
> > /* GEN8 chicken */
> > -#define HDC_CHICKEN0 _MMIO(0x7300)
> > -#define CNL_HDC_CHICKEN0 _MMIO(0xE5F0)
> > -#define ICL_HDC_MODE _MMIO(0xE5F4)
> > -#define HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE(1 << 15)
> > -#define HDC_FENCE_DEST_SLM_DISABLE(1 << 14)
> > -#define HDC_DONOT_FETCH_MEM_WHEN_MASKED (1 << 11)
> > -#define HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT (1 <<
> > 5)
> > -#define HDC_FORCE_NON_COHERENT(1 << 4)
> > -#define HDC_BARRIER_PERFORMANCE_DISABLE (1 << 10)
> > +#define HDC_CHICKEN0 _MMIO(0
> > x7300)
> > +#define CNL_HDC_CHICKEN0 _MMIO(0xE5F0)
> > +#define ICL_HDC_MODE _MMIO(0
> > xE5F4)
> > +#define HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLEREG_BIT
> > (15)
> > +#define HDC_FENCE_DEST_SLM_DISABLEREG_BIT
> > (14)
> > +#define HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W REG_BIT(13)
> > +#define HDC_COHERENT_ACCESS_L1_CACHE_DIS REG_BIT(12)
> > +#define HDC_DONOT_FETCH_MEM_WHEN_MASKED REG_BIT(11)
> > +#define HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT REG_BIT
> > (5)
> > +#define HDC_FORCE_NON_COHERENTREG_BIT
> > (4)
> > +#define HDC_BARRIER_PERFORMANCE_DISABLE REG_BIT(10)
> >
> > #define GEN8_HDC_CHICKEN1 _MMIO(0x7304)
> >
> > --
> > 2.25.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 11/11] drm/i915/tgl: Implement Wa_1407901919
On Thu, Feb 27, 2020 at 02:01:01PM -0800, José Roberto de Souza wrote:
> This will fix a memory coherence issue.
>
> v3: using whitespace to make easy to read WA (Chris)
>
> BSpec: 52890
> Cc: Chris Wilson
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
> drivers/gpu/drm/i915/i915_reg.h | 20 +++-
> 2 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3e375a3b7714..c59e1a604ab8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -601,6 +601,14 @@ static void tgl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
>*/
> wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK,
> FF_MODE2_TDS_TIMER_128, 0);
> +
> + /* Wa_1407901919:tgl */
> + wa_add(wal, ICL_HDC_MODE,
> +HDC_COHERENT_ACCESS_L1_CACHE_DIS |
> +HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W,
I'm not sure if this is what the workaround is asking for. The way I
understood the workaround, the 2-dword STATE_COMPUTE_MODE instruction
has a couple bits that must be left at 0. STATE_COMPUTE_MODE is
basically how we ultimately load the HDC_MODE registers (rather than
using a simple LRI like we do for a bunch of other registers), but the
workaround isn't asking us to worry about bits 13+14 in the HDC_MODE
register itself, but rather those flags bits on the instruction that
manipulates the register.
Every time there's a context switch, the hardware will generate a copy
of this instruction as part of the context image in writes to RAM; I'm
assuming these bits aren't set on those hardware-created instructions?
Assuming that's true, then I think this workaround would just be
userspace's responsibility --- if they submit an explicit
STATE_COMPUTE_MODE instruction that isn't just part of the context
image, they need to follow the workaround guidance here and leave two of
those bits set to 0.
Matt
> +0,
> +HDC_COHERENT_ACCESS_L1_CACHE_DIS |
> +HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W);
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 80cf02a6eec1..28822585537b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7883,15 +7883,17 @@ enum {
> #define GEN8_LQSC_FLUSH_COHERENT_LINES (1 << 21)
>
> /* GEN8 chicken */
> -#define HDC_CHICKEN0 _MMIO(0x7300)
> -#define CNL_HDC_CHICKEN0 _MMIO(0xE5F0)
> -#define ICL_HDC_MODE _MMIO(0xE5F4)
> -#define HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE (1 << 15)
> -#define HDC_FENCE_DEST_SLM_DISABLE (1 << 14)
> -#define HDC_DONOT_FETCH_MEM_WHEN_MASKED (1 << 11)
> -#define HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT (1 << 5)
> -#define HDC_FORCE_NON_COHERENT (1 << 4)
> -#define HDC_BARRIER_PERFORMANCE_DISABLE (1 << 10)
> +#define HDC_CHICKEN0 _MMIO(0x7300)
> +#define CNL_HDC_CHICKEN0 _MMIO(0xE5F0)
> +#define ICL_HDC_MODE _MMIO(0xE5F4)
> +#define HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE REG_BIT(15)
> +#define HDC_FENCE_DEST_SLM_DISABLE REG_BIT(14)
> +#define HDC_DIS_L1_INVAL_FOR_NON_L1_CACHEABLE_W REG_BIT(13)
> +#define HDC_COHERENT_ACCESS_L1_CACHE_DISREG_BIT(12)
> +#define HDC_DONOT_FETCH_MEM_WHEN_MASKED REG_BIT(11)
> +#define HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT REG_BIT(5)
> +#define HDC_FORCE_NON_COHERENT REG_BIT(4)
> +#define HDC_BARRIER_PERFORMANCE_DISABLE REG_BIT(10)
>
> #define GEN8_HDC_CHICKEN1_MMIO(0x7304)
>
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/vgpu: improve vgpu abstractions
== Series Details == Series: series starting with [1/3] drm/i915/vgpu: improve vgpu abstractions URL : https://patchwork.freedesktop.org/series/74024/ State : success == Summary == CI Bug Log - changes from CI_DRM_8020_full -> Patchwork_16735_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8020_full and Patchwork_16735_full: ### New IGT tests (1) ### * igt@i915_selftest@perf: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_16735_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-glk: [PASS][1] -> [INCOMPLETE][2] ([i915#1291] / [i915#58] / [k.org#198133]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk1/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-glk9/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb3/igt@gem_exec_sched...@wide-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-iclb1/igt@gem_exec_sched...@wide-bsd.html * igt@gem_exec_whisper@basic-queues-forked: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-apl3/igt@gem_exec_whis...@basic-queues-forked.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-apl3/igt@gem_exec_whis...@basic-queues-forked.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#454]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-iclb7/igt@i915_pm...@dc6-dpms.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#72]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk4/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-glk7/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-apl2/igt@kms_f...@flip-vs-suspend-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-apl6/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#123] / [i915#69]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-skl8/igt@kms_frontbuffer_track...@psr-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-skl7/igt@kms_frontbuffer_track...@psr-suspend.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16735/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#899]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8020/shard-glk9/igt@kms_plane_low...@pipe-a-tiling-y.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Don't check uv_wm in skl_plane_wm_equals()
== Series Details ==
Series: series starting with [1/4] drm/i915: Don't check uv_wm in
skl_plane_wm_equals()
URL : https://patchwork.freedesktop.org/series/74092/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8033 -> Patchwork_16768
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_16768:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_lrc:
- {fi-tgl-dsi}: NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
Known issues
Here are the changes found in Patchwork_16768 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@active:
- fi-cfl-8109u: [PASS][2] -> [DMESG-FAIL][3] ([i915#666])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8033/fi-cfl-8109u/igt@i915_selftest@l...@active.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-cfl-8109u/igt@i915_selftest@l...@active.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([CI#94] / [i915#402])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8033/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][6] ([CI#94]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8033/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6700k2: [INCOMPLETE][8] ([i915#151]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8033/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][10] ([fdo#111407]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8033/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][12] ([i915#44]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8033/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [DMESG-WARN][14] ([CI#94] / [i915#402]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8033/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16768/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#44]: https://gitlab.freedesktop.org/drm/intel/issues/44
[i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666
Participating hosts (48 -> 41)
--
Additional (4): fi-kbl-soraka fi-byt-j1900 fi-glk-dsi fi-kbl-7560u
Missing(11): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-bwr-2160
fi-snb-2520m fi-ctg-p8600 fi-ivb-3770 fi-bdw-samus fi-byt-clapper fi-skl-6600u
fi-snb-2600
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8033 -> Patchwork_16768
CI-20190529: 20190529
CI_DRM_8033: de34c8a09179f693b84174d43855172ec76c30b3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16768: bf886daea063a6a886ea297a554e12d69692 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
bf886daea063 drm/i915: Implement display w/a 1140 for glk/cnl
c32d3d0a88d0 drm/i915: Enable transition watermarks for glk
1a8724cb6ad6
Re: [Intel-gfx] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use
Hi Chris, On Fri, Feb 28, 2020 at 10:43:36AM +, Chris Wilson wrote: > Several tests depend upon the implicit engine->mmio_base but have no > means of determining the physical layout. Since the kernel has started > providing this information, start putting it to use. > > Signed-off-by: Chris Wilson Looks good! Reviewed-by: Andi Shyti Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 09/11] drm/i915/tgl: Restrict Wa_1408615072 to A0 stepping
On Thu, Feb 27, 2020 at 02:00:59PM -0800, José Roberto de Souza wrote:
> It is fixed in B0 stepping.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 22aa205793e5..a101d8072b5b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6838,8 +6838,9 @@ static void tgl_init_clock_gating(struct
> drm_i915_private *dev_priv)
> unsigned int i;
>
> /* Wa_1408615072:tgl */
> - intel_uncore_rmw(_priv->uncore, UNSLICE_UNIT_LEVEL_CLKGATE2,
> - 0, VSUNIT_CLKGATE_DIS_TGL);
> + if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
> + intel_uncore_rmw(_priv->uncore, UNSLICE_UNIT_LEVEL_CLKGATE2,
> + 0, VSUNIT_CLKGATE_DIS_TGL);
I think this workaround is also implemented in the wrong location. This
is a render engine register (part of the 94D0-951C render forcewake
range on bspec 52078) and part of the MCR range (bspec 52079), so we
should program this in the engine_wa_init rather than the clock gating
function.
The ICL/EHL version (which we based the TGL WA on) is also in the wrong
place for the same reasons.
At some point we should probably audit all the other GT/engine/MCR
registers we're dealing with in the init_clock_gating functions and move
them out to more appropriate places.
Matt
>
> /* This is not a WA. Enable VD HCP & MFX_ENC powergate */
> for (i = 0; i < I915_MAX_VCS; i++) {
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 9:31 PM Dave Airlie wrote: > > On Sat, 29 Feb 2020 at 05:34, Eric Anholt wrote: > > > > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote: > > > > > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > > > > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > > > > b) we probably need to take a large step back here. > > > > > > > > > > Look at this from a sponsor POV, why would I give X.org/fd.o > > > > > sponsorship money that they are just giving straight to google to pay > > > > > for hosting credits? Google are profiting in some minor way from these > > > > > hosting credits being bought by us, and I assume we aren't getting any > > > > > sort of discounts here. Having google sponsor the credits costs google > > > > > substantially less than having any other company give us money to do > > > > > it. > > > > > > > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty > > > > comparable in terms of what you get and what you pay for them. > > > > Obviously providers like Packet and Digital Ocean who offer bare-metal > > > > services are cheaper, but then you need to find someone who is going > > > > to properly administer the various machines, install decent > > > > monitoring, make sure that more storage is provisioned when we need > > > > more storage (which is basically all the time), make sure that the > > > > hardware is maintained in decent shape (pretty sure one of the fd.o > > > > machines has had a drive in imminent-failure state for the last few > > > > months), etc. > > > > > > > > Given the size of our service, that's a much better plan (IMO) than > > > > relying on someone who a) isn't an admin by trade, b) has a million > > > > other things to do, and c) hasn't wanted to do it for the past several > > > > years. But as long as that's the resources we have, then we're paying > > > > the cloud tradeoff, where we pay more money in exchange for fewer > > > > problems. > > > > > > Admin for gitlab and CI is a full time role anyways. The system is > > > definitely not self sustaining without time being put in by you and > > > anholt still. If we have $75k to burn on credits, and it was diverted > > > to just pay an admin to admin the real hw + gitlab/CI would that not > > > be a better use of the money? I didn't know if we can afford $75k for > > > an admin, but suddenly we can afford it for gitlab credits? > > > > As I think about the time that I've spent at google in less than a > > year on trying to keep the lights on for CI and optimize our > > infrastructure in the current cloud environment, that's more than the > > entire yearly budget you're talking about here. Saying "let's just > > pay for people to do more work instead of paying for full-service > > cloud" is not a cost optimization. > > > > > > > > Yes, we could federate everything back out so everyone runs their own > > > > builds and executes those. Tinderbox did something really similar to > > > > that IIRC; not sure if Buildbot does as well. Probably rules out > > > > pre-merge testing, mind. > > > > > > Why? does gitlab not support the model? having builds done in parallel > > > on runners closer to the test runners seems like it should be a thing. > > > I guess artifact transfer would cost less then as a result. > > > > Let's do some napkin math. The biggest artifacts cost we have in Mesa > > is probably meson-arm64/meson-arm (60MB zipped from meson-arm64, > > downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day, > > makes ~1.8TB/month ($180 or so). We could build a local storage next > > to the lava dispatcher so that the artifacts didn't have to contain > > the rootfs that came from the container (~2/3 of the insides of the > > zip file), but that's another service to build and maintain. Building > > the drivers once locally and storing it would save downloading the > > other ~1/3 of the inside of the zip file, but that requires a big > > enough system to do builds in time. > > > > I'm planning on doing a local filestore for google's lava lab, since I > > need to be able to move our xml files off of the lava DUTs to get the > > xml results we've become accustomed to, but this would not bubble up > > to being a priority for my time if I wasn't doing it anyway. If it > > takes me a single day to set all this up (I estimate a couple of > > weeks), that costs my employer a lot more than sponsoring the costs of > > the inefficiencies of the system that has accumulated. > > I'm not trying to knock the engineering works the CI contributors have > done at all, but I've never seen a real discussion about costs until > now. Engineers aren't accountants. > > The thing we seem to be missing here is fiscal responsibility. I know > this email is us being fiscally responsible, but it's kinda after the > fact. > > I cannot commit my employer to spending a large amount of money (> 0 > actually) without a long and lengthy process with checks and bounds. > Can you? > > The
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 12:00 AM Daniel Stone wrote: > > Hi Matt, > > On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote: > > We're paying 75K USD for the bandwidth to transfer data from the > > GitLab cloud instance. i.e., for viewing the https site, for > > cloning/updating git repos, and for downloading CI artifacts/images to > > the testing machines (AFAIU). > > I believe that in January, we had $2082 of network cost (almost > entirely egress; ingress is basically free) and $1750 of cloud-storage > cost (almost all of which was download). That's based on 16TB of > cloud-storage (CI artifacts, container images, file uploads, Git LFS) > egress and 17.9TB of other egress (the web service itself, repo > activity). Projecting that out gives us roughly $45k of network > activity alone, so it looks like this figure is based on a projected > increase of ~50%. > > The actual compute capacity is closer to $1150/month. Could we have the full GCP bill posted? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 37/51] drm/rockchip: Drop explicit drm_mode_config_cleanup call
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20200228]
[cannot apply to drm-intel/for-linux-next linus/master
pinchartl-media/drm/du/next v5.6-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-managed-resources-v3/20200229-005817
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/rockchip/rockchip_drm_drv.c: In function 'rockchip_drm_bind':
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.c:147:3: error: label
>> 'err_mode_config_cleanup' used but not defined
goto err_mode_config_cleanup;
^~~~
vim +/err_mode_config_cleanup +147 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
2048e3286f347db Mark Yao 2014-08-22 110
f706974a69b6e2b Tomeu Vizoso 2016-06-10 111 static int
rockchip_drm_bind(struct device *dev)
2048e3286f347db Mark Yao 2014-08-22 112 {
f706974a69b6e2b Tomeu Vizoso 2016-06-10 113 struct drm_device
*drm_dev;
2048e3286f347db Mark Yao 2014-08-22 114 struct
rockchip_drm_private *private;
2048e3286f347db Mark Yao 2014-08-22 115 int ret;
2048e3286f347db Mark Yao 2014-08-22 116
f706974a69b6e2b Tomeu Vizoso 2016-06-10 117 drm_dev =
drm_dev_alloc(_drm_driver, dev);
0f2886057be322d Tom Gundersen 2016-09-21 118 if (IS_ERR(drm_dev))
0f2886057be322d Tom Gundersen 2016-09-21 119 return
PTR_ERR(drm_dev);
2048e3286f347db Mark Yao 2014-08-22 120
f706974a69b6e2b Tomeu Vizoso 2016-06-10 121 dev_set_drvdata(dev,
drm_dev);
f706974a69b6e2b Tomeu Vizoso 2016-06-10 122
f706974a69b6e2b Tomeu Vizoso 2016-06-10 123 private =
devm_kzalloc(drm_dev->dev, sizeof(*private), GFP_KERNEL);
f706974a69b6e2b Tomeu Vizoso 2016-06-10 124 if (!private) {
f706974a69b6e2b Tomeu Vizoso 2016-06-10 125 ret = -ENOMEM;
9127f99c4801f32 Tomasz Figa 2016-06-21 126 goto err_free;
f706974a69b6e2b Tomeu Vizoso 2016-06-10 127 }
f706974a69b6e2b Tomeu Vizoso 2016-06-10 128
2048e3286f347db Mark Yao 2014-08-22 129 drm_dev->dev_private =
private;
2048e3286f347db Mark Yao 2014-08-22 130
5182c1a556d7ff7 Yakir Yang2016-07-24 131
INIT_LIST_HEAD(>psr_list);
60beeccc72cabef Sean Paul 2018-03-05 132
mutex_init(>psr_list_lock);
5182c1a556d7ff7 Yakir Yang2016-07-24 133
ccea91998c8f140 Jeffy Chen2017-04-06 134 ret =
rockchip_drm_init_iommu(drm_dev);
ccea91998c8f140 Jeffy Chen2017-04-06 135 if (ret)
ccea91998c8f140 Jeffy Chen2017-04-06 136 goto err_free;
ccea91998c8f140 Jeffy Chen2017-04-06 137
7db42e97bb41bd5 Daniel Vetter 2020-02-27 138 ret =
drm_mode_config_init(drm_dev);
7db42e97bb41bd5 Daniel Vetter 2020-02-27 139 if (ret)
7db42e97bb41bd5 Daniel Vetter 2020-02-27 140 goto
err_iommu_cleanup;
2048e3286f347db Mark Yao 2014-08-22 141
2048e3286f347db Mark Yao 2014-08-22 142
rockchip_drm_mode_config_init(drm_dev);
2048e3286f347db Mark Yao 2014-08-22 143
2048e3286f347db Mark Yao 2014-08-22 144 /* Try to bind all sub
drivers. */
2048e3286f347db Mark Yao 2014-08-22 145 ret =
component_bind_all(dev, drm_dev);
2048e3286f347db Mark Yao 2014-08-22 146 if (ret)
ccea91998c8f140 Jeffy Chen2017-04-06 @147 goto
err_mode_config_cleanup;
2048e3286f347db Mark Yao 2014-08-22 148
ccea91998c8f140 Jeffy Chen2017-04-06 149 ret =
drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
ccea91998c8f140 Jeffy Chen2017-04-06 150 if (ret)
ccea91998c8f140 Jeffy Chen2017-04-06 151 goto
err_unbind_all;
ccea91998c8f140 Jeffy Chen2017-04-06 152
ccea91998c8f140 Jeffy Chen2017-04-06 153
drm_mode_config_reset(drm_dev);
2048e3286f347db Mark Yao 2014-08-22 154
2048e3286f347db Mark Yao 2014-08-22 155 /*
2048e3286f347db Mark Yao 2014-08-22 156* enable drm i
Re: [Intel-gfx] [PATCH v3 08/11] drm/i915/tgl: Add note about Wa_1409142259
On Thu, Feb 27, 2020 at 02:00:58PM -0800, José Roberto de Souza wrote:
> Different issues with the same fix, so justing adding
> Wa_1409142259, Wa_1409252684, Wa_1409217633, Wa_1409207793,
> Wa_1409178076 and 1408979724 to the comment so other devs can check if
> this Was were implemetend with a simple grep.
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 0cdd3c50e0ae..ba0265763484 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -580,7 +580,15 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
>struct i915_wa_list *wal)
> {
> - /* Wa_1409142259:tgl */
> + /*
> + * Wa_1409142259:tgl
> + * Wa_1409347922:tgl
> + * Wa_1409252684:tgl
> + * Wa_1409217633:tgl
> + * Wa_1409207793:tgl
> + * Wa_1409178076:tgl
> + * Wa_1408979724:tgl
> + */
> WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
> GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
>
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/display: nuke skl workaround for pre-production hw
According to intel_detect_preproduction_hw(), the SKL stepping D0 is
still pre-preproduction so we can nuke the additional workaround.
WA database says it applies to all steppings, but bspec disagrees.
After talking to HW people they said it was fixed either on B0 or D0.
While at it, nuke dangling new line.
v2: fix typo in commit message (Michael) and note that W/A db disagrees
with the steppings this is applicable (Ville).
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ab2e2454f038..c33eb4f8aa70 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16887,14 +16887,8 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
if (intel_ddi_crt_present(dev_priv))
intel_crt_init(dev_priv);
- /*
-* Haswell uses DDI functions to detect digital outputs.
-* On SKL pre-D0 the strap isn't connected, so we assume
-* it's there.
-*/
found = intel_de_read(dev_priv, DDI_BUF_CTL(PORT_A)) &
DDI_INIT_DISPLAY_DETECTED;
- /* WaIgnoreDDIAStrap: skl */
- if (found || IS_GEN9_BC(dev_priv))
+ if (found)
intel_ddi_init(dev_priv, PORT_A);
/* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
@@ -16915,7 +16909,6 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
if (IS_GEN9_BC(dev_priv) &&
intel_bios_is_port_present(dev_priv, PORT_E))
intel_ddi_init(dev_priv, PORT_E);
-
} else if (HAS_PCH_SPLIT(dev_priv)) {
int found;
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 07/11] drm/i915/tgl: Fix the Wa number of a fix
On Thu, Feb 27, 2020 at 02:00:57PM -0800, José Roberto de Souza wrote: > The Wa number for this fix is Wa_1607087056 the BSpec bug id is > 1607087056, just updating to match BSpec. > > BSpec: 52890 > Signed-off-by: José Roberto de Souza Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 80411e408039..0cdd3c50e0ae 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -931,7 +931,7 @@ tgl_gt_workarounds_init(struct drm_i915_private *i915, > struct i915_wa_list *wal) > SUBSLICE_UNIT_LEVEL_CLKGATE2, > CPSSUNIT_CLKGATE_DIS); > > - /* Wa_1409180338:tgl */ > + /* Wa_1607087056:tgl also know as BUG:1409180338 */ > if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) > wa_write_or(wal, > SLICE_UNIT_LEVEL_CLKGATE, > -- > 2.25.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/11] drm/i915/tgl: Implement Wa_1806527549
On Thu, Feb 27, 2020 at 02:00:52PM -0800, José Roberto de Souza wrote: > This will whitelist the HIZ_CHICKEN register so mesa can disable the > optimizations and avoid hang when using D16_UNORM. > > v2: moved to the right place and used the right function() (Chris) > > Cc: Matt Roper > Cc: Rafael Antognolli > Cc: Chris Wilson > Signed-off-by: José Roberto de Souza Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index d402b8ebc780..5d85b7531f76 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -1259,6 +1259,9 @@ static void tgl_whitelist_build(struct intel_engine_cs > *engine) > > /* Wa_1808121037:tgl */ > whitelist_reg(w, GEN7_COMMON_SLICE_CHICKEN1); > + > + /* Wa_1806527549:tgl */ > + whitelist_reg(w, HIZ_CHICKEN); > break; > default: > break; > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: introduce global sseu pinning
On 28/02/2020 18:44, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-02-28 16:02:29)
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As a result using OA (and NOA feeding into it) so far has required us
to use a power configuration that can work for all contexts. The only
power configuration fullfilling this is powergating half the execution
units.
This makes performance analysis for 3D workloads somewhat pointless.
Failing to find a solution that would work for everybody, this change
introduces a new i915-perf stream open parameter that punts the
decision off to userspace. If this parameter is omitted, the existing
Gen11 behavior remains (half EU array powergating).
This change takes the initiative to move all perf related sseu
configuration into i915_perf.c
The code looks fine, your argument is sound. My only reservation is the
danger of this becoming the defacto default and so catching users's
profiling their system by surprise.
As far as I can see, this will only be using non default (default = full
EU array on !gen11, default = half EU array on gen11) on Gen11.
Except Gen11 we don't have those asymetric subslices (remember gen12 has
dual slices of 16 EUs).
It all bad choices :
- let everybody do what they want but risk invalid OA data with no
warning
- force everybody to the same config and only on gen11 risk a hang
if VME samplers end up being used (which is a subset of all media workloads)
@@ -3628,6 +3678,16 @@ static int read_properties_unlocked(struct i915_perf
*perf,
case DRM_I915_PERF_PROP_HOLD_PREEMPTION:
props->hold_preemption = !!value;
break;
+ case DRM_I915_PERF_PROP_GLOBAL_SSEU: {
+ if (copy_from_user(>user_sseu,
+ u64_to_user_ptr(value),
+ sizeof(props->user_sseu))) {
+ DRM_DEBUG("Unable to copy global sseu
parameter\n");
+ return -EFAULT;
+ }
Since this affects system state for other users, I would suggest this
has a privilege check
+ props->user_sseu_present = true;
+ break;
i915_perf_ioctl_open_locked:
if (props->user_sseu_present && IS_GEN(11))
privileged_op = true;
?
I'm going to go with priviliged for all gens except if user request ==
default.
Thanks a lot,
-Lionel
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 49/51] drm/udl: Drop explicit drm_mode_config_cleanup call
On Thu, Feb 27, 2020 at 07:15:20PM +0100, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> This allows us to delete a bit of onion unwinding in
> udl_modeset_init().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> v2: Explain why this cleanup is possible (Laurent).
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Daniel Vetter
> Cc: Thomas Zimmermann
> Cc: Emil Velikov
> Cc: Gerd Hoffmann
> Cc: "Noralf Trønnes"
> Cc: Thomas Gleixner
> Cc: Sam Ravnborg
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/udl/udl_drv.c | 1 -
> drivers/gpu/drm/udl/udl_drv.h | 1 -
> drivers/gpu/drm/udl/udl_modeset.c | 21 ++---
> 3 files changed, 6 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 8b78c356beb5..b447fb053e78 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -37,7 +37,6 @@ DEFINE_DRM_GEM_FOPS(udl_driver_fops);
> static void udl_driver_release(struct drm_device *dev)
> {
> udl_fini(dev);
> - udl_modeset_cleanup(dev);
> }
>
> static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index e67227c44cc4..1de7eb1b6aac 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -68,7 +68,6 @@ struct udl_device {
>
> /* modeset */
> int udl_modeset_init(struct drm_device *dev);
> -void udl_modeset_cleanup(struct drm_device *dev);
> struct drm_connector *udl_connector_init(struct drm_device *dev);
>
> struct urb *udl_get_urb(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index d59ebac70b15..cad0c87f8de6 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -468,7 +468,9 @@ int udl_modeset_init(struct drm_device *dev)
> struct drm_connector *connector;
> int ret;
>
> - drm_mode_config_init(dev);
> + ret = drm_mode_config_init(dev);
> + if (ret)
> + return ret;
>
> dev->mode_config.min_width = 640;
> dev->mode_config.min_height = 480;
> @@ -482,10 +484,8 @@ int udl_modeset_init(struct drm_device *dev)
> dev->mode_config.funcs = _mode_funcs;
>
> connector = udl_connector_init(dev);
> - if (IS_ERR(connector)) {
> - ret = PTR_ERR(connector);
> - goto err_drm_mode_config_cleanup;
> - }
> + if (IS_ERR(connector))
> + return PTR_ERR(connector);
>
> format_count = ARRAY_SIZE(udl_simple_display_pipe_formats);
>
> @@ -494,18 +494,9 @@ int udl_modeset_init(struct drm_device *dev)
> udl_simple_display_pipe_formats,
> format_count, NULL, connector);
> if (ret)
> - goto err_drm_mode_config_cleanup;
> + return ret;
>
> drm_mode_config_reset(dev);
>
> return 0;
> -
> -err_drm_mode_config_cleanup:
> - drm_mode_config_cleanup(dev);
> - return ret;
> -}
> -
> -void udl_modeset_cleanup(struct drm_device *dev)
> -{
> - drm_mode_config_cleanup(dev);
> }
> --
> 2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Don't check for wm changes until we've compute the wms fully
From: Ville Syrjälä
Currently we're comparing the watermarks between the old and new states
before we've fully computed the new watermarks. In particular
skl_build_pipe_wm() will not account for the amount of ddb space we'll
have. That information is only available during skl_compute_ddb()
which will proceed to zero out any watermark level exceeding the
ddb allocation. If we're short on ddb space this will end up
adding the plane to the state due erronously determining that the
watermarks have changed. Fix the problem by deferring
skl_wm_add_affected_planes() until we have the final watermarks
computed.
Noticed this when trying enable transition watermarks on glk.
We now computed the trans_wm as 28, but we only had 14 blocks
of ddb, and thus skl_compute_ddb() ended up disabling the cursor
trans_wm every time. Thus we ended up adding the cursor to every
commit that didn't actually affect the cursor at all.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 39299811b650..a3d76e69caae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5762,16 +5762,24 @@ skl_compute_wm(struct intel_atomic_state *state)
ret = skl_build_pipe_wm(new_crtc_state);
if (ret)
return ret;
-
- ret = skl_wm_add_affected_planes(state, crtc);
- if (ret)
- return ret;
}
ret = skl_compute_ddb(state);
if (ret)
return ret;
+ /*
+* skl_compute_ddb() will have adjusted the final watermarks
+* based on how much ddb is available. Now we can actually
+* check if the final watermarks changed.
+*/
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ ret = skl_wm_add_affected_planes(state, crtc);
+ if (ret)
+ return ret;
+ }
+
skl_print_wm_changes(state);
return 0;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Enable transition watermarks for glk
From: Ville Syrjälä We are mistakenly skipping transition watermarks on glk. Fix up the condition for glk, and toss in the w/a name from the database. v2: Reorder the ipc enabled vs. platform check to be more sensible Signed-off-by: Ville Syrjälä Reviewed-by: Rodrigo Vivi #v1 --- drivers/gpu/drm/i915/intel_pm.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index a3d76e69caae..f7c11b9f2c29 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5120,14 +5120,17 @@ static void skl_compute_transition_wm(const struct intel_crtc_state *crtc_state, const u16 trans_amount = 10; /* This is configurable amount */ u16 wm0_sel_res_b, trans_offset_b, res_blocks; - /* Transition WM are not recommended by HW team for GEN9 */ - if (INTEL_GEN(dev_priv) <= 9) - return; - /* Transition WM don't make any sense if ipc is disabled */ if (!dev_priv->ipc_enabled) return; + /* +* WaDisableTWM:skl,kbl,cfl,bxt +* Transition WM are not recommended by HW team for GEN9 +*/ + if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) + return; + trans_min = 14; if (INTEL_GEN(dev_priv) >= 11) trans_min = 4; -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Implement display w/a 1140 for glk/cnl
From: Ville Syrjälä
Display w/a #1140 tells us we have to program the transition
watermark to the minimum value on glk/cnl. Let's do that.
Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f7c11b9f2c29..04013af1eaf1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5116,8 +5116,7 @@ static void skl_compute_transition_wm(const struct
intel_crtc_state *crtc_state,
{
struct drm_device *dev = crtc_state->uapi.crtc->dev;
const struct drm_i915_private *dev_priv = to_i915(dev);
- u16 trans_min, trans_y_tile_min;
- const u16 trans_amount = 10; /* This is configurable amount */
+ u16 trans_min, trans_amount, trans_y_tile_min;
u16 wm0_sel_res_b, trans_offset_b, res_blocks;
/* Transition WM don't make any sense if ipc is disabled */
@@ -5131,9 +5130,16 @@ static void skl_compute_transition_wm(const struct
intel_crtc_state *crtc_state,
if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv))
return;
- trans_min = 14;
if (INTEL_GEN(dev_priv) >= 11)
trans_min = 4;
+ else
+ trans_min = 14;
+
+ /* Display WA #1140: glk,cnl */
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ trans_amount = 0;
+ else
+ trans_amount = 10; /* This is configurable amount */
trans_offset_b = trans_min + trans_amount;
@@ -5160,7 +5166,6 @@ static void skl_compute_transition_wm(const struct
intel_crtc_state *crtc_state,
/* WA BUG:1938466 add one block for non y-tile planes */
if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))
res_blocks += 1;
-
}
/*
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Don't check uv_wm in skl_plane_wm_equals()
From: Ville Syrjälä
The hardware never sees the uv_wm values (apart from
uv_wm.min_ddb_alloc affecting the ddb allocation). Thus there
is no point in comparing uv_wm to determine if we need to
reprogram the watermark registers. So let's check only the
rgb/y watermark in skl_plane_wm_equals(). But let's leave
a comment behind so that the next person reading this doesn't
get as confused as I did when I added this check.
If the ddb allocation ends up changing due to uv_wm
skl_ddb_add_affected_planes() takes care of adding the plane
to the state.
TODO: we should perhaps just eliminate uv_wm from the state
and simply track the min_ddb_alloc for uv instead.
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 345429e5ad45..39299811b650 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5400,8 +5400,12 @@ static bool skl_plane_wm_equals(struct drm_i915_private
*dev_priv,
int level, max_level = ilk_wm_max_level(dev_priv);
for (level = 0; level <= max_level; level++) {
- if (!skl_wm_level_equals(>wm[level], >wm[level]) ||
- !skl_wm_level_equals(>uv_wm[level],
>uv_wm[level]))
+ /*
+* We don't check uv_wm as the hardware doesn't actually
+* use it. It only gets used for calculating the required
+* ddb allocation.
+*/
+ if (!skl_wm_level_equals(>wm[level], >wm[level]))
return false;
}
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 48/51] drm/mipi-dbi: Drop explicit drm_mode_config_cleanup call
On Thu, Feb 27, 2020 at 07:15:19PM +0100, Daniel Vetter wrote:
> Allows us to drop the drm_driver.release callback from all
> drivers, and remove the mipi_dbi_release() function.
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> v2: Explain why this cleanup is possible (Laurent).
>
> Cc: Laurent Pinchart
> Reviewed-by: Noralf Trønnes
> Tested-by: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Cc: David Lechner
> Cc: Kamlesh Gurudasani
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 16
> drivers/gpu/drm/tiny/hx8357d.c | 1 -
> drivers/gpu/drm/tiny/ili9225.c | 1 -
> drivers/gpu/drm/tiny/ili9341.c | 1 -
> drivers/gpu/drm/tiny/ili9486.c | 1 -
> drivers/gpu/drm/tiny/mi0283qt.c | 1 -
> drivers/gpu/drm/tiny/st7586.c | 1 -
> drivers/gpu/drm/tiny/st7735r.c | 1 -
> include/drm/drm_mipi_dbi.h | 1 -
> 9 files changed, 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 9de1586659be..c0060a1c569f 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -582,22 +582,6 @@ int mipi_dbi_dev_init(struct mipi_dbi_dev *dbidev,
> }
> EXPORT_SYMBOL(mipi_dbi_dev_init);
>
> -/**
> - * mipi_dbi_release - DRM driver release helper
> - * @drm: DRM device
> - *
> - * This function finalizes and frees _dbi.
> - *
> - * Drivers can use this as their _driver->release callback.
> - */
> -void mipi_dbi_release(struct drm_device *drm)
> -{
> - DRM_DEBUG_DRIVER("\n");
> -
> - drm_mode_config_cleanup(drm);
> -}
> -EXPORT_SYMBOL(mipi_dbi_release);
> -
> /**
> * mipi_dbi_hw_reset - Hardware reset of controller
> * @dbi: MIPI DBI structure
> diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
> index c88b84366dc5..af7f3d10aac3 100644
> --- a/drivers/gpu/drm/tiny/hx8357d.c
> +++ b/drivers/gpu/drm/tiny/hx8357d.c
> @@ -196,7 +196,6 @@ DEFINE_DRM_GEM_CMA_FOPS(hx8357d_fops);
> static struct drm_driver hx8357d_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = _fops,
> - .release= mipi_dbi_release,
> DRM_GEM_CMA_VMAP_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "hx8357d",
> diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
> index fa998a16026c..118477af4491 100644
> --- a/drivers/gpu/drm/tiny/ili9225.c
> +++ b/drivers/gpu/drm/tiny/ili9225.c
> @@ -346,7 +346,6 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9225_fops);
> static struct drm_driver ili9225_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = _fops,
> - .release= mipi_dbi_release,
> DRM_GEM_CMA_VMAP_DRIVER_OPS,
> .name = "ili9225",
> .desc = "Ilitek ILI9225",
> diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
> index 945e15169866..e152de369019 100644
> --- a/drivers/gpu/drm/tiny/ili9341.c
> +++ b/drivers/gpu/drm/tiny/ili9341.c
> @@ -152,7 +152,6 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9341_fops);
> static struct drm_driver ili9341_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = _fops,
> - .release= mipi_dbi_release,
> DRM_GEM_CMA_VMAP_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "ili9341",
> diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
> index 38d293cf5377..577aea662aa4 100644
> --- a/drivers/gpu/drm/tiny/ili9486.c
> +++ b/drivers/gpu/drm/tiny/ili9486.c
> @@ -165,7 +165,6 @@ DEFINE_DRM_GEM_CMA_FOPS(ili9486_fops);
> static struct drm_driver ili9486_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = _fops,
> - .release= mipi_dbi_release,
> DRM_GEM_CMA_VMAP_DRIVER_OPS,
> .debugfs_init = mipi_dbi_debugfs_init,
> .name = "ili9486",
> diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c
> index b8c973bc2347..decaf57053ff 100644
> --- a/drivers/gpu/drm/tiny/mi0283qt.c
> +++ b/drivers/gpu/drm/tiny/mi0283qt.c
> @@ -156,7 +156,6 @@ DEFINE_DRM_GEM_CMA_FOPS(mi0283qt_fops);
> static struct drm_driver mi0283qt_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> .fops = _fops,
> -
Re: [Intel-gfx] [PATCH 47/51] drm/mipi-dbi: Move drm_mode_config_init into mipi library
On Thu, Feb 27, 2020 at 07:15:18PM +0100, Daniel Vetter wrote:
> 7/7 drivers agree that's the right choice, let's do this.
>
> This avoids duplicating the same old error checking code over all 7
> drivers, which is the motivation here.
>
> Reviewed-by: Noralf Trønnes
> Tested-by: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Cc: David Lechner
> Cc: Kamlesh Gurudasani
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 4
> drivers/gpu/drm/tiny/hx8357d.c | 2 --
> drivers/gpu/drm/tiny/ili9225.c | 2 --
> drivers/gpu/drm/tiny/ili9341.c | 2 --
> drivers/gpu/drm/tiny/ili9486.c | 2 --
> drivers/gpu/drm/tiny/mi0283qt.c | 2 --
> drivers/gpu/drm/tiny/st7586.c | 2 --
> drivers/gpu/drm/tiny/st7735r.c | 2 --
> 8 files changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index a678e07508d4..9de1586659be 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -510,6 +510,10 @@ int mipi_dbi_dev_init_with_formats(struct mipi_dbi_dev
> *dbidev,
> if (!dbidev->dbi.command)
> return -EINVAL;
>
> + ret = drm_mode_config_init(drm);
> + if (ret)
> + return ret;
> +
> dbidev->tx_buf = devm_kmalloc(drm->dev, tx_buf_size, GFP_KERNEL);
> if (!dbidev->tx_buf)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
> index 42bc5dadcb1c..c88b84366dc5 100644
> --- a/drivers/gpu/drm/tiny/hx8357d.c
> +++ b/drivers/gpu/drm/tiny/hx8357d.c
> @@ -239,8 +239,6 @@ static int hx8357d_probe(struct spi_device *spi)
> }
> drmm_add_final_kfree(drm, dbidev);
>
> - drm_mode_config_init(drm);
> -
> dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_LOW);
> if (IS_ERR(dc)) {
> DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
> diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
> index aae88dc5b3f7..fa998a16026c 100644
> --- a/drivers/gpu/drm/tiny/ili9225.c
> +++ b/drivers/gpu/drm/tiny/ili9225.c
> @@ -390,8 +390,6 @@ static int ili9225_probe(struct spi_device *spi)
> }
> drmm_add_final_kfree(drm, dbidev);
>
> - drm_mode_config_init(drm);
> -
> dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(dbi->reset)) {
> DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
> diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
> index 7d40cb4ff72b..945e15169866 100644
> --- a/drivers/gpu/drm/tiny/ili9341.c
> +++ b/drivers/gpu/drm/tiny/ili9341.c
> @@ -197,8 +197,6 @@ static int ili9341_probe(struct spi_device *spi)
> }
> drmm_add_final_kfree(drm, dbidev);
>
> - drm_mode_config_init(drm);
> -
> dbi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(dbi->reset)) {
> DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
> diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
> index 7d735fc67498..38d293cf5377 100644
> --- a/drivers/gpu/drm/tiny/ili9486.c
> +++ b/drivers/gpu/drm/tiny/ili9486.c
> @@ -211,8 +211,6 @@ static int ili9486_probe(struct spi_device *spi)
> }
> drmm_add_final_kfree(drm, dbidev);
>
> - drm_mode_config_init(drm);
> -
> dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(dbi->reset)) {
> DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
> diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c
> index 8555a56bce8c..b8c973bc2347 100644
> --- a/drivers/gpu/drm/tiny/mi0283qt.c
> +++ b/drivers/gpu/drm/tiny/mi0283qt.c
> @@ -201,8 +201,6 @@ static int mi0283qt_probe(struct spi_device *spi)
> }
> drmm_add_final_kfree(drm, dbidev);
>
> - drm_mode_config_init(drm);
> -
> dbi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(dbi->reset)) {
> DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
> diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
> index 427c2561f5f4..1f1a576be93c 100644
> --- a/drivers/gpu/drm/tiny/st7586.c
> +++ b/drivers/gpu/drm/tiny/st7586.c
> @@ -331,8 +331,6 @@ static int st7586_probe(struct spi_device *spi)
> }
> drmm_add_final_kfree(drm, dbidev);
>
> - drm_mode_config_init(drm);
> -
> bufsize = (st7586_mode.vdisplay + 2) / 3 * st7586_mode.hdisplay;
>
> dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
> index b447235c3d47..0f48a5a2d3d7 100644
> --- a/drivers/gpu/drm/tiny/st7735r.c
> +++ b/drivers/gpu/drm/tiny/st7735r.c
> @@ -212,8 +212,6 @@ static int st7735r_probe(struct
Re: [Intel-gfx] [PATCH 29/51] drm/cirrus: Drop explicit drm_mode_config_cleanup call
On Thu, Feb 27, 2020 at 07:15:00PM +0100, Daniel Vetter wrote:
> We can even delete the drm_driver.release hook now!
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> v2: Explain why this cleanup is possible (Laurent).
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Cc: virtualizat...@lists.linux-foundation.org
Acked-by: Sam Ravnborg
But as stated in other post - using drmm_mode_config_init()
would make this more readable.
Sam
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index a9d789a56536..6ac0286810ec 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -510,11 +510,15 @@ static const struct drm_mode_config_funcs
> cirrus_mode_config_funcs = {
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> -static void cirrus_mode_config_init(struct cirrus_device *cirrus)
> +static int cirrus_mode_config_init(struct cirrus_device *cirrus)
> {
> struct drm_device *dev = >dev;
> + int ret;
> +
> + ret = drm_mode_config_init(dev);
> + if (ret)
> + return ret;
>
> - drm_mode_config_init(dev);
> dev->mode_config.min_width = 0;
> dev->mode_config.min_height = 0;
> dev->mode_config.max_width = CIRRUS_MAX_PITCH / 2;
> @@ -522,15 +526,12 @@ static void cirrus_mode_config_init(struct
> cirrus_device *cirrus)
> dev->mode_config.preferred_depth = 16;
> dev->mode_config.prefer_shadow = 0;
> dev->mode_config.funcs = _mode_config_funcs;
> +
> + return 0;
> }
>
> /* -- */
>
> -static void cirrus_release(struct drm_device *dev)
> -{
> - drm_mode_config_cleanup(dev);
> -}
> -
> DEFINE_DRM_GEM_FOPS(cirrus_fops);
>
> static struct drm_driver cirrus_driver = {
> @@ -544,7 +545,6 @@ static struct drm_driver cirrus_driver = {
>
> .fops= _fops,
> DRM_GEM_SHMEM_DRIVER_OPS,
> - .release = cirrus_release,
> };
>
> static int cirrus_pci_probe(struct pci_dev *pdev,
> @@ -591,7 +591,9 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> if (cirrus->mmio == NULL)
> goto err_unmap_vram;
>
> - cirrus_mode_config_init(cirrus);
> + ret = cirrus_mode_config_init(cirrus);
> + if (ret)
> + goto err_cleanup;
>
> ret = cirrus_conn_init(cirrus);
> if (ret < 0)
> @@ -613,7 +615,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> return 0;
>
> err_cleanup:
> - drm_mode_config_cleanup(dev);
> iounmap(cirrus->mmio);
> err_unmap_vram:
> iounmap(cirrus->vram);
> --
> 2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Sat, 29 Feb 2020 at 05:34, Eric Anholt wrote: > > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote: > > > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > > > b) we probably need to take a large step back here. > > > > > > > > Look at this from a sponsor POV, why would I give X.org/fd.o > > > > sponsorship money that they are just giving straight to google to pay > > > > for hosting credits? Google are profiting in some minor way from these > > > > hosting credits being bought by us, and I assume we aren't getting any > > > > sort of discounts here. Having google sponsor the credits costs google > > > > substantially less than having any other company give us money to do > > > > it. > > > > > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty > > > comparable in terms of what you get and what you pay for them. > > > Obviously providers like Packet and Digital Ocean who offer bare-metal > > > services are cheaper, but then you need to find someone who is going > > > to properly administer the various machines, install decent > > > monitoring, make sure that more storage is provisioned when we need > > > more storage (which is basically all the time), make sure that the > > > hardware is maintained in decent shape (pretty sure one of the fd.o > > > machines has had a drive in imminent-failure state for the last few > > > months), etc. > > > > > > Given the size of our service, that's a much better plan (IMO) than > > > relying on someone who a) isn't an admin by trade, b) has a million > > > other things to do, and c) hasn't wanted to do it for the past several > > > years. But as long as that's the resources we have, then we're paying > > > the cloud tradeoff, where we pay more money in exchange for fewer > > > problems. > > > > Admin for gitlab and CI is a full time role anyways. The system is > > definitely not self sustaining without time being put in by you and > > anholt still. If we have $75k to burn on credits, and it was diverted > > to just pay an admin to admin the real hw + gitlab/CI would that not > > be a better use of the money? I didn't know if we can afford $75k for > > an admin, but suddenly we can afford it for gitlab credits? > > As I think about the time that I've spent at google in less than a > year on trying to keep the lights on for CI and optimize our > infrastructure in the current cloud environment, that's more than the > entire yearly budget you're talking about here. Saying "let's just > pay for people to do more work instead of paying for full-service > cloud" is not a cost optimization. > > > > > Yes, we could federate everything back out so everyone runs their own > > > builds and executes those. Tinderbox did something really similar to > > > that IIRC; not sure if Buildbot does as well. Probably rules out > > > pre-merge testing, mind. > > > > Why? does gitlab not support the model? having builds done in parallel > > on runners closer to the test runners seems like it should be a thing. > > I guess artifact transfer would cost less then as a result. > > Let's do some napkin math. The biggest artifacts cost we have in Mesa > is probably meson-arm64/meson-arm (60MB zipped from meson-arm64, > downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day, > makes ~1.8TB/month ($180 or so). We could build a local storage next > to the lava dispatcher so that the artifacts didn't have to contain > the rootfs that came from the container (~2/3 of the insides of the > zip file), but that's another service to build and maintain. Building > the drivers once locally and storing it would save downloading the > other ~1/3 of the inside of the zip file, but that requires a big > enough system to do builds in time. > > I'm planning on doing a local filestore for google's lava lab, since I > need to be able to move our xml files off of the lava DUTs to get the > xml results we've become accustomed to, but this would not bubble up > to being a priority for my time if I wasn't doing it anyway. If it > takes me a single day to set all this up (I estimate a couple of > weeks), that costs my employer a lot more than sponsoring the costs of > the inefficiencies of the system that has accumulated. I'm not trying to knock the engineering works the CI contributors have done at all, but I've never seen a real discussion about costs until now. Engineers aren't accountants. The thing we seem to be missing here is fiscal responsibility. I know this email is us being fiscally responsible, but it's kinda after the fact. I cannot commit my employer to spending a large amount of money (> 0 actually) without a long and lengthy process with checks and bounds. Can you? The X.org board has budgets and procedures as well. I as a developer of Mesa should not be able to commit the X.org foundation to spending large amounts of money without checks and bounds. The CI infrastructure lacks any checks and
Re: [Intel-gfx] [PATCH 26/51] drm: Manage drm_mode_config_init with drmm_
Hi Daniel.
Some bikeshedding in the following.
with or with addressing (IMHO valid points) consider the patch:
Reviewed-by: Sam Ravnborg
Sam
On Thu, Feb 27, 2020 at 07:14:57PM +0100, Daniel Vetter wrote:
> drm_mode_config_cleanup is idempotent, so no harm in calling this
> twice. This allows us to gradually switch drivers over by removing
> explicit drm_mode_config_cleanup calls.
>
> With this step it's not also possible that (at least for simple
> drivers) automatic resource cleanup can be done correctly without a
> drm_driver->release hook. Therefore allow this now in
> devm_drm_dev_init().
I am not really sure what you try to explain here?
Should the "not" be deleted?
>
> Also with drmm_ explicit drm_driver->release hooks are kinda not the
> best option, so deprecate that hook to discourage future users.
The ->release hooks has others uses until everything is moved over to
drmm_, or so I think. So deprecation seems a lttle too soon.
>
> v2: Fixup the example in the kerneldoc too.
>
> v3:
> - For paranoia, double check that minor->dev == dev in the release
> hook, because I botched the pointer math in the drmm library.
> - Call drm_mode_config_cleanup when drmm_add_action fails, we'd be
> missing some mutex_destroy and ida_cleanup otherwise (Laurent)
>
> v4: Add a drmm_add_action_or_reset (like devm_ has) to encapsulate this
> pattern (Noralf).
>
> v5: Fix oversight in the new add_action_or_reset macro (Noralf)
^ drmm_add_action_or_reset
>
> Cc: Laurent Pinchart
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Acked-by: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 23 +++
> drivers/gpu/drm/drm_managed.c | 14 ++
> drivers/gpu/drm/drm_mode_config.c | 13 -
> include/drm/drm_managed.h | 7 +++
> include/drm/drm_mode_config.h | 2 +-
> 5 files changed, 41 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 3cf40864d4a6..bb326b9bcde0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -98,6 +98,8 @@ static void drm_minor_alloc_release(struct drm_device *dev,
> void *data)
> struct drm_minor *minor = data;
> unsigned long flags;
>
> + WARN_ON(dev != minor->dev);
> +
> put_device(minor->kdev);
>
> spin_lock_irqsave(_minor_lock, flags);
> @@ -267,8 +269,7 @@ void drm_minor_release(struct drm_minor *minor)
> *
> * The following example shows a typical structure of a DRM display driver.
> * The example focus on the probe() function and the other functions that is
> - * almost always present and serves as a demonstration of devm_drm_dev_init()
> - * usage with its accompanying drm_driver->release callback.
> + * almost always present and serves as a demonstration of
> devm_drm_dev_init().
> *
> * .. code-block:: c
> *
> @@ -278,16 +279,8 @@ void drm_minor_release(struct drm_minor *minor)
> * struct clk *pclk;
> * };
> *
> - * static void driver_drm_release(struct drm_device *drm)
> - * {
> - * struct driver_device *priv = container_of(...);
> - *
> - * drm_mode_config_cleanup(drm);
> - * }
> - *
> * static struct drm_driver driver_drm_driver = {
> * [...]
> - * .release = driver_drm_release,
> * };
> *
> * static int driver_probe(struct platform_device *pdev)
> @@ -312,7 +305,9 @@ void drm_minor_release(struct drm_minor *minor)
> * }
> * drmm_add_final_kfree(drm, priv);
> *
> - * drm_mode_config_init(drm);
> + * ret = drm_mode_config_init(drm);
> + * if (ret)
> + * return ret;
We do not print anything in drm_mode_config_init() - so should
we do it here?
Otherwise we only get the more generic error from the driver core.
> *
> * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> * if (!priv->userspace_facing)
> @@ -710,8 +705,7 @@ static void devm_drm_dev_init_release(void *data)
> * @driver: DRM driver
> *
> * Managed drm_dev_init(). The DRM device initialized with this function is
> - * automatically put on driver detach using drm_dev_put(). You must supply a
> - * _driver.release callback to control the finalization explicitly.
> + * automatically put on driver detach using drm_dev_put().
> *
> * RETURNS:
> * 0 on success, or error code on failure.
> @@ -722,9 +716,6 @@ int devm_drm_dev_init(struct device *parent,
> {
> int ret;
>
> - if (WARN_ON(!driver->release))
> - return -EINVAL;
> -
> ret = drm_dev_init(dev, driver, parent);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 626656369f0b..6376be01bbc8 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: split intel_modeset_init() pre/post gem init
== Series Details == Series: series starting with [1/3] drm/i915: split intel_modeset_init() pre/post gem init URL : https://patchwork.freedesktop.org/series/74021/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8019_full -> Patchwork_16734_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16734_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16734_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16734_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-tglb2/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-tglb5/igt@i915_module_l...@reload-with-fault-injection.html * igt@runner@aborted: - shard-tglb: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-tglb5/igt@run...@aborted.html New tests - New tests have been introduced between CI_DRM_8019_full and Patchwork_16734_full: ### New IGT tests (4) ### * igt@drm_mm@all: - Statuses : - Exec time: [None] s * igt@i915_selftest@mock: - Statuses : - Exec time: [None] s * igt@i915_selftest@perf: - Statuses : - Exec time: [None] s * igt@kms_selftest@all: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_16734_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-apl7/igt@gem_ctx_isolat...@bcs0-s3.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_ctx_persistence@close-replace-race: - shard-apl: [PASS][6] -> [INCOMPLETE][7] ([fdo#103927]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-apl8/igt@gem_ctx_persiste...@close-replace-race.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-apl3/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][8] -> [SKIP][9] ([fdo#112080]) +12 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][10] -> [SKIP][11] ([i915#677]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109276] / [i915#677]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112146]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb7/igt@gem_exec_sched...@wide-bsd.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-iclb1/igt@gem_exec_sched...@wide-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#644]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-glk2/igt@gem_pp...@flink-and-close-vma-leak.html - shard-tglb: [PASS][18] -> [FAIL][19] ([i915#644]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-tglb1/igt@gem_pp...@flink-and-close-vma-leak.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16734/shard-tglb7/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_module_load@reload-with-fault-injection: - shard-skl: [PASS][20] -> [INCOMPLETE][21] ([i915#671]) [20]:
Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()
On Fri, Feb 28, 2020 at 07:04:41PM +0100, Peter Zijlstra wrote: > On Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote: > > > And why not mark gen8_canonical_addr() __always_inline? > > > > Right, marking those two functions as __always_inline is the other > > option. The problem is, if you keep doing it, eventually you end up > > with __always_inline-itis spreading all over the place. And it affects > > all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case. > > At least this fix is localized. > > I'm all for __always_inline in this case, the compiler not inlining sign > extention is just retarded, FWIW, in this case it's salq$8, %rax sarq$8, %rax i.e. 8 bytes. Sure, that's 3 bytes longer than call, but really, WTF? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative registers
On 2020-02-28 10:43:37, Chris Wilson wrote:
> Some of the non-privileged registers are at the same offset on each
> engine. We can improve our coverage for unknown HW layout by using the
> reported engine->mmio_base for relative offsets.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Dale B Stimson
> ---
> tests/i915/gem_ctx_isolation.c | 164 -
> 1 file changed, 100 insertions(+), 64 deletions(-)
>
> diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
> index 1b66fec11..eff4b1df2 100644
> --- a/tests/i915/gem_ctx_isolation.c
> +++ b/tests/i915/gem_ctx_isolation.c
> @@ -70,6 +70,7 @@ static const struct named_register {
> uint32_t ignore_bits;
> uint32_t write_mask; /* some registers bits do not exist */
> bool masked;
> + bool relative;
> } nonpriv_registers[] = {
> { "NOPID", NOCTX, RCS0, 0x2094 },
> { "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
> @@ -109,7 +110,6 @@ static const struct named_register {
> { "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
> { "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
> { "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
> - { "CS_GPR", GEN8, RCS0, 0x2600, 32 },
> { "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
> { "OACTXID", GEN8, RCS0, 0x2364 },
> { "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2, .write_mask = ~0x3 },
> @@ -138,79 +138,56 @@ static const struct named_register {
>
> { "CTX_PREEMPT", NOCTX /* GEN10 */, RCS0, 0x2248 },
> { "CS_CHICKEN1", GEN11, RCS0, 0x2580, .masked = true },
> - { "HDC_CHICKEN1", GEN_RANGE(10, 10), RCS0, 0x7304, .masked = true },
>
> /* Privileged (enabled by w/a + FORCE_TO_NONPRIV) */
> { "CTX_PREEMPT", NOCTX /* GEN9 */, RCS0, 0x2248 },
> { "CS_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x2580, .masked = true },
> { "COMMON_SLICE_CHICKEN2", GEN_RANGE(9, 9), RCS0, 0x7014, .masked =
> true },
> - { "HDC_CHICKEN1", GEN_RANGE(9, 9), RCS0, 0x7304, .masked = true },
> + { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x7304, .masked = true },
> { "SLICE_COMMON_ECO_CHICKEN1", GEN_RANGE(11, 11) /* + glk */, RCS0,
> 0x731c, .masked = true },
> { "L3SQREG4", NOCTX /* GEN9:skl,kbl */, RCS0, 0xb118, .write_mask =
> ~0x10 },
> { "HALF_SLICE_CHICKEN7", GEN_RANGE(11, 11), RCS0, 0xe194, .masked =
> true },
> { "SAMPLER_MODE", GEN_RANGE(11, 11), RCS0, 0xe18c, .masked = true },
>
> - { "BCS_GPR", GEN9, BCS0, 0x22600, 32 },
> { "BCS_SWCTRL", GEN8, BCS0, 0x22200, .write_mask = 0x3, .masked = true
> },
>
> { "MFC_VDBOX1", NOCTX, VCS0, 0x12800, 64 },
> { "MFC_VDBOX2", NOCTX, VCS1, 0x1c800, 64 },
>
> - { "VCS0_GPR", GEN_RANGE(9, 10), VCS0, 0x12600, 32 },
> - { "VCS1_GPR", GEN_RANGE(9, 10), VCS1, 0x1c600, 32 },
> - { "VECS_GPR", GEN_RANGE(9, 10), VECS0, 0x1a600, 32 },
> -
> - { "VCS0_GPR", GEN11, VCS0, 0x1c0600, 32 },
> - { "VCS1_GPR", GEN11, VCS1, 0x1c4600, 32 },
> - { "VCS2_GPR", GEN11, VCS2, 0x1d0600, 32 },
> - { "VCS3_GPR", GEN11, VCS3, 0x1d4600, 32 },
> - { "VECS_GPR", GEN11, VECS0, 0x1c8600, 32 },
> + { "xCS_GPR", GEN9, ALL, 0x600, 32, .relative = true },
>
> {}
> }, ignore_registers[] = {
> { "RCS timestamp", GEN6, ~0u, 0x2358 },
> { "BCS timestamp", GEN7, ~0u, 0x22358 },
>
> - { "VCS0 timestamp", GEN_RANGE(7, 10), ~0u, 0x12358 },
> - { "VCS1 timestamp", GEN_RANGE(7, 10), ~0u, 0x1c358 },
> - { "VECS timestamp", GEN_RANGE(8, 10), ~0u, 0x1a358 },
> -
> - { "VCS0 timestamp", GEN11, ~0u, 0x1c0358 },
> - { "VCS1 timestamp", GEN11, ~0u, 0x1c4358 },
> - { "VCS2 timestamp", GEN11, ~0u, 0x1d0358 },
> - { "VCS3 timestamp", GEN11, ~0u, 0x1d4358 },
> - { "VECS timestamp", GEN11, ~0u, 0x1c8358 },
> + { "xCS timestamp", GEN8, ALL, 0x358, .relative = true },
>
> /* huc read only */
> - { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2000 },
> - { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2014 },
> - { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x23b0 },
> -
> - { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2000 },
> - { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x2014 },
> - { "BSD1 0x2000", GEN11, ~0u, 0x1c4000 + 0x23b0 },
> -
> - { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2000 },
> - { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x2014 },
> - { "BSD2 0x2000", GEN11, ~0u, 0x1d + 0x23b0 },
> -
> - { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2000 },
> - { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x2014 },
> - { "BSD3 0x2000", GEN11, ~0u, 0x1d4000 + 0x23b0 },
> + { "BSD 0x2000", GEN11, ALL, 0x2000, .relative = true },
> + { "BSD 0x2014", GEN11, ALL, 0x2014, .relative = true },
> + { "BSD 0x23b0", GEN11, ALL, 0x23b0, .relative = true },
>
> {}
> };
>
> -static const char *register_name(uint32_t offset, char *buf, size_t len)
> +static const char *
> +register_name(uint32_t offset, uint32_t
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use
On 2020-02-28 10:43:36, Chris Wilson wrote:
> Several tests depend upon the implicit engine->mmio_base but have no
> means of determining the physical layout. Since the kernel has started
> providing this information, start putting it to use.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Dale B Stimson
> ---
> lib/i915/gem_engine_topology.c | 84 ++
> lib/i915/gem_engine_topology.h | 5 ++
> tests/i915/gem_ctx_shared.c| 38 +--
> tests/i915/gem_exec_latency.c | 17 ---
> 4 files changed, 111 insertions(+), 33 deletions(-)
>
> diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
> index 58dff3208..640777ae4 100644
> --- a/lib/i915/gem_engine_topology.c
> +++ b/lib/i915/gem_engine_topology.c
> @@ -21,7 +21,12 @@
> * IN THE SOFTWARE.
> */
>
> +#include
> +#include
> +
> #include "drmtest.h"
> +#include "igt_sysfs.h"
> +#include "intel_chipset.h"
> #include "ioctl_wrappers.h"
>
> #include "i915/gem_engine_topology.h"
> @@ -327,3 +332,82 @@ bool gem_engine_is_equal(const struct
> intel_execution_engine2 *e1,
> {
> return e1->class == e2->class && e1->instance == e2->instance;
> }
> +
> +static int descend(int dir, const char *path)
> +{
> + int fd;
> +
> + fd = openat(dir, path, O_RDONLY);
> + close(dir);
> +
> + return fd;
> +}
> +
> +int gem_engine_property_scanf(int i915, const char *engine, const char *attr,
> + const char *fmt, ...)
> +{
> + FILE *file;
> + va_list ap;
> + int ret;
> + int fd;
> +
> + fd = igt_sysfs_open(i915);
> + if (fd < 0)
> + return fd;
> +
> + fd = descend(fd, "engine");
> + if (fd < 0)
> + return fd;
> +
> + fd = descend(fd, engine);
> + if (fd < 0)
> + return fd;
> +
> + fd = descend(fd, attr);
> + if (fd < 0)
> + return fd;
> +
> + file = fdopen(fd, "r");
> + if (!file) {
> + close(fd);
> + return -1;
> + }
> +
> + va_start(ap, fmt);
> + ret = vfscanf(file, fmt, ap);
> + va_end(ap);
> +
> + fclose(file);
> + return ret;
> +}
> +
> +uint32_t gem_engine_mmio_base(int i915, const char *engine)
> +{
> + unsigned int mmio = 0;
> +
> + if (gem_engine_property_scanf(i915, engine, "mmio_base",
> + "%x", ) < 0) {
> + int gen = intel_gen(intel_get_drm_devid(i915));
> +
> + /* The layout of xcs1+ is unreliable -- hence the property! */
> + if (!strcmp(engine, "rcs0")) {
> + mmio = 0x2000;
> + } else if (!strcmp(engine, "bcs0")) {
> + mmio = 0x22000;
> + } else if (!strcmp(engine, "vcs0")) {
> + if (gen < 6)
> + mmio = 0x4000;
> + else if (gen < 11)
> + mmio = 0x12000;
> + else
> + mmio = 0x1c;
> + } else if (!strcmp(engine, "vecs0")) {
> + if (gen < 11)
> + mmio = 0x1a000;
> + else
> + mmio = 0x1c8000;
> + }
> + }
> +
> + return mmio;
> +}
> diff --git a/lib/i915/gem_engine_topology.h b/lib/i915/gem_engine_topology.h
> index 027d86be2..219c84b72 100644
> --- a/lib/i915/gem_engine_topology.h
> +++ b/lib/i915/gem_engine_topology.h
> @@ -75,4 +75,9 @@ struct intel_execution_engine2
> gem_eb_flags_to_engine(unsigned int flags);
> #define __for_each_physical_engine(fd__, e__) \
> for_each_physical_engine(fd__, 0, e__)
>
> +__attribute__((format(scanf, 4, 5)))
> +int gem_engine_property_scanf(int i915, const char *engine, const char *attr,
> + const char *fmt, ...);
> +uint32_t gem_engine_mmio_base(int i915, const char *engine);
> +
> #endif /* GEM_ENGINE_TOPOLOGY_H */
> diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
> index 820b96c1a..9ea020d7b 100644
> --- a/tests/i915/gem_ctx_shared.c
> +++ b/tests/i915/gem_ctx_shared.c
> @@ -38,6 +38,7 @@
>
> #include
>
> +#include "i915/gem_engine_topology.h"
> #include "igt_rand.h"
> #include "igt_vgem.h"
> #include "sync_file.h"
> @@ -548,6 +549,14 @@ static uint32_t store_timestamp(int i915,
> return obj.handle;
> }
>
> +static uint32_t ring_base(int i915, unsigned ring)
> +{
> + if (ring == I915_EXEC_DEFAULT)
> + ring = I915_EXEC_RENDER; /* XXX */
> +
> + return gem_engine_mmio_base(i915, gem_eb_flags_to_engine(ring).name);
> +}
> +
> static void independent(int i915, unsigned ring, unsigned flags)
> {
> const int TIMESTAMP = 1023;
> @@ -555,33 +564,8 @@ static void independent(int i915, unsigned ring,
> unsigned flags)
> igt_spin_t *spin[MAX_ELSP_QLEN];
> unsigned int mmio_base;
>
> - /* XXX i915_query()! */
> -
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,3/3] drm/i915: HDCP: retry link integrity check on failure (rev3)
== Series Details == Series: series starting with [v2,3/3] drm/i915: HDCP: retry link integrity check on failure (rev3) URL : https://patchwork.freedesktop.org/series/73961/ State : failure == Summary == Applying: drm/i915: HDCP: retry link integrity check on failure error: sha1 information is lacking or useless (drivers/gpu/drm/i915/display/intel_hdmi.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: HDCP: retry link integrity check on failure When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote: > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > > b) we probably need to take a large step back here. > > > > > > Look at this from a sponsor POV, why would I give X.org/fd.o > > > sponsorship money that they are just giving straight to google to pay > > > for hosting credits? Google are profiting in some minor way from these > > > hosting credits being bought by us, and I assume we aren't getting any > > > sort of discounts here. Having google sponsor the credits costs google > > > substantially less than having any other company give us money to do > > > it. > > > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty > > comparable in terms of what you get and what you pay for them. > > Obviously providers like Packet and Digital Ocean who offer bare-metal > > services are cheaper, but then you need to find someone who is going > > to properly administer the various machines, install decent > > monitoring, make sure that more storage is provisioned when we need > > more storage (which is basically all the time), make sure that the > > hardware is maintained in decent shape (pretty sure one of the fd.o > > machines has had a drive in imminent-failure state for the last few > > months), etc. > > > > Given the size of our service, that's a much better plan (IMO) than > > relying on someone who a) isn't an admin by trade, b) has a million > > other things to do, and c) hasn't wanted to do it for the past several > > years. But as long as that's the resources we have, then we're paying > > the cloud tradeoff, where we pay more money in exchange for fewer > > problems. > > Admin for gitlab and CI is a full time role anyways. The system is > definitely not self sustaining without time being put in by you and > anholt still. If we have $75k to burn on credits, and it was diverted > to just pay an admin to admin the real hw + gitlab/CI would that not > be a better use of the money? I didn't know if we can afford $75k for > an admin, but suddenly we can afford it for gitlab credits? As I think about the time that I've spent at google in less than a year on trying to keep the lights on for CI and optimize our infrastructure in the current cloud environment, that's more than the entire yearly budget you're talking about here. Saying "let's just pay for people to do more work instead of paying for full-service cloud" is not a cost optimization. > > Yes, we could federate everything back out so everyone runs their own > > builds and executes those. Tinderbox did something really similar to > > that IIRC; not sure if Buildbot does as well. Probably rules out > > pre-merge testing, mind. > > Why? does gitlab not support the model? having builds done in parallel > on runners closer to the test runners seems like it should be a thing. > I guess artifact transfer would cost less then as a result. Let's do some napkin math. The biggest artifacts cost we have in Mesa is probably meson-arm64/meson-arm (60MB zipped from meson-arm64, downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day, makes ~1.8TB/month ($180 or so). We could build a local storage next to the lava dispatcher so that the artifacts didn't have to contain the rootfs that came from the container (~2/3 of the insides of the zip file), but that's another service to build and maintain. Building the drivers once locally and storing it would save downloading the other ~1/3 of the inside of the zip file, but that requires a big enough system to do builds in time. I'm planning on doing a local filestore for google's lava lab, since I need to be able to move our xml files off of the lava DUTs to get the xml results we've become accustomed to, but this would not bubble up to being a priority for my time if I wasn't doing it anyway. If it takes me a single day to set all this up (I estimate a couple of weeks), that costs my employer a lot more than sponsoring the costs of the inefficiencies of the system that has accumulated. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: reintroduce wait on OA configuration completion
== Series Details == Series: drm/i915/perf: reintroduce wait on OA configuration completion URL : https://patchwork.freedesktop.org/series/74014/ State : success == Summary == CI Bug Log - changes from CI_DRM_8019_full -> Patchwork_16733_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8019_full and Patchwork_16733_full: ### New IGT tests (4) ### * igt@drm_mm@all: - Statuses : - Exec time: [None] s * igt@i915_selftest@mock: - Statuses : - Exec time: [None] s * igt@i915_selftest@perf: - Statuses : - Exec time: [None] s * igt@kms_selftest@all: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_16733_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103665]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-iclb6/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb6/igt@gem_exec_sched...@in-order-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb3/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@i915_pm_rps@reset: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#413]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-iclb6/igt@i915_pm_...@reset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-iclb8/igt@i915_pm_...@reset.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#72]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-glk4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-apl2/igt@kms_f...@flip-vs-suspend-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-apl1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#34]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8019/shard-skl10/igt@kms_f...@plain-flip-ts-check-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16733/shard-skl2/igt@kms_f...@plain-flip-ts-check-interruptible.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: -
Re: [Intel-gfx] [CI] PR for TGL DMC v2.06
On Fri, 2020-02-28 at 12:21 +0200, Petri Latvala wrote: > On Thu, Feb 27, 2020 at 11:42:03PM +, Souza, Jose wrote: > > The following changes since commit > > efcfa03ae6100dfe523ebf612e03c3a90fc4c794: > > > > linux-firmware: Update firmware file for Intel Bluetooth AX201 > > (2020- > > 02-24 07:43:42 -0500) > > > > are available in the Git repository at: > > > > git://anongit.freedesktop.org/drm/drm-firmware tgl_dmc_2.06 > > > > for you to fetch changes up to > > e2396319167724e9ffddc377f300469923fccdcb: > > > > i915: Add DMC firmware v2.06 for TGL (2020-02-27 15:24:56 2020 > > -0800) > > > > > > José Roberto de Souza (1): > > i915: Add DMC firmware v2.06 for TGL > > > > WHENCE | 3 +++ > > i915/tgl_dmc_ver2_06.bin | Bin 0 -> 18660 bytes > > 2 files changed, 3 insertions(+) > > create mode 100644 i915/tgl_dmc_ver2_06.bin > > Patchwork didn't pick up this PR, I suspect the extra newlines to be > the issue. Can you try resending this without the automatic newlines > before the commit shas? > > If patchwork recognizes it as a pull request, it will appear in here: > https://patchwork.freedesktop.org/api/1.0/projects/intel-gfx/events/?page=1=2020-02-20=pull-request-new > Hi Petri Still needed? According to https://patchwork.freedesktop.org/patch/355624/?series=74048=2 it was manually picked. > > -- > Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix 90/270 degree rotated RGB565 src coord checks (rev3)
== Series Details == Series: drm/i915: Fix 90/270 degree rotated RGB565 src coord checks (rev3) URL : https://patchwork.freedesktop.org/series/59956/ State : success == Summary == CI Bug Log - changes from CI_DRM_8032 -> Patchwork_16766 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16766/index.html Known issues Here are the changes found in Patchwork_16766 that come from known issues: ### IGT changes ### Issues hit * igt@kms_addfb_basic@addfb25-x-tiled: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@kms_addfb_ba...@addfb25-x-tiled.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16766/fi-tgl-y/igt@kms_addfb_ba...@addfb25-x-tiled.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][3] ([CI#94]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16766/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][5] ([fdo#111096] / [i915#323]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16766/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@prime_self_import@basic-llseek-bad: - fi-tgl-y: [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16766/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html Warnings * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [FAIL][9] ([i915#704]) -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16766/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704 Participating hosts (47 -> 43) -- Additional (3): fi-byt-j1900 fi-bsw-kefka fi-kbl-r Missing(7): fi-ilk-m540 fi-kbl-7560u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-blb-e6850 fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8032 -> Patchwork_16766 CI-20190529: 20190529 CI_DRM_8032: e61f34133ad908d4b455344daa7b4edb9fcf680c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16766: f854cfdc461f875018564763c6981da8fae31b09 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f854cfdc461f drm/i915: Fix 90/270 degree rotated RGB565 src coord checks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16766/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clean up DPLL output/refclock tracking (rev2)
== Series Details ==
Series: drm/i915: Clean up DPLL output/refclock tracking (rev2)
URL : https://patchwork.freedesktop.org/series/73977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8032 -> Patchwork_16764
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16764/index.html
Known issues
Here are the changes found in Patchwork_16764 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2] ([i915#151])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-skl-6600u/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16764/fi-skl-6600u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-cml-s: [PASS][3] -> [DMESG-FAIL][4] ([i915#877])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16764/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([CI#94] / [i915#402])
+1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16764/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
Possible fixes
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8]
+1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16764/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html
Warnings
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [FAIL][9] ([i915#704]) -> [SKIP][10] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16764/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][11] ([fdo#111096] / [i915#323]) -> [FAIL][12]
([fdo#111407])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16764/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#998]: https://gitlab.freedesktop.org/drm/intel/issues/998
Participating hosts (47 -> 44)
--
Additional (4): fi-byt-j1900 fi-bdw-5557u fi-bsw-kefka fi-kbl-r
Missing(7): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-bwr-2160
fi-ctg-p8600 fi-pnv-d510 fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8032 -> Patchwork_16764
CI-20190529: 20190529
CI_DRM_8032: e61f34133ad908d4b455344daa7b4edb9fcf680c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16764: 8ab21b812217008f9addcd71af53a833e04e76f4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8ab21b812217 drm/i915: Unify the DPLL ref clock frequency tracking
7766f980fe46 drm/i915/hsw: Use the read-out WRPLL/SPLL state instead of reading
out again
dcf2a96e2ea6 drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculation
7c9bf0760704 drm/i915/hsw: Split out the WRPLL, LCPLL, SPLL frequency
calculation
9b1ae235617a drm/i915/hsw: Split out the SPLL parameter calculation
d44f7bddc44c drm/i915/hsw: Rename the get HDMI/DP DPLL funcs to get WRPLL/LCPLL
12c8e6996ea5 drm/i915/skl: Parametrize the DPLL ref clock instead of
open-coding it
16cbb5c45f38 drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.c
e7b63db4be61 drm/i915/hsw: Use the DPLL ID when calculating DPLL clock
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix 90/270 degree rotated RGB565 src coord checks (rev3)
== Series Details == Series: drm/i915: Fix 90/270 degree rotated RGB565 src coord checks (rev3) URL : https://patchwork.freedesktop.org/series/59956/ State : warning == Summary == $ dim checkpatch origin/drm-tip f854cfdc461f drm/i915: Fix 90/270 degree rotated RGB565 src coord checks -:65: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #65: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:318: + hsub = vsub = max(hsub, vsub); total: 0 errors, 0 warnings, 1 checks, 53 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/perf: introduce global sseu pinning
== Series Details == Series: drm/i915/perf: introduce global sseu pinning URL : https://patchwork.freedesktop.org/series/74086/ State : failure == Summary == Applying: drm/i915/perf: introduce global sseu pinning error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_perf.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/perf: introduce global sseu pinning When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()
On Thu, Feb 27, 2020 at 07:03:42PM -0600, Josh Poimboeuf wrote: > > And why not mark gen8_canonical_addr() __always_inline? > > Right, marking those two functions as __always_inline is the other > option. The problem is, if you keep doing it, eventually you end up > with __always_inline-itis spreading all over the place. And it affects > all the other callers, at least in the CONFIG_CC_OPTIMIZE_FOR_SIZE case. > At least this fix is localized. I'm all for __always_inline in this case, the compiler not inlining sign extention is just retarded, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Thu, Feb 27, 2020 at 7:38 PM Dave Airlie wrote: > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote: > > > > Hi all, > > > > You might have read the short take in the X.org board meeting minutes > > already, here's the long version. > > > > The good news: gitlab.fd.o has become very popular with our > > communities, and is used extensively. This especially includes all the > > CI integration. Modern development process and tooling, yay! > > > > The bad news: The cost in growth has also been tremendous, and it's > > breaking our bank account. With reasonable estimates for continued > > growth we're expecting hosting expenses totalling 75k USD this year, > > and 90k USD next year. With the current sponsors we've set up we can't > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > without any of the CI features enabled would total 30k USD, which is > > within X.org's ability to support through various sponsorships, mostly > > through XDC. > > > > Note that X.org does no longer sponsor any CI runners themselves, > > we've stopped that. The huge additional expenses are all just in > > storing and serving build artifacts and images to outside CI runners > > sponsored by various companies. A related topic is that with the > > growth in fd.o it's becoming infeasible to maintain it all on > > volunteer admin time. X.org is therefore also looking for admin > > sponsorship, at least medium term. > > > > Assuming that we want cash flow reserves for one year of gitlab.fd.o > > (without CI support) and a trimmed XDC and assuming no sponsor payment > > meanwhile, we'd have to cut CI services somewhere between May and June > > this year. The board is of course working on acquiring sponsors, but > > filling a shortfall of this magnitude is neither easy nor quick work, > > and we therefore decided to give an early warning as soon as possible. > > Any help in finding sponsors for fd.o is very much appreciated. > > a) Ouch. > > b) we probably need to take a large step back here. If we're taking a step back here, I also want to recognize what a tremendous success this has been so far and thank everybody involved for building something so useful. Between gitlab and the CI, our workflow has improved and code quality has gone up. I don't have anything useful to add to the technical discussion, except that that it seems pretty standard engineering practice to build a system, observe it and identify and eliminate bottlenecks. Planning never hurts, of course, but I don't think anybody could have realistically modeled and projected the cost of this infrastructure as it's grown organically and fast. Kristian > Look at this from a sponsor POV, why would I give X.org/fd.o > sponsorship money that they are just giving straight to google to pay > for hosting credits? Google are profiting in some minor way from these > hosting credits being bought by us, and I assume we aren't getting any > sort of discounts here. Having google sponsor the credits costs google > substantially less than having any other company give us money to do > it. > > If our current CI architecture is going to burn this amount of money a > year and we hadn't worked this out in advance of deploying it then I > suggest the system should be taken offline until we work out what a > sustainable system would look like within the budget we have, whether > that be never transferring containers and build artifacts from the > google network, just having local runner/build combos etc. > > Dave. > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Clean up DPLL output/refclock tracking (rev2)
== Series Details == Series: drm/i915: Clean up DPLL output/refclock tracking (rev2) URL : https://patchwork.freedesktop.org/series/73977/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915: Fix bounds check in intel_get_shared_dpll_id() Okay! Commit: drm/i915: Move DPLL HW readout/sanitize fns to intel_dpll_mgr.c Okay! Commit: drm/i915: Keep the global DPLL state in a DPLL specific struct Okay! Commit: drm/i915: Move the DPLL vfunc inits after the func defines Okay! Commit: drm/i915/hsw: Use the DPLL ID when calculating DPLL clock Okay! Commit: drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.c Okay! Commit: drm/i915/skl: Parametrize the DPLL ref clock instead of open-coding it Okay! Commit: drm/i915/hsw: Rename the get HDMI/DP DPLL funcs to get WRPLL/LCPLL Okay! Commit: drm/i915/hsw: Split out the SPLL parameter calculation Okay! Commit: drm/i915/hsw: Split out the WRPLL, LCPLL, SPLL frequency calculation Okay! Commit: drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculation +drivers/gpu/drm/i915/display/intel_dpll_mgr.c:2514:5: warning: symbol 'cnl_hdmi_pll_ref_clock' was not declared. Should it be static? Commit: drm/i915/hsw: Use the read-out WRPLL/SPLL state instead of reading out again Okay! Commit: drm/i915: Unify the DPLL ref clock frequency tracking -O:drivers/gpu/drm/i915/display/intel_dpll_mgr.c:2511:5: warning: symbol 'cnl_hdmi_pll_ref_clock' was not declared. Should it be static? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Clean up DPLL output/refclock tracking (rev2)
== Series Details ==
Series: drm/i915: Clean up DPLL output/refclock tracking (rev2)
URL : https://patchwork.freedesktop.org/series/73977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
19fd5dd4fc02 drm/i915: Fix bounds check in intel_get_shared_dpll_id()
4a956a747f48 drm/i915: Move DPLL HW readout/sanitize fns to intel_dpll_mgr.c
a46550bb063a drm/i915: Keep the global DPLL state in a DPLL specific struct
-:311: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON &
recovery code rather than BUG() or BUG_ON()
#311: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:3835:
+ BUG_ON(dev_priv->dpll.num_shared_dpll > I915_NUM_PLLS);
-:400: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#400: FILE: drivers/gpu/drm/i915/i915_drv.h:1057:
+ struct mutex lock;
total: 0 errors, 1 warnings, 1 checks, 339 lines checked
b87324c7e4d4 drm/i915: Move the DPLL vfunc inits after the func defines
e7b63db4be61 drm/i915/hsw: Use the DPLL ID when calculating DPLL clock
16cbb5c45f38 drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.c
-:607: CHECK:CAMELCASE: Avoid CamelCase:
#607: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:1024:
+ if (pll == SPLL_FREQ_810MHz)
-:607: CHECK:BRACES: braces {} should be used on all arms of this statement
#607: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:1024:
+ if (pll == SPLL_FREQ_810MHz)
[...]
+ else if (pll == SPLL_FREQ_1350MHz)
[...]
+ else if (pll == SPLL_FREQ_2700MHz)
[...]
+ else {
[...]
-:609: CHECK:CAMELCASE: Avoid CamelCase:
#609: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:1026:
+ else if (pll == SPLL_FREQ_1350MHz)
-:611: CHECK:CAMELCASE: Avoid CamelCase:
#611: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:1028:
+ else if (pll == SPLL_FREQ_2700MHz)
-:613: CHECK:BRACES: Unbalanced braces around else statement
#613: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:1030:
+ else {
-:645: CHECK:LINE_SPACING: Please don't use multiple blank lines
#645: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:1558:
+
+
-:787: CHECK:LINE_SPACING: Please don't use multiple blank lines
#787: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:2593:
+
+
-:1001: CHECK:LINE_SPACING: Please don't use multiple blank lines
#1001: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:4339:
+
+
total: 0 errors, 0 warnings, 8 checks, 968 lines checked
12c8e6996ea5 drm/i915/skl: Parametrize the DPLL ref clock instead of
open-coding it
d44f7bddc44c drm/i915/hsw: Rename the get HDMI/DP DPLL funcs to get WRPLL/LCPLL
9b1ae235617a drm/i915/hsw: Split out the SPLL parameter calculation
-:29: CHECK:CAMELCASE: Avoid CamelCase:
#29: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:969:
+ crtc_state->dpll_hw_state.spll = SPLL_PLL_ENABLE | SPLL_FREQ_1350MHz |
total: 0 errors, 0 warnings, 1 checks, 51 lines checked
7c9bf0760704 drm/i915/hsw: Split out the WRPLL, LCPLL, SPLL frequency
calculation
dcf2a96e2ea6 drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculation
-:523: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
drm_i915_private *' should also have an identifier name
#523: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.h:378:
+int intel_dpll_get_freq(struct drm_i915_private *,
-:523: WARNING:FUNCTION_ARGUMENTS: function definition argument 'const struct
intel_shared_dpll *' should also have an identifier name
#523: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.h:378:
+int intel_dpll_get_freq(struct drm_i915_private *,
total: 0 errors, 2 warnings, 0 checks, 479 lines checked
7766f980fe46 drm/i915/hsw: Use the read-out WRPLL/SPLL state instead of reading
out again
8ab21b812217 drm/i915: Unify the DPLL ref clock frequency tracking
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix return in assert_mmap_offset()
== Series Details == Series: drm/i915/selftests: Fix return in assert_mmap_offset() URL : https://patchwork.freedesktop.org/series/74081/ State : success == Summary == CI Bug Log - changes from CI_DRM_8032 -> Patchwork_16763 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16763/index.html Known issues Here are the changes found in Patchwork_16763 that come from known issues: ### IGT changes ### Issues hit * igt@prime_self_import@basic-with_fd_dup: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@prime_self_import@basic-with_fd_dup.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16763/fi-tgl-y/igt@prime_self_import@basic-with_fd_dup.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][3] ([CI#94]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16763/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@prime_self_import@basic-llseek-bad: - fi-tgl-y: [DMESG-WARN][5] ([CI#94] / [i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16763/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html Warnings * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [FAIL][7] ([i915#704]) -> [FAIL][8] ([i915#579]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16763/fi-kbl-guc/igt@i915_pm_...@basic-rte.html * igt@runner@aborted: - fi-kbl-8809g: [FAIL][9] ([i915#1209]) -> [FAIL][10] ([i915#192] / [i915#193] / [i915#194]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-8809g/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16763/fi-kbl-8809g/igt@run...@aborted.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#1209]: https://gitlab.freedesktop.org/drm/intel/issues/1209 [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192 [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193 [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 [i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704 Participating hosts (47 -> 45) -- Additional (4): fi-byt-j1900 fi-bdw-5557u fi-bsw-kefka fi-kbl-r Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bsw-nick fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8032 -> Patchwork_16763 CI-20190529: 20190529 CI_DRM_8032: e61f34133ad908d4b455344daa7b4edb9fcf680c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16763: b5ac082a9130804ebed1ded7b0b2dc7ea28e9f84 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b5ac082a9130 drm/i915/selftests: Fix return in assert_mmap_offset() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16763/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 50/51] drm/udl: drop drm_driver.release hook
On Fri, Feb 28, 2020 at 12:46 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 28.02.20 um 09:40 schrieb Daniel Vetter:
> > On Fri, Feb 28, 2020 at 8:44 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi Daniel
> >>
> >> Am 27.02.20 um 19:15 schrieb Daniel Vetter:
> >>> There's only two functions called from that:
> >>> drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are
> >>> also called from the ubs_driver->disconnect hook, so entirely
> >>> pointless to do the same again in the ->release hook.
> >>
> >> The disconnect hook calls drm_kms_helper_poll_disable() instead if
> >> _fini(). They are the same, except that _disable() does not clear
> >> dev->mode_config.poll_enabled to false. Is this OK?
> >
> > oops, I overlooked that. But yeah for driver shutdown it's the same
> > really, we're not going to re-enable. _disable is meant for suspend so
> > youc an re-enable again on resume.
> >
> > I'll augment the commit message on the next round to clarify that.
>
> Well, we have a managed API. It could support
> drmm_kms_helper_poll_init(). :)
You're ahead of the game here, but yes that's the plan. And a lot
more. Ideally I really want to get rid of both bus_driver->remove and
drm_driver->release callbacks for all drivers.
Also, for polling you actually want devm_kms_poll_init, since polling
should be stopped at unplug/remove time. Not at drm_driver release
time :-)
-Daniel
>
> Best regards
> Thomas
>
> > -Daniel
> >
> >
> >> Best regards
> >> Thomas
> >>
> >>>
> >>> Furthermore by the time we clean up the drm_driver we really shouldn't
> >>> be touching hardware anymore, so stopping the poll worker and freeing
> >>> the urb allocations in ->disconnect is the right thing to do.
> >>>
> >>> Now disconnect still cleans things up before unregistering the driver,
> >>> but that's a different issue.
> >>>
> >>> Signed-off-by: Daniel Vetter
> >>> Cc: Dave Airlie
> >>> Cc: Sean Paul
> >>> Cc: Daniel Vetter
> >>> Cc: Thomas Zimmermann
> >>> Cc: Emil Velikov
> >>> Cc: Gerd Hoffmann
> >>> Cc: "Noralf Trønnes"
> >>> Cc: Sam Ravnborg
> >>> Cc: Thomas Gleixner
> >>> Cc: Alex Deucher
> >>> ---
> >>> drivers/gpu/drm/udl/udl_drv.c | 6 --
> >>> drivers/gpu/drm/udl/udl_drv.h | 1 -
> >>> drivers/gpu/drm/udl/udl_main.c | 10 --
> >>> 3 files changed, 17 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> >>> index b447fb053e78..7f140898df3e 100644
> >>> --- a/drivers/gpu/drm/udl/udl_drv.c
> >>> +++ b/drivers/gpu/drm/udl/udl_drv.c
> >>> @@ -34,14 +34,8 @@ static int udl_usb_resume(struct usb_interface
> >>> *interface)
> >>>
> >>> DEFINE_DRM_GEM_FOPS(udl_driver_fops);
> >>>
> >>> -static void udl_driver_release(struct drm_device *dev)
> >>> -{
> >>> - udl_fini(dev);
> >>> -}
> >>> -
> >>> static struct drm_driver driver = {
> >>> .driver_features = DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET,
> >>> - .release = udl_driver_release,
> >>>
> >>> /* gem hooks */
> >>> .gem_create_object = udl_driver_gem_create_object,
> >>> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> >>> index 1de7eb1b6aac..2642f94a63fc 100644
> >>> --- a/drivers/gpu/drm/udl/udl_drv.h
> >>> +++ b/drivers/gpu/drm/udl/udl_drv.h
> >>> @@ -76,7 +76,6 @@ int udl_submit_urb(struct drm_device *dev, struct urb
> >>> *urb, size_t len);
> >>> void udl_urb_completion(struct urb *urb);
> >>>
> >>> int udl_init(struct udl_device *udl);
> >>> -void udl_fini(struct drm_device *dev);
> >>>
> >>> int udl_render_hline(struct drm_device *dev, int log_bpp, struct urb
> >>> **urb_ptr,
> >>>const char *front, char **urb_buf_ptr,
> >>> diff --git a/drivers/gpu/drm/udl/udl_main.c
> >>> b/drivers/gpu/drm/udl/udl_main.c
> >>> index 538718919916..f5d27f2a5654 100644
> >>> --- a/drivers/gpu/drm/udl/udl_main.c
> >>> +++ b/drivers/gpu/drm/udl/udl_main.c
> >>> @@ -351,13 +351,3 @@ int udl_drop_usb(struct drm_device *dev)
> >>> udl_free_urb_list(dev);
> >>> return 0;
> >>> }
> >>> -
> >>> -void udl_fini(struct drm_device *dev)
> >>> -{
> >>> - struct udl_device *udl = to_udl(dev);
> >>> -
> >>> - drm_kms_helper_poll_fini(dev);
> >>> -
> >>> - if (udl->urbs.count)
> >>> - udl_free_urb_list(dev);
> >>> -}
> >>>
> >>
> >> --
> >> Thomas Zimmermann
> >> Graphics Driver Developer
> >> SUSE Software Solutions Germany GmbH
> >> Maxfeldstr. 5, 90409 Nürnberg, Germany
> >> (HRB 36809, AG Nürnberg)
> >> Geschäftsführer: Felix Imendörffer
> >>
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915/gt: Expose engine properties via sysfs
== Series Details == Series: series starting with [1/7] drm/i915/gt: Expose engine properties via sysfs URL : https://patchwork.freedesktop.org/series/74080/ State : success == Summary == CI Bug Log - changes from CI_DRM_8032 -> Patchwork_16762 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16762/index.html Known issues Here are the changes found in Patchwork_16762 that come from known issues: ### IGT changes ### Issues hit * igt@prime_self_import@basic-llseek-size: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([CI#94] / [i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16762/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][3] ([fdo#111096] / [i915#323]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16762/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@prime_self_import@basic-llseek-bad: - fi-tgl-y: [DMESG-WARN][5] ([CI#94] / [i915#402]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16762/fi-tgl-y/igt@prime_self_imp...@basic-llseek-bad.html Warnings * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [FAIL][7] ([i915#704]) -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8032/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16762/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#704]: https://gitlab.freedesktop.org/drm/intel/issues/704 Participating hosts (47 -> 44) -- Additional (4): fi-byt-j1900 fi-bdw-5557u fi-bsw-kefka fi-kbl-r Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bsw-nick fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8032 -> Patchwork_16762 CI-20190529: 20190529 CI_DRM_8032: e61f34133ad908d4b455344daa7b4edb9fcf680c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5477: 3fe5828f45fc533ba4d9ee84dbb5aea320ce61bc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16762: 5d649480e8d65d575734e7c7831df72be1d91c6b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5d649480e8d6 drm/i915/gt: Expose heartbeat interval via sysfs 60fac5998627 drm/i915/gt: Expose preempt reset timeout via sysfs 6e9daee1bf88 drm/i915/gt: Expose reset stop timeout via sysfs e01f8abc4a64 drm/i915/gt: Expose busywait duration to sysfs ac66efa1d295 drm/i915/gt: Expose timeslice duration to sysfs 25aedca1dd0a drm/i915/gt: Expose engine->mmio_base via sysfs d3b9bcf44547 drm/i915/gt: Expose engine properties via sysfs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16762/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Refactor Gen11+ SAGV support (rev6)
== Series Details == Series: Refactor Gen11+ SAGV support (rev6) URL : https://patchwork.freedesktop.org/series/73856/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8018_full -> Patchwork_16732_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16732_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16732_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16732_full: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries_display_on: - shard-glk: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-glk6/igt@debugfs_test@read_all_entries_display_on.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-glk1/igt@debugfs_test@read_all_entries_display_on.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-skl: [PASS][3] -> [INCOMPLETE][4] +6 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_rotation_crc@sprite-rotation-180: - shard-tglb: NOTRUN -> [INCOMPLETE][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb5/igt@kms_rotation_...@sprite-rotation-180.html * igt@kms_rotation_crc@sprite-rotation-270: - shard-tglb: [PASS][6] -> [INCOMPLETE][7] +10 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-tglb2/igt@kms_rotation_...@sprite-rotation-270.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb5/igt@kms_rotation_...@sprite-rotation-270.html * igt@runner@aborted: - shard-tglb: NOTRUN -> ([FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb7/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb8/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb2/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb6/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb5/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb6/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb5/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb7/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb8/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb2/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb3/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb6/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-tglb5/igt@run...@aborted.html Warnings * igt@runner@aborted: - shard-kbl: [FAIL][21] ([i915#92]) -> ([FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35]) ([fdo#109383] / [fdo#111012] / [i915#92]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-kbl6/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl7/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl6/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl7/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl4/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl6/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl1/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl7/igt@run...@aborted.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16732/shard-kbl4/igt@run...@aborted.html [30]:
[Intel-gfx] [PATCH v2 3/3] drm/i915: HDCP: retry link integrity check on failure
From: Oliver Barta
A single Ri mismatch doesn't automatically mean that the link integrity
is broken. Update and check of Ri and Ri' are done asynchronously. In
case an update happens just between the read of Ri' and the check against
Ri there will be a mismatch even if the link integrity is fine otherwise.
A failure can also be caused by transmission errors on DDC.
Signed-off-by: Oliver Barta
---
[v2] Rebased patch series from master to drm-intel-next-queued branch.
drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index ac4276157182..296b4e1bb3c6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1516,7 +1516,7 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
}
static
-bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+bool intel_hdmi_hdcp_check_link_once(struct intel_digital_port *intel_dig_port)
{
struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
struct intel_connector *connector =
@@ -1539,13 +1539,26 @@ bool intel_hdmi_hdcp_check_link(struct
intel_digital_port *intel_dig_port)
if (wait_for((intel_de_read(i915, HDCP_STATUS(i915, cpu_transcoder,
port)) & (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC)) ==
(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
- DRM_ERROR("Ri' mismatch detected, link check failed (%x)\n",
+ DRM_DEBUG("Ri' mismatch detected (%x)\n",
intel_de_read(i915, HDCP_STATUS(i915, cpu_transcoder,
port)));
return false;
}
return true;
}
+static
+bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+{
+ int retry;
+
+ for (retry = 0; retry < 3; retry++)
+ if (intel_hdmi_hdcp_check_link_once(intel_dig_port))
+ return true;
+
+ DRM_ERROR("Link check failed\n");
+ return false;
+}
+
struct hdcp2_hdmi_msg_timeout {
u8 msg_id;
u16 timeout;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: HDCP: fix Ri prime and R0 checks during auth
From: Oliver Barta
Including HDCP_STATUS_ENC bit in the checks is pointless.
It is simply not set at this point.
Signed-off-by: Oliver Barta
Fixes: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
---
[v2] Rebased patch series from master to drm-intel-next-queued branch.
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 229b4e329864..89d035da95e7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -705,7 +705,7 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
/* Wait for R0 ready */
if (wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)) &
-(HDCP_STATUS_R0_READY | HDCP_STATUS_ENC), 1)) {
+HDCP_STATUS_R0_READY, 1)) {
DRM_ERROR("Timed out waiting for R0 ready\n");
return -ETIMEDOUT;
}
@@ -738,7 +738,7 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
/* Wait for Ri prime match */
if (!wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)) &
- (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
+ HDCP_STATUS_RI_MATCH, 1))
break;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: HDCP: fix Ri prime check done during link check
From: Oliver Barta
The check was always succeeding even in case of a mismatch due to the
HDCP_STATUS_ENC bit being set. Make sure both bits are actually set.
Signed-off-by: Oliver Barta
Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI")
---
[v2] Rebased patch series from master to drm-intel-next-queued branch.
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0ac9bdfbc094..ac4276157182 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1536,7 +1536,8 @@ bool intel_hdmi_hdcp_check_link(struct intel_digital_port
*intel_dig_port)
intel_de_write(i915, HDCP_RPRIME(i915, cpu_transcoder, port), ri.reg);
/* Wait for Ri prime match */
- if (wait_for(intel_de_read(i915, HDCP_STATUS(i915, cpu_transcoder,
port)) &
+ if (wait_for((intel_de_read(i915, HDCP_STATUS(i915, cpu_transcoder,
+port)) & (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC)) ==
(HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1)) {
DRM_ERROR("Ri' mismatch detected, link check failed (%x)\n",
intel_de_read(i915, HDCP_STATUS(i915, cpu_transcoder,
port)));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote: > > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote: > > > > We could also do stuff like reducing the amount of tests we run on each > > commit, and punt some testing to a per-weekend test-run or someting > > like that. We don't *need* to know about every problem up front, just > > the stuff that's about to be released, really. The other stuff is just > > nice to have. If it's too expensive, I would say drop it. > > I don't agree that pre-merge testing is just nice to have. A problem > which is only caught after it lands in mainline has a much bigger impact > than one which is already caught earlier. > one thought.. since with mesa+margebot we effectively get at least two(ish) CI runs per MR, ie. one when it is initially pushed, and one when margebot rebases and tries to merge, could we leverage this to have trimmed down pre-margebot CI which tries to just target affected drivers, with margebot doing a full CI run (when it is potentially batching together multiple MRs)? Seems like a way to reduce our CI runs with a good safety net to prevent things from slipping through the cracks. (Not sure how much that would help reduce bandwidth costs, but I guess it should help a bit.) BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915/gt: Expose engine properties via sysfs
== Series Details == Series: series starting with [1/7] drm/i915/gt: Expose engine properties via sysfs URL : https://patchwork.freedesktop.org/series/74080/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/gt: Expose engine properties via sysfs - +drivers/gpu/drm/i915/gt/sysfs_engines.c:51:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:52:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:56:10: error: bad integer constant expression Commit: drm/i915/gt: Expose engine->mmio_base via sysfs +drivers/gpu/drm/i915/gt/sysfs_engines.c:60:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression -O:drivers/gpu/drm/i915/gt/sysfs_engines.c:51:10: error: bad integer constant expression -O:drivers/gpu/drm/i915/gt/sysfs_engines.c:52:10: error: bad integer constant expression Commit: drm/i915/gt: Expose timeslice duration to sysfs Okay! Commit: drm/i915/gt: Expose busywait duration to sysfs +drivers/gpu/drm/i915/intel_wakeref.c:135:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y Commit: drm/i915/gt: Expose reset stop timeout via sysfs Okay! Commit: drm/i915/gt: Expose preempt reset timeout via sysfs Okay! Commit: drm/i915/gt: Expose heartbeat interval via sysfs Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915/gt: Expose engine properties via sysfs
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Expose engine properties via
sysfs
URL : https://patchwork.freedesktop.org/series/74080/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d3b9bcf44547 drm/i915/gt: Expose engine properties via sysfs
-:76: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#76:
new file mode 100644
-:181: CHECK:SPACING: No space is necessary after a cast
#181: FILE: drivers/gpu/drm/i915/gt/sysfs_engines.c:101:
+show_unknown ? BITS_PER_TYPE(typeof(caps)) : count) {
total: 0 errors, 1 warnings, 1 checks, 242 lines checked
25aedca1dd0a drm/i915/gt: Expose engine->mmio_base via sysfs
ac66efa1d295 drm/i915/gt: Expose timeslice duration to sysfs
e01f8abc4a64 drm/i915/gt: Expose busywait duration to sysfs
6e9daee1bf88 drm/i915/gt: Expose reset stop timeout via sysfs
60fac5998627 drm/i915/gt: Expose preempt reset timeout via sysfs
5d649480e8d6 drm/i915/gt: Expose heartbeat interval via sysfs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: introduce global sseu pinning
Quoting Lionel Landwerlin (2020-02-28 16:02:29)
> On Gen11 powergating half the execution units is a functional
> requirement when using the VME samplers. Not fullfilling this
> requirement can lead to hangs.
>
> This unfortunately plays fairly poorly with the NOA requirements. NOA
> requires a stable power configuration to maintain its configuration.
>
> As a result using OA (and NOA feeding into it) so far has required us
> to use a power configuration that can work for all contexts. The only
> power configuration fullfilling this is powergating half the execution
> units.
>
> This makes performance analysis for 3D workloads somewhat pointless.
>
> Failing to find a solution that would work for everybody, this change
> introduces a new i915-perf stream open parameter that punts the
> decision off to userspace. If this parameter is omitted, the existing
> Gen11 behavior remains (half EU array powergating).
>
> This change takes the initiative to move all perf related sseu
> configuration into i915_perf.c
The code looks fine, your argument is sound. My only reservation is the
danger of this becoming the defacto default and so catching users's
profiling their system by surprise.
> @@ -3628,6 +3678,16 @@ static int read_properties_unlocked(struct i915_perf
> *perf,
> case DRM_I915_PERF_PROP_HOLD_PREEMPTION:
> props->hold_preemption = !!value;
> break;
> + case DRM_I915_PERF_PROP_GLOBAL_SSEU: {
> + if (copy_from_user(>user_sseu,
> + u64_to_user_ptr(value),
> + sizeof(props->user_sseu))) {
> + DRM_DEBUG("Unable to copy global sseu
> parameter\n");
> + return -EFAULT;
> + }
Since this affects system state for other users, I would suggest this
has a privilege check
> + props->user_sseu_present = true;
> + break;
i915_perf_ioctl_open_locked:
if (props->user_sseu_present && IS_GEN(11))
privileged_op = true;
?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/20] drm/i915: Skip barriers inside waits (rev4)
== Series Details ==
Series: series starting with [01/20] drm/i915: Skip barriers inside waits (rev4)
URL : https://patchwork.freedesktop.org/series/73999/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8018_full -> Patchwork_16731_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16731_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16731_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_16731_full:
### IGT changes ###
Possible regressions
* {igt@i915_selftest@perf@request} (NEW):
- shard-iclb: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-iclb2/igt@i915_selftest@p...@request.html
- shard-skl: NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-skl1/igt@i915_selftest@p...@request.html
- shard-tglb: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-tglb7/igt@i915_selftest@p...@request.html
* {igt@i915_selftest@perf_request} (NEW):
- shard-iclb: NOTRUN -> [SKIP][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-iclb1/igt@i915_selftest@perf_request.html
* igt@runner@aborted:
- shard-tglb: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-tglb7/igt@run...@aborted.html
Warnings
* igt@i915_selftest@live@gt_lrc:
- shard-tglb: [DMESG-FAIL][6] ([i915#1233]) -> [DMESG-FAIL][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-tglb1/igt@i915_selftest@live@gt_lrc.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-tglb3/igt@i915_selftest@live@gt_lrc.html
New tests
-
New tests have been introduced between CI_DRM_8018_full and
Patchwork_16731_full:
### New IGT tests (6) ###
* igt@drm_mm@all:
- Statuses :
- Exec time: [None] s
* igt@i915_selftest@mock:
- Statuses :
- Exec time: [None] s
* igt@i915_selftest@perf:
- Statuses :
- Exec time: [None] s
* igt@i915_selftest@perf@request:
- Statuses : 7 incomplete(s)
- Exec time: [0.0] s
* igt@i915_selftest@perf_request:
- Statuses : 4 skip(s)
- Exec time: [0.0] s
* igt@kms_selftest@all:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_16731_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic-nohangcheck:
- shard-snb: [PASS][8] -> [FAIL][9] ([i915#1148])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-snb2/igt@gem_ctx_e...@basic-nohangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-snb2/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_persistence@close-replace-race:
- shard-kbl: [PASS][10] -> [INCOMPLETE][11] ([fdo#103665] /
[i915#1291])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-kbl4/igt@gem_ctx_persiste...@close-replace-race.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-kbl4/igt@gem_ctx_persiste...@close-replace-race.html
* igt@gem_ctx_shared@exec-shared-gtt-bsd1:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#616])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-tglb6/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-tglb1/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html
* igt@gem_exec_schedule@implicit-read-write-bsd:
- shard-iclb: [PASS][14] -> [SKIP][15] ([i915#677])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-iclb6/igt@gem_exec_sched...@implicit-read-write-bsd.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#112146])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-iclb6/igt@gem_exec_sched...@in-order-bsd.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-iclb1/igt@gem_exec_sched...@in-order-bsd.html
* igt@i915_pm_rps@waitboost:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#413])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8018/shard-iclb2/igt@i915_pm_...@waitboost.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16731/shard-iclb6/igt@i915_pm_...@waitboost.html
Re: [Intel-gfx] [PATCH v18 4/8] drm/i915: Introduce more *_state_changed indicators
On Fri, Feb 28, 2020 at 08:56:58AM +, Lisovskiy, Stanislav wrote:
> On Thu, 2020-02-27 at 18:12 +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 04:57:33PM +0200, Stanislav Lisovskiy wrote:
> > > The reasoning behind this is such that current dependencies
> > > in the code are rather implicit in a sense, we have to constantly
> > > check a bunch of different bits like state->modeset,
> > > state->active_pipe_changes, which sometimes can indicate counter
> > > intuitive changes.
> > >
> > > By introducing more fine grained state change tracking we achieve
> > > better readability and dependency maintenance for the code.
> > >
> > > For example it is no longer needed to evaluate active_pipe_changes
> > > to understand if there were changes for wm/ddb - lets just have
> > > a correspondent bit in a state, called ddb_state_changed.
> > >
> > > active_pipe_changes just indicate whether there was some pipe added
> > > or removed. Then we evaluate if wm/ddb had been changed.
> > > Same for sagv/bw state. ddb changes may or may not affect if out
> > > bandwidth constraints have been changed.
> > >
> > > v2: Add support for older Gens in order not to introduce
> > > regressions
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_atomic.c | 2 ++
> > > drivers/gpu/drm/i915/display/intel_bw.c | 28 ++-
> > > -
> > > drivers/gpu/drm/i915/display/intel_display.c | 16 ++
> > > .../drm/i915/display/intel_display_types.h| 32 ---
> > >
> > > drivers/gpu/drm/i915/intel_pm.c | 5 ++-
> > > 5 files changed, 62 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > index d043057d2fa0..0db9c66d3c0f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> > > @@ -525,6 +525,8 @@ void intel_atomic_state_clear(struct
> > > drm_atomic_state *s)
> > > state->dpll_set = state->modeset = false;
> > > state->global_state_changed = false;
> > > state->active_pipes = 0;
> > > + state->ddb_state_changed = false;
> > > + state->bw_state_changed = false;
> >
> > Not really liking these.
> >
> > After some pondering I was thinking along the lines of something
> > simple
> > like this:
> >
> > struct bw_state {
> > u8 sagv_reject;
> > };
> >
> > bw_check()
> > {
> > for_each_crtc_in_state() {
> > if (sagv_possible(crtc_state))
> > new->sagv_reject &= ~BIT(pipe);
> > else
> > new->sagv_reject |= BIT(pipe);
> > }
> >
> > calculate new->qgv_mask
> > }
>
> This is exactly what's done in the next patch, except
> that I store pipe, which are allowed to have SAGV, i.e:
I think inverted mask idea leads to neater code because then we
don't have to care which pipes are actually present in the hw
and which are fused off/not present:
sagv_reject == 0 -> SAGV possible
sagv_reject != 0 -> SAGV not possible
>
> struct intel_bw_state {
> struct intel_global_state base;
>
> + /*
> + * Contains a bit mask, used to determine, whether
> correspondent
> + * pipe allows SAGV or not.
> + */
> + u8 pipe_sagv_mask;
> +
> + /*
> + * Used to determine if we already had calculated
> + * SAGV mask for this state once.
> + */
> + bool sagv_calculated;
> +
> + /*
> + * Contains final SAGV decision based on current mask,
> + * to prevent doing the same job over and over again.
> + */
> + bool can_sagv;
> +
>
> Also the mask is calculated almost exactly same way:
>
> static void icl_compute_sagv_mask(struct intel_atomic_state *state)
> +{
> + struct intel_crtc *crtc;
> + struct intel_crtc_state *new_crtc_state;
> + int i;
> + struct intel_bw_state *new_bw_state =
> intel_bw_get_state(state);
> +
> + if (IS_ERR(new_bw_state)) {
> + WARN(1, "Could not get bw_state\n");
> + return;
> + }
> +
> + for_each_new_intel_crtc_in_state(state, crtc,
> + new_crtc_state, i) {
> + if (skl_can_enable_sagv_on_pipe(state, crtc->pipe))
> + new_bw_state->pipe_sagv_mask |= BIT(crtc-
> >pipe);
> + else
> + new_bw_state->pipe_sagv_mask &= ~BIT(crtc-
> >pipe);
> + }
> +}
>
> But this patch is not about that - it is about how we signal/determine
> that some change has to be written at commit stage.
> As you remember when we were discussed offline, I just wanted to have
> some expicit way to mark if some global state subsystem had changed,
> without having to do any additional checks, because imho all the checks
> we should do during atomic check, while commit simply applies what has
> to be applied.
>
> If you are really against having those boolean or any other way to be
>
Re: [Intel-gfx] [PATCH] drm/i915: Minimize uaccess exposure in i915_gem_execbuffer2_ioctl()
On Thu, Feb 27, 2020 at 10:26:00PM +, Chris Wilson wrote: > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > > @@ -2947,6 +2947,13 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, > > void *data, > > u64_to_user_ptr(args->buffers_ptr); > > unsigned int i; > > > > + /* > > +* Do the call to gen8_canonical_addr() outside the > > +* uaccess-enabled region to minimize uaccess exposure. > > +*/ > > + for (i = 0; i < args->buffer_count; i++) > > + exec2_list[i].offset = > > gen8_canonical_addr(exec2_list[i].offset); > > > Another loop over all the objects, where we intentionally try and skip > unmodified entries? To save 2 instructions from inside the second loop? > > Colour me skeptical. So are you're saying these arrays can be large and that you have performance concerns? -- Josh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Add glk to intel_detect_preproduction_hw()
On Tue, Jan 28, 2020 at 05:51:52PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Detect GLK pre-production steppings. Not 100% of A2 being pre-prod
> since the spec is a bit of a mess but feels more or less correct.
>
> Suggested-by: Chris Wilson
> Signed-off-by: Ville Syrjälä
On the series:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5a5846d892f4..d89d54f5593c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -438,6 +438,7 @@ static void intel_detect_preproduction_hw(struct
> drm_i915_private *dev_priv)
> pre |= IS_SKL_REVID(dev_priv, 0, SKL_REVID_F0);
> pre |= IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST);
> pre |= IS_KBL_REVID(dev_priv, 0, KBL_REVID_A0);
> + pre |= IS_GLK_REVID(dev_priv, 0, GLK_REVID_A2);
>
> if (pre) {
> DRM_ERROR("This is a pre-production stepping. "
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a8a08c63278e..d62b57ba0ced 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1578,6 +1578,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>
> #define GLK_REVID_A0 0x0
> #define GLK_REVID_A1 0x1
> +#define GLK_REVID_A2 0x2
> +#define GLK_REVID_B0 0x3
>
> #define IS_GLK_REVID(dev_priv, since, until) \
> (IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Fix 90/270 degree rotated RGB565 src coord checks
From: Ville Syrjälä
Supposedly both src coordinates have to even when doing 90/270
degree rotation with RGB565. This is definitely true for the
X coordinate (we just get a black screen when it is odd). My
experiments didn't show any misbehaviour with an odd
Y coordinate, but let's trust the spec and reject that one
as well.
v2: Ignore ccs hsub/vsub
v3: Clarify the CCS special (Maarten)
Deal with tgl+ CCS modifiers where we
do need to look at hsub/vsub
Reviewed-by: Maarten Lankhorst #v2
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c | 32 ++---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 22ad6dde46ce..1ec5025c90f0 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -282,6 +282,16 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
u32 src_x, src_y, src_w, src_h, hsub, vsub;
bool rotated = drm_rotation_90_or_270(plane_state->hw.rotation);
+ /*
+* FIXME hsub/vsub vs. block size is a mess. Pre-tgl CCS
+* abuses hsub/vsub so we can't use them here. But as they
+* are limited to 32bpp RGB formats we don't actually need
+* to check anything.
+*/
+ if (fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS)
+ return 0;
+
/*
* Hardware doesn't handle subpixel coordinates.
* Adjust to (macro)pixel boundary, but be careful not to
@@ -296,26 +306,26 @@ int intel_plane_check_src_coordinates(struct
intel_plane_state *plane_state)
drm_rect_init(src, src_x << 16, src_y << 16,
src_w << 16, src_h << 16);
- if (!fb->format->is_yuv)
- return 0;
-
- /* YUV specific checks */
- if (!rotated) {
+ if (fb->format->format == DRM_FORMAT_RGB565 && rotated) {
+ hsub = 2;
+ vsub = 2;
+ } else {
hsub = fb->format->hsub;
vsub = fb->format->vsub;
- } else {
- hsub = vsub = max(fb->format->hsub, fb->format->vsub);
}
+ if (rotated)
+ hsub = vsub = max(hsub, vsub);
+
if (src_x % hsub || src_w % hsub) {
- DRM_DEBUG_KMS("src x/w (%u, %u) must be a multiple of %u for
%sYUV planes\n",
- src_x, src_w, hsub, rotated ? "rotated " : "");
+ DRM_DEBUG_KMS("src x/w (%u, %u) must be a multiple of %u
(rotated: %s)\n",
+ src_x, src_w, hsub, yesno(rotated));
return -EINVAL;
}
if (src_y % vsub || src_h % vsub) {
- DRM_DEBUG_KMS("src y/h (%u, %u) must be a multiple of %u for
%sYUV planes\n",
- src_y, src_h, vsub, rotated ? "rotated " : "");
+ DRM_DEBUG_KMS("src y/h (%u, %u) must be a multiple of %u
(rotated: %s)\n",
+ src_y, src_h, vsub, yesno(rotated));
return -EINVAL;
}
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: introduce global sseu pinning
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As a result using OA (and NOA feeding into it) so far has required us
to use a power configuration that can work for all contexts. The only
power configuration fullfilling this is powergating half the execution
units.
This makes performance analysis for 3D workloads somewhat pointless.
Failing to find a solution that would work for everybody, this change
introduces a new i915-perf stream open parameter that punts the
decision off to userspace. If this parameter is omitted, the existing
Gen11 behavior remains (half EU array powergating).
This change takes the initiative to move all perf related sseu
configuration into i915_perf.c
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 +--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 4 +
drivers/gpu/drm/i915/gt/intel_sseu.c| 34 +---
drivers/gpu/drm/i915/i915_perf.c| 90 ++---
drivers/gpu/drm/i915/i915_perf_types.h | 7 ++
include/uapi/drm/i915_drm.h | 11 +++
6 files changed, 108 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index e525ead073f7..652f84c3cc2b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1279,10 +1279,10 @@ static int get_ringsize(struct i915_gem_context *ctx,
return 0;
}
-static int
-user_to_context_sseu(struct drm_i915_private *i915,
-const struct drm_i915_gem_context_param_sseu *user,
-struct intel_sseu *context)
+int
+i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context)
{
const struct sseu_dev_info *device = _INFO(i915)->sseu;
@@ -1417,7 +1417,7 @@ static int set_sseu(struct i915_gem_context *ctx,
goto out_ce;
}
- ret = user_to_context_sseu(i915, _sseu, );
+ ret = i915_gem_user_to_context_sseu(i915, _sseu, );
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 3ae61a355d87..dff1380373f4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -222,4 +222,8 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
*it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
+int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context);
+
#endif /* !__I915_GEM_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 74f793423231..b01b6e2c3e54 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -65,7 +65,6 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
{
const struct sseu_dev_info *sseu = _INFO(i915)->sseu;
bool subslice_pg = sseu->has_subslice_pg;
- struct intel_sseu ctx_sseu;
u8 slices, subslices;
u32 rpcs = 0;
@@ -76,33 +75,8 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
if (INTEL_GEN(i915) < 9)
return 0;
- /*
-* If i915/perf is active, we want a stable powergating configuration
-* on the system.
-*
-* We could choose full enablement, but on ICL we know there are use
-* cases which disable slices for functional, apart for performance
-* reasons. So in this case we select a known stable subset.
-*/
- if (!i915->perf.exclusive_stream) {
- ctx_sseu = *req_sseu;
- } else {
- ctx_sseu = intel_sseu_from_device_info(sseu);
-
- if (IS_GEN(i915, 11)) {
- /*
-* We only need subslice count so it doesn't matter
-* which ones we select - just turn off low bits in the
-* amount of half of all available subslices per slice.
-*/
- ctx_sseu.subslice_mask =
- ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
- ctx_sseu.slice_mask = 0x1;
- }
- }
-
- slices = hweight8(ctx_sseu.slice_mask);
- subslices = hweight8(ctx_sseu.subslice_mask);
+ slices = hweight8(req_sseu->slice_mask);
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Some upside-down panel handling fixes
== Series Details == Series: drm/i915: Some upside-down panel handling fixes URL : https://patchwork.freedesktop.org/series/74076/ State : success == Summary == CI Bug Log - changes from CI_DRM_8030 -> Patchwork_16761 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16761/index.html Known issues Here are the changes found in Patchwork_16761 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gem_contexts: - fi-cfl-guc: [PASS][1] -> [DMESG-FAIL][2] ([i915#730]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8030/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16761/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html * igt@kms_addfb_basic@addfb25-y-tiled: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8030/fi-tgl-y/igt@kms_addfb_ba...@addfb25-y-tiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16761/fi-tgl-y/igt@kms_addfb_ba...@addfb25-y-tiled.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111096] / [i915#323]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8030/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16761/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@prime_self_import@basic-llseek-size: - fi-tgl-y: [DMESG-WARN][7] ([CI#94] / [i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8030/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16761/fi-tgl-y/igt@prime_self_imp...@basic-llseek-size.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#730]: https://gitlab.freedesktop.org/drm/intel/issues/730 Participating hosts (50 -> 43) -- Additional (2): fi-glk-dsi fi-ilk-650 Missing(9): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bsw-kefka fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8030 -> Patchwork_16761 CI-20190529: 20190529 CI_DRM_8030: dbdc956c90598337bef46cede52b082954651c0e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5476: 6628336d5699e3fda2c3b64b1c9fc5426b6de29a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16761: 91740cf1d41cdc75321a68067c5bdd0d5e55b297 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 91740cf1d41c drm/i915/dp: Use BDB_GENERAL_FEATURES VBT block info for builtin panel-orientation 3da5c24d3382 drm/i915/dsi: Remove readback of panel orientation on BYT / CHT == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16761/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter > wrote: > > Hi all, > > > > You might have read the short take in the X.org board meeting > > minutes > > already, here's the long version. > > > > The good news: gitlab.fd.o has become very popular with our > > communities, and is used extensively. This especially includes all > > the > > CI integration. Modern development process and tooling, yay! > > > > The bad news: The cost in growth has also been tremendous, and it's > > breaking our bank account. With reasonable estimates for continued > > growth we're expecting hosting expenses totalling 75k USD this > > year, > > and 90k USD next year. With the current sponsors we've set up we > > can't > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > without any of the CI features enabled would total 30k USD, which > > is > > within X.org's ability to support through various sponsorships, > > mostly > > through XDC. > > > > Note that X.org does no longer sponsor any CI runners themselves, > > we've stopped that. The huge additional expenses are all just in > > storing and serving build artifacts and images to outside CI > > runners > > sponsored by various companies. A related topic is that with the > > growth in fd.o it's becoming infeasible to maintain it all on > > volunteer admin time. X.org is therefore also looking for admin > > sponsorship, at least medium term. > > > > Assuming that we want cash flow reserves for one year of > > gitlab.fd.o > > (without CI support) and a trimmed XDC and assuming no sponsor > > payment > > meanwhile, we'd have to cut CI services somewhere between May and > > June > > this year. The board is of course working on acquiring sponsors, > > but > > filling a shortfall of this magnitude is neither easy nor quick > > work, > > and we therefore decided to give an early warning as soon as > > possible. > > Any help in finding sponsors for fd.o is very much appreciated. > > a) Ouch. > > b) we probably need to take a large step back here. > I kinda agree, but maybe the step doesn't have to be *too* large? I wonder if we could solve this by restructuring the project a bit. I'm talking purely from a Mesa point of view here, so it might not solve the full problem, but: 1. It feels silly that we need to test changes to e.g the i965 driver on dragonboards. We only have a big "do not run CI at all" escape- hatch. 2. A lot of us are working for a company that can probably pay for their own needs in terms of CI. Perhaps moving some costs "up front" to the company that needs it can make the future of CI for those who can't do this 3. I think we need a much more detailed break-down of the cost to make educated changes. For instance, how expensive is Docker image uploads/downloads (e.g intermediary artifacts) compared to build logs and final test-results? What kind of artifacts? One suggestion would be to do something more similar to what the kernel does, and separate into different repos for different subsystems. This could allow us to have separate testing-pipelines for these repos, which would mean that for instance a change to RADV didn't trigger a full Panfrost test-run. This would probably require us to accept using a more branch-heavy work-flow. I don't personally think that would be a bad thing. But this is all kinda based on an assumption that running hardware- testing is the expensive part. I think that's quite possibly the case, but some more numbers would be helpful. I mean, it might turn out that just throwing up a Docker cache inside the organizations that host runners might be sufficient for all I know... We could also do stuff like reducing the amount of tests we run on each commit, and punt some testing to a per-weekend test-run or someting like that. We don't *need* to know about every problem up front, just the stuff that's about to be released, really. The other stuff is just nice to have. If it's too expensive, I would say drop it. I would really hope that we can consider approaches like this before we throw out the baby with the bathwater... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/24] drm/i915/selftests: Be a little more lenient for reset workers
Chris Wilson writes:
> Give the reset worker a kick before losing help when waiting for hang
> recovery, as the CPU scheduler is a little unreliable.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 74 ++
> 1 file changed, 52 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index 95da6b880e3f..af5b3da6d894 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -90,6 +90,48 @@ static int wait_for_submit(struct intel_engine_cs *engine,
> return -ETIME;
> }
>
> +static int wait_for_reset(struct intel_engine_cs *engine,
> + struct i915_request *rq,
> + unsigned long timeout)
> +{
> + timeout += jiffies;
> + do {
> + cond_resched();
> + intel_engine_flush_submission(engine);
> +
> + if (READ_ONCE(engine->execlists.pending[0]))
> + continue;
> +
> + if (i915_request_completed(rq))
> + break;
> +
> + if (READ_ONCE(rq->fence.error))
> + break;
> + } while (time_before(jiffies, timeout));
> +
> + flush_scheduled_work();
> +
> + if (rq->fence.error != -EIO) {
> + pr_err("%s: hanging request %llx:%lld not reset\n",
> +engine->name,
> +rq->fence.context,
> +rq->fence.seqno);
> + return -EINVAL;
> + }
> +
> + /* Give the request a jiffie to complete after flushing the worker */
> + if (i915_request_wait(rq, 0,
> + max(0l, (long)(timeout - jiffies)) + 1) < 0) {
> + pr_err("%s: hanging request %llx:%lld did not complete\n",
> +engine->name,
> +rq->fence.context,
> +rq->fence.seqno);
> + return -ETIME;
> + }
> +
> + return 0;
> +}
> +
> static int live_sanitycheck(void *arg)
> {
> struct intel_gt *gt = arg;
> @@ -1805,14 +1847,9 @@ static int __cancel_active0(struct live_preempt_cancel
> *arg)
> if (err)
> goto out;
>
> - if (i915_request_wait(rq, 0, HZ / 5) < 0) {
> - err = -EIO;
> - goto out;
> - }
> -
> - if (rq->fence.error != -EIO) {
> - pr_err("Cancelled inflight0 request did not report -EIO\n");
> - err = -EINVAL;
> + err = wait_for_reset(arg->engine, rq, HZ / 2);
> + if (err) {
> + pr_err("Cancelled inflight0 request did not reset\n");
> goto out;
> }
>
> @@ -1870,10 +1907,9 @@ static int __cancel_active1(struct live_preempt_cancel
> *arg)
> goto out;
>
> igt_spinner_end(>a.spin);
> - if (i915_request_wait(rq[1], 0, HZ / 5) < 0) {
> - err = -EIO;
> + err = wait_for_reset(arg->engine, rq[1], HZ / 2);
> + if (err)
> goto out;
> - }
>
> if (rq[0]->fence.error != 0) {
> pr_err("Normal inflight0 request did not complete\n");
> @@ -1953,10 +1989,9 @@ static int __cancel_queued(struct live_preempt_cancel
> *arg)
> if (err)
> goto out;
>
> - if (i915_request_wait(rq[2], 0, HZ / 5) < 0) {
> - err = -EIO;
> + err = wait_for_reset(arg->engine, rq[2], HZ / 2);
> + if (err)
> goto out;
> - }
>
> if (rq[0]->fence.error != -EIO) {
> pr_err("Cancelled inflight0 request did not report -EIO\n");
> @@ -2014,14 +2049,9 @@ static int __cancel_hostile(struct live_preempt_cancel
> *arg)
> if (err)
> goto out;
>
> - if (i915_request_wait(rq, 0, HZ / 5) < 0) {
> - err = -EIO;
> - goto out;
> - }
> -
> - if (rq->fence.error != -EIO) {
> - pr_err("Cancelled inflight0 request did not report -EIO\n");
> - err = -EINVAL;
> + err = wait_for_reset(arg->engine, rq, HZ / 2);
> + if (err) {
> + pr_err("Cancelled inflight0 request did not reset\n");
> goto out;
> }
>
> --
> 2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: > On 28/02/2020 11:28, Erik Faye-Lund wrote: > > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter < > > > daniel.vet...@ffwll.ch> > > > wrote: > > > > Hi all, > > > > > > > > You might have read the short take in the X.org board meeting > > > > minutes > > > > already, here's the long version. > > > > > > > > The good news: gitlab.fd.o has become very popular with our > > > > communities, and is used extensively. This especially includes > > > > all > > > > the > > > > CI integration. Modern development process and tooling, yay! > > > > > > > > The bad news: The cost in growth has also been tremendous, and > > > > it's > > > > breaking our bank account. With reasonable estimates for > > > > continued > > > > growth we're expecting hosting expenses totalling 75k USD this > > > > year, > > > > and 90k USD next year. With the current sponsors we've set up > > > > we > > > > can't > > > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > > > without any of the CI features enabled would total 30k USD, > > > > which > > > > is > > > > within X.org's ability to support through various sponsorships, > > > > mostly > > > > through XDC. > > > > > > > > Note that X.org does no longer sponsor any CI runners > > > > themselves, > > > > we've stopped that. The huge additional expenses are all just > > > > in > > > > storing and serving build artifacts and images to outside CI > > > > runners > > > > sponsored by various companies. A related topic is that with > > > > the > > > > growth in fd.o it's becoming infeasible to maintain it all on > > > > volunteer admin time. X.org is therefore also looking for admin > > > > sponsorship, at least medium term. > > > > > > > > Assuming that we want cash flow reserves for one year of > > > > gitlab.fd.o > > > > (without CI support) and a trimmed XDC and assuming no sponsor > > > > payment > > > > meanwhile, we'd have to cut CI services somewhere between May > > > > and > > > > June > > > > this year. The board is of course working on acquiring > > > > sponsors, > > > > but > > > > filling a shortfall of this magnitude is neither easy nor quick > > > > work, > > > > and we therefore decided to give an early warning as soon as > > > > possible. > > > > Any help in finding sponsors for fd.o is very much appreciated. > > > a) Ouch. > > > > > > b) we probably need to take a large step back here. > > > > > I kinda agree, but maybe the step doesn't have to be *too* large? > > > > I wonder if we could solve this by restructuring the project a bit. > > I'm > > talking purely from a Mesa point of view here, so it might not > > solve > > the full problem, but: > > > > 1. It feels silly that we need to test changes to e.g the i965 > > driver > > on dragonboards. We only have a big "do not run CI at all" escape- > > hatch. > > Yeah, changes on vulkan drivers or backend compilers should be > fairly > sandboxed. > > We also have tools that only work for intel stuff, that should never > trigger anything on other people's HW. > > Could something be worked out using the tags? > I think so! We have the pre-defined environment variable CI_MERGE_REQUEST_LABELS, and we can do variable conditions: https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables That sounds like a pretty neat middle-ground to me. I just hope that new pipelines are triggered if new labels are added, because not everyone is allowed to set labels, and sometimes people forget... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Friday 2020-02-28 08:59, Daniel Stone wrote: > >I believe that in January, we had $2082 of network cost (almost >entirely egress; ingress is basically free) and $1750 of >cloud-storage cost (almost all of which was download). That's based >on 16TB of cloud-storage (CI artifacts, container images, file >uploads, Git LFS) egress and 17.9TB of other egress (the web service >itself, repo activity). Projecting that out [×12 for a year] gives >us roughly $45k of network activity alone, I had come to a similar conclusion a few years back: It is not very economic to run ephemereal buildroots (and anything like it) between two (or more) "significant locations" of which one end is located in a Large Cloud datacenter like EC2/AWS/etc. As for such usecases, me and my surrounding peers have used (other) offerings where there is 50 TB free network/month, and yes that may have entailed doing more adminning than elsewhere - but an admin appreciates $2000 a lot more than a corporation, too. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Thu, 27 Feb 2020 22:27:04 +0100 Daniel Vetter said: Might I suggest that given the kind of expenses detailed here, literally buying 1 - 4 reasonably specced boxes and hosting them at OSUOSL would be incredibly cheaper? (we (enlightenment.org) have been doing so for years on a single box). We farm out CI to travis via gihub mirrors as it's not considered an essential core service (unlike mailing lists, git, phabricator whch nwe still run - we can live without CI for a while and find other ways). The cost is the odd HDD replacement every few years and maybe every 10y or so a new box. That's a massively lower cost than you are quoting below. OSUOSL provide bandwidth, power, rack space etc. for free. They have been fantastic IMHO and the whole "no fat bills" is awesome and you get a full system to set up any way you like. You just bring the box. That should drop cost through the floor. It will require some setup and admin though. > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This especially includes all the > CI integration. Modern development process and tooling, yay! > > The bad news: The cost in growth has also been tremendous, and it's > breaking our bank account. With reasonable estimates for continued > growth we're expecting hosting expenses totalling 75k USD this year, > and 90k USD next year. With the current sponsors we've set up we can't > sustain that. We estimate that hosting expenses for gitlab.fd.o > without any of the CI features enabled would total 30k USD, which is > within X.org's ability to support through various sponsorships, mostly > through XDC. > > Note that X.org does no longer sponsor any CI runners themselves, > we've stopped that. The huge additional expenses are all just in > storing and serving build artifacts and images to outside CI runners > sponsored by various companies. A related topic is that with the > growth in fd.o it's becoming infeasible to maintain it all on > volunteer admin time. X.org is therefore also looking for admin > sponsorship, at least medium term. > > Assuming that we want cash flow reserves for one year of gitlab.fd.o > (without CI support) and a trimmed XDC and assuming no sponsor payment > meanwhile, we'd have to cut CI services somewhere between May and June > this year. The board is of course working on acquiring sponsors, but > filling a shortfall of this magnitude is neither easy nor quick work, > and we therefore decided to give an early warning as soon as possible. > Any help in finding sponsors for fd.o is very much appreciated. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > xorg-de...@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, 2020-02-28 at 10:43 +, Daniel Stone wrote: > On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund > wrote: > > On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote: > > > Yeah, changes on vulkan drivers or backend compilers should be > > > fairly > > > sandboxed. > > > > > > We also have tools that only work for intel stuff, that should > > > never > > > trigger anything on other people's HW. > > > > > > Could something be worked out using the tags? > > > > I think so! We have the pre-defined environment variable > > CI_MERGE_REQUEST_LABELS, and we can do variable conditions: > > > > https://docs.gitlab.com/ee/ci/yaml/#onlyvariablesexceptvariables > > > > That sounds like a pretty neat middle-ground to me. I just hope > > that > > new pipelines are triggered if new labels are added, because not > > everyone is allowed to set labels, and sometimes people forget... > > There's also this which is somewhat more robust: > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569 > > I'm not sure it's more robust, but yeah that a useful tool too. The reason I'm skeptical about the robustness is that we'll miss testing if this misses a path. That can of course be fixed by testing everything once things are in master, and fixing up that list when something breaks on master. The person who wrote a change knows more about the intricacies of the changes than a computer will ever do. But humans are also good at making mistakes, so I'm not sure which one is better. Maybe the union of both? As long as we have both rigorous testing after something landed in master (doesn't nessecarily need to happen right after, but for now that's probably fine), as well as a reasonable heuristic for what testing is needed pre-merge, I think we're good. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, 2020-02-28 at 10:47 +0100, Daniel Vetter wrote: > On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund > wrote: > > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter < > > > daniel.vet...@ffwll.ch> > > > wrote: > > > > Hi all, > > > > > > > > You might have read the short take in the X.org board meeting > > > > minutes > > > > already, here's the long version. > > > > > > > > The good news: gitlab.fd.o has become very popular with our > > > > communities, and is used extensively. This especially includes > > > > all > > > > the > > > > CI integration. Modern development process and tooling, yay! > > > > > > > > The bad news: The cost in growth has also been tremendous, and > > > > it's > > > > breaking our bank account. With reasonable estimates for > > > > continued > > > > growth we're expecting hosting expenses totalling 75k USD this > > > > year, > > > > and 90k USD next year. With the current sponsors we've set up > > > > we > > > > can't > > > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > > > without any of the CI features enabled would total 30k USD, > > > > which > > > > is > > > > within X.org's ability to support through various sponsorships, > > > > mostly > > > > through XDC. > > > > > > > > Note that X.org does no longer sponsor any CI runners > > > > themselves, > > > > we've stopped that. The huge additional expenses are all just > > > > in > > > > storing and serving build artifacts and images to outside CI > > > > runners > > > > sponsored by various companies. A related topic is that with > > > > the > > > > growth in fd.o it's becoming infeasible to maintain it all on > > > > volunteer admin time. X.org is therefore also looking for admin > > > > sponsorship, at least medium term. > > > > > > > > Assuming that we want cash flow reserves for one year of > > > > gitlab.fd.o > > > > (without CI support) and a trimmed XDC and assuming no sponsor > > > > payment > > > > meanwhile, we'd have to cut CI services somewhere between May > > > > and > > > > June > > > > this year. The board is of course working on acquiring > > > > sponsors, > > > > but > > > > filling a shortfall of this magnitude is neither easy nor quick > > > > work, > > > > and we therefore decided to give an early warning as soon as > > > > possible. > > > > Any help in finding sponsors for fd.o is very much appreciated. > > > > > > a) Ouch. > > > > > > b) we probably need to take a large step back here. > > > > > > > I kinda agree, but maybe the step doesn't have to be *too* large? > > > > I wonder if we could solve this by restructuring the project a bit. > > I'm > > talking purely from a Mesa point of view here, so it might not > > solve > > the full problem, but: > > > > 1. It feels silly that we need to test changes to e.g the i965 > > driver > > on dragonboards. We only have a big "do not run CI at all" escape- > > hatch. > > > > 2. A lot of us are working for a company that can probably pay for > > their own needs in terms of CI. Perhaps moving some costs "up > > front" to > > the company that needs it can make the future of CI for those who > > can't > > do this > > > > 3. I think we need a much more detailed break-down of the cost to > > make > > educated changes. For instance, how expensive is Docker image > > uploads/downloads (e.g intermediary artifacts) compared to build > > logs > > and final test-results? What kind of artifacts? > > We have logs somewhere, but no one yet got around to analyzing that. > Which will be quite a bit of work to do since the cloud storage is > totally disconnected from the gitlab front-end, making the connection > to which project or CI job caused something is going to require > scripting. Volunteers definitely very much welcome I think. > Fair enough, but just keep in mind that the same thing as optimizing software applies here; working blindly reduces the impact. So if we want to fix the current situation, this is going to have to be a priority, I think. > > One suggestion would be to do something more similar to what the > > kernel > > does, and separate into different repos for different subsystems. > > This > > could allow us to have separate testing-pipelines for these repos, > > which would mean that for instance a change to RADV didn't trigger > > a > > full Panfrost test-run. > > Uh as someone who lives the kernel multi-tree model daily, there's a > _lot_ of pain involved. Could you please elaborate a bit? We're not the kernel, so I'm not sure all of the kernel-pains apply to us. But we probably have other pains as well ;-) But yeah, it might be better to take smaller steps first, and see if that helps. > I think much better to look at filtering out > CI targets for when nothing relevant happened. But that gets somewhat > tricky, since "nothing relevant" is always only relative to some > baseline, so bit of scripting and all involved to make sure you don't > run stuff too
[Intel-gfx] [PATCH v2 13/13] drm/i915: Unify the DPLL ref clock frequency tracking
All platforms using the shared DPLL framework use 3 reference clocks for
their DPLLs: SSC, non-SSC and DSI. For a more unified way across
platforms store the frequency of these ref clocks as part of the DPLL
global state. This also allows us to keep the HW access reading out the
ref clock value separate from the DPLL frequency calculation that
depends on the ref clock.
For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code
has its own logic for calculating DPLL parameters instead of the shared
DPLL framework.
v2:
- Apply the ICL combo PHY PLL ref_clock/2 adjustment during the
frequency->PLL param conversion direction as well. (CI shards)
- s/kHZ/kHz/ (Ville)
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 5 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 175 --
drivers/gpu/drm/i915/i915_drv.h | 5 +
3 files changed, 129 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d2461d7946bf..1e6eb7f2f72d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -920,6 +920,11 @@ static int i915_shared_dplls_info(struct seq_file *m, void
*unused)
int i;
drm_modeset_lock_all(dev);
+
+ seq_printf(m, "PLL refclks: non-SSC: %d kHz, SSC: %d kHz\n",
+ dev_priv->dpll.ref_clks.nssc,
+ dev_priv->dpll.ref_clks.ssc);
+
for (i = 0; i < dev_priv->dpll.num_shared_dpll; i++) {
struct intel_shared_dpll *pll = _priv->dpll.shared_dplls[i];
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index 7e6da58a47c9..76d14486b3a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -56,6 +56,7 @@ struct intel_dpll_mgr {
void (*update_active_dpll)(struct intel_atomic_state *state,
struct intel_crtc *crtc,
struct intel_encoder *encoder);
+ void (*update_ref_clks)(struct drm_i915_private *i915);
void (*dump_hw_state)(struct drm_i915_private *dev_priv,
const struct intel_dpll_hw_state *hw_state);
};
@@ -886,16 +887,9 @@ static int hsw_ddi_wrpll_get_freq(struct drm_i915_private
*dev_priv,
switch (wrpll & WRPLL_REF_MASK) {
case WRPLL_REF_SPECIAL_HSW:
- /*
-* muxed-SSC for BDW.
-* non-SSC for non-ULT HSW. Check FUSE_STRAP3
-* for the non-SSC reference frequency.
-*/
+ /* Muxed-SSC for BDW, non-SSC for non-ULT HSW. */
if (IS_HASWELL(dev_priv) && !IS_HSW_ULT(dev_priv)) {
- if (intel_de_read(dev_priv, FUSE_STRAP3) &
HSW_REF_CLK_SELECT)
- refclk = 24;
- else
- refclk = 135;
+ refclk = dev_priv->dpll.ref_clks.nssc;
break;
}
/* fall through */
@@ -905,10 +899,10 @@ static int hsw_ddi_wrpll_get_freq(struct drm_i915_private
*dev_priv,
* code only cares about 5% accuracy, and spread is a max of
* 0.5% downspread.
*/
- refclk = 135;
+ refclk = dev_priv->dpll.ref_clks.ssc;
break;
case WRPLL_REF_LCPLL:
- refclk = 2700;
+ refclk = 270;
break;
default:
MISSING_CASE(wrpll);
@@ -920,7 +914,7 @@ static int hsw_ddi_wrpll_get_freq(struct drm_i915_private
*dev_priv,
n = (wrpll & WRPLL_DIVIDER_FB_MASK) >> WRPLL_DIVIDER_FB_SHIFT;
/* Convert to KHz, p & r have a fixed point portion */
- return (refclk * n * 100) / (p * r) * 2;
+ return (refclk * n / 10) / (p * r) * 2;
}
static struct intel_shared_dpll *
@@ -1049,6 +1043,16 @@ static bool hsw_get_dpll(struct intel_atomic_state
*state,
return true;
}
+static void hsw_update_dpll_ref_clks(struct drm_i915_private *i915)
+{
+ i915->dpll.ref_clks.ssc = 135000;
+ /* Non-SSC is only used on non-ULT HSW. */
+ if (intel_de_read(i915, FUSE_STRAP3) & HSW_REF_CLK_SELECT)
+ i915->dpll.ref_clks.nssc = 24000;
+ else
+ i915->dpll.ref_clks.nssc = 135000;
+}
+
static void hsw_dump_hw_state(struct drm_i915_private *dev_priv,
const struct intel_dpll_hw_state *hw_state)
{
@@ -1108,6 +1112,7 @@ static const struct intel_dpll_mgr hsw_pll_mgr = {
.dpll_info = hsw_plls,
.get_dplls = hsw_get_dpll,
.put_dplls = intel_put_dpll,
+ .update_ref_clks = hsw_update_dpll_ref_clks,
.dump_hw_state =
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Some upside-down panel handling fixes
== Series Details ==
Series: drm/i915: Some upside-down panel handling fixes
URL : https://patchwork.freedesktop.org/series/74076/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3da5c24d3382 drm/i915/dsi: Remove readback of panel orientation on BYT / CHT
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'Commit 82daca297506 ("drm/i915: Add
"panel orientation" property to the panel connector, v6.")'
#10:
Commit 82daca297506 ("drm/i915: Add "panel orientation" property to the
total: 1 errors, 0 warnings, 0 checks, 67 lines checked
91740cf1d41c drm/i915/dp: Use BDB_GENERAL_FEATURES VBT block info for builtin
panel-orientation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/24] drm/i915/selftests: Wait for the kernel context switch
Quoting Mika Kuoppala (2020-02-28 15:09:28)
> Chris Wilson writes:
>
> > As we require a context switch to ensure that the current context is
> > switched out and saved to memory, perform an explicit switch to the
> > kernel context and wait for it.
>
> The patch subject is not incorrect. Just feels that the kernel
> context is a patsy in here.
>
> So I would s/kernel// on subject but keep in commit msg
>
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 37 +++---
> > 1 file changed, 28 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > index d7f98aada626..95da6b880e3f 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > @@ -4015,6 +4015,31 @@ static int emit_semaphore_signal(struct
> > intel_context *ce, void *slot)
> > return 0;
> > }
> >
> > +static int context_sync(struct intel_context *ce)
> > +{
> > + struct i915_request *rq;
> > + struct dma_fence *fence;
> > + int err = 0;
> > +
> > + rq = intel_engine_create_kernel_request(ce->engine);
> > + if (IS_ERR(rq))
> > + return PTR_ERR(rq);
> > +
> > + fence = i915_active_fence_get(>timeline->last_request);
> > + if (fence) {
> > + i915_request_await_dma_fence(rq, fence);
> > + dma_fence_put(fence);
> > + }
> > +
> > + rq = i915_request_get(rq);
> > + i915_request_add(rq);
> > + if (i915_request_wait(rq, 0, HZ / 2) < 0)
> > + err = -ETIME;
> > + i915_request_put(rq);
> > +
> > + return err;
> > +}
> > +
> > static int live_lrc_layout(void *arg)
> > {
> > struct intel_gt *gt = arg;
> > @@ -4638,16 +4663,10 @@ static int __lrc_timestamp(const struct
> > lrc_timestamp *arg, bool preempt)
> > wmb();
> > }
> >
> > - if (i915_request_wait(rq, 0, HZ / 2) < 0) {
> > - err = -ETIME;
> > - goto err;
> > - }
> > -
> > - /* and wait for switch to kernel */
> > - if (igt_flush_test(arg->engine->i915)) {
> > - err = -EIO;
> > + /* and wait for switch to kernel (to save our context to memory) */
> > + err = context_sync(arg->ce[0]);
> > + if (err)
> > goto err;
> > - }
> >
> > rmb();
>
> For me the context_sync could be context_flush and it would
> allow the rmb() to be snuck inside.
I hear you. The rmb() is really associated with the action of confirming
the switch and can justifiably be inside the context_sync/flush.
The rmb is just there to placate inner daemons, so I didn't think about
it when forcing the emission of the kernel request.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/24] drm/i915/selftests: Wait for the kernel context switch
Chris Wilson writes:
> As we require a context switch to ensure that the current context is
> switched out and saved to memory, perform an explicit switch to the
> kernel context and wait for it.
The patch subject is not incorrect. Just feels that the kernel
context is a patsy in here.
So I would s/kernel// on subject but keep in commit msg
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 37 +++---
> 1 file changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index d7f98aada626..95da6b880e3f 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -4015,6 +4015,31 @@ static int emit_semaphore_signal(struct intel_context
> *ce, void *slot)
> return 0;
> }
>
> +static int context_sync(struct intel_context *ce)
> +{
> + struct i915_request *rq;
> + struct dma_fence *fence;
> + int err = 0;
> +
> + rq = intel_engine_create_kernel_request(ce->engine);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + fence = i915_active_fence_get(>timeline->last_request);
> + if (fence) {
> + i915_request_await_dma_fence(rq, fence);
> + dma_fence_put(fence);
> + }
> +
> + rq = i915_request_get(rq);
> + i915_request_add(rq);
> + if (i915_request_wait(rq, 0, HZ / 2) < 0)
> + err = -ETIME;
> + i915_request_put(rq);
> +
> + return err;
> +}
> +
> static int live_lrc_layout(void *arg)
> {
> struct intel_gt *gt = arg;
> @@ -4638,16 +4663,10 @@ static int __lrc_timestamp(const struct lrc_timestamp
> *arg, bool preempt)
> wmb();
> }
>
> - if (i915_request_wait(rq, 0, HZ / 2) < 0) {
> - err = -ETIME;
> - goto err;
> - }
> -
> - /* and wait for switch to kernel */
> - if (igt_flush_test(arg->engine->i915)) {
> - err = -EIO;
> + /* and wait for switch to kernel (to save our context to memory) */
> + err = context_sync(arg->ce[0]);
> + if (err)
> goto err;
> - }
>
> rmb();
For me the context_sync could be context_flush and it would
allow the rmb() to be snuck inside.
But I seem to gravitate towards lower resolution and
apparently you prefer to be more fine grained and
explicit on callsites so,
Reviewed-by: Mika Kuoppala
>
> --
> 2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
