On 13/12/2023 17:24, Tvrtko Ursulin wrote:
Hi Andrzej,
On 13/12/2023 16:13, Andrzej Hajda wrote:
On 13.12.2023 02:37, Patchwork wrote:
*Patch Details*
*Series:* drm/i915: (stolen) memory region related fixes
*URL:* https://patchwork.freedesktop.org/series/127721/
<https://patchwork.freedesktop.org/series/127721/>
*State:* failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v1/index.html <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v1/index.html>
CI Bug Log - changes from CI_DRM_14010 -> Patchwork_127721v1
Summary
*FAILURE*
Serious unknown changes coming with Patchwork_127721v1 absolutely
need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_127721v1, please notify your bug team
(I915-ci-infra@xxxxxxxxxxxxxxxxxxxxx) to allow them
to document this new failure mode, which will reduce false positives
in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v1/index.html
Participating hosts (31 -> 33)
Additional (4): bat-dg2-8 bat-dg2-9 bat-mtlp-8 fi-pnv-d510
Missing (2): bat-adlp-11 fi-snb-2520m
Possible new issues
Here are the unknown changes that may have been introduced in
Patchwork_127721v1:
IGT changes
Possible regressions
*
igt@i915_module_load@load:
o bat-mtlp-8: NOTRUN -> INCOMPLETE
<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_127721v1/bat-mtlp-8/igt@i915_module_load@xxxxxxxxx>
This is due to overlapping initial fb's vma with GuC reserved area on
MTL, see ggtt_reserve_guc_top.
My dirty quick_fix proposed:
@@ -143,6 +143,9 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(vma))
goto err_obj;
+ if (base + size > GUC_GGTT_TOP)
+ base = min(base, GUC_GGTT_TOP) - size;
+
I saw you posting this before but forgot to comment. I couldn't quite
figure out what the logic is supposed to do and how it wouldn't fail to
inherit any firmware setup splash screen?
Other than making the firmware aware and not use that range, I was
thinking what else we could do in i915? Copy the fb to a non-conflicting
location and re-program the display engine? If that is doable without
visible glitching and can be fast enough not to slow the boot a lot.
Unless I am missing something in your proposal?
Aha I missed the fact we write out new PTEs!
Display code will update without glitching to the new plane address?
Regards,
Tvrtko
