[Intel-gfx] [PATCH] drm/i915/gem: Don't try to map and fence 8K/bigjoiner scanout buffers
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without the mappable flag. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event is 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 11 +--
drivers/gpu/drm/i915/display/intel_overlay.c | 11 ---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 ++-
4 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index 3f77f3013584..53c156d9a9f9 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -144,7 +144,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
if (!ret) {
vma = i915_gem_object_pin_to_display_plane(obj, &ww, alignment,
- view, pinctl);
+ view, pinctl,
uses_fence);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
goto err_unpin;
@@ -218,9 +218,16 @@ int intel_plane_pin_fb(struct intel_plane_state
*plane_state)
INTEL_INFO(dev_priv)->display.cursor_needs_physical;
if (!intel_fb_uses_dpt(fb)) {
+ struct intel_crtc *crtc = to_intel_crtc(plane_state->hw.crtc);
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+ bool uses_fence = intel_plane_uses_fence(plane_state);
+ bool is_bigjoiner = crtc_state->bigjoiner ||
+ crtc_state->bigjoiner_slave;
+
vma = intel_pin_and_fence_fb_obj(fb, phys_cursor,
&plane_state->view.gtt,
-
intel_plane_uses_fence(plane_state),
+uses_fence && !is_bigjoiner,
&plane_state->flags);
if (IS_ERR(vma))
return PTR_ERR(vma);
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 7e3f5c6ca484..e9563b40b911 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -755,10 +755,14 @@ static u32 overlay_cmd_reg(struct
drm_intel_overlay_put_image *params)
return cmd;
}
-static struct i915_vma *intel_overlay_pin_fb(struct drm_i915_gem_object
*new_bo)
+static struct i915_vma *intel_overlay_pin_fb(struct drm_i915_gem_object
*new_bo,
+struct intel_overlay *overlay)
{
struct i915_gem_ww_ctx ww;
struct i915_vma *vma;
+ const struct intel_plane_state *plane_state =
+ to_intel_plane_state(overlay->crtc->base.primary->state);
+ bool uses_fence = intel_plane_uses_fence(plane_state);
int ret
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Remove check for low voltage sku for max dp source rate (rev4)
== Series Details == Series: drm/i915/display: Remove check for low voltage sku for max dp source rate (rev4) URL : https://patchwork.freedesktop.org/series/95444/ State : success == Summary == CI Bug Log - changes from CI_DRM_10788 -> Patchwork_21441 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/index.html Participating hosts (39 -> 34) -- Missing(5): fi-tgl-dsi bat-dg1-6 fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 Known issues Here are the changes found in Patchwork_21441 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][2] ([fdo#109271]) +27 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][3] -> [INCOMPLETE][4] ([i915#2940]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10788/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [PASS][6] -> [FAIL][7] ([i915#4165]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10788/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [PASS][8] -> [DMESG-WARN][9] ([i915#295]) +18 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10788/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html * igt@runner@aborted: - fi-bsw-n3050: NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#1436] / [i915#3428] / [i915#4312]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-bsw-n3050/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-bdw-5557u: [INCOMPLETE][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10788/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][13] ([i915#2940]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10788/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428 [i915#4165]: https://gitlab.freedesktop.org/drm/intel/issues/4165 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 Build changes - * Linux: CI_DRM_10788 -> Patchwork_21441 CI-20190529: 20190529 CI_DRM_10788: e5d0af998bc3f67620833aa9a6acb06b3e01 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6261: 0433f0d6063d8450af1e8518047d3679b9e5a6c1 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21441: 016eabc98af5b08ee7859a5907701a03dde85847 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 016eabc98af5 drm/i915/display: Remove check for low voltage sku for max dp source rate == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21441/index.html
[Intel-gfx] [PATCH] drm/i915/display: Remove check for low voltage sku for max dp source rate
The low voltage sku check can be ignored as OEMs need to consider that
when designing the board and then put any limits in VBT.
Same is now changed in Bspec pages.
v2: Added debug print for combo PHY procmon reference values
to get voltage configuration of combo PHY ports. (Imre)
Signed-off-by: Ankit Nautiyal
---
.../gpu/drm/i915/display/intel_combo_phy.c| 4 +++
drivers/gpu/drm/i915/display/intel_dp.c | 32 ++-
2 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 634e8d449457..01ff86b3ff91 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -112,6 +112,10 @@ static bool icl_verify_procmon_ref_values(struct
drm_i915_private *dev_priv,
procmon = icl_get_procmon_ref_values(dev_priv, phy);
+ drm_dbg(&dev_priv->drm,
+ "Combo PHY %c PROCMON values : 0x%x, 0x%x, 0x%x\n",
+ phy_name(phy), procmon->dw1, procmon->dw9, procmon->dw10);
+
ret = check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW1(phy),
(0xff << 16) | 0xff, procmon->dw1);
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW9(phy),
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f5dc2126d140..693d7e097295 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -385,23 +385,13 @@ static int dg2_max_source_rate(struct intel_dp *intel_dp)
return intel_dp_is_edp(intel_dp) ? 81 : 135;
}
-static bool is_low_voltage_sku(struct drm_i915_private *i915, enum phy phy)
-{
- u32 voltage;
-
- voltage = intel_de_read(i915, ICL_PORT_COMP_DW3(phy)) &
VOLTAGE_INFO_MASK;
-
- return voltage == VOLTAGE_INFO_0_85V;
-}
-
static int icl_max_source_rate(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
enum phy phy = intel_port_to_phy(dev_priv, dig_port->base.port);
- if (intel_phy_is_combo(dev_priv, phy) &&
- (is_low_voltage_sku(dev_priv, phy) || !intel_dp_is_edp(intel_dp)))
+ if (intel_phy_is_combo(dev_priv, phy) && !intel_dp_is_edp(intel_dp))
return 54;
return 81;
@@ -409,23 +399,7 @@ static int icl_max_source_rate(struct intel_dp *intel_dp)
static int ehl_max_source_rate(struct intel_dp *intel_dp)
{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
- enum phy phy = intel_port_to_phy(dev_priv, dig_port->base.port);
-
- if (intel_dp_is_edp(intel_dp) || is_low_voltage_sku(dev_priv, phy))
- return 54;
-
- return 81;
-}
-
-static int dg1_max_source_rate(struct intel_dp *intel_dp)
-{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
-
- if (intel_phy_is_combo(i915, phy) && is_low_voltage_sku(i915, phy))
+ if (intel_dp_is_edp(intel_dp))
return 54;
return 81;
@@ -468,7 +442,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
max_rate = dg2_max_source_rate(intel_dp);
else if (IS_ALDERLAKE_P(dev_priv) || IS_ALDERLAKE_S(dev_priv) ||
IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
- max_rate = dg1_max_source_rate(intel_dp);
+ max_rate = 81;
else if (IS_JSL_EHL(dev_priv))
max_rate = ehl_max_source_rate(intel_dp);
else
--
2.25.1
[Intel-gfx] [PULL] topic/amdgpu-dp2.0-mst
topic/amdgpu-dp2.0-mst-2021-10-25: UAPI Changes: Nope! Cross-subsystem Changes: drm_dp_update_payload_part1() takes a new argument for specifying what the VCPI slot start is Core Changes: Make the DP MST helpers aware of the current starting VCPI slot/VCPI total slot count... Driver Changes: ...and then add support for taking advantage of this for 128b/132b links on DP 2.0 for amdgpu The following changes since commit 6f2f7c83303d2227f47551423e507d77d9ea01c7: Merge tag 'drm-intel-gt-next-2021-10-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-10-22 06:30:34 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/topic/amdgpu-dp2.0-mst-2021- 10-25 for you to fetch changes up to 41724ea273cdda5261db4fabd6bfb1375fbc96b2: drm/amd/display: Add DP 2.0 MST DM Support (2021-10-25 21:21:09 -0400) UAPI Changes: Nope! Cross-subsystem Changes: drm_dp_update_payload_part1() takes a new argument for specifying what the VCPI slot start is Core Changes: Make the DP MST helpers aware of the current starting VCPI slot/VCPI total slot count... Driver Changes: ...and then add support for taking advantage of this for 128b/132b links on DP 2.0 for amdgpu Bhawanpreet Lakha (3): drm: Remove slot checks in dp mst topology during commit drm: Update MST First Link Slot Information Based on Encoding Format drm/amd/display: Add DP 2.0 MST DM Support Fangzhi Zuo (1): drm/amd/display: Add DP 2.0 MST DC Support drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 ++ .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 + .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 5 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 14 + drivers/gpu/drm/amd/display/dc/core/dc_link.c | 292 + drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++ drivers/gpu/drm/amd/display/dc/dc_link.h | 7 + drivers/gpu/drm/amd/display/dc/dc_stream.h | 13 + drivers/gpu/drm/drm_dp_mst_topology.c | 42 ++- drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- drivers/gpu/drm/radeon/radeon_dp_mst.c | 4 +- include/drm/drm_dp_mst_helper.h | 5 +- 13 files changed, 423 insertions(+), 16 deletions(-)
Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.
On Wed, Oct 13, 2021 at 02:12:20PM -0400, Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> or Degamma props in the new CRTC state, allowing any invalid size to
> be passed on.
> 2. Each driver has its own LUT size, which could also be different for
> legacy users.
>
> [How]
> 1. Create |degamma_lut_size| and |gamma_lut_size| to save the LUT sizes
> assigned by the driver when it's initializing its color and CTM
> management.
> 2. Create drm_atomic_helper_check_crtc which is called by
> drm_atomic_helper_check to check the LUT sizes saved in drm_crtc that
> they match the sizes in the new CRTC state.
> 3. Rename older lut checks that test for the color channels to indicate
> it's a channel check. It's not included in drm_atomic_helper_check_crtc
> as it's hardware specific and is to be called by the driver.
> 4. As the LUT size check now happens in drm_atomic_helper_check, remove
> the lut check in intel_color.c
I'd probably split the rename out from the crtc check since they're only
tangentially related.
>
> Fixes: igt@kms_color@pipe-A-invalid-gamma-lut-sizes on MTK
> Tested on Zork(amdgpu) and Jacuzzi(mediatek), volteer(TGL)
>
> v1:
> 1. Fix typos
> 2. Remove the LUT size check from intel driver
> 3. Rename old LUT check to indicate it's a channel change
>
> Signed-off-by: Mark Yacoub
> ---
> drivers/gpu/drm/drm_atomic_helper.c| 60 ++
> drivers/gpu/drm/drm_color_mgmt.c | 14 ++---
> drivers/gpu/drm/i915/display/intel_color.c | 14 ++---
> include/drm/drm_atomic_helper.h| 1 +
> include/drm/drm_color_mgmt.h | 7 +--
> include/drm/drm_crtc.h | 11
> 6 files changed, 89 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index bc3487964fb5e..5feb2ad0209c3 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -929,6 +929,62 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_atomic_helper_check_planes);
>
> +/**
> + * drm_atomic_helper_check_crtcs - validate state object for CRTC changes
> + * @state: the driver state object
> + *
> + * Check the CRTC state object such as the Gamma/Degamma LUT sizes if the new
> + * state holds them.
> + *
> + * RETURNS:
> + * Zero for success or -errno
> + */
> +int drm_atomic_helper_check_crtcs(struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *new_crtc_state;
> + int i;
> +
> + for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->color_mgmt_changed &&
> + new_crtc_state->gamma_lut) {
> + uint64_t supported_lut_size = crtc->gamma_lut_size;
> + uint32_t supported_legacy_lut_size = crtc->gamma_size;
> + uint32_t new_state_lut_size =
> + drm_color_lut_size(new_crtc_state->gamma_lut);
> +
> + if (new_state_lut_size != supported_lut_size &&
> + new_state_lut_size != supported_legacy_lut_size) {
> + drm_dbg_state(
> + state->dev,
> + "Invalid Gamma LUT size. Should be %u
> (or %u for legacy) but got %u.\n",
> + supported_lut_size,
> + supported_legacy_lut_size,
> + new_state_lut_size);
> + return -EINVAL;
> + }
> + }
> +
> + if (new_crtc_state->color_mgmt_changed &&
> + new_crtc_state->degamma_lut) {
> + uint32_t new_state_lut_size =
> + drm_color_lut_size(new_crtc_state->degamma_lut);
> + uint64_t supported_lut_size = crtc->degamma_lut_size;
> +
> + if (new_state_lut_size != supported_lut_size) {
> + drm_dbg_state(
> + state->dev,
> + "Invalid Degamma LUT size. Should be %u
> but got %u.\n",
> + supported_lut_size, new_state_lut_size);
> + return -EINVAL;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_check_crtcs);
> +
> /**
> * drm_atomic_helper_check - validate state object
> * @dev: DRM device
> @@ -974,6 +1030,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> + ret = drm_atomic_helper_check_crtcs(state);
> + if (ret)
> + return ret;
> +
> if (state->legacy_cursor_update)
> state->async_updat
Re: [Intel-gfx] [PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
On Mon, 25 Oct 2021 at 23:51, Daniel Vetter wrote: > > On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen > wrote: > > > > Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver. > > Tvrtko will bring added bandwidth and focus to the GT/GEM domain > > (drm-intel-gt-next). > > > > This will help with the increased driver maintenance efforts, allows > > alternating the drm-intel-gt-next pull requests and also should increase > > the coverage for the maintenance in general. > > > > Signed-off-by: Joonas Lahtinen > > Cc: David Airlie > > Cc: Daniel Vetter > > Acked-by: Jani Nikula > > Acked-by: Rodrigo Vivi > > Acked-by: Tvrtko Ursulin > > Cc: Sean Paul > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: dri-de...@lists.freedesktop.org > > Acked-by: Daniel Vetter Acked-by: Dave Airlie
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/trace: Hide backend specific fields behind Kconfig
== Series Details == Series: drm/i915/trace: Hide backend specific fields behind Kconfig URL : https://patchwork.freedesktop.org/series/96258/ State : success == Summary == CI Bug Log - changes from CI_DRM_10787_full -> Patchwork_21440_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21440_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][1] ([i915#2842]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][2] -> [FAIL][3] ([i915#2842]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/shard-iclb6/igt@gem_exec_fair@basic-pace-s...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-iclb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-skl10/igt@gem_huc_c...@huc-copy.html * igt@gem_userptr_blits@dmabuf-sync: - shard-skl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3323]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-skl10/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1436] / [i915#716]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/shard-skl3/igt@gen9_exec_pa...@allowed-single.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-skl9/igt@gen9_exec_pa...@allowed-single.html * igt@i915_module_load@reload-no-display: - shard-iclb: [PASS][10] -> [DMESG-WARN][11] ([i915#2867]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/shard-iclb6/igt@i915_module_l...@reload-no-display.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-iclb2/igt@i915_module_l...@reload-no-display.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#454]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/shard-iclb7/igt@i915_pm...@dc6-dpms.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-iclb3/igt@i915_pm...@dc6-dpms.html - shard-skl: NOTRUN -> [FAIL][14] ([i915#454]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-skl4/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1937]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-kbl4/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271]) +10 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-apl7/igt@i915_pm_...@modeset-lpsp-stress.html * igt@i915_selftest@live@gt_pm: - shard-skl: NOTRUN -> [DMESG-FAIL][17] ([i915#1886] / [i915#2291]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-skl4/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - shard-snb: [PASS][18] -> [INCOMPLETE][19] ([i915#3921]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/shard-snb2/igt@i915_selftest@l...@hangcheck.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-snb6/igt@i915_selftest@l...@hangcheck.html * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip: - shard-skl: NOTRUN -> [FAIL][20] ([i915#3743]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-skl4/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip: - shard-skl: NOTRUN -> [FAIL][21] ([i915#3763]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/shard-skl10/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html * igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#3886]) +2 similar issues [22]: https://intel-g
[Intel-gfx] [PATCH RESEND v5 2/4] drm: Update MST First Link Slot Information Based on Encoding Format
From: Bhawanpreet Lakha
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.
v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check
v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
atomic drivers (this is a temporary workaround and should be removed when
we are moving out the non atomic driver helpers)
v4:
*fixed typo and formatting
v5: (no functional changes)
* Fixed formatting in drm_dp_mst_update_slots()
* Reference mst_state instead of mst_state->mgr for debugging info
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
[v5 nitpicks]
Reviewed-by: Lyude Paul
Signed-off-by: Lyude Paul
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c| 4 +--
include/drm/drm_dp_mst_helper.h | 5 ++-
6 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ff0f91c93ba4..6169488e2011 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
/* It's OK for this to fail */
- drm_dp_update_payload_part1(mst_mgr);
+ drm_dp_update_payload_part1(mst_mgr, 1);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04ed34a7f71c..571da0c2f39f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3355,6 +3355,10 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
/**
* drm_dp_update_payload_part1() - Execute payload update part 1
* @mgr: manager to use.
+ * @start_slot: this is the cur slot
+ *
+ * NOTE: start_slot is a temporary workaround for non-atomic drivers,
+ * this will be removed when non-atomic mst helpers are moved out of the helper
*
* This iterates over all proposed virtual channels, and tries to
* allocate space in the link for them. For 0->slots transitions,
@@ -3365,12 +3369,12 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
* after calling this the driver should generate ACT and payload
* packets.
*/
-int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
+int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int
start_slot)
{
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
int i, j;
- int cur_slots = 1;
+ int cur_slots = start_slot;
bool skip;
mutex_lock(&mgr->payload_lock);
@@ -4505,6 +4509,27 @@ int drm_dp_atomic_release_vcpi_slots(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+/**
+ * drm_dp_mst_update_slots() - updates the slot info depending on the DP
ecoding format
+ * @mst_state: mst_state to update
+ * @link_encoding_cap: the ecoding format on the link
+ */
+void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state,
uint8_t link_encoding_cap)
+{
+ if (link_encoding_cap == DP_CAP_ANSI_128B132B) {
+ mst_state->total_avail_slots = 64;
+ mst_state->start_slot = 0;
+ } else {
+ mst_state->total_avail_slots = 63;
+ mst_state->start_slot = 1;
+ }
+
+ DRM_DEBUG_KMS("%s encoding format on mst_state 0x%p\n",
+ (link_encoding_cap == DP_CAP_ANSI_128B132B) ?
"128b/132b":"8b/10b",
+ mst_state);
+}
+EXPORT_SYMBOL(drm_dp_mst_update_slots);
+
/**
* drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
* @mgr: manager for this port
@@ -5224,7 +5249,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63, payload_count = 0;
+ int avail_slots = mst_state->total_avail_slots, payload_count = 0;
list_for_each_entry(vcpi, &mst_state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -5253,7 +5278,7 @@ dr
[Intel-gfx] [PATCH v5 2/4] drm: Update MST First Link Slot Information Based on Encoding Format
From: Bhawanpreet Lakha
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.
v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check
v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
atomic drivers (this is a temporary workaround and should be removed when
we are moving out the non atomic driver helpers)
v4:
*fixed typo and formatting
v5: (no functional changes)
* Fixed formatting in drm_dp_mst_update_slots()
* Reference mst_state instead of mst_state->mgr for debugging info
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
[v5 nitpicks]
Reviewed-by: Lyude Paul
Signed-off-by: Lyude Paul
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 36 ---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c| 4 +--
include/drm/drm_dp_mst_helper.h | 5 ++-
6 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index ff0f91c93ba4..6169488e2011 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -251,7 +251,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
}
/* It's OK for this to fail */
- drm_dp_update_payload_part1(mst_mgr);
+ drm_dp_update_payload_part1(mst_mgr, 1);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04ed34a7f71c..571da0c2f39f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3355,6 +3355,10 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
/**
* drm_dp_update_payload_part1() - Execute payload update part 1
* @mgr: manager to use.
+ * @start_slot: this is the cur slot
+ *
+ * NOTE: start_slot is a temporary workaround for non-atomic drivers,
+ * this will be removed when non-atomic mst helpers are moved out of the helper
*
* This iterates over all proposed virtual channels, and tries to
* allocate space in the link for them. For 0->slots transitions,
@@ -3365,12 +3369,12 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
* after calling this the driver should generate ACT and payload
* packets.
*/
-int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
+int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr, int
start_slot)
{
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
int i, j;
- int cur_slots = 1;
+ int cur_slots = start_slot;
bool skip;
mutex_lock(&mgr->payload_lock);
@@ -4505,6 +4509,27 @@ int drm_dp_atomic_release_vcpi_slots(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+/**
+ * drm_dp_mst_update_slots() - updates the slot info depending on the DP
ecoding format
+ * @mst_state: mst_state to update
+ * @link_encoding_cap: the ecoding format on the link
+ */
+void drm_dp_mst_update_slots(struct drm_dp_mst_topology_state *mst_state,
uint8_t link_encoding_cap)
+{
+ if (link_encoding_cap == DP_CAP_ANSI_128B132B) {
+ mst_state->total_avail_slots = 64;
+ mst_state->start_slot = 0;
+ } else {
+ mst_state->total_avail_slots = 63;
+ mst_state->start_slot = 1;
+ }
+
+ DRM_DEBUG_KMS("%s encoding format on mst_state 0x%p\n",
+ (link_encoding_cap == DP_CAP_ANSI_128B132B) ?
"128b/132b":"8b/10b",
+ mst_state);
+}
+EXPORT_SYMBOL(drm_dp_mst_update_slots);
+
/**
* drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
* @mgr: manager for this port
@@ -5224,7 +5249,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state
*mst_state)
{
struct drm_dp_vcpi_allocation *vcpi;
- int avail_slots = 63, payload_count = 0;
+ int avail_slots = mst_state->total_avail_slots, payload_count = 0;
list_for_each_entry(vcpi, &mst_state->vcpis, next) {
/* Releasing VCPI is always OK-even if the port is gone */
@@ -5253,7 +5278,7 @@ dr
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms
== Series Details == Series: drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms URL : https://patchwork.freedesktop.org/series/96250/ State : success == Summary == CI Bug Log - changes from CI_DRM_10786_full -> Patchwork_21439_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21439_full that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - shard-tglb: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-tglb7/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-tglb8/igt@core_hotunp...@unbind-rebind.html * igt@drm_mm@all@insert: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#2485]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-skl10/igt@drm_mm@a...@insert.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-skl2/igt@drm_mm@a...@insert.html * igt@gem_ctx_sseu@invalid-sseu: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#280]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-tglb3/igt@gem_ctx_s...@invalid-sseu.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][12] -> [SKIP][13] ([fdo#109271]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_parallel@engines@basic: - shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-glk8/igt@gem_exec_parallel@engi...@basic.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-glk4/igt@gem_exec_parallel@engi...@basic.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-tglb3/igt@gem_huc_c...@huc-copy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-skl4/igt@gem_pr...@exhaustion.html * igt@gem_pxp@create-valid-protected-context: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#4270]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-tglb3/igt@gem_...@create-valid-protected-context.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-kbl3/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][21] ([i915#3002]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-skl10/igt@gem_userptr_bl...@input-checking.html * igt@gen9_exec_parse@bb-start-out: - shard-tglb: NOTRUN -> [SKIP][22] ([i915#2856]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/shard-tglb3/igt@gen9_exec_pa...@bb-start-out.html * igt@i915_selftest@live@hangcheck: - shard-snb: [PASS][23] -> [INCOMPLETE][24] ([i915#3921]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/shard-snb2/igt@i915_selftest@l...@hangcheck.html [24]: htt
Re: [Intel-gfx] [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig
On 10/25/2021 09:34, Matthew Brost wrote:
Hide the guc_id and tail fields, for request trace points, behind
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
are ABI (maybe?) so don't change them without kernel developers Kconfig
options.
The i915 sw arch team have previously hard blocked requests for changes
to trace points from user land tool developers on the grounds that trace
points are not ABI and are free to change at whim as and when the i915
internal implementation changes. They are purely for use of developers
to debug the i915 driver as the i915 driver currently stands at any
given instant.
So I don't see how it can be argued that we must not update any trace
points to allow for debugging of i915 scheduling issues on current
platforms. And having to enable extra config options just to keep
existing higher level trace points usable seems broken.
John.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_trace.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 9795f456cccf..4f5238d02b51 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
__entry->ctx, __entry->seqno, __entry->flags)
);
+#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
DECLARE_EVENT_CLASS(i915_request,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq),
@@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
__entry->guc_id, __entry->ctx, __entry->seqno,
__entry->tail)
);
+#else
+DECLARE_EVENT_CLASS(i915_request,
+ TP_PROTO(struct i915_request *rq),
+ TP_ARGS(rq),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u64, ctx)
+__field(u16, class)
+__field(u16, instance)
+__field(u32, seqno)
+),
+
+ TP_fast_assign(
+ __entry->dev = rq->engine->i915->drm.primary->index;
+ __entry->class = rq->engine->uabi_class;
+ __entry->instance = rq->engine->uabi_instance;
+ __entry->ctx = rq->fence.context;
+ __entry->seqno = rq->fence.seqno;
+ ),
+
+ TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->ctx, __entry->seqno)
+);
+#endif
DEFINE_EVENT(i915_request, i915_request_add,
TP_PROTO(struct i915_request *rq),
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/trace: Hide backend specific fields behind Kconfig
== Series Details ==
Series: drm/i915/trace: Hide backend specific fields behind Kconfig
URL : https://patchwork.freedesktop.org/series/96258/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10787 -> Patchwork_21440
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/index.html
Participating hosts (42 -> 37)
--
Missing(5): bat-dg1-6 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 fi-ctg-p8600
Known issues
Here are the changes found in Patchwork_21440 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][1] ([fdo#109271]) +48 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/fi-pnv-d510/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][2] ([i915#1602] / [i915#2426] /
[i915#4312])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_parallel@engines@userptr:
- fi-pnv-d510:[INCOMPLETE][3] ([i915#299]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html
* igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u: [INCOMPLETE][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/fi-tgl-dsi/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/fi-tgl-dsi/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [DMESG-FAIL][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10787/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#299]: https://gitlab.freedesktop.org/drm/intel/issues/299
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
Build changes
-
* Linux: CI_DRM_10787 -> Patchwork_21440
CI-20190529: 20190529
CI_DRM_10787: d93fcfcb1caac6d1299830be20e5bd5cf8451c71 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6260: 46994310410404a07d142f33fab220d718c27f64 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21440: 621c2565d8e5b7b234c53d9e0dffd1f175437fdc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
621c2565d8e5 drm/i915/trace: Hide backend specific fields behind Kconfig
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21440/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/trace: Hide backend specific fields behind Kconfig
== Series Details ==
Series: drm/i915/trace: Hide backend specific fields behind Kconfig
URL : https://patchwork.freedesktop.org/series/96258/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
621c2565d8e5 drm/i915/trace: Hide backend specific fields behind Kconfig
-:31: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#31: FILE: drivers/gpu/drm/i915/i915_trace.h:822:
+DECLARE_EVENT_CLASS(i915_request,
+ TP_PROTO(struct i915_request *rq),
-:34: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#34: FILE: drivers/gpu/drm/i915/i915_trace.h:825:
+ TP_STRUCT__entry(
-:42: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#42: FILE: drivers/gpu/drm/i915/i915_trace.h:833:
+ TP_fast_assign(
total: 0 errors, 0 warnings, 3 checks, 39 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms
== Series Details ==
Series: drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern
platforms
URL : https://patchwork.freedesktop.org/series/96250/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10786 -> Patchwork_21439
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/index.html
Participating hosts (41 -> 36)
--
Additional (1): fi-tgl-1115g4
Missing(6): bat-dg1-6 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 fi-ctg-p8600
fi-pnv-d510
Known issues
Here are the changes found in Patchwork_21439 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@query-info:
- fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([fdo#109315])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html
* igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4: NOTRUN -> [FAIL][3] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- fi-bdw-5557u: [PASS][4] -> [INCOMPLETE][5] ([i915#146])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-bdw-5557u/igt@gem_exec_susp...@basic-s3.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#1155])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([i915#4103]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-modeset@c-dp2:
- fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#165]) +2
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-dp2:
- fi-cfl-8109u: [PASS][12] -> [DMESG-WARN][13] ([i915#165] /
[i915#295])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp2.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp2.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([fdo#109285])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][15] -> [DMESG-WARN][16] ([i915#4269])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@primary_mmap_gtt:
- fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([i915#1072]) +3 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-1115g4: NOTRUN -> [SKIP][18] ([i915#3301])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- {fi-hsw-gt1}: [DMESG-WARN][19] ([i915#3303]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10786/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21439/fi-hsw-gt1/igt@i915_selftest@l...@hangcheck.html
* igt@kms_flip@basic-flip-vs-modeset@c-dp1:
- fi-cfl-8109
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allow engine reset failure to do a GT reset in hangcheck selftest
On 10/23/2021 11:36, Thomas Hellström wrote: On 10/23/21 20:18, Matthew Brost wrote: On Sat, Oct 23, 2021 at 07:46:48PM +0200, Thomas Hellström wrote: On 10/22/21 20:09, John Harrison wrote: And to be clear, the engine reset is not supposed to fail. Whether issued by GuC or i915, the GDRST register is supposed to self clear according to the bspec. If we are being sent the G2H notification for an engine reset failure then the assumption is that the hardware is broken. This is not a situation that is ever intended to occur in a production system. Therefore, it is not something we should spend huge amounts of effort on making a perfect selftest for. I don't agree. Selftests are there to verify that assumptions made and contracts in the code hold and that hardware behaves as intended / assumed. No selftest should ideally trigger in a production driver / system. That doesn't mean we can remove all selftests or ignore updating them for altered assumptions / contracts. I think it's important here to acknowledge the fact that this and the perf selftest have found two problems that need consideration for fixing for a production system. I'm confused - we are going down the rabbit hole here. Back to this patch. This test was written for very specific execlists behavior. It was updated to also support the GuC. In that update we missed fixing the failure path, well because it always passed. Now it has failed, we see that it doesn't fail gracefully, and takes down the machine. This patch fixes that. It also openned my eyes to the horror show reset locking that needs to be fixed long term. Well the email above wasn't really about the correctness of this particular patch (I should probably have altered the subject to reflect that) but rather about the assumption that failures that should never occur in a production system are not worth spending time on selftests for. My point is that we have to make assumptions that the hardware is basically functional. Otherwise, where do you stop? Do you write a selftest for every conceivable operation of the hardware and prove that it still works every single day? No. That is pointless and we don't have the resources to test everything that the hardware can possibly do. We have to cope as gracefully as possible in the case where the hardware does not behave as intended, such as not killing the entire OS when a selftest fails. But I don't think we should be spending time on writing a perfect test for something that is supposed to be impossible at the hardware level. The purpose of the selftests is to test the driver behaviour, not the hardware. John. For the patch itself, I'll take a deeper look at the patch and get back. /Thomas
Re: [Intel-gfx] [PATCH v2 00/17] drm/i915/dg2: Enabling 64k page size and flat ccs
(apologies for not quoting, I wasn't subscribed before now) some quick thoughts: - Can we split these patches in to two series, one for each topic. They don't seem specifically related. - to simplify 64K page support, could we just set minimum allocation size to 64K and round up for allocation requests? Placement then becomes much simpler, no need to align the va to 2MB, just fit it in wherever it fits and always use 64K PTEs in GTT This would simplify the code a lot and would benefit performance due up to 16x fewer page walks. If we did this, we would not have to consider 2MB boundaries at all, we could drop all the colour handling etc. The only down side might be some waste of allocation if there are lots of very small buffers. However, I think most gfx related use cases would not be badly affected by this (even a cursor plane is 64k, usually). Are there any usecases that you are aware of that would be impacted badly by this idea? (maybe some compute workload?) - flat ccs modifiers: there seems to be some confusion over whether there should be a separate modifier for this. As it dictates a new layout it seems like it should be a new modifier. Was there any internal discussions about this that you could elaborate on here?
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix recursive lock in GuC submission
On Mon, Oct 25, 2021 at 03:23:00PM +0300, Joonas Lahtinen wrote:
> Quoting Thomas Hellström (2021-10-21 08:39:48)
> > On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
>
>
>
> > > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > > pinned with GuC submission")
> > > Signed-off-by: Matthew Brost
> > > Cc: sta...@vger.kernel.org
>
> This Cc: stable annotation is unnecessary.
>
> Please always use "dim fixes 1a52faed31311" for helping to decide which
> Cc's are needed. In this case stable is not needed. If it was, there
> would be an indication of kernel version. In this case this is fine to
> be picked up by in drm-intel-next-fixes PR.
>
> Let's pay attention to the right Fixes: annotation while submitting and
> reviewing patches.
>
Will do. Working on getting push rights. Is there any documentation with
all the rules when pushing as it seems like there are a lot of rules.
Matt
> Regards, Joonas
Re: [Intel-gfx] [PATCH 00/47] GuC submission support
On 10/25/2021 02:37, Joonas Lahtinen wrote: Quoting Matthew Brost (2021-10-22 19:42:19) On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: Hi Matt & John, Can you please queue patches with the right Fixes: references to convert all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS protection for now. Please do so before next Wednesday so we get it queued in drm-intel-next-fixes. Don't we already do that? I checked i915_trace.h and every tracepoint I added (intel_context class, i915_request_guc_submit) is protected by LOW_LEVEL_TRACEPOINTS. The only thing I changed outside of that protection is adding the guc_id field to existing i915_request class tracepoints. It's the first search hit for "guc" inside the i915_trace.h file :) Without the guc_id in those tracepoints these are basically useless with GuC submission. We could revert that if it is a huge deal but as I said then they are useless... Let's eliminate it for now and restore the tracepoint exactly as it was. For what purpose? Your request above was about not adding new tracepoints outside of a low level CONFIG setting. I can understand that on the grounds of not swamping high level tracing with low level details that are not important to the general developer. But this is not about adding extra tracepoints, this is about making the existing tracepoints usable. With GuC submission, the GuC id is a vital piece of information. Without that, you cannot correlate anything that is happening between i915, GuC and the hardware. Which basically means that for a GuC submission based platform, those tracepoints are useless without this information. And GuC submission is POR for all platforms from ADL-P/DG1 onwards. So by not allowing this update, you are preventing any kind of meaningful debug of any scheduling/execution type issues. Again, if you are wanting to reduce spam in higher level debug then sure, make the entire set of scheduling tracepoints LOW_LEVEL only. But keeping them around in a censored manner is pointless. They are not ABI, they are allowed to change as and when necessary. And now, it is necessary to update them to match the new POR submission model for current and all future platforms. If there is an immediate need, we should instead have an auxilary tracepoint which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the information of the basic tracepoint. For the longer term solution we should align towards the dma fence tracepoints. When those are combined with the OA information, one should be able to get a good understanding of both the software and hardware scheduling decisions. I don't follow this. OA information does not tell you any details of what the GuC is doing. DRM/DMA generic tracepoints certainly won't tell you any hardware/firmware or even i915 specific information. And that is a much longer term goal than being able to debug current platforms with the current driver. John. Regards, Joonas Matt There's the orthogonal track to discuss what would be the stable set of tracepoints we could expose. However, before that discussion is closed, let's keep a rather strict line to avoid potential maintenance burned. We can then relax in the future as needed. Regards, Joonas Quoting Matthew Brost (2021-06-24 10:04:29) As discussed in [1], [2] we are enabling GuC submission support in the i915. This is a subset of the patches in step 5 described in [1], basically it is absolute to enable CI with GuC submission on gen11+ platforms. This series itself will likely be broken down into smaller patch sets to merge. Likely into CTBs changes, basic submission, virtual engines, and resets. A following series will address the missing patches remaining from [1]. Locally tested on TGL machine and basic tests seem to be passing. Signed-off-by: Matthew Brost [1] https://patchwork.freedesktop.org/series/89844/ [2] https://patchwork.freedesktop.org/series/91417/ Daniele Ceraolo Spurio (1): drm/i915/guc: Unblock GuC submission on Gen11+ John Harrison (10): drm/i915/guc: Module load failure test for CT buffer creation drm/i915: Track 'serial' counts for virtual engines drm/i915/guc: Provide mmio list to be saved/restored on engine reset drm/i915/guc: Don't complain about reset races drm/i915/guc: Enable GuC engine reset drm/i915/guc: Fix for error capture after full GPU reset with GuC drm/i915/guc: Hook GuC scheduling policies up drm/i915/guc: Connect reset modparam updates to GuC policy flags drm/i915/guc: Include scheduling policies in the debugfs state dump drm/i915/guc: Add golden context to GuC ADS Matthew Brost (36): drm/i915/guc: Relax CTB response timeout drm/i915/guc: Improve error message for unsolicited CT response drm/i915/guc: Increase size of CTB buffers drm/i915/guc: Add non blocking CTB send function drm/i915/guc: Add stall timer to non blocking CTB send function drm/i915/guc: Optim
[Intel-gfx] [PATCH 7/8] drm/amdgpu: move vram inline functions into a header
Move shared vram inline functions and structs
into a header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 51
1 file changed, 51 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
new file mode 100644
index ..32cd6f54b6f3
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2021 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __AMDGPU_VRAM_MGR_H__
+#define __AMDGPU_VRAM_MGR_H__
+
+#include
+
+struct amdgpu_vram_mgr_node {
+ struct ttm_resource base;
+ struct list_head blocks;
+ unsigned long flags;
+};
+
+static inline uint64_t amdgpu_node_start(struct drm_buddy_block *block)
+{
+ return drm_buddy_block_offset(block);
+}
+
+static inline uint64_t amdgpu_node_size(struct drm_buddy_block *block)
+{
+ return PAGE_SIZE << drm_buddy_block_order(block);
+}
+
+static inline struct amdgpu_vram_mgr_node *
+to_amdgpu_vram_mgr_node(struct ttm_resource *res)
+{
+ return container_of(res, struct amdgpu_vram_mgr_node, base);
+}
+
+#endif
--
2.25.1
[Intel-gfx] [PATCH 6/8] drm/i915: add free_unused_pages support to i915
add drm_buddy_free_unused_pages() support on
contiguous allocation
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 963468228392..162947af8e04 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -98,6 +98,14 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
if (unlikely(err))
goto err_free_blocks;
+ if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
+ err = drm_buddy_free_unused_pages(mm, (uint64_t)n_pages <<
PAGE_SHIFT,
+ &bman_res->blocks);
+
+ if (unlikely(err))
+ goto err_free_blocks;
+ }
+
*res = &bman_res->base;
return 0;
--
2.25.1
[Intel-gfx] [PATCH v2 1/8] drm: move the buddy allocator from i915 into common drm
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- add Makefile support for drm buddy
- export functions and write kerneldoc description
- Remove i915 selftest config check condition as buddy selftest
will be moved to drm selftest folder
cleanup i915 buddy references in i915 driver module
and replace with drm buddy
V2:
- include header file in alphabetical order (Thomas)
- merged changes listed in the body section into a single patch
to keep the build intact (Christian, Jani)
Signed-off-by: Arunpravin
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_buddy.c | 521 ++
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/i915_buddy.c | 466
drivers/gpu/drm/i915/i915_buddy.h | 143 -
drivers/gpu/drm/i915/i915_module.c| 3 -
drivers/gpu/drm/i915/i915_scatterlist.c | 11 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 33 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 4 +-
include/drm/drm_buddy.h | 153 +
11 files changed, 702 insertions(+), 638 deletions(-)
create mode 100644 drivers/gpu/drm/drm_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.c
delete mode 100644 drivers/gpu/drm/i915/i915_buddy.h
create mode 100644 include/drm/drm_buddy.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0dff40bb863c..dc61e91a3154 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y :=drm_aperture.o drm_auth.o drm_cache.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_managed.o drm_vblank_work.o
+ drm_managed.o drm_vblank_work.o drm_buddy.o
drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o
drm_dma.o \
drm_legacy_misc.o drm_lock.o drm_memory.o
drm_scatter.o \
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
new file mode 100644
index ..39eb1d224bec
--- /dev/null
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -0,0 +1,521 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+
+#include
+
+static struct kmem_cache *slab_blocks;
+
+static struct drm_buddy_block *drm_block_alloc(struct drm_buddy_mm *mm,
+ struct drm_buddy_block *parent,
+ unsigned int order,
+ u64 offset)
+{
+ struct drm_buddy_block *block;
+
+ BUG_ON(order > DRM_BUDDY_MAX_ORDER);
+
+ block = kmem_cache_zalloc(slab_blocks, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ block->header = offset;
+ block->header |= order;
+ block->parent = parent;
+
+ BUG_ON(block->header & DRM_BUDDY_HEADER_UNUSED);
+ return block;
+}
+
+static void drm_block_free(struct drm_buddy_mm *mm,
+ struct drm_buddy_block *block)
+{
+ kmem_cache_free(slab_blocks, block);
+}
+
+static void mark_allocated(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_STATE;
+ block->header |= DRM_BUDDY_ALLOCATED;
+
+ list_del(&block->link);
+}
+
+static void mark_free(struct drm_buddy_mm *mm,
+ struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_STATE;
+ block->header |= DRM_BUDDY_FREE;
+
+ list_add(&block->link,
+&mm->free_list[drm_buddy_block_order(block)]);
+}
+
+static void mark_split(struct drm_buddy_block *block)
+{
+ block->header &= ~DRM_BUDDY_HEADER_STATE;
+ block->header |= DRM_BUDDY_SPLIT;
+
+ list_del(&block->link);
+}
+
+/**
+ * drm_buddy_init - init memory manager
+ *
+ * @mm: DRM buddy manager to initialize
+ * @size: size in bytes to manage
+ * @chunk_size: minimum page size in bytes for our allocations
+ *
+ * Initializes the memory manager and its resources.
+ *
+ * Returns:
+ * 0 on success, error code on failure.
+ */
+int drm_buddy_init(struct drm_buddy_mm *mm, u64 size, u64 chunk_size)
+{
+ unsigned int i;
+ u64 offset;
+
+ if (size < chunk_size)
+ return -EINVAL;
+
+ if (chunk_size < PAGE_SIZE)
+ return -EINVAL;
+
+ if (!is_power_of_2(chunk_size))
+ return -EINVAL;
+
+ size = round_down(size, chunk_size);
+
+ mm->size = size;
+ mm->av
[Intel-gfx] [PATCH 3/8] drm: implement top-down allocation method
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a low specific
range, allocator traverses from the root block and splits
the larger blocks until it reaches the specific block and
in the process of splitting, lower orders in the freelist
are occupied with low range address blocks and for the
subsequent TOPDOWN memory request we may return the low
range blocks.To overcome this issue, we may go with the
below approach.
The other approach, sorting each order list entries in
ascending order and compares the last entry of each
order list in the freelist and return the max block.
This creates sorting overhead on every drm_buddy_free()
request and split up of larger blocks for a single page
request.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 42 +++--
include/drm/drm_buddy.h | 1 +
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 406e3d521903..9d3547bcc5da 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -362,6 +362,27 @@ alloc_range(struct drm_buddy_mm *mm,
return ERR_PTR(err);
}
+static struct drm_buddy_block *
+get_maxblock(struct list_head *head)
+{
+ struct drm_buddy_block *max_block = NULL, *node;
+
+ max_block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+link);
+
+ if (!max_block)
+ return NULL;
+
+ list_for_each_entry(node, head, link) {
+ if (drm_buddy_block_offset(node) >
+ drm_buddy_block_offset(max_block))
+ max_block = node;
+ }
+
+ return max_block;
+}
+
static struct drm_buddy_block *
alloc_from_freelist(struct drm_buddy_mm *mm,
unsigned int order,
@@ -372,13 +393,22 @@ alloc_from_freelist(struct drm_buddy_mm *mm,
int err;
for (i = order; i <= mm->max_order; ++i) {
- if (!list_empty(&mm->free_list[i])) {
- block = list_first_entry_or_null(&mm->free_list[i],
-struct drm_buddy_block,
-link);
+ if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
+ if (!list_empty(&mm->free_list[i])) {
+ block = get_maxblock(&mm->free_list[i]);
- if (block)
- break;
+ if (block)
+ break;
+ }
+ } else {
+ if (!list_empty(&mm->free_list[i])) {
+ block =
list_first_entry_or_null(&mm->free_list[i],
+struct
drm_buddy_block,
+link);
+
+ if (block)
+ break;
+ }
}
}
diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
index c7bb5509a7ad..cd8021d2d6e7 100644
--- a/include/drm/drm_buddy.h
+++ b/include/drm/drm_buddy.h
@@ -28,6 +28,7 @@
})
#define DRM_BUDDY_RANGE_ALLOCATION (1 << 0)
+#define DRM_BUDDY_TOPDOWN_ALLOCATION (1 << 1)
struct drm_buddy_block {
#define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
--
2.25.1
Re: [Intel-gfx] [PATCH 03/13] drm: add Makefile support for drm buddy
On 20/10/21 1:51 pm, Thomas Zimmermann wrote:
> Hi
>
> Am 20.10.21 um 00:53 schrieb Arunpravin:
>> - Include drm buddy to DRM root Makefile
>> - Add drm buddy init and exit function calls
>>to drm core
>
> Is there a hard requirement to have this code in the core?
>
> IMHO there's already too much code in the DRM core that should rather go
> into helpers. The allocator should live in it's own module and driver
> should init it if needed.
>
Hi Thomas,
I will check on this
@Daniel, Could you please share your opinion
Regards,
Arun
>>
>> Signed-off-by: Arunpravin
>> ---
>> drivers/gpu/drm/Makefile | 2 +-
>> drivers/gpu/drm/drm_drv.c | 3 +++
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 0dff40bb863c..dc61e91a3154 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -18,7 +18,7 @@ drm-y := drm_aperture.o drm_auth.o drm_cache.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_managed.o drm_vblank_work.o
>> +drm_managed.o drm_vblank_work.o drm_buddy.o
>>
>> drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o
>> drm_dma.o \
>> drm_legacy_misc.o drm_lock.o drm_memory.o
>> drm_scatter.o \
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 7a5097467ba5..6707eec21bef 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -43,6 +43,7 @@
>> #include
>> #include
>> #include
>> +#include
>
> In alphabetical order please. Here and everywhere else.
>
> Best regards
> Thomas
>
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_internal.h"
>> @@ -1034,6 +1035,7 @@ static void drm_core_exit(void)
>> drm_sysfs_destroy();
>> idr_destroy(&drm_minors_idr);
>> drm_connector_ida_destroy();
>> +drm_buddy_module_exit();
>> }
>>
>> static int __init drm_core_init(void)
>> @@ -1043,6 +1045,7 @@ static int __init drm_core_init(void)
>> drm_connector_ida_init();
>> idr_init(&drm_minors_idr);
>> drm_memcpy_init_early();
>> +drm_buddy_module_init();
>>
>> ret = drm_sysfs_init();
>> if (ret < 0) {
>>
>
[Intel-gfx] [PATCH 4/8] drm/i915: add top-down alloc support to i915
add top down allocation support to i915 driver Signed-off-by: Arunpravin --- drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c index 75197ba6e40d..963468228392 100644 --- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c @@ -53,6 +53,9 @@ static int i915_ttm_buddy_man_alloc(struct ttm_resource_manager *man, INIT_LIST_HEAD(&bman_res->blocks); bman_res->mm = mm; + if (place->flags & TTM_PL_FLAG_TOPDOWN) + bman_res->flags |= DRM_BUDDY_TOPDOWN_ALLOCATION; + if (place->fpfn || lpfn != man->size) bman_res->flags |= DRM_BUDDY_RANGE_ALLOCATION; -- 2.25.1
[Intel-gfx] [PATCH 5/8] drm: Implement method to free unused pages
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 103
include/drm/drm_buddy.h | 4 ++
2 files changed, 107 insertions(+)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 9d3547bcc5da..0da8510736eb 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -284,6 +284,109 @@ static inline bool contains(u64 s1, u64 e1, u64 s2, u64
e2)
return s1 <= s2 && e1 >= e2;
}
+/**
+ * drm_buddy_free_unused_pages - free unused pages
+ *
+ * @mm: DRM buddy manager
+ * @actual_size: original size requested
+ * @blocks: output list head to add allocated blocks
+ *
+ * For contiguous allocation, we round up the size to the nearest
+ * power of two value, drivers consume *actual* size, so remaining
+ * portions are unused and it can be freed.
+ *
+ * Returns:
+ * 0 on success, error code on failure.
+ */
+int drm_buddy_free_unused_pages(struct drm_buddy_mm *mm,
+ u64 actual_size,
+ struct list_head *blocks)
+{
+ struct drm_buddy_block *block;
+ struct drm_buddy_block *buddy;
+ u64 actual_start;
+ u64 actual_end;
+ LIST_HEAD(dfs);
+ u64 count = 0;
+ int err;
+
+ if (!list_is_singular(blocks))
+ return -EINVAL;
+
+ block = list_first_entry_or_null(blocks,
+struct drm_buddy_block,
+link);
+
+ if (!block)
+ return -EINVAL;
+
+ if (actual_size > drm_buddy_block_size(mm, block))
+ return -EINVAL;
+
+ if (actual_size == drm_buddy_block_size(mm, block))
+ return 0;
+
+ list_del(&block->link);
+
+ actual_start = drm_buddy_block_offset(block);
+ actual_end = actual_start + actual_size - 1;
+
+ if (drm_buddy_block_is_allocated(block))
+ mark_free(mm, block);
+
+ list_add(&block->tmp_link, &dfs);
+
+ while (1) {
+ block = list_first_entry_or_null(&dfs,
+struct drm_buddy_block,
+tmp_link);
+
+ if (!block)
+ break;
+
+ list_del(&block->tmp_link);
+
+ if (count == actual_size)
+ return 0;
+
+ if (contains(actual_start, actual_end,
drm_buddy_block_offset(block),
+ (drm_buddy_block_offset(block) +
drm_buddy_block_size(mm, block) - 1))) {
+ BUG_ON(!drm_buddy_block_is_free(block));
+
+ /* Allocate only required blocks */
+ mark_allocated(block);
+ mm->avail -= drm_buddy_block_size(mm, block);
+ list_add_tail(&block->link, blocks);
+ count += drm_buddy_block_size(mm, block);
+ continue;
+ }
+
+ if (drm_buddy_block_order(block) == 0)
+ continue;
+
+ if (!drm_buddy_block_is_split(block)) {
+ err = split_block(mm, block);
+
+ if (unlikely(err))
+ goto err_undo;
+ }
+
+ list_add(&block->right->tmp_link, &dfs);
+ list_add(&block->left->tmp_link, &dfs);
+ }
+
+ return -ENOSPC;
+
+err_undo:
+ buddy = get_buddy(block);
+ if (buddy &&
+ (drm_buddy_block_is_free(block) &&
+drm_buddy_block_is_free(buddy)))
+ __drm_buddy_free(mm, block);
+ return err;
+}
+EXPORT_SYMBOL(drm_buddy_free_unused_pages);
+
static struct drm_buddy_block *
alloc_range(struct drm_buddy_mm *mm,
u64 start, u64 end,
diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
index cd8021d2d6e7..1dfc80c88e1f 100644
--- a/include/drm/drm_buddy.h
+++ b/include/drm/drm_buddy.h
@@ -145,6 +145,10 @@ int drm_buddy_alloc(struct drm_buddy_mm *mm,
struct list_head *blocks,
unsigned long flags);
+int drm_buddy_free_unused_pages(struct drm_buddy_mm *mm,
+ u64 actual_size,
+ struct list_head *blocks);
+
void drm_buddy_free(struct drm_buddy_mm *mm, struct drm_buddy_block *block);
void drm_buddy_free_list(struct drm_buddy_mm *mm, struct list_head *objects);
--
2.25.1
[Intel-gfx] [PATCH 8/8] drm/amdgpu: add drm buddy support to amdgpu
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 97 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 239 ++
3 files changed, 221 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index acfa207cf970..da12b4ff2e45 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -30,12 +30,15 @@
#include
#include
+#include "amdgpu_vram_mgr.h"
+
/* state back for walking over vram_mgr and gtt_mgr allocations */
struct amdgpu_res_cursor {
uint64_tstart;
uint64_tsize;
uint64_tremaining;
- struct drm_mm_node *node;
+ void*node;
+ uint32_tmem_type;
};
/**
@@ -52,27 +55,63 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
uint64_t start, uint64_t size,
struct amdgpu_res_cursor *cur)
{
+ struct drm_buddy_block *block;
+ struct list_head *head, *next;
struct drm_mm_node *node;
- if (!res || res->mem_type == TTM_PL_SYSTEM) {
- cur->start = start;
- cur->size = size;
- cur->remaining = size;
- cur->node = NULL;
- WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
- return;
- }
+ if (!res)
+ goto err_out;
BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
- node = to_ttm_range_mgr_node(res)->mm_nodes;
- while (start >= node->size << PAGE_SHIFT)
- start -= node++->size << PAGE_SHIFT;
+ cur->mem_type = res->mem_type;
+
+ switch (cur->mem_type) {
+ case TTM_PL_VRAM:
+ head = &to_amdgpu_vram_mgr_node(res)->blocks;
+
+ block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+link);
+ if (!block)
+ goto err_out;
+
+ while (start >= amdgpu_node_size(block)) {
+ start -= amdgpu_node_size(block);
+
+ next = block->link.next;
+ if (next != head)
+ block = list_entry(next, struct
drm_buddy_block, link);
+ }
+
+ cur->start = amdgpu_node_start(block) + start;
+ cur->size = min(amdgpu_node_size(block) - start, size);
+ cur->remaining = size;
+ cur->node = block;
+ break;
+ case TTM_PL_TT:
+ node = to_ttm_range_mgr_node(res)->mm_nodes;
+ while (start >= node->size << PAGE_SHIFT)
+ start -= node++->size << PAGE_SHIFT;
+
+ cur->start = (node->start << PAGE_SHIFT) + start;
+ cur->size = min((node->size << PAGE_SHIFT) - start, size);
+ cur->remaining = size;
+ cur->node = node;
+ break;
+ default:
+ goto err_out;
+ }
- cur->start = (node->start << PAGE_SHIFT) + start;
- cur->size = min((node->size << PAGE_SHIFT) - start, size);
+ return;
+
+err_out:
+ cur->start = start;
+ cur->size = size;
cur->remaining = size;
- cur->node = node;
+ cur->node = NULL;
+ WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+ return;
}
/**
@@ -85,7 +124,9 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
*/
static inline void amdgpu_res_next(struct amdgpu_res_cursor *cur, uint64_t
size)
{
- struct drm_mm_node *node = cur->node;
+ struct drm_buddy_block *block;
+ struct drm_mm_node *node;
+ struct list_head *next;
BUG_ON(size > cur->remaining);
@@ -99,9 +140,27 @@ static inline void amdgpu_res_next(struct amdgpu_res_cursor
*cur, uint64_t size)
return;
}
- cur->node = ++node;
- cur->start = node->start << PAGE_SHIFT;
- cur->size = min(node->size << PAGE_SHIFT, cur->remaining);
+ switch (cur->mem_type) {
+ case TTM_PL_VRAM:
+ block = cur->node;
+
+ next = block->link.next;
+ block = list_entry(next, struct drm_buddy_block, link);
+
+ cur->node = block;
+ cur->start = amdgpu_node_start(block);
+ cur->size = min(amdgpu_node_size(block), cur->remaining);
+ break;
+ case TTM_PL_TT:
+ node = cur->node;
+
+ cur->node = ++node;
+ cur->start =
[Intel-gfx] [PATCH v2 2/8] drm: improve drm_buddy_alloc function
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915 driver to drm buddy
V2:
merged below changes to keep the build unbroken
- drm_buddy_alloc_range() becomes obsolete and may be removed
- enable ttm range allocation (fpfn / lpfn) support in i915 driver
- apply enhanced drm_buddy_alloc() function to i915 driver
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 265 +++---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 67 ++---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +
include/drm/drm_buddy.h | 22 +-
4 files changed, 207 insertions(+), 149 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 39eb1d224bec..406e3d521903 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -274,63 +274,6 @@ void drm_buddy_free_list(struct drm_buddy_mm *mm, struct
list_head *objects)
}
EXPORT_SYMBOL(drm_buddy_free_list);
-/**
- * drm_buddy_alloc - allocate power-of-two blocks
- *
- * @mm: DRM buddy manager to allocate from
- * @order: size of the allocation
- *
- * The order value here translates to:
- *
- * 0 = 2^0 * mm->chunk_size
- * 1 = 2^1 * mm->chunk_size
- * 2 = 2^2 * mm->chunk_size
- *
- * Returns:
- * allocated ptr to the &drm_buddy_block on success
- */
-struct drm_buddy_block *
-drm_buddy_alloc(struct drm_buddy_mm *mm, unsigned int order)
-{
- struct drm_buddy_block *block = NULL;
- unsigned int i;
- int err;
-
- for (i = order; i <= mm->max_order; ++i) {
- block = list_first_entry_or_null(&mm->free_list[i],
-struct drm_buddy_block,
-link);
- if (block)
- break;
- }
-
- if (!block)
- return ERR_PTR(-ENOSPC);
-
- BUG_ON(!drm_buddy_block_is_free(block));
-
- while (i != order) {
- err = split_block(mm, block);
- if (unlikely(err))
- goto out_free;
-
- /* Go low */
- block = block->left;
- i--;
- }
-
- mark_allocated(block);
- mm->avail -= drm_buddy_block_size(mm, block);
- kmemleak_update_trace(block);
- return block;
-
-out_free:
- if (i != order)
- __drm_buddy_free(mm, block);
- return ERR_PTR(err);
-}
-EXPORT_SYMBOL(drm_buddy_alloc);
-
static inline bool overlaps(u64 s1, u64 e1, u64 s2, u64 e2)
{
return s1 <= e2 && e1 >= s2;
@@ -341,52 +284,22 @@ static inline bool contains(u64 s1, u64 e1, u64 s2, u64
e2)
return s1 <= s2 && e1 >= e2;
}
-/**
- * drm_buddy_alloc_range - allocate range
- *
- * @mm: DRM buddy manager to allocate from
- * @blocks: output list head to add allocated blocks
- * @start: start of the allowed range for this block
- * @size: size of the allocation
- *
- * Intended for pre-allocating portions of the address space, for example to
- * reserve a block for the initial framebuffer or similar, hence the
expectation
- * here is that drm_buddy_alloc() is still the main vehicle for
- * allocations, so if that's not the case then the drm_mm range allocator is
- * probably a much better fit, and so you should probably go use that instead.
- *
- * Note that it's safe to chain together multiple alloc_ranges
- * with the same blocks list
- *
- * Returns:
- * 0 on success, error code on failure.
- */
-int drm_buddy_alloc_range(struct drm_buddy_mm *mm,
- struct list_head *blocks,
- u64 start, u64 size)
+static struct drm_buddy_block *
+alloc_range(struct drm_buddy_mm *mm,
+ u64 start, u64 end,
+ unsigned int order)
{
struct drm_buddy_block *block;
struct drm_buddy_block *buddy;
- LIST_HEAD(allocated);
LIST_HEAD(dfs);
- u64 end;
int err;
int i;
- if (size < mm->chunk_size)
- return -EINVAL;
-
- if (!IS_ALIGNED(size | start, mm->chunk_size))
- return -EINVAL;
-
- if (range_overflows(start, size, mm->size))
- return -EINVAL;
+ end = end - 1;
for (i = 0; i < mm->n_roots; ++i)
list_add_tail(&mm->roots[i]->tmp_link, &dfs);
- end = start + size - 1;
-
do {
u64 block_start;
u64 block_end;
@@ -394,31 +307,32 @@ int drm_buddy_alloc_range(struct drm_buddy_mm *mm,
block = list_first_entry_or_null(&dfs,
struct drm_buddy_block,
tmp_link);
+
if (!block)
break;
[Intel-gfx] ✓ Fi.CI.IGT: success for MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
== Series Details == Series: MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer URL : https://patchwork.freedesktop.org/series/96247/ State : success == Summary == CI Bug Log - changes from CI_DRM_10784_full -> Patchwork_21438_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21438_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10784/shard-kbl1/igt@gem_ctx_isolation@preservation...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-kbl6/igt@gem_ctx_isolation@preservation...@vecs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10784/shard-glk9/igt@gem_exec_fair@basic-none-r...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10784/shard-tglb3/igt@gem_exec_fair@basic-p...@vcs1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_gttfill@all: - shard-glk: [PASS][8] -> [DMESG-WARN][9] ([i915#118]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10784/shard-glk3/igt@gem_exec_gttf...@all.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-glk6/igt@gem_exec_gttf...@all.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [WARN][10] ([i915#2658]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-skl4/igt@gem_pr...@exhaustion.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_10784/shard-iclb1/igt@i915_pm...@dc6-psr.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-iclb3/igt@i915_pm...@dc6-psr.html * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip: - shard-kbl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3777]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-kbl4/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html * igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-kbl7/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc: - shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3886]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-skl4/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-apl8/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_ccs: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271]) +15 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-apl8/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_ccs.html * igt@kms_chamelium@hdmi-hpd-storm-disable: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +5 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-skl8/igt@kms_chamel...@hdmi-hpd-storm-disable.html * igt@kms_color_chamelium@pipe-a-ctm-blue-to-red: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-kbl7/igt@kms_color_chamel...@pipe-a-ctm-blue-to-red.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: NOTRUN -> [DMESG-WARN][20] ([i915#180]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_crc@pipe-d-cursor-suspend:
[Intel-gfx] [PATCH] drm/i915/trace: Hide backend specific fields behind Kconfig
Hide the guc_id and tail fields, for request trace points, behind
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Trace points
are ABI (maybe?) so don't change them without kernel developers Kconfig
options.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_trace.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 9795f456cccf..4f5238d02b51 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -787,6 +787,7 @@ TRACE_EVENT(i915_request_queue,
__entry->ctx, __entry->seqno, __entry->flags)
);
+#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
DECLARE_EVENT_CLASS(i915_request,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq),
@@ -816,6 +817,32 @@ DECLARE_EVENT_CLASS(i915_request,
__entry->guc_id, __entry->ctx, __entry->seqno,
__entry->tail)
);
+#else
+DECLARE_EVENT_CLASS(i915_request,
+ TP_PROTO(struct i915_request *rq),
+ TP_ARGS(rq),
+
+ TP_STRUCT__entry(
+__field(u32, dev)
+__field(u64, ctx)
+__field(u16, class)
+__field(u16, instance)
+__field(u32, seqno)
+),
+
+ TP_fast_assign(
+ __entry->dev = rq->engine->i915->drm.primary->index;
+ __entry->class = rq->engine->uabi_class;
+ __entry->instance = rq->engine->uabi_instance;
+ __entry->ctx = rq->fence.context;
+ __entry->seqno = rq->fence.seqno;
+ ),
+
+ TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
+ __entry->dev, __entry->class, __entry->instance,
+ __entry->ctx, __entry->seqno)
+);
+#endif
DEFINE_EVENT(i915_request, i915_request_add,
TP_PROTO(struct i915_request *rq),
--
2.32.0
Re: [Intel-gfx] [PATCH] drm/i915: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
On 25/10/2021 12:32, Wan Jiabing wrote:
Fix following coccicheck warning:
./drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:3117:15-22: WARNING:
ERR_CAST can be used with eb->requests[i].
Signed-off-by: Wan Jiabing
Pushed to drm-intel-gt-next. Thanks.
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4d7da07442f2..eb2dcaf78d08 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3114,7 +3114,7 @@ eb_requests_create(struct i915_execbuffer *eb, struct
dma_fence *in_fence,
/* Allocate a request for this batch buffer nice and early. */
eb->requests[i] = i915_request_create(eb_find_context(eb, i));
if (IS_ERR(eb->requests[i])) {
- out_fence = ERR_PTR(PTR_ERR(eb->requests[i]));
+ out_fence = ERR_CAST(eb->requests[i]);
eb->requests[i] = NULL;
return out_fence;
}
Re: [Intel-gfx] [PATCH 00/47] GuC submission support
On Mon, Oct 25, 2021 at 12:37:02PM +0300, Joonas Lahtinen wrote: > Quoting Matthew Brost (2021-10-22 19:42:19) > > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: > > > Hi Matt & John, > > > > > > Can you please queue patches with the right Fixes: references to convert > > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS > > > protection for now. Please do so before next Wednesday so we get it > > > queued in drm-intel-next-fixes. > > > > > > > Don't we already do that? I checked i915_trace.h and every tracepoint I > > added (intel_context class, i915_request_guc_submit) is protected by > > LOW_LEVEL_TRACEPOINTS. > > > > The only thing I changed outside of that protection is adding the guc_id > > field to existing i915_request class tracepoints. > > It's the first search hit for "guc" inside the i915_trace.h file :) > > > Without the guc_id in > > those tracepoints these are basically useless with GuC submission. We > > could revert that if it is a huge deal but as I said then they are > > useless... > > Let's eliminate it for now and restore the tracepoint exactly as it was. > Don't really agree - let's render tracepoints to be useless? Are tracepoints ABI? I googled this and couldn't really find a definie answer. If tracepoints are ABI, then OK I can revert this change but still this is a poor technical decision (tracepoints should not be ABI). > If there is an immediate need, we should instead have an auxilary tracepoint > which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the > information of the basic tracepoint. > Regardless of what I said above, I'll post 2 patches. The 1st just remove the GuC, the 2nd modify the tracepoint to include guc_id if LOW_LEVEL_TRACEPOINTS is defined. > For the longer term solution we should align towards the dma fence > tracepoints. When those are combined with the OA information, one should > be able to get a good understanding of both the software and hardware > scheduling decisions. > Not sure about this either. I use these tracepoins to correlate things to the GuC log. Between the 2, if you know what you are doing you basically can figure out everything that is happening. Fields in the trace translate directly to fields in the GuC log. Some of these fields are backend specific, not sure how these could be pushed the dma fence tracepoints. For what it is worth, without these tracepoints we'd likely still have a bunch of bugs in the GuC firmware. I understand these points, several other i915 developers do, and several of the GuC firmware developers do too. Matt > Regards, Joonas > > > > > Matt > > > > > There's the orthogonal track to discuss what would be the stable set of > > > tracepoints we could expose. However, before that discussion is closed, > > > let's keep a rather strict line to avoid potential maintenance burned. > > > > > > We can then relax in the future as needed. > > > > > > Regards, Joonas > > > > > > Quoting Matthew Brost (2021-06-24 10:04:29) > > > > As discussed in [1], [2] we are enabling GuC submission support in the > > > > i915. This is a subset of the patches in step 5 described in [1], > > > > basically it is absolute to enable CI with GuC submission on gen11+ > > > > platforms. > > > > > > > > This series itself will likely be broken down into smaller patch sets to > > > > merge. Likely into CTBs changes, basic submission, virtual engines, and > > > > resets. > > > > > > > > A following series will address the missing patches remaining from [1]. > > > > > > > > Locally tested on TGL machine and basic tests seem to be passing. > > > > > > > > Signed-off-by: Matthew Brost > > > > > > > > [1] https://patchwork.freedesktop.org/series/89844/ > > > > [2] https://patchwork.freedesktop.org/series/91417/ > > > > > > > > Daniele Ceraolo Spurio (1): > > > > drm/i915/guc: Unblock GuC submission on Gen11+ > > > > > > > > John Harrison (10): > > > > drm/i915/guc: Module load failure test for CT buffer creation > > > > drm/i915: Track 'serial' counts for virtual engines > > > > drm/i915/guc: Provide mmio list to be saved/restored on engine reset > > > > drm/i915/guc: Don't complain about reset races > > > > drm/i915/guc: Enable GuC engine reset > > > > drm/i915/guc: Fix for error capture after full GPU reset with GuC > > > > drm/i915/guc: Hook GuC scheduling policies up > > > > drm/i915/guc: Connect reset modparam updates to GuC policy flags > > > > drm/i915/guc: Include scheduling policies in the debugfs state dump > > > > drm/i915/guc: Add golden context to GuC ADS > > > > > > > > Matthew Brost (36): > > > > drm/i915/guc: Relax CTB response timeout > > > > drm/i915/guc: Improve error message for unsolicited CT response > > > > drm/i915/guc: Increase size of CTB buffers > > > > drm/i915/guc: Add non blocking CTB send function > > > > drm/i915/guc: Add stall timer to non blocking CTB send function > > > > drm/i915/guc: Optimize CTB write
[Intel-gfx] ✓ Fi.CI.BAT: success for MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
== Series Details ==
Series: MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
URL : https://patchwork.freedesktop.org/series/96247/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10784 -> Patchwork_21438
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/index.html
Participating hosts (42 -> 36)
--
Additional (1): fi-pnv-d510
Missing(7): fi-ilk-m540 bat-dg1-6 fi-hsw-4200u fi-icl-u2 fi-bsw-cyan
bat-adlp-4 fi-ctg-p8600
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21438:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_frontbuffer_tracking@basic:
- {fi-hsw-gt1}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10784/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/fi-hsw-gt1/igt@kms_frontbuffer_track...@basic.html
Known issues
Here are the changes found in Patchwork_21438 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/fi-pnv-d510/igt@gem_ctx_cre...@basic.html
* igt@gem_exec_parallel@engines@userptr:
- fi-pnv-d510:NOTRUN -> [INCOMPLETE][4] ([i915#299])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/fi-pnv-d510/igt@gem_exec_parallel@engi...@userptr.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][5] ([i915#2403] / [i915#2722] /
[i915#4312])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/fi-pnv-d510/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#299]: https://gitlab.freedesktop.org/drm/intel/issues/299
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
Build changes
-
* Linux: CI_DRM_10784 -> Patchwork_21438
CI-20190529: 20190529
CI_DRM_10784: 4afbf8baed08e569711f413cce2ccd415b1a51c9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6260: 46994310410404a07d142f33fab220d718c27f64 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21438: f6ff060dd9a1872af489e8ad4890ca43a07cf8b0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f6ff060dd9a1 MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21438/index.html
Re: [Intel-gfx] [PATCH 21/28] drm/i915: Drain the ttm delayed workqueue too
On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
wrote:
>
> Be thorough..
>
> Signed-off-by: Maarten Lankhorst
Is this strictly needed for something? Needs a proper commit message anyway.
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 22c891720c6d..7c5ed5957fe2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1819,6 +1819,7 @@ static inline void i915_gem_drain_freed_objects(struct
> drm_i915_private *i915)
> */
> while (atomic_read(&i915->mm.free_count)) {
> flush_work(&i915->mm.free_work);
> + flush_delayed_work(&i915->bdev.wq);
> rcu_barrier();
> }
> }
> --
> 2.33.0
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
== Series Details == Series: drm/i915: Use ERR_CAST instead of ERR_PTR(PTR_ERR()) URL : https://patchwork.freedesktop.org/series/96246/ State : success == Summary == CI Bug Log - changes from CI_DRM_10783_full -> Patchwork_21436_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21436_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-apl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [FAIL][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl7/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl7/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl7/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl6/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl6/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl4/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl4/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl2/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-apl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl3/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl4/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl4/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl4/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl4/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl6/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl6/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl7/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl7/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl7/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl8/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl7/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl8/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl8/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl8/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/shard-apl1/boot.html [44]: https://intel-gfx-ci.01.org/tree/drm-t
Re: [Intel-gfx] [PATCH 28/28] drm/i915: Remove short-term pins from execbuf, v4.
On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
wrote:
>
> Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
> protected by the object lock.
>
> This removes the need to unpin, which is done by just releasing the
> lock.
>
> eb_reserve is slightly reworked for readability, but the same steps
> are still done:
> - First pass pins with NONBLOCK.
> - Second pass unbinds all objects first, then pins.
> - Third pass is only called when not all objects are softpinned, and
> unbinds all objects, then calls i915_gem_evict_vm(), then pins.
>
> When evicting the entire vm in eb_reserve() we do temporarily pin objects
> that are marked with EXEC_OBJECT_PINNED. This is because they are already
> at their destination, and i915_gem_evict_vm() would otherwise unbind them.
>
> However, we reduce the visibility of those pins by limiting the pin
> to our call to i915_gem_evict_vm() only, and pin with vm->mutex held,
> instead of the entire duration of the execbuf.
>
> Not sure the latter matters, one can hope..
> In theory we could kill the pinning by adding an extra flag to the vma
> to temporarily prevent unbinding for gtt for i915_gem_evict_vm only, but
> I think that might be overkill. We're still holding the object lock, and
> we don't have blocking eviction yet. It's likely sufficient to simply
> enforce EXEC_OBJECT_PINNED for all objects on >= gen12.
>
> Changes since v1:
> - Split out eb_reserve() into separate functions for readability.
> Changes since v2:
> - Make batch buffer mappable on platforms where only GGTT is available,
> to prevent moving the batch buffer during relocations.
> Changes since v3:
> - Preserve current behavior for batch buffer, instead be cautious when
> calling i915_gem_object_ggtt_pin_ww, and re-use the current batch vma
> if it's inside ggtt and map-and-fenceable.
>
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 252 ++
> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
> drivers/gpu/drm/i915/i915_vma.c | 24 +-
> 3 files changed, 161 insertions(+), 116 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index bbf2a10738f7..19f91143cfcf 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -439,7 +439,7 @@ eb_pin_vma(struct i915_execbuffer *eb,
> else
> pin_flags = entry->offset & PIN_OFFSET_MASK;
>
> - pin_flags |= PIN_USER | PIN_NOEVICT | PIN_OFFSET_FIXED;
> + pin_flags |= PIN_USER | PIN_NOEVICT | PIN_OFFSET_FIXED | PIN_VALIDATE;
> if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
> pin_flags |= PIN_GLOBAL;
>
> @@ -457,17 +457,15 @@ eb_pin_vma(struct i915_execbuffer *eb,
> entry->pad_to_size,
> entry->alignment,
> eb_pin_flags(entry, ev->flags) |
> -PIN_USER | PIN_NOEVICT);
> +PIN_USER | PIN_NOEVICT |
> PIN_VALIDATE);
> if (unlikely(err))
> return err;
> }
>
> if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
> err = i915_vma_pin_fence(vma);
> - if (unlikely(err)) {
> - i915_vma_unpin(vma);
> + if (unlikely(err))
> return err;
> - }
>
> if (vma->fence)
> ev->flags |= __EXEC_OBJECT_HAS_FENCE;
> @@ -483,13 +481,9 @@ eb_pin_vma(struct i915_execbuffer *eb,
> static inline void
> eb_unreserve_vma(struct eb_vma *ev)
> {
> - if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
> - return;
> -
> if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
> __i915_vma_unpin_fence(ev->vma);
>
> - __i915_vma_unpin(ev->vma);
> ev->flags &= ~__EXEC_OBJECT_RESERVED;
> }
>
> @@ -682,10 +676,8 @@ static int eb_reserve_vma(struct i915_execbuffer *eb,
>
> if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
> err = i915_vma_pin_fence(vma);
> - if (unlikely(err)) {
> - i915_vma_unpin(vma);
> + if (unlikely(err))
> return err;
> - }
>
> if (vma->fence)
> ev->flags |= __EXEC_OBJECT_HAS_FENCE;
> @@ -697,85 +689,129 @@ static int eb_reserve_vma(struct i915_execbuffer *eb,
> return 0;
> }
>
> -static int eb_reserve(struct i915_execbuffer *eb)
> +static int eb_evict_vm(struct i915_execbuffer *eb)
> +{
> + const unsigned int count = eb->buffer_count;
> + unsigned int i;
> + int err;
> +
> + err = mutex_lock_interruptible(&eb->context->vm->mutex);
> + if (e
Re: [Intel-gfx] [PATCH -next] drm: Small optimization to intel_dp_mst_atomic_master_trans_check
On Thu, Oct 21, 2021 at 10:22:43PM -0400, He Ying wrote:
> If we want to return from for_each_intel_connector_iter(), one
> way is calling drm_connector_list_iter_end() before returning
> to avoid memleak. The other way is just breaking from the bracket
> and then returning after the outside drm_connector_list_iter_end().
> Obviously, the second way makes code smaller and more clear.
> Apply it to the function intel_dp_mst_atomic_master_trans_check().
Matches what we seem to be doing everywhere else.
Applied to drm-intel-next. Thanks.
>
> Signed-off-by: He Ying
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 8d13d7b26a25..bbecbbbcb10d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -231,6 +231,7 @@ intel_dp_mst_atomic_master_trans_check(struct
> intel_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> struct drm_connector_list_iter connector_list_iter;
> struct intel_connector *connector_iter;
> + int ret = 0;
>
> if (DISPLAY_VER(dev_priv) < 12)
> return 0;
> @@ -243,7 +244,6 @@ intel_dp_mst_atomic_master_trans_check(struct
> intel_connector *connector,
> struct intel_digital_connector_state *conn_iter_state;
> struct intel_crtc_state *crtc_state;
> struct intel_crtc *crtc;
> - int ret;
>
> if (connector_iter->mst_port != connector->mst_port ||
> connector_iter == connector)
> @@ -252,8 +252,8 @@ intel_dp_mst_atomic_master_trans_check(struct
> intel_connector *connector,
> conn_iter_state =
> intel_atomic_get_digital_connector_state(state,
>
> connector_iter);
> if (IS_ERR(conn_iter_state)) {
> - drm_connector_list_iter_end(&connector_list_iter);
> - return PTR_ERR(conn_iter_state);
> + ret = PTR_ERR(conn_iter_state);
> + break;
> }
>
> if (!conn_iter_state->base.crtc)
> @@ -262,20 +262,18 @@ intel_dp_mst_atomic_master_trans_check(struct
> intel_connector *connector,
> crtc = to_intel_crtc(conn_iter_state->base.crtc);
> crtc_state = intel_atomic_get_crtc_state(&state->base, crtc);
> if (IS_ERR(crtc_state)) {
> - drm_connector_list_iter_end(&connector_list_iter);
> - return PTR_ERR(crtc_state);
> + ret = PTR_ERR(crtc_state);
> + break;
> }
>
> ret = drm_atomic_add_affected_planes(&state->base, &crtc->base);
> - if (ret) {
> - drm_connector_list_iter_end(&connector_list_iter);
> - return ret;
> - }
> + if (ret)
> + break;
> crtc_state->uapi.mode_changed = true;
> }
> drm_connector_list_iter_end(&connector_list_iter);
>
> - return 0;
> + return ret;
> }
>
> static int
> --
> 2.17.1
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH] drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms
From: Ville Syrjälä
Looks like we never updated intel_bios_is_port_dp_dual_mode() when
the VBT port mapping became erratic on modern platforms. This
is causing us to look up the wrong child device and thus throwing
the heuristic off (ie. we might end looking at a child device for
a genuine DP++ port when we were supposed to look at one for a
native HDMI port).
Fix it up by not using the outdated port_mapping[] in
intel_bios_is_port_dp_dual_mode() and rely on
intel_bios_encoder_data_lookup() instead.
Cc: sta...@vger.kernel.org
Tested-by: Randy Dunlap
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 85 +--
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index f9776ca85de3..2b1423a43437 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1707,6 +1707,39 @@ static void sanitize_aux_ch(struct
intel_bios_encoder_data *devdata,
child->aux_channel = 0;
}
+static u8 dvo_port_type(u8 dvo_port)
+{
+ switch (dvo_port) {
+ case DVO_PORT_HDMIA:
+ case DVO_PORT_HDMIB:
+ case DVO_PORT_HDMIC:
+ case DVO_PORT_HDMID:
+ case DVO_PORT_HDMIE:
+ case DVO_PORT_HDMIF:
+ case DVO_PORT_HDMIG:
+ case DVO_PORT_HDMIH:
+ case DVO_PORT_HDMII:
+ return DVO_PORT_HDMIA;
+ case DVO_PORT_DPA:
+ case DVO_PORT_DPB:
+ case DVO_PORT_DPC:
+ case DVO_PORT_DPD:
+ case DVO_PORT_DPE:
+ case DVO_PORT_DPF:
+ case DVO_PORT_DPG:
+ case DVO_PORT_DPH:
+ case DVO_PORT_DPI:
+ return DVO_PORT_DPA;
+ case DVO_PORT_MIPIA:
+ case DVO_PORT_MIPIB:
+ case DVO_PORT_MIPIC:
+ case DVO_PORT_MIPID:
+ return DVO_PORT_MIPIA;
+ default:
+ return dvo_port;
+ }
+}
+
static enum port __dvo_port_to_port(int n_ports, int n_dvo,
const int port_mapping[][3], u8 dvo_port)
{
@@ -2623,35 +2656,17 @@ bool intel_bios_is_port_edp(struct drm_i915_private
*i915, enum port port)
return false;
}
-static bool child_dev_is_dp_dual_mode(const struct child_device_config *child,
- enum port port)
+static bool child_dev_is_dp_dual_mode(const struct child_device_config *child)
{
- static const struct {
- u16 dp, hdmi;
- } port_mapping[] = {
- /*
-* Buggy VBTs may declare DP ports as having
-* HDMI type dvo_port :( So let's check both.
-*/
- [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
- [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
- [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
- [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
- [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
- };
-
- if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
- return false;
-
if ((child->device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) !=
(DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
return false;
- if (child->dvo_port == port_mapping[port].dp)
+ if (dvo_port_type(child->dvo_port) == DVO_PORT_DPA)
return true;
/* Only accept a HDMI dvo_port as DP++ if it has an AUX channel */
- if (child->dvo_port == port_mapping[port].hdmi &&
+ if (dvo_port_type(child->dvo_port) == DVO_PORT_HDMIA &&
child->aux_channel != 0)
return true;
@@ -2661,10 +2676,36 @@ static bool child_dev_is_dp_dual_mode(const struct
child_device_config *child,
bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *i915,
enum port port)
{
+ static const struct {
+ u16 dp, hdmi;
+ } port_mapping[] = {
+ /*
+* Buggy VBTs may declare DP ports as having
+* HDMI type dvo_port :( So let's check both.
+*/
+ [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
+ [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
+ [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
+ [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
+ [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, },
+ };
const struct intel_bios_encoder_data *devdata;
+ if (HAS_DDI(i915)) {
+ const struct intel_bios_encoder_data *devdata;
+
+ devdata = intel_bios_encoder_data_lookup(i915, port);
+
+ return devdata && child_dev_is_dp_dual_mode(&devdata->child);
+ }
+
+ if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
+ return false;
+
list_for_each_entry(devdat
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
== Series Details == Series: drm/i915: Use ERR_CAST instead of ERR_PTR(PTR_ERR()) URL : https://patchwork.freedesktop.org/series/96246/ State : success == Summary == CI Bug Log - changes from CI_DRM_10783 -> Patchwork_21436 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/index.html Participating hosts (37 -> 35) -- Additional (3): fi-kbl-x1275 fi-bxt-dsi fi-tgl-1115g4 Missing(5): bat-dg1-6 fi-bsw-cyan fi-icl-u2 bat-adlp-4 fi-ctg-p8600 Known issues Here are the changes found in Patchwork_21436 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([fdo#109315]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-x1275: NOTRUN -> [SKIP][3] ([fdo#109271]) +28 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@gem_huc_copy@huc-copy: - fi-kbl-x1275: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html - fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#1155]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-skl-6600u: [PASS][8] -> [FAIL][9] ([i915#3239]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-skl-6600u/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][10] -> [INCOMPLETE][11] ([i915#3921]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bxt-dsi: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-x1275: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-bxt-dsi: NOTRUN -> [SKIP][16] ([fdo#109271]) +30 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html - fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-bxt-dsi: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#533]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-x1275: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#533]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21436/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][20] (
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v2,1/8] drm: move the buddy allocator from i915 into common drm
== Series Details == Series: series starting with [v2,1/8] drm: move the buddy allocator from i915 into common drm URL : https://patchwork.freedesktop.org/series/96245/ State : failure == Summary == Applying: drm: move the buddy allocator from i915 into common drm Using index info to reconstruct a base tree... M drivers/gpu/drm/Makefile M drivers/gpu/drm/drm_drv.c Falling back to patching base and 3-way merge... Removing drivers/gpu/drm/i915/i915_buddy.h Removing drivers/gpu/drm/i915/i915_buddy.c Auto-merging drivers/gpu/drm/drm_drv.c Auto-merging drivers/gpu/drm/Makefile CONFLICT (content): Merge conflict in drivers/gpu/drm/Makefile error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm: move the buddy allocator from i915 into common drm 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".
Re: [Intel-gfx] [PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
On Mon, Oct 25, 2021 at 3:49 PM Joonas Lahtinen wrote: > > Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver. > Tvrtko will bring added bandwidth and focus to the GT/GEM domain > (drm-intel-gt-next). > > This will help with the increased driver maintenance efforts, allows > alternating the drm-intel-gt-next pull requests and also should increase > the coverage for the maintenance in general. > > Signed-off-by: Joonas Lahtinen > Cc: David Airlie > Cc: Daniel Vetter > Acked-by: Jani Nikula > Acked-by: Rodrigo Vivi > Acked-by: Tvrtko Ursulin > Cc: Sean Paul > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: dri-de...@lists.freedesktop.org Acked-by: Daniel Vetter > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 98aa1f55ed41..07553156a1c2 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9361,6 +9361,7 @@ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and > derivative chipsets) > M: Jani Nikula > M: Joonas Lahtinen > M: Rodrigo Vivi > +M: Tvrtko Ursulin > L: intel-gfx@lists.freedesktop.org > S: Supported > W: https://01.org/linuxgraphics/ > -- > 2.31.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH] MAINTAINERS: Add Tvrtko as drm/i915 co-maintainer
Add Tvrtko Ursulin as a co-maintainer for drm/i915 driver. Tvrtko will bring added bandwidth and focus to the GT/GEM domain (drm-intel-gt-next). This will help with the increased driver maintenance efforts, allows alternating the drm-intel-gt-next pull requests and also should increase the coverage for the maintenance in general. Signed-off-by: Joonas Lahtinen Cc: David Airlie Cc: Daniel Vetter Acked-by: Jani Nikula Acked-by: Rodrigo Vivi Acked-by: Tvrtko Ursulin Cc: Sean Paul Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: dri-de...@lists.freedesktop.org --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 98aa1f55ed41..07553156a1c2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9361,6 +9361,7 @@ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) M: Jani Nikula M: Joonas Lahtinen M: Rodrigo Vivi +M: Tvrtko Ursulin L: intel-gfx@lists.freedesktop.org S: Supported W: https://01.org/linuxgraphics/ -- 2.31.1
[Intel-gfx] [PATCH] drm/i915: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
Fix following coccicheck warning:
./drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:3117:15-22: WARNING:
ERR_CAST can be used with eb->requests[i].
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4d7da07442f2..eb2dcaf78d08 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3114,7 +3114,7 @@ eb_requests_create(struct i915_execbuffer *eb, struct
dma_fence *in_fence,
/* Allocate a request for this batch buffer nice and early. */
eb->requests[i] = i915_request_create(eb_find_context(eb, i));
if (IS_ERR(eb->requests[i])) {
- out_fence = ERR_PTR(PTR_ERR(eb->requests[i]));
+ out_fence = ERR_CAST(eb->requests[i]);
eb->requests[i] = NULL;
return out_fence;
}
--
2.20.1
Re: [Intel-gfx] [PATCH] drm/i915: Prefer struct_size over open coded arithmetic
Hi Jani, On Mon, Oct 18, 2021 at 01:00:01PM +0300, Jani Nikula wrote: > On Sat, 16 Oct 2021, Len Baker wrote: > > Hi Daniel and Jani, > > > > On Wed, Oct 13, 2021 at 01:51:30PM +0200, Daniel Vetter wrote: > >> On Wed, Oct 13, 2021 at 02:24:05PM +0300, Jani Nikula wrote: > >> > On Mon, 11 Oct 2021, Len Baker wrote: > >> > > Hi, > >> > > > >> > > On Sun, Oct 03, 2021 at 12:42:58PM +0200, Len Baker wrote: > >> > >> As noted in the "Deprecated Interfaces, Language Features, Attributes, > >> > >> and Conventions" documentation [1], size calculations (especially > >> > >> multiplication) should not be performed in memory allocator (or > >> > >> similar) > >> > >> function arguments due to the risk of them overflowing. This could > >> > >> lead > >> > >> to values wrapping around and a smaller allocation being made than the > >> > >> caller was expecting. Using those allocations could lead to linear > >> > >> overflows of heap memory and other misbehaviors. > >> > >> > >> > >> In this case these are not actually dynamic sizes: all the operands > >> > >> involved in the calculation are constant values. However it is better > >> > >> to > >> > >> refactor them anyway, just to keep the open-coded math idiom out of > >> > >> code. > >> > >> > >> > >> So, add at the end of the struct i915_syncmap a union with two > >> > >> flexible > >> > >> array members (these arrays share the same memory layout). This is > >> > >> possible using the new DECLARE_FLEX_ARRAY macro. And then, use the > >> > >> struct_size() helper to do the arithmetic instead of the argument > >> > >> "size + count * size" in the kmalloc and kzalloc() functions. > >> > >> > >> > >> Also, take the opportunity to refactor the __sync_seqno and > >> > >> __sync_child > >> > >> making them more readable. > >> > >> > >> > >> This code was detected with the help of Coccinelle and audited and > >> > >> fixed > >> > >> manually. > >> > >> > >> > >> [1] > >> > >> https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments > >> > >> > >> > >> Signed-off-by: Len Baker > >> > >> --- > >> > >> drivers/gpu/drm/i915/i915_syncmap.c | 12 > >> > >> 1 file changed, 8 insertions(+), 4 deletions(-) > >> > > > >> > > I received a mail telling that this patch doesn't build: > >> > > > >> > > == Series Details == > >> > > > >> > > Series: drm/i915: Prefer struct_size over open coded arithmetic > >> > > URL : https://patchwork.freedesktop.org/series/95408/ > >> > > State : failure > >> > > > >> > > But it builds without error against linux-next (tag next-20211001). > >> > > Against > >> > > which tree and branch do I need to build? > >> > > >> > drm-tip [1]. It's a sort of linux-next for graphics. I think there are > >> > still some branches that don't feed to linux-next. > >> > >> Yeah we need to get gt-next in linux-next asap. Joonas promised to send > >> out his patch to make that happen in dim. > >> -Daniel > > > > Is there a possibility that you give an "Acked-by" tag? And then this patch > > goes to the mainline through the Kees' tree or Gustavo's tree? > > If this does not apply to drm-intel-gt-next (or drm-tip), applying it to > some other branch will just cause unnecessary conflicts later on. It's > unnecessary extra work. It's not an urgent fix or anything, there is no > reason to do that. So that's a NAK. Ok. Understood. > > Or is it better to wait for drm-tip to update? > > drm-tip is up to date, it's just that one of the branches that feed to > it is (was?) not feeding to linux-next. Sorry, but I'm missing something here. In linux-next this is the commit history of include/linux/stddef.h file: 3080ea5553cc stddef: Introduce DECLARE_FLEX_ARRAY() helper 50d7bd38c3aa stddef: Introduce struct_group() helper macro e7f18c22e6be stddef: Fix kerndoc for sizeof_field() and offsetofend() 4229a470175b stddef.h: Introduce sizeof_field() ... But in drm-tip this is the commit history: 4229a470175b stddef.h: Introduce sizeof_field() ... For this patch the DECLARE_FLEX_ARRAY() helper is needed. But the build fails due to the last tree commits for stddef.h file are not present. So, if I understand correctly, drm-tip is not up to date with linux-next. Regards, Len > > If you're contributing to drm, please consider basing your patches on > top of drm-tip. > > > BR, > Jani. > > > > > > Regards, > > Len > > > >> > >> > > >> > BR, > >> > Jani. > >> > > >> > > >> > [1] https://cgit.freedesktop.org/drm/drm-tip > >> > > >> > > >> > > > >> > > Regards, > >> > > Len > >> > > >> > -- > >> > Jani Nikula, Intel Open Source Graphics Center > >> > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> http://blog.ffwll.ch > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 26/28] drm/nouveau: use the new interator in nv50_wndw_prepare_fb
Am 13.10.21 um 16:29 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:40PM +0200, Christian König wrote:
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 8d048bacd6f0..30712a681e2a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -539,6 +539,8 @@ nv50_wndw_prepare_fb(struct drm_plane *plane, struct
drm_plane_state *state)
struct nouveau_bo *nvbo;
struct nv50_head_atom *asyh;
struct nv50_wndw_ctxdma *ctxdma;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
int ret;
NV_ATOMIC(drm, "%s prepare: %p\n", plane->name, fb);
@@ -561,7 +563,13 @@ nv50_wndw_prepare_fb(struct drm_plane *plane, struct
drm_plane_state *state)
asyw->image.handle[0] = ctxdma->object.handle;
}
- asyw->state.fence = dma_resv_get_excl_unlocked(nvbo->bo.base.resv);
+ dma_resv_iter_begin(&cursor, nvbo->bo.base.resv, false);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
+ /* TODO: We only use the first writer here */
Same thing as with the atomic core helper. This is actually broken,
because for atomic we really do _not_ want to wait for any shared fences.
Which this will do, if there's no exclusive fence attached.
So upgrading my general concern on this and the atomic helper patch to a
reject, since I think it's broken.
Since we simply had a misunderstanding with that could I get an rb for
that now?
Thanks,
Christian.
-Daniel
+ asyw->state.fence = dma_fence_get(fence);
+ break;
+ }
+ dma_resv_iter_end(&cursor);
asyw->image.offset[0] = nvbo->offset;
if (wndw->func->prepare) {
--
2.25.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev11)
== Series Details == Series: drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev11) URL : https://patchwork.freedesktop.org/series/81764/ State : success == Summary == CI Bug Log - changes from CI_DRM_10783_full -> Patchwork_21435_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_21435_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-snb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [FAIL][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4338]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb7/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb7/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb7/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb6/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/shard-snb2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb7/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb7/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb7/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb6/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb5/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb5/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb4/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb4/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/shard-snb4/boot.html [44]:
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix recursive lock in GuC submission
Quoting Thomas Hellström (2021-10-21 08:39:48)
> On Wed, 2021-10-20 at 12:21 -0700, Matthew Brost wrote:
> > Fixes: 1a52faed31311 ("drm/i915/guc: Take engine PM when a context is
> > pinned with GuC submission")
> > Signed-off-by: Matthew Brost
> > Cc: sta...@vger.kernel.org
This Cc: stable annotation is unnecessary.
Please always use "dim fixes 1a52faed31311" for helping to decide which
Cc's are needed. In this case stable is not needed. If it was, there
would be an indication of kernel version. In this case this is fine to
be picked up by in drm-intel-next-fixes PR.
Let's pay attention to the right Fixes: annotation while submitting and
reviewing patches.
Regards, Joonas
Re: [Intel-gfx] [PATCH v2 14/17] uapi/drm/dg2: Format modifier for DG2 unified compression and clear color
On 21.10.2021 17.35, Ville Syrjälä wrote: On Thu, Oct 21, 2021 at 07:56:24PM +0530, Ramalingam C wrote: From: Matt Roper DG2 unifies render compression and media compression into a single format for the first time. The programming and buffer layout is supposed to match compression on older gen12 platforms, but the actual compression algorithm is different from any previous platform; as such, we need a new framebuffer modifier to represent buffers in this format, but otherwise we can re-use the existing gen12 compression driver logic. DG2 clear color render compression uses Tile4 layout. Therefore, we need to define a new format modifier for uAPI to support clear color rendering. Signed-off-by: Matt Roper Signed-off-by: Mika Kahola (v2) Signed-off-by: Juha-Pekka Heikkilä Signed-off-by: Ramalingam C cc: Simon Ser Cc: Pekka Paalanen --- drivers/gpu/drm/i915/display/intel_display.c | 3 ++ .../drm/i915/display/intel_display_types.h| 10 +++- drivers/gpu/drm/i915/display/intel_fb.c | 7 +++ .../drm/i915/display/skl_universal_plane.c| 49 +-- include/uapi/drm/drm_fourcc.h | 30 5 files changed, 94 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 9b678839bf2b..2949fe9f5b9f 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -1013,6 +1013,9 @@ intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd) cmd->pixel_format); case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS: case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS: + case I915_FORMAT_MOD_F_TILED_DG2_RC_CCS: + case I915_FORMAT_MOD_F_TILED_DG2_MC_CCS: + case I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC: return lookup_format_info(gen12_ccs_formats, ARRAY_SIZE(gen12_ccs_formats), cmd->pixel_format); That seems not right. Flat CCS is invisible to the user so the format info should not include a CCS plane. I had cleaned out those rc and mc ccs from here long time ago, I wonder where did they come back from? On my development tree they're not there. Also I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC is here in totally wrong place, it should have its own gen12_flat_ccs_cc_formats table. /Juha-Pekka
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable PXP support
== Series Details == Series: Enable PXP support URL : https://patchwork.freedesktop.org/series/96232/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10782_full -> Patchwork_21434_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21434_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21434_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21434_full: ### IGT changes ### Possible regressions * igt@gem_pxp@hw-rejects-pxp-buffer: - shard-tglb: [PASS][1] -> [SKIP][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/shard-tglb5/igt@gem_...@hw-rejects-pxp-buffer.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-tglb1/igt@gem_...@hw-rejects-pxp-buffer.html Known issues Here are the changes found in Patchwork_21434_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-skl: NOTRUN -> [INCOMPLETE][3] ([i915#198]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-skl7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_sseu@engines: - shard-tglb: NOTRUN -> [SKIP][4] ([i915#280]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-tglb3/igt@gem_ctx_s...@engines.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][8] -> [SKIP][9] ([fdo#109271]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-tglb5/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/shard-glk6/igt@gem_exec_whis...@basic-contexts-priority-all.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-glk8/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-apl8/igt@gem_huc_c...@huc-copy.html * igt@gem_softpin@noreloc-s3: - shard-kbl: NOTRUN -> [DMESG-WARN][17] ([i915#180]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-kbl7/igt@gem_soft...@noreloc-s3.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-apl7/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@readonly-unsync: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#3297]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-tglb2/igt@gem_userptr_bl...@readonly-unsync.html * igt@gen3_render_mixed_blits: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/shard-tglb2/igt@gen3_render_mixed_blits.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([i915#1436] / [i915#71
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev11)
== Series Details == Series: drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev11) URL : https://patchwork.freedesktop.org/series/81764/ State : success == Summary == CI Bug Log - changes from CI_DRM_10783 -> Patchwork_21435 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/index.html Participating hosts (37 -> 33) -- Additional (1): fi-tgl-1115g4 Missing(5): bat-dg1-6 fi-bsw-cyan fi-ilk-650 bat-adlp-4 fi-ctg-p8600 Known issues Here are the changes found in Patchwork_21435 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([fdo#109315]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#1155]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#4103]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([fdo#109285]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#1072]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([i915#3301]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html Possible fixes * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [FAIL][10] ([i915#4165]) -> [PASS][11] +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][12] ([i915#4269]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [DMESG-WARN][14] ([i915#295]) -> [PASS][15] +18 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10783/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21435/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#4165]: https://gitlab.freedesktop.org/drm/intel/issues/4165 [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269 Build changes - * Linux: CI_DRM_10783 -> Patchwork_21435 CI-20190529: 20190529 CI_DRM_1
Re: [Intel-gfx] [PATCH 00/47] GuC submission support
Quoting Matthew Brost (2021-10-22 19:42:19) > On Fri, Oct 22, 2021 at 12:35:04PM +0300, Joonas Lahtinen wrote: > > Hi Matt & John, > > > > Can you please queue patches with the right Fixes: references to convert > > all the GuC tracepoints to be protected by the LOW_LEVEL_TRACEPOINTS > > protection for now. Please do so before next Wednesday so we get it > > queued in drm-intel-next-fixes. > > > > Don't we already do that? I checked i915_trace.h and every tracepoint I > added (intel_context class, i915_request_guc_submit) is protected by > LOW_LEVEL_TRACEPOINTS. > > The only thing I changed outside of that protection is adding the guc_id > field to existing i915_request class tracepoints. It's the first search hit for "guc" inside the i915_trace.h file :) > Without the guc_id in > those tracepoints these are basically useless with GuC submission. We > could revert that if it is a huge deal but as I said then they are > useless... Let's eliminate it for now and restore the tracepoint exactly as it was. If there is an immediate need, we should instead have an auxilary tracepoint which is enabled only through LOW_LEVEL_TRACEPOINTS and that amends the information of the basic tracepoint. For the longer term solution we should align towards the dma fence tracepoints. When those are combined with the OA information, one should be able to get a good understanding of both the software and hardware scheduling decisions. Regards, Joonas > > Matt > > > There's the orthogonal track to discuss what would be the stable set of > > tracepoints we could expose. However, before that discussion is closed, > > let's keep a rather strict line to avoid potential maintenance burned. > > > > We can then relax in the future as needed. > > > > Regards, Joonas > > > > Quoting Matthew Brost (2021-06-24 10:04:29) > > > As discussed in [1], [2] we are enabling GuC submission support in the > > > i915. This is a subset of the patches in step 5 described in [1], > > > basically it is absolute to enable CI with GuC submission on gen11+ > > > platforms. > > > > > > This series itself will likely be broken down into smaller patch sets to > > > merge. Likely into CTBs changes, basic submission, virtual engines, and > > > resets. > > > > > > A following series will address the missing patches remaining from [1]. > > > > > > Locally tested on TGL machine and basic tests seem to be passing. > > > > > > Signed-off-by: Matthew Brost > > > > > > [1] https://patchwork.freedesktop.org/series/89844/ > > > [2] https://patchwork.freedesktop.org/series/91417/ > > > > > > Daniele Ceraolo Spurio (1): > > > drm/i915/guc: Unblock GuC submission on Gen11+ > > > > > > John Harrison (10): > > > drm/i915/guc: Module load failure test for CT buffer creation > > > drm/i915: Track 'serial' counts for virtual engines > > > drm/i915/guc: Provide mmio list to be saved/restored on engine reset > > > drm/i915/guc: Don't complain about reset races > > > drm/i915/guc: Enable GuC engine reset > > > drm/i915/guc: Fix for error capture after full GPU reset with GuC > > > drm/i915/guc: Hook GuC scheduling policies up > > > drm/i915/guc: Connect reset modparam updates to GuC policy flags > > > drm/i915/guc: Include scheduling policies in the debugfs state dump > > > drm/i915/guc: Add golden context to GuC ADS > > > > > > Matthew Brost (36): > > > drm/i915/guc: Relax CTB response timeout > > > drm/i915/guc: Improve error message for unsolicited CT response > > > drm/i915/guc: Increase size of CTB buffers > > > drm/i915/guc: Add non blocking CTB send function > > > drm/i915/guc: Add stall timer to non blocking CTB send function > > > drm/i915/guc: Optimize CTB writes and reads > > > drm/i915/guc: Add new GuC interface defines and structures > > > drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor > > > drm/i915/guc: Add lrc descriptor context lookup array > > > drm/i915/guc: Implement GuC submission tasklet > > > drm/i915/guc: Add bypass tasklet submission path to GuC > > > drm/i915/guc: Implement GuC context operations for new inteface > > > drm/i915/guc: Insert fence on context when deregistering > > > drm/i915/guc: Defer context unpin until scheduling is disabled > > > drm/i915/guc: Disable engine barriers with GuC during unpin > > > drm/i915/guc: Extend deregistration fence to schedule disable > > > drm/i915: Disable preempt busywait when using GuC scheduling > > > drm/i915/guc: Ensure request ordering via completion fences > > > drm/i915/guc: Disable semaphores when using GuC scheduling > > > drm/i915/guc: Ensure G2H response has space in buffer > > > drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC > > > drm/i915/guc: Update GuC debugfs to support new GuC > > > drm/i915/guc: Add several request trace points > > > drm/i915: Add intel_context tracing > > > drm/i915/guc: GuC virtual engines > > > drm/i915: Hold reference to intel_context over life of i915
Re: [Intel-gfx] [PATCH] drm/i915: Add NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk
Hi,
On 10/25/21 10:25, Jani Nikula wrote:
> On Sun, 24 Oct 2021, Hans de Goede wrote:
>> Add a NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk to fix i915 not working on
>> the Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC).
>>
>> The Xiaomi Mi Pad 2 uses quite an unusual hardware-design for a Cherry
>> Trail tablet. It deviates from the typical reference design based tablets
>> in many ways.
>>
>> The Mi Pad 2 does not have any DisplayPort or HDMI outouts. I suspect that
>> as part of its unusual design it also has some supply rail which is only
>> used for DisplayPort or HDMI not connected.
>>
>> Force-enabling the dpio-common-bc powerwell as the i915 normal does at boot
>> appears to cause the P-Unit to hang. When booting with a serial-usb console
>> the following errors are logged before the system freezes:
>>
>> i915 :00:02.0: [drm] *ERROR* timeout setting power well state
>> (f3ff)
>> i915 :00:02.0: [drm] *ERROR* Display PHY 0 is not power up
>> [ cut here ]
>> i915 :00:02.0: DPIO read pipe A reg 0x8170 == 0x
>> WARNING: CPU: 3 PID: 258 at drivers/gpu/drm/i915/intel_sideband.c:257
>> vlv_dpio_read+0x95/0xb0 [i915]
>> ...
>> Call Trace:
>> chv_dpio_cmn_power_well_enable+0xab/0x210 [i915]
>> __intel_display_power_get_domain.part.0+0xa0/0xc0 [i915]
>> intel_power_domains_init_hw+0x26d/0x760 [i915]
>> intel_modeset_init_noirq+0x5d/0x270 [i915]
>> i915_driver_probe+0x6b6/0xd10 [i915]
>> ...
>>
>> If I disable the WARN about the register being 0x, so that the
>> system can log some more dmesg output over the serial console before
>> freezing, the following errors are also logged:
>>
>> i915 :00:02.0: [drm] *ERROR* timeout setting power well state
>> (fcfff3ff)
>> i915 :00:02.0: [drm] *ERROR* Display PHY 1 is not power up
>>
>> With this patch to disable the force-enabling of the PHY 0 / dpio-common-bc
>> powerwell in place, this error for PHY 1 goes away. So it seems that trying
>> the force-enabling of the PHY 0 / dpio-common-bc powerwell freezes the
>> P-Unit, causing the subsequent enabling of PHY 1 to also fail (and causing
>> the entire system to freeze within seconds).
>>
>> With this patch the PHY 1 error disappears and the entire system works.
>>
>> Note this change also moves the intel_init_quirks() call a bit up inside
>> intel_modeset_init_noirq() this is necessary so that the quirk is set
>> before the intel_power_domains_init_hw() call. This is harmless, all that
>> intel_init_quirks() does is set some bits in drm_i915_private.quirks and
>> make some drm_info() log calls.
>>
>> Reported-by: Tsuchiya Yuto
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
>> .../gpu/drm/i915/display/intel_display_power.c | 16 ++--
>> drivers/gpu/drm/i915/display/intel_quirks.c | 10 ++
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> 4 files changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 015854b5078c..1fb885cc86c9 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -12467,6 +12467,8 @@ int intel_modeset_init_noirq(struct drm_i915_private
>> *i915)
>> if (ret)
>> goto cleanup_bios;
>>
>> +intel_init_quirks(i915);
>> +
>> /* FIXME: completely on the wrong abstraction layer */
>> intel_power_domains_init_hw(i915, false);
>>
>> @@ -12501,8 +12503,6 @@ int intel_modeset_init_noirq(struct drm_i915_private
>> *i915)
>> INIT_WORK(&i915->atomic_helper.free_work,
>>intel_atomic_helper_free_state_worker);
>>
>> -intel_init_quirks(i915);
>> -
>> intel_fbc_init(i915);
>>
>> return 0;
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>> index cce1a926fcc1..eeaba3dc064b 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>> @@ -2090,8 +2090,14 @@ __intel_display_power_get_domain(struct
>> drm_i915_private *dev_priv,
>> if (intel_display_power_grab_async_put_ref(dev_priv, domain))
>> return;
>>
>> -for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
>> +for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain)) {
>> +if (domain == POWER_DOMAIN_INIT &&
>> +(dev_priv->quirks & QUIRK_NO_VLV_DISP_PW_DPIO_CMN_BC_INIT)
>> &&
>> +power_well->desc->id == VLV_DISP_PW_DPIO_CMN_BC)
>> +continue;
>> +
>> intel_power_well_get(dev_priv, power_well);
>> +}
>
> Cc: Imre
>
> There has got to be a way to hide this better. Having this here is
> unacceptable.
Thank you for your quick review.
For a first quick hack I just re
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add struct to hold IP version
On Fri, 22 Oct 2021, Lucas De Marchi wrote:
> On Thu, Oct 21, 2021 at 04:11:26PM +0300, Jani Nikula wrote:
>>On Wed, 20 Oct 2021, "Souza, Jose" wrote:
>>> On Wed, 2021-10-20 at 12:47 +0300, Jani Nikula wrote:
On Tue, 19 Oct 2021, José Roberto de Souza wrote:
> The constant platform display version is not using this new struct but
> the runtime variant will definitely use it.
Cc: Some more folks to hijack this thread. Sorry! ;)
We added runtime info to i915, because we had this idea and goal of
turning the device info to a truly const pointer to the info structures
in i915_pci.c that are stored in rodata. The idea was that we'll have a
complete split of mutable and immutable device data, with all the
mutable data in runtime info.
Alas, we never got there. More and more data that was mostly const but
sometimes needed tweaking kept piling up. mkwrite_device_info() was
supposed to be a clue not to modify device info runtime, but instead it
proliferated. Now we have places like intel_fbc_init() disabling FBC
through that. But most importantly, we have fusing that considerably
changes the device info, and the copying all of that data over to
runtime info probably isn't worth it.
Should we just acknowledge that the runtime info is useless, and move
some of that data to intel_device_info and some of it elsewhere in i915?
>>>
>>> With newer platforms getting more and more modular, I believe we will
>>> need to store even more mutable platform information.
>>>
>>> In my opinion a separation of immutable and mutable platform
>>> information is cleaner and easier to maintain.
>>
>>Yeah, that's kind of what the original point was with device and runtime
>>info split. It's just that a lot of the supposedly immutable platform
>>info has turned into mutable information.
>>
>>I think either we need to properly follow through with that idea, and
>>only store a const struct intel_device_info * to the rodata in
>>i915_pci.c, or just scrap it. None of this "almost immutable" business
>>that we currently have. "Almost immutable" means "mutable".
>>
>>The main problem is that we'll still want to have the initial values in
>>static data. One idea is something like this:
>>
>>struct intel_device_info {
>> const struct intel_runtime_info *runtime_info;
>>/* ... */
>>};
>>
>>static const struct intel_device_info i965g_info = {
>> .runtime_info = &i965g_initial_runtime_info;
>>/* ... */
>>};
>>
>>And things like .pipe_mask would be part of struct
>>intel_runtime_info. You'd copy the stuff over from intel_device_info
>>runtime_info member to i915->__runtime, but i915->__info would be a
>>const pointer to the device info. You'd never access the runtime_info
>>member after of intel_device_info after probe.
>
>
> I like this approach. I think the only problem would be that if someone
> inadvertently do a i915->__info->runtime_info they will be accessing the
> wrong data. So maybe to be clear do
>
> struct intel_device_info {
> const void *initial_runtime_info;
> /* ... */
> };
>
> static const struct intel_device_info i965g_info = {
> .initial_runtime_info = &i965g_initial_runtime_info;
> /* ... */
> };
>
> this would make it opaque and even hint by the name so the developer is
> not tempted to add a cast.
I think that's all fairly straightforward. Any ideas on how to do the
flags split cleanly, though? I already dislike the
DEV_INFO_FOR_EACH_FLAG() and DEV_INFO_DISPLAY_FOR_EACH_FLAG() split.
BR,
Jani.
>
> Lucas De Marchi
>
>>
>>It's just really painful, for instance because we already have two sets
>>of flags, display and non-display, and those would be multiplied to
>>mutable/immutable. And we should probably increase, not decrease, the
>>split between display and non-display. The macro horror show of
>>i915_pci.c would just grow worse.
>>
>>
>>BR,
>>Jani.
>>
>>
>>
>>>
BR,
Jani.
>>>
>>
>>--
>>Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Add NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk
On Sun, 24 Oct 2021, Hans de Goede wrote:
> Add a NO_VLV_DISP_PW_DPIO_CMN_BC_INIT quirk to fix i915 not working on
> the Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC).
>
> The Xiaomi Mi Pad 2 uses quite an unusual hardware-design for a Cherry
> Trail tablet. It deviates from the typical reference design based tablets
> in many ways.
>
> The Mi Pad 2 does not have any DisplayPort or HDMI outouts. I suspect that
> as part of its unusual design it also has some supply rail which is only
> used for DisplayPort or HDMI not connected.
>
> Force-enabling the dpio-common-bc powerwell as the i915 normal does at boot
> appears to cause the P-Unit to hang. When booting with a serial-usb console
> the following errors are logged before the system freezes:
>
> i915 :00:02.0: [drm] *ERROR* timeout setting power well state
> (f3ff)
> i915 :00:02.0: [drm] *ERROR* Display PHY 0 is not power up
> [ cut here ]
> i915 :00:02.0: DPIO read pipe A reg 0x8170 == 0x
> WARNING: CPU: 3 PID: 258 at drivers/gpu/drm/i915/intel_sideband.c:257
> vlv_dpio_read+0x95/0xb0 [i915]
> ...
> Call Trace:
> chv_dpio_cmn_power_well_enable+0xab/0x210 [i915]
> __intel_display_power_get_domain.part.0+0xa0/0xc0 [i915]
> intel_power_domains_init_hw+0x26d/0x760 [i915]
> intel_modeset_init_noirq+0x5d/0x270 [i915]
> i915_driver_probe+0x6b6/0xd10 [i915]
> ...
>
> If I disable the WARN about the register being 0x, so that the
> system can log some more dmesg output over the serial console before
> freezing, the following errors are also logged:
>
> i915 :00:02.0: [drm] *ERROR* timeout setting power well state
> (fcfff3ff)
> i915 :00:02.0: [drm] *ERROR* Display PHY 1 is not power up
>
> With this patch to disable the force-enabling of the PHY 0 / dpio-common-bc
> powerwell in place, this error for PHY 1 goes away. So it seems that trying
> the force-enabling of the PHY 0 / dpio-common-bc powerwell freezes the
> P-Unit, causing the subsequent enabling of PHY 1 to also fail (and causing
> the entire system to freeze within seconds).
>
> With this patch the PHY 1 error disappears and the entire system works.
>
> Note this change also moves the intel_init_quirks() call a bit up inside
> intel_modeset_init_noirq() this is necessary so that the quirk is set
> before the intel_power_domains_init_hw() call. This is harmless, all that
> intel_init_quirks() does is set some bits in drm_i915_private.quirks and
> make some drm_info() log calls.
>
> Reported-by: Tsuchiya Yuto
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> .../gpu/drm/i915/display/intel_display_power.c | 16 ++--
> drivers/gpu/drm/i915/display/intel_quirks.c | 10 ++
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 4 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 015854b5078c..1fb885cc86c9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12467,6 +12467,8 @@ int intel_modeset_init_noirq(struct drm_i915_private
> *i915)
> if (ret)
> goto cleanup_bios;
>
> + intel_init_quirks(i915);
> +
> /* FIXME: completely on the wrong abstraction layer */
> intel_power_domains_init_hw(i915, false);
>
> @@ -12501,8 +12503,6 @@ int intel_modeset_init_noirq(struct drm_i915_private
> *i915)
> INIT_WORK(&i915->atomic_helper.free_work,
> intel_atomic_helper_free_state_worker);
>
> - intel_init_quirks(i915);
> -
> intel_fbc_init(i915);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index cce1a926fcc1..eeaba3dc064b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -2090,8 +2090,14 @@ __intel_display_power_get_domain(struct
> drm_i915_private *dev_priv,
> if (intel_display_power_grab_async_put_ref(dev_priv, domain))
> return;
>
> - for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
> + for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain)) {
> + if (domain == POWER_DOMAIN_INIT &&
> + (dev_priv->quirks & QUIRK_NO_VLV_DISP_PW_DPIO_CMN_BC_INIT)
> &&
> + power_well->desc->id == VLV_DISP_PW_DPIO_CMN_BC)
> + continue;
> +
> intel_power_well_get(dev_priv, power_well);
> + }
Cc: Imre
There has got to be a way to hide this better. Having this here is
unacceptable.
BR,
Jani.
>
> power_domains->domain_use_count[domain]++;
> }
> @@ -2184,8 +2190,14 @@ __intel_display_power_put_domain(struct
> drm_i915_private *dev_priv,
>
> power_domains->domain_use_co
Re: [Intel-gfx] [PATCH] drm/i915/vlv_dsi: Double pixelclock on read-back for dual-link panels
On Sun, 24 Oct 2021, Hans de Goede wrote:
> In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk()
> for dual-link panels. This fixes the following WARN triggering:
>
> i915 :00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in pixel_rate
> (expected 235710, found 118056)
> i915 :00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in
> hw.pipe_mode.crtc_clock (expected 235710, found 118056)
> i915 :00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in
> hw.adjusted_mode.crtc_clock (expected 235710, found 118056)
> i915 :00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in port_clock
> (expected 235710, found 118056)
> [ cut here ]
> pipe state doesn't match!
> WARNING: CPU: 3 PID: 136 at
> drivers/gpu/drm/i915/display/intel_display.c:9125
> intel_display_finish_reset+0x1bd3/0x2050 [i915]
> ...
>
> This has been tested on a Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC) tablet,
> with a 1536x2048 dual-link DSI panel.
>
> Note this fix was taken from icl_dsi.c which does the same in
> its get_config().
>
> Cc: Tsuchiya Yuto
> Signed-off-by: Hans de Goede
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index 3e646a58b38a..2b7909bc52ff 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -1265,7 +1265,9 @@ static void intel_dsi_get_config(struct intel_encoder
> *encoder,
>struct intel_crtc_state *pipe_config)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> u32 pclk;
> +
> drm_dbg_kms(&dev_priv->drm, "\n");
>
> pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
> @@ -1277,6 +1279,9 @@ static void intel_dsi_get_config(struct intel_encoder
> *encoder,
> pclk = vlv_dsi_get_pclk(encoder, pipe_config);
> }
>
> + if (intel_dsi->dual_link)
> + pclk *= 2;
> +
> if (pclk) {
> pipe_config->hw.adjusted_mode.crtc_clock = pclk;
> pipe_config->port_clock = pclk;
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable PXP support
== Series Details == Series: Enable PXP support URL : https://patchwork.freedesktop.org/series/96232/ State : success == Summary == CI Bug Log - changes from CI_DRM_10782 -> Patchwork_21434 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/index.html Participating hosts (38 -> 34) -- Additional (1): fi-tgl-1115g4 Missing(5): bat-dg1-6 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 Known issues Here are the changes found in Patchwork_21434 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-1115g4: NOTRUN -> [SKIP][1] ([fdo#109315]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([fdo#109315] / [i915#2575]) +16 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#1155]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#4103]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-modeset@c-dp2: - fi-cfl-8109u: [PASS][8] -> [DMESG-WARN][9] ([i915#165]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([fdo#109285]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [PASS][11] -> [DMESG-WARN][12] ([i915#165] / [i915#295]) +20 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#3301]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][15] ([i915#1602] / [i915#2426] / [i915#4312]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][16] ([i915#3921]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][18] ([i915#4269]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10782/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21434/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]:
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix inconsistent IS_ERR and PTR_ERR
On 22/10/2021 13:06, Kai Song wrote:
Fix inconsistent IS_ERR and PTR_ERR in i915_gem_dmabuf.c
Signed-off-by: Kai Song
Pushed to drm-intel-gt-next. Thanks.
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 4a6bb64c3a35..3cc74b0fed06 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -102,7 +102,7 @@ static int igt_dmabuf_import_same_driver_lmem(void *arg)
obj = __i915_gem_object_create_user(i915, PAGE_SIZE, &lmem, 1);
if (IS_ERR(obj)) {
pr_err("__i915_gem_object_create_user failed with err=%ld\n",
- PTR_ERR(dmabuf));
+ PTR_ERR(obj));
err = PTR_ERR(obj);
goto out_ret;
}
@@ -158,7 +158,7 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
regions, num_regions);
if (IS_ERR(obj)) {
pr_err("__i915_gem_object_create_user failed with err=%ld\n",
- PTR_ERR(dmabuf));
+ PTR_ERR(obj));
err = PTR_ERR(obj);
goto out_ret;
}
[Intel-gfx] [PATCH V2 1/2] drm/i915/pxp: run CI with PXP and MEI_PXP enabled.
By default it will be off in normal builds. Signed-off-by: Tejas Upadhyay --- drivers/gpu/drm/i915/Kconfig.debug | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index e7fd3e76f8a2..fa181693184b 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -48,6 +48,8 @@ config DRM_I915_DEBUG select DRM_I915_DEBUG_RUNTIME_PM select DRM_I915_SW_FENCE_DEBUG_OBJECTS select DRM_I915_SELFTEST + select INTEL_MEI_PXP # used by igt/gem_pxp + select DRM_I915_PXP # used by igt/gem_pxp select BROKEN # for prototype uAPI default n help -- 2.31.1
[Intel-gfx] [PATCH V2 2/2] drm/i915/gt: Hold RPM wakelock during PXP suspend
selftest --r live shows failure in suspend tests when
RPM wakelock is not acquired during suspend.
This changes addresses below error :
<4> [154.177535] RPM wakelock ref not held during HW access
<4> [154.177575] WARNING: CPU: 4 PID: 5772 at
drivers/gpu/drm/i915/intel_runtime_pm.h:113
fwtable_write32+0x240/0x320 [i915]
<4> [154.177974] Modules linked in: i915(+) vgem drm_shmem_helper
fuse snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
ledtrig_audio mei_hdcp mei_pxp x86_pkg_temp_thermal coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_intel_dspcfg
snd_hda_codec snd_hwdep igc snd_hda_core ttm mei_me ptp
snd_pcm prime_numbers mei i2c_i801 pps_core i2c_smbus intel_lpss_pci
btusb btrtl btbcm btintel bluetooth ecdh_generic ecc [last unloaded: i915]
<4> [154.178143] CPU: 4 PID: 5772 Comm: i915_selftest Tainted: G
U5.15.0-rc6-CI-Patchwork_21432+ #1
<4> [154.178154] Hardware name: ASUS System Product Name/TUF GAMING
Z590-PLUS WIFI, BIOS 0811 04/06/2021
<4> [154.178160] RIP: 0010:fwtable_write32+0x240/0x320 [i915]
<4> [154.178604] Code: 15 7b e1 0f 0b e9 34 fe ff ff 80 3d a9 89 31
00 00 0f 85 31 fe ff ff 48 c7 c7 88 9e 4f a0 c6 05 95 89 31 00 01 e8
c0 15 7b e1 <0f> 0b e9 17 fe ff ff 8b 05 0f 83 58 e2 85 c0 0f 85 8d
00 00 00 48
<4> [154.178614] RSP: 0018:c900016279f0 EFLAGS: 00010286
<4> [154.178626] RAX: RBX: 888204fe0ee0
RCX: 0001
<4> [154.178634] RDX: 8001 RSI: 823142b5
RDI:
<4> [154.178641] RBP: 000320f0 R08:
R09: c000cd5a
<4> [154.178647] R10: 000f8c90 R11: c90001627808
R12:
<4> [154.178654] R13: 4000 R14: a04d12e0
R15:
<4> [154.178660] FS: 7f7390aa4c00() GS:88844f00()
knlGS:
<4> [154.178669] CS: 0010 DS: ES: CR0: 80050033
<4> [154.178675] CR2: 55bc40595028 CR3: 000204474005
CR4: 00770ee0
<4> [154.178682] PKRU: 5554
<4> [154.178687] Call Trace:
<4> [154.178706] intel_pxp_fini_hw+0x23/0x30 [i915]
<4> [154.179284] intel_pxp_suspend+0x1f/0x30 [i915]
<4> [154.179807] live_gt_resume+0x5b/0x90 [i915]
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 524eaf678790..65535f459f9b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -298,10 +298,14 @@ static void wait_for_suspend(struct intel_gt *gt)
void intel_gt_suspend_prepare(struct intel_gt *gt)
{
+ intel_wakeref_t wakeref;
+
user_forcewake(gt, true);
wait_for_suspend(gt);
- intel_pxp_suspend(>->pxp, false);
+ with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
+ intel_pxp_suspend(>->pxp, false);
+ }
}
static suspend_state_t pm_suspend_target(void)
--
2.31.1
[Intel-gfx] [PATCH V2 0/2] Enable PXP support
There are recent tests added in IGT which tests PXP. As PXP not enabled by default CI is skipping the tests. This patch series : 1. Enables PXP 2. Fixes the crash occures(RPM wakelock not acquired) after enabling PXP Tejas Upadhyay (2): drm/i915/pxp: run CI with PXP and MEI_PXP enabled. drm/i915/gt: Hold RPM wakelock during PXP suspend drivers/gpu/drm/i915/Kconfig.debug| 2 ++ drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.31.1
