Hey, Is a single performance hit during boot allowed? If so, this is a better solution, as it helps on !PREEMPT_RT as well:
https://patchwork.freedesktop.org/series/170759/ The first patch in that series is a better solution than unconditionally disabling stolen memory, as I from what I understand the problem only exists when media gt is enabled. If not, we should probably unconditionally disable stolen framebuffer all the time. But with the series, we preserve the initial framebuffer contents and ensure a smooth handover, even without stolen. The warning in 2/2 is probably fine. Kind regards, ~Maarten Lankhorst On 11/4/26 04:27, Junxiao Chang wrote: > CPU access to stolen memory ranges can introduce latency spikes that > compromise real-time (RT) guarantees on PREEMPT_RT kernels. > > On PREEMPT_RT configurations, bypass retrieving the initial plane's > framebuffer from stolen memory. This forces the driver to fall back to > standard allocations, preventing RT latency degradation at the expense > of seamless boot display takeover. > > Signed-off-by: Junxiao Chang <[email protected]> > --- > drivers/gpu/drm/xe/display/xe_initial_plane.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/xe/display/xe_initial_plane.c > b/drivers/gpu/drm/xe/display/xe_initial_plane.c > index 0f86b73036d03..fd0e2962412dd 100644 > --- a/drivers/gpu/drm/xe/display/xe_initial_plane.c > +++ b/drivers/gpu/drm/xe/display/xe_initial_plane.c > @@ -87,6 +87,12 @@ initial_plane_bo(struct xe_device *xe, > struct ttm_resource_manager *stolen; > u64 pte; > > + if (IS_ENABLED(CONFIG_PREEMPT_RT)) { > + drm_dbg_kms(&xe->drm, > + "Skipping FB allocation from stolen mem due > to PREEMPT_RT\n"); > + return NULL; > + } > + > stolen = ttm_manager_type(&xe->ttm, XE_PL_STOLEN); > if (!stolen) { > drm_dbg_kms(&xe->drm, "No stolen for initial FB\n");
