Prefer to use system memory for global framebuffers, and reserve
the space for FBC use only.
Now that multiple CRTC's can use FBC's, the simple heuristic
of using less than half of stolen is no longer sufficient.
Additionally, there are reports of system hangs when using stolen
memory, and there are also various workarounds that are avoided
by using system memory instead.
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260630135523.1775379-4-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
Remove the fallback for VRAM to system memory, I tested it and that
doesn't work at all, only a black screen with pipe fault errors were
observed.
On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6. Since we additionally aren't counting how
much memory is used for stolen and we could in theory fill up the
entire stolen area with DPT's, avoid using stolen and only use the
default memory region.
Using stolen may also result in random system hangs under load.
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Fixes: 775d0adc01 ("drm/xe/fbdev: Limit the usage of stolen for LNL+")
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
Do the PTE local memory bit check also for the case when
the initial FB lives in stolen. We have two cases to worry about
here: MTL+ with LMEMBAR, and pre-MTL with stolen being just
(slightly special) physical memory.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-11-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
Add a few helpers that allow us to abstract the xe initial FB PTE
check a bit. Still very ad-hoc compared to the nicely abstracted
i915 counterpart, but whatever.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-10-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
Inform the poor sop reading the logs why the initial FB was rejected
if there is no stolen memory.
Technically this should perhaps be an error since the plane is known
to be enabled at this point, and if there is no stolen then it clearly
can't be scanning out from anywhere. But maybe there are some
virtualization passthrough cases and whatnot where we might not be
able to get access to stolen, so keep it as debug (same as i915).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-9-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
For some reason we've split the alignment of 'base' vs. 'size'
to live on separate sides of the xe initial plane PTE readout.
There's no reason for this split, so make things less confusing
by aligning both at the same time.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-7-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
The initial FB stuff is ultimately about display stuff, so
use the proper display specific debug level for it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-6-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Hook the shared i915 display DP link KUnit tests into the xe display
test build.
Build the shared display test source from the i915 display test directory
when xe display support is enabled.
v2: Unchanged.
v3: Add SPDX license header. (Michał)
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260707124849.135319-2-imre.deak@intel.com
With the special d3cold handling in xe runtime suspend/resume separated,
unify the non-d3cold paths with i915. There are multiple changes here at
once that probably wouldn't make much sense to split out further.
Add the call to intel_display_driver_pm_runtime_suspend(), which, for
the time being, is a no-op. The intel_hpd_poll_enable() is called later.
Add the call to intel_display_driver_pm_runtime_suspend_late(), which
starts calling intel_display_power_runtime_suspend() and
intel_opregion_notify_adapter(). Deep down, the former should take care
of intel_dmc_wl_flush_release_work(), allowing us to drop the extra call
in xe_display_pm_runtime_suspend_late(). The intel_hpd_poll_enable()
call is also done here, postponed from the previous location in
xe_display_pm_runtime_suspend().
Add the call to intel_display_driver_pm_runtime_resume_early(), which
contains the intel_display_power_runtime_resume() and
intel_opregion_notify_adapter() counterparts to the calls in
intel_display_power_runtime_suspend_late().
Finally, intel_display_driver_pm_runtime_resume() replaces the direct
calls to intel_hpd_init(), intel_hpd_poll_disable(), and
skl_watermark_ipc_update(). (The hotplug poll enable/disable calls are
asymmetric.)
v2:
- Rebase, move placement of the calls
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/16205a1ee08e83f6e2f4dd30ed98fc043684a73e.1782913901.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add new display runtime PM hook xe_display_pm_runtime_resume_early(), to
be called before IRQ resume. This is initially a no-op placeholder.
Add comments on the timing relative to irq suspend/resume to all the
runtime PM hooks.
v2: Add stub for CONFIG_DRM_XE_DISPLAY=n
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260702071457.2985893-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Make the special d3cold paths completely separate from the rest of the
runtime pm calls.
The intel_dmc_wl_flush_release_work() call right after
xe_display_pm_suspend_late() might be completely redundant, but this
avoids any functional changes.
Wiggle the comment while at it. It gets duplicated for now, but this
will be addressed in the follow-up.
v2: Update comments
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/73693f137e9601e027ab7e7add2a7b08d5a2f675.1782913901.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add new high-level functions intel_display_driver_runtime_pm_enable()
and intel_display_driver_runtime_pm_disable() to abstract the low-level
functions intel_display_power_enable() and
intel_display_power_disable(), respectively.
The asymmetry in the "runtime pm enable/disable" and "pm runtime
suspend/etc" naming is intentional, with the latter intended to be
called from the PM hooks.
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/c95cb644a35ede7d4d456fd1654ce0b42b6eea33.1782913901.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently, xe_display_bo_framebuffer_init() unconditionally attempts to
apply XE_BO_FLAG_FORCE_WC to the buffer and rejects the FB creation with
-EINVAL if the BO is already VM_BINDed.
However, for imported dma-bufs (ttm_bo_type_sg), this check doesn't seem
to make much sense since CPU caching policy is entirely controlled by
the exporter. Plus there is no place to set this flag, in the first
place. Also this is not rejected if not yet vm_binded, but that seems
arbitrary since setting or not setting FORCE_WC should a noop either
way, at this stage, and whether it is currently VM_BINDed makes no
difference.
Currently if we run an app and offload rendering to an external dGPU,
like NV or another xe device, the dma-buf passed back to the compositor
(igpu) will be an actual external import from xe pov, and it will be
missing FORCE_WC, and if the compositor side did a VM_BIND before
turning into it into an fb the whole thing gets rejected.
So it looks like we either need to reject outright, no matter what, or
this usecase is valid and we need to loosen the restriction for sg
buffers. Proposing here to loosen the restriction.
Assisted-by: Gemini:gemini-3.1-pro-preview
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7919
Fixes: 44e694958b ("drm/xe/display: Implement display support")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Link: https://patch.msgid.link/20260612170501.550816-2-matthew.auld@intel.com
(cherry picked from commit 3e493f88c8)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
The intel_opregion_cleanup() call should really be in display. Move it
at the end of intel_display_driver_probe_noirq().
For xe, this is a completely non-functional change now that the
noirq/nogem cleanup calls are in the right order.
For i915, this only changes the relative order of
intel_opregion_cleanup() and i915_perf_fini(), which should be of no
consequence.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/8ccd49a5945e0560ba22079d686db1268e8e9f7f.1781549229.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The display driver init and cleanup calls are slightly asymmetric. The
cleanup order should be intel_display_driver_remove_noirq() and
intel_display_driver_remove_nogem(), not the other way around. This is
also what i915 does. Follow suit in xe.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/afb11c4e11cc4d946f0360aaad1664d004a93f41.1781549229.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_opregion_setup(), intel_dram_detect(), and intel_bw_init_hw()
calls should really be in display. Move them at the beginning of
intel_display_driver_probe_noirq().
This is a completely non-functional change for xe.
For i915, the init order changes slightly:
- i915_pcode_init() will happen before intel_opregion_setup(). This
should be of no consequence.
- The intel_gvt_init() calls will happen before the mentioned
functions. There's a lot going on in intel_gvt_init(), but it does not
look like this should have dependencies on them either.
Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Link: https://patch.msgid.link/aa37d6443516ae660c2de53aba8ca42e6e6d1a5c.1781549229.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Store tiling function pointer in struct intel_panic instead of struct
intel_framebuffer, and store struct intel_panic pointer instead of
struct intel_framebuffer pointer in struct drm_scanout_buffer private
member.
To make this happen, pass the tiling function pointer to panic setup
hook, and initialize sb->private in the hook for clarity.
This allows us to drop the dependency on struct intel_framebuffer from
i915 and xe panic code.
Note: It would be less verbose to have a typedef for the tiling function
pointer. However, there isn't a nice location for it that wouldn't also
increase header interdependencies.
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://patch.msgid.link/d97abae79db3437c617cd4cb6193ba017b3a8d78.1780394867.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The calls leading up to __intel_display_driver_pm_suspend() are
surrounded by near identical display calls. Move the calls inside
__intel_display_driver_pm_suspend() to clean up and deduplicate.
There's a slight functional change in that
intel_display_driver_pm_suspend() returns early for
!HAS_DISPLAY(). Assume this is what we want, and there are no cases
where display engine is present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/fdca3720537b6b79a754a83811d07b97d47e0db0.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Replace direct intel_display_driver_pm_suspend() and additional calls
with intel_display_driver_shutdown(). This switches to use
drm_atomic_helper_shutdown() instead of drm_atomic_helper_suspend(),
which is the more appropriate thing to do anyway.
Not calling intel_display_driver_pm_suspend() from the xe shutdown path
unblocks further follow-up changes.
There's a slight functional change in that
intel_display_driver_shutdown() returns early for !HAS_DISPLAY(). Assume
this is what we want, and there are no cases where display engine is
present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/e6783c063f8c0d4a2b413e550165896a3d977585.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add new function intel_display_driver_shutdown_late() to be called
"later" in the struct pci_driver .shutdown hook.
There's a slight functional change in that
intel_display_driver_shutdown_late() returns early for
!HAS_DISPLAY(). Assume this is what we want, and there are no cases
where display engine is present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/d200966191a3845e6b9586d20884e285670734d1.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add new functions intel_display_driver_pm_suspend_late() and
intel_display_driver_pm_resume_early(), to be called from the
corresponding struct dev_pm_ops hooks.
There's a slight functional change for !HAS_DISPLAY() in that the new
functions return early. Assume this is what we want, and there are no
cases where display engine is present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/a429a0ea7ac8e97a98c26ffe5be5db934267ec8d.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_display_driver_pm_resume() calls are surrounded by near
identical display calls. Move the calls inside
intel_display_driver_pm_resume().
There's a slight functional change in that
intel_display_driver_pm_resume() returns early for
!HAS_DISPLAY(). Assume this is what we want, and there are no cases
where display engine is present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/2cb01e10de88e6436c54643acbcef2afd3188a58.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_display_driver_pm_suspend() calls are surrounded by near
identical display calls. Move the calls inside
intel_display_driver_pm_suspend().
There's a slight functional change in that
intel_display_driver_pm_suspend() returns early for
!HAS_DISPLAY(). Assume this is what we want, and there are no cases
where display engine is present but all pipes have been fused off.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/82cfac0b966a8a82c8cf85e6b7b050223b7d5e33.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The shutdown functions get called from the struct pci_driver .shutdown
hook, not through the struct dev_pm_ops hooks. Name accordingly,
dropping the "pm" from the name, even if shutdown has a lot of
similarities with suspend.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/8d5b5aa92cff77a99b3687c231a50ec576d6f37e.1780389001.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Fix Xe oops in suspend/shutdown when display was disabled (Jani)
Display in general:
- More general refactor towards display separation (Jani)
- Preparation for fix Adaptive-Sync SDP for PR with Link ON + Auxless-ALPM (Ankit)
- PSR related fixes and improvements (Jouni)
- Use polling when irqs are unavailable (Michal)
- Split bandwidth params into platform- and display-IP-specific structs (Gustavo)
- Revert "drm/i915/backlight: Remove try_vesa_interface" (Suraj)
- Casf & scaler refactoring (Michal)
- Add support for pipe background color (Maarten)
- General clean-ups (Maarten)
- Sanitize DP link capability change handling (Imre)
- Multiple BW QGV fixes (Ville)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmoYRLYACgkQ+mJfZA7r
E8rtVQgArEfJhvSxvoALAQjfeM/mjWHj0AThfCxROed2Z1TO5WN+BB9hXzwGwEqA
EE6TnKhDEQZy22a/t/iNhDDUy1UTYifMbfFAsdVz7NYfXKZpkRdJ4/mZk6MVEcrd
jEbrIw8ZQ7SPTvhVdKn6zWvLzPskrJqzfIS4JFYJn61MepfD+QhOayoUxEU9gTjZ
+SNSHu0lQSpwYwz+0AV65CkDwSbFZDqMLtDd8MxI0b4X8kjX1D9MH+QNu2wYnk7i
9hqcErJ/jH/hMCNHwCIdPh6sfli8qpN7GbAdDcgkA+/E0hsJBkdJe2cSDGxUA/Ws
76P8PjtZ3sGbq7vPL/Db6t0lY1yVJQ==
=cTLp
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2026-05-28' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Xe related:
- Fix Xe oops in suspend/shutdown when display was disabled (Jani)
Display in general:
- More general refactor towards display separation (Jani)
- Preparation for fix Adaptive-Sync SDP for PR with Link ON + Auxless-ALPM (Ankit)
- PSR related fixes and improvements (Jouni)
- Use polling when irqs are unavailable (Michal)
- Split bandwidth params into platform- and display-IP-specific structs (Gustavo)
- Revert "drm/i915/backlight: Remove try_vesa_interface" (Suraj)
- Casf & scaler refactoring (Michal)
- Add support for pipe background color (Maarten)
- General clean-ups (Maarten)
- Sanitize DP link capability change handling (Imre)
- Multiple BW QGV fixes (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/ahhFE5Co5PdZQKG8@intel.com
The detect hook of connectors - called by HPD polling - will check if
user accesses are enabled and prevent the connector detection if that's
not the case. Accordingly enable user accesses during system resume by
calling intel_display_driver_enable_user_access() before enabling HPD
polling.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/f9803b937ba3044052a81e1673ac374809548ba7.1780310011.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
It's confusing that intel_display_power.[ch] exposes two groups of
interfaces, one named intel_power_domains_*() and one
intel_display_power_*().
Unify on the latter, based on the file name, but also because it's more
generic. This makes the caller side easier to follow.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/8fae4b0e3476aeffb0164215b7e0f0ae1d825f72.1779800132.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
xe_display_flush_cleanup_work() is a bit of an oddball function in xe
display code. There shouldn't be anything this specific or xe
specific. While I'm not sure what the correct refactor for the function
should be, move it to shared display code for starters, next to the
eerily similar but slightly different intel_has_pending_fb_unpin() that
is only called from i915 core.
The main goal here is to unblock some refactors on
for_each_intel_crtc().
v2: Add FIXME comment (Ville)
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260525110553.651208-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add a number of *_display_irq_handler() functions to group together the
various display irq handler parts for the platforms, to declutter the
core i915 irq code from the details.
Add master_ctl to struct intel_display_irq_state, and pass the state
pointer to the handlers where necessary. The handler function signatures
are intentionally the same to allow for more refactoring.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/5088a9a658ce9a57049c999ee2ebababd7536b6c.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Call the platform specific display irq postinstall hooks via
intel_display_irq_postinstall().
Relocate the gen11 HAS_DISPLAY() check to
intel_display_irq_postinstall(), as the funcs pointer won't be
initialized for no display.
v2:
- relocate HAS_DISPLAY() (Sashiko)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/65f1ad73628fb6dbdf6e782493eaecb1d61abaf7.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Introduce display irq hooks with struct intel_display_irq_funcs, and add
the ->reset hook as the first thing. Call the reset hooks from i915 and
xe core via intel_display_irq_reset().
Relocate the gen8 and gen11 HAS_DISPLAY() check to
intel_display_irq_reset(), as the funcs pointer won't be initialized for
no display.
Note: We're increasingly moving to the territory of not touching display
at all if there's no display or it has been fused off. Which is good,
but care must be taken to not have hardware setup required also for no
display cases in display code. Also note that the line is fuzzy for
older platforms, but there we also don't have fusing.
v2:
- make the structs static const (Sashiko)
- relocate HAS_DISPLAY() (Sashiko)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/f9d75e8af92b5550a9d07f29491be5313b7c866b.1778688699.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The xe driver keeps track of whether to probe display, and whether
display hardware is there, using xe->info.probe_display. It gets set to
false if there's no display after intel_display_device_probe(). However,
the display may also be disabled via fuses, detected at a later time in
intel_display_device_info_runtime_init().
In this case, the xe driver does for_each_intel_crtc() on uninitialized
mode config in xe_display_flush_cleanup_work(), leading to a NULL
pointer dereference, and generally calls display code with display info
cleared.
Check for intel_display_device_present() after
intel_display_device_info_runtime_init(), and reset
xe->info.probe_display as necessary. Also do unset_display_features()
for completeness, although display runtime init has already done
that. This will need to be unified across all cases later.
Move intel_display_device_info_runtime_init() call slightly earlier,
similar to i915, to avoid a bunch of unnecessary setup for no display
cases.
Note #1: The xe driver has no business doing low level display plumbing
like for_each_intel_crtc() to begin with. It all needs to happen in
display code.
Note #2: The actual bug is present already in commit 44e694958b
("drm/xe/display: Implement display support"), but the oops was likely
introduced later at commit ddf6492e0e ("drm/xe/display: Make display
suspend/resume work on discrete").
Fixes: 44e694958b ("drm/xe/display: Implement display support")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7904
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/6150
Cc: stable@vger.kernel.org # v6.8+
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260515160920.1082842-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Instead of updating drm_driver.driver_features in the runtime, we
can use macro which value depends on the CONFIG_DRM_XE_DISPLAY.
And if display support is later disabled by the xe_modparam then we
will clear related bits in the drm_device.driver_features instead.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260512183342.3374-6-michal.wajdeczko@intel.com
Instead of updating the drm_driver.fbdev_probe field in the runtime,
we can use macro which value depends on the actual Kconfig setup.
The .fbdev_probe hook will not be used by the drm core unless we
also enable a DRIVER_MODESET driver feature flag, and this flag
still depends on the xe_modparam.probe_display parameter.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260512183342.3374-5-michal.wajdeczko@intel.com
There is no need to include xe_device.h in the xe_display.h header.
Include it in the xe_display.c file instead.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260512183342.3374-4-michal.wajdeczko@intel.com
