drm/i915/display: add struct intel_irq_regs and use it

Add struct intel_irq_regs, a display version of struct i915_irq_regs,
and use it. The goal is to reduce the dependency on i915 core types and
headers.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/56118c2e40e171e898034a7bea6c8d14f515f5c1.1777972548.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: add typedef for intel_reg_t and use it

Add a typedef alias intel_reg_t for i915_reg_t, and use it exclusively
in display code. The goal is to eventually define a distinct type for
display, but for now just use an alias.

In a handful of places include intel_display_reg_defs.h instead of
i915_reg_defs.h to get the definition, and isolate the i915_reg_defs.h
include there.

Reviewed-by: Michał Grzelak <michal.grzelak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/f5bb0122143c39ce7f9ce8a1605a7637e569f7f8.1777972548.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: Copy color pipeline from plane in the primary joiner pipe

When copying plane color state in a joiner configuration, use the plane in
the primary joiner pipe since it carries the pipeline number selected by
the user-space.

This assumes that all pipes in the joiner are symmetric in their plane
color capabilities.

Cc: stable@vger.kernel.org # v6.19+
Fixes: a78f1b6baf4d ("drm/i915/color: Add framework to program CSC")
Tested-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260511053213.3122314-2-chaitanya.kumar.borah@intel.com

drm/i915: Consolidate the intel_plane_(un)pin_fb() implementations

Currently i915 and xe each implement their own versions of
intel_plane_(un)pin(). Now that we have the fb_pin parent
interface we can consolidate this to a single implementation.

The result is a mixture of the i915 and xe implementations.
The reuse_vma() hack comes from xe (and i915 doesn't implement
that part of the parent interface, and the pin_params are
taken from i915 since the platforms supported by i915 need
more things.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-17-ville.syrjala@linux.intel.com

drm/xe: Use xe_fb_pin_ggtt_pin() for the initial FB pin

Use xe_fb_pin_ggtt_pin() instead of intel_fb_pin_to_ggtt() for
the initial FB pin. We want to get rid of intel_fb_pin_to_ggtt()
and just use the new fb_pin parent interface.

This still isn't quite the final solution since we bypass the
actual parent interface and call the implementation directly.
But sorting that out will require more cleanup to the initial
FB code.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-16-ville.syrjala@linux.intel.com

drm/i915/fbdev: Use intel_parent_fb_pin_ggtt_(un)pin()

Replace the intel_fb_pin_to_ggtt() and intel_fb_unpin_vma() with the
new abstract parent interface (intel_parent_fb_pin_ggtt_(un)pin()).

xe no longer needs intel_fb_unpin_vma(), and in i915 it now
becomes and internal function to i915_fb_pin.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-15-ville.syrjala@linux.intel.com

drm/i915: Introduce the main fb_pin parent interface

Introduce the main part of the new fb_pin parent interface:
- intel_parent_fb_pin_ggtt_(un)pin()
- intel_parent_fb_pin_dpt_(un)pin()
- intel_parent_fb_pin_reuse_vma()

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-14-ville.syrjala@linux.intel.com

drm/xe: Restructure reuse_vma()

Restructure reuse_vma() into a form that doesn't need the plane
state structs, and rename the result to xe_fb_pin_reuse_vma().
This will become the new fb_pin parent interface.

v2: Fix memcmp() arguments

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-13-ville.syrjala@linux.intel.com

drm/xe: Introduce xe_fb_pin_ggtt_(un)pin()

Extract the inner DPT parts of intel_plane_(un)pin() into the
xe_fb_pin_ggtt_(un)pin(). These will become part of the new
fb_pin parent interface.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-12-ville.syrjala@linux.intel.com

drm/xe: Introduce xe_fb_pin_dpt_(un)pin()

Extract the inner DPT parts of intel_plane_(un)pin() into the
xe_fb_pin_dpt_(un)pin(). These will become part of the new
fb_pin parent interface.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-11-ville.syrjala@linux.intel.com

drm/xe: Reorganize intel_plane_pin_fb() a bit

Move most of the plane state stuff out from the inner parts
of intel_plane_pin_fb(). The plan is to take those inner parts and
abstract them into the new fb_pin parent interface, and we don't
want any plane_state stuff there.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-10-ville.syrjala@linux.intel.com

drm/xe: Kill the fbdev vma reuse hack

This fbdev vma reuse hacks is a massive layering violation. It
really does not belong in the fb pinning code. And it's in the
way of properly abstracting this stuff, so kill it.

I don't think this hack even does anything useful because the
normal view will just use bo->ggtt_node when present, and the
fbdev bo will be permanenly pinned with xe_bo_create_pin_map_at_novm()
which does set up bo->ggtt_node. So we should never end up
rebuilding the PTEs for the fbdev bo, even without the reuse hack.

v2: Pimp the commit message a a bit (Jani)
v3: Also nuke intel_fbdev_vma_pointer()

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-9-ville.syrjala@linux.intel.com

drm/xe: Move the FORCE_WC assert into __xe_pin_fb_vma()

No need to bother the higher level pinning code with the
FORCE_WC assert. Move it into the lower level function.

This also introduces the check to intel_fb_pin_to_ggtt(), which
(for the moment) is still used for the fbdev bo setup. But this
is all display stuff we're talking about here so having the check
is correct everywhere.

v2: Pimp the commit message a bit (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-8-ville.syrjala@linux.intel.com

drm/i915: Introduce i915_fb_pin_ggtt_(un)pin()

Extract the inner DPT parts of intel_plane_(un)pin() into the
i915_fb_pin_ggtt_(un)pin(). These will become part of the new
fb_pin parent interface.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-7-ville.syrjala@linux.intel.com

drm/i915: Introduce i915_fb_pin_dpt_(un)pin()

Extract the inner DPT parts of intel_plane_(un)pin() into the
i915_fb_pin_dpt_(un)pin(). These will become part of the new
fb_pin parent interface.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-6-ville.syrjala@linux.intel.com

drm/i915: Reorganize intel_plane_pin_fb() a bit

Move most of the plane state stuff out from the inner parts
of intel_plane_pin_fb(). The plan is to take those inner parts and
abstract them into the new fb_pin parent interface, and we don't
want any plane_state stuff there.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-5-ville.syrjala@linux.intel.com

drm/i915: Move the i915_dpt_offset()==0 assert

Move the i915_dpt_offset() check into the lower level
intel_fb_pin_to_dpt() function. Clears out some of the unnecessary
junk from the higher level code, making it easier to introduce
the new fb_pin parent interface.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-4-ville.syrjala@linux.intel.com

drm/i915: Move intel_fb_pin_params to the parent interface

strut intel_fb_pin_params will be an important part of the fb_pin
interface, so move the definition to the parent interface file.

Or maybe we should have a separate header for this kind of stuff
since the users of the parent interface will need the struct
definition but not the parent interface vfunc struct definitions?

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-3-ville.syrjala@linux.intel.com

drm/i915: Introduce intel_parent_fb_pin_get_map()

Introduce the "fb_pin" parent interface, as the first trivial step
move the *_get_map() stuff there.

The whole "fb_pin" as an interface might not really make sense,
and perhaps this (and other stuff) should just be collected into
some kind of "bo" interface. But let's go with "fb_pin" for now
to match where things are implemented, and possibly restructure
it later.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260508143426.26504-2-ville.syrjala@linux.intel.com

drm/i915/dp: Fix VSC dynamic range signaling for RGB formats

For RGB, set dynamic_range to CTA or VESA based on
crtc_state->limited_color_range so sinks apply correct
quantization. YCbCr remains limited (CTA) range.
(DP v1.4, Table 5-1)

v2:
- Added Reported-by and Tested-by tags

v3:
- Add back YCbCr comment(Suraj)

Cc: stable@vger.kernel.org #v5.8+
Reported-by: DeepChirp <DeepChirp@outlook.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15874
Tested-by: DeepChirp <DeepChirp@outlook.com>
Fixes: 9799c4c3b76e ("drm/i915/dp: Add compute routine for DP VSC SDP")
Assisted-by: GitHub-Copilot:GPT-5.4
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260505090920.2479112-1-chaitanya.kumar.borah@intel.com

Documentation/gpu: add remaining DOC: comments to Intel display documentation

Not all of the overview DOC: comments in the display driver are
incorporated into the documentation. Add the missing ones, including
some function documentation.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/589c46cf9a46763f4fbb7e1756656e6d71ba1431.1778235406.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Documentation/gpu: use === for Intel display section heading underlines

Prefer to use === instead of --- for top level section heading
underlines to allow using the latter for sub-headings later.

While at it, fix the underline lenghts where needed.

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/f49968792220ca3ff24efde813550850340d092e.1778235406.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Documentation/gpu: add dedicated documentation for Intel display

Nowadays, the display support for drm/i915 and drm/xe is shared between
the drivers, even though the code is located under drm/i915/display.

The drm/i915 documentation has everything, including display topics, in
one huge page, while the drm/xe documentation is well-organized but
hardly mentions display. It's not great, to put it mildly.

Split out the Intel display documentation to a dedicated directory,
Documentation/gpu/intel-display. Also directly split the
functionality/feature documentation to dedicated pages to keep the main
index page high level and readable. We'll want to organize this further,
but just sort them alphabetically for starters.

Drop the boilerplate documentation sections that don't actually document
anything.

Cross-reference drm/i915, drm/xe, and intel-display.

Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/21bfa7777eb0926eadd309d4c6f5c9cf48405cf0.1778235406.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/ddi: Fix cleanup after HDMI connector init failure

Perform the missing DDI DP connector cleanup steps after HDMI connector
initialization failure during DDI encoder/connector initialization.

This fixes the leaked DP MST encoder, AUX state, and connector object.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260507065940.2046690-2-imre.deak@intel.com

drm/i915/ddi: Fix cleanup after DP connector init failure

Fix the error path during DDI encoder/connector initialization by
calling the missing TC port cleanup function.

This fixes the leaked TC port state.

Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260507065940.2046690-1-imre.deak@intel.com

drm/i915/dp: Drop call to intel_panel_fixed_mode() from compute_config

At the moment, in intel_dp_compute_config(), intel_panel_fixed_mode() is
called to check if the panel has any fixed mode or not. If it is an eDP
and has the fixed mode, then intel_panel_compute_config() is called.

However, the intel_panel_compute_config already checks if the panel
supports a fixed mode and returns early if it doesn't. This makes the
earlier check in the caller redundant.
Remove this extra check for intel_panel_fixed_mode().

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-6-ankit.k.nautiyal@intel.com

drm/i915/intel_sdvo: Drop call to intel_panel_fixed_mode() from compute_config

Currently, in intel_sdvo_compute_config(), intel_panel_fixed_mode() is
called to get the fixed mode. However, since the call is made after
intel_panel_compute_config, that copies the selected fixed mode to the
adjusted mode, we can directly use the crtc_state->hw.adjusted_mode.

So remove the extra call to intel_panel_fixed_mode() and use adjusted
mode instead.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-5-ankit.k.nautiyal@intel.com

drm/i915/intel_dvo: Drop call to intel_panel_fixed_mode() from compute_config

The function intel_dvo_compute_config() calls intel_panel_fixed_mode() only
to check if there is a valid fixed_mode and based on that it then calls
intel_panel_compute_config().

However, since the intel_panel_compute_config() already checks for
fixed_mode and we can drop the call to intel_panel_fixed_mode().

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-4-ankit.k.nautiyal@intel.com

drm/i915/intel_panel: Avoid calls to intel_panel_fixed_mode() in mode_valid

Currently, most callers of intel_panel_mode_valid() also call
intel_panel_fixed_mode(). This is done either to check for the presence of
a fixed mode for the connector or to get the clock of the fixed mode, which
is then compared against the max dotclock for the pipe.

Since intel_panel_mode_valid() already calls intel_panel_fixed_mode()
internally, we can avoid yet another call to intel_panel_fixed_mode() from
the caller.

Remove the redundant call to intel_panel_fixed_mode() in mode_valid paths.
To get the clock for the fixed mode, extend the helper
intel_panel_mode_valid() to accept 'target_clock' as an out param.
The 'target_clock' can then be used by the callers to check against the
max dotclock.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-3-ankit.k.nautiyal@intel.com

drm/i915/intel_sdvo: Check fixed_mode->clock against max_dotclock in mode_valid

For LVDS SDVO, mode validation checks the requested mode against the
pipe max dotclock, but does not validate the selected fixed mode clock.

After intel_panel_mode_valid(), get the fixed mode and validate its
clock against the max dotclock.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-2-ankit.k.nautiyal@intel.com

drm/i915/hdcp: Skip inactive MST connectors when building stream list

intel_hdcp_required_content_stream() walks every connector on the
digital port to populate hdcp_port_data->streams[]. The only filter is
connector_status_disconnected, which reflects physical presence on the
MST topology, not whether the connector currently drives a stream.
On a multi-sink MST setup where only a subset of sinks are modeset,
the loop can pick a sibling MST connector that is connected but has
no active CRTC / VC payload. intel_conn_to_vcpi() then logs "MST
Payload not present" and returns 0, and the bogus StreamID=0 is
written to the repeater in RepeaterAuth_Stream_Manage (DPCD 0x693F0).
Authentication completes, but the repeater shortly raises
LINK_INTEGRITY_FAILURE (RxStatus 0x69493 bit4) because the StreamID
does not match any stream on its input. The HDCP check work then
tears the link down, the Content Protection property drops back to
DESIRED, and userspace observes a spurious HDCP enable failure.
Filter the connector iteration to only those with a CRTC assigned in
the new atomic state, so intel_conn_to_vcpi() is called for the
connector actually being enabled and reads its real VCPI from the MST
topology state.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Link: https://patch.msgid.link/20260505094022.4064256-1-suraj.kandpal@intel.com

drm/xe: Respect pin_params.alignment for GGTT

Fix __xe_pin_fb_vma_ggtt() to actually respect the GGTT alignment
specified by the display code. Misalignment can cause GTT faults
etc.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260430154602.11393-2-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

drm/xe: Use fb cached min alignment

Instead of just looking at the first plane use the fb cached overall
minimum alignment.

This aligns with how the i915 version of intel_plane_pin_fb works.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
[vsyrjala: Rebase due to pin_params]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260430154602.11393-1-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

drm/i915/irq: drop unnecessary forward declarations and includes

The i915_irq.h header has a bunch of leftover forward declarations and
includes. Remove them.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260505084150.3346378-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Revert "drm/i915: replace select with dependency for visible DEBUG_OBJECTS"

This reverts commit 025f89b01ed8d5e65d87ed54f231e10c6ac08188.

025f89b01ed8 ("drm/i915: replace select with dependency for visible
DEBUG_OBJECTS") breaks the build in certain scenarios, presumably
because config DRM_I915_DEBUG selects DRM_I915_SW_FENCE_DEBUG_OBJECTS
without looking at its dependencies, allowing
DRM_I915_SW_FENCE_DEBUG_OBJECTS=y and DEBUG_OBJECTS=n.

Fixes: 025f89b01ed8 ("drm/i915: replace select with dependency for visible DEBUG_OBJECTS")
Cc: Julian Braha <julianbraha@gmail.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Link: https://patch.msgid.link/20260506101957.202271-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: replace select with dependency for visible DEBUG_OBJECTS

DRM_I915_SW_FENCE_DEBUG_OBJECTS currently selects DEBUG_OBJECTS even though
DEBUG_OBJECTS is visible to users. Other config options use 'depends on'
for DEBUG_OBJECTS, so let's do the same here.

This select-visible Kconfig misusage was detected by Kconfirm, a static
analysis tool for Kconfig.

Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260502191932.4491-1-julianbraha@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: remove HAS_PCH_NOP() dependency from clock gating

intel_pch_init_clock_gating() already handles unsupported PCH types,
including PCH_NOP, by doing nothing.

Drop the explicit HAS_PCH_NOP() check from the IVB clock gating
path and always call the display helper directly. This removes one
more direct dependency on display-side PCH macros from
intel_clock_gating.c.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-9-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915/display: move pre-HSW clock gating init to display

Move the remaining pre-HSW display clock gating programming into
display.

This also drops display register includes from intel_clock_gating.c.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-8-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915/display: move HSW and BDW clock gating init to display

Move the HSW and BDW display clock gating programming into the display
code.  In this case we need two different helpers, because the common
code between these two is split in the middle.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-7-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915/display: move GLK clock gating init to display

Move the GLK-specific display clock gating programming into display
intel_display_clock_gating.c, to remove more dependencies from i915 to
display registers.

Now that all remaining Gen9-family callers moved into display, we can
move the shared Gen9 display clock gating helper into display and
remove the old local helper from intel_clock_gating.c.

Additionally, the SKL_DE_COMPRESSED_HASH_MODE programming was
protected by HAS_LLC(), but that's incidental, because in Gen9
platforms, only SKL and KBL, for which this workaround applies, have
LLC().  In order not to use HAS_LLC() in display code, we can simply
remove this check from the generic Gen9 function and move the
SKL_DE_COMPRESSED_HASH_MODE programming to the KBL and SKL specific
functions.  And, intentionally or not, CFL and CML were also using
this workaround, because they also have LLC, even though the comments
were only mentioning SKL and KBL.  In order not to change anything
functionally with this patch, the workaround was also added to
intel_display_cfl_init_clock_gating().

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-6-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915/display: move BXT clock gating init to display

Move the BXT-specific display clock gating programming into display
intel_display_clock_gating.c, to remove more dependencies from i915.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-5-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915/display: move CFL clock gating init to display

Move the CFL/CML-specific display clock gating programming into
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-4-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915: move KBL clock gating init to display

Move the KBL-specific display clock gating programming into a
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-3-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915: move SKL clock gating init to display

Move the SKL-specific display clock gating programming into a new file
inside display.

This removes dependency from intel_clock_gating.c to the display's
intel_pch.h file, so we can remove the include statement.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-2-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915/hdcp: Drop mgr->base.lock acquisition in intel_conn_to_vcpi()

Now that intel_conn_to_vcpi() reads the MST topology state via
drm_atomic_get_new_mst_topology_state(), the topology state belongs
to this atomic commit and is already serialized through the atomic
state's private object machinery. There is no need to additionally
take mgr->base.lock here.
Taking it from the HDCP enable path in commit_tail with
state->base.acquire_ctx is also unsafe: by this point the
acquire_ctx is no longer in a state where new modeset locks may be
acquired through it, which produces a modeset-lock splat on MST +
HDCP. Drop the drm_modeset_lock() call.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Link: https://patch.msgid.link/20260504101117.3619984-3-suraj.kandpal@intel.com

drm/i915/hdcp: Use new MST topology state in intel_conn_to_vcpi()

intel_conn_to_vcpi() runs from the HDCP enable path in commit_tail
and looks up the VCPI via mgr->base.state. When an ALLOCATE_PAYLOAD
is being driven on the mgr just before HDCP enable, that payload
list is being mutated in place, so the lookup can miss the port and
trip drm_WARN_ON(!payload), causing HDCP to be programmed with
VCPI 0.
Use drm_atomic_get_new_mst_topology_state() to read the topology
state attached to this atomic commit (stable, decided in
atomic_check), and bail out cleanly when no topology state or
payload is present for this port instead of WARNing.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Link: https://patch.msgid.link/20260504101117.3619984-2-suraj.kandpal@intel.com

drm/i915/display: move display funcs under modeset sub-struct

Move generic crtc-ish modeset related functions under a new modeset
sub-struct of struct intel_display. Rename struct intel_display_funcs to
intel_modeset_funcs to make it a little bit more specific. Remove the
funcs sub-struct.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/7849de3a5c9755639c179917c6a298de9ac832c0.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move cdclk funcs under cdclk sub-struct

Move cdclk related functions under cdclk sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/a3cadca7cfd03486404af497fa62efb8e2d2adcd.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move dpll funcs under dpll sub-struct

Move dpll related functions under dpll sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/02efd924d7efdf42655f5c9bfd0f79a6df5fe2b4.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move hotplug irq funcs under hotplug sub-struct

Move hotplug irq related functions under hotplug sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/9419cff5038d60a6c95c247b83f54b6559067e0d.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move watermark funcs under wm sub-struct

Move watermark related functions under wm sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/6b74ab66692dce20b2a6a8cb8cfdef222b2983ca.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move fdi funcs under fdi sub-struct

Move fdi related functions under fdi sub-struct of struct intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/c48bad63ec94259773d05ef056268b02e119d635.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move color funcs under color sub-struct

Move color related functions under color sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/77cc5dd365f3346c4cbbe7a5d883bca413138c94.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: move audio funcs under audio sub-struct

Move audio related functions under audio sub-struct of struct
intel_display.

The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.

Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/60d626286b77c2faa9ff0518855dd083906b24be.1777537663.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: Avoid stale PIPE_SCANLINE values after crtc_enable

When a CRTC is moved to a different transcoder (e.g. on DP-MST stream
allocation), PIPE_SCANLINE and PIPE_FRMCNT can return values latched
from the previous transcoder/mode for up to one vblank period after
the new pipe is enabled. The vblank evasion code in
intel_pipe_update_start()/end() then samples a stale or boundary
scanline and the frame counter ticks during the critical section,
producing diagnostic errors of the form:

  [243.348405] xe 0000:00:02.0: [drm] *ERROR* Atomic update failure on
pipe B (start=300 end=301) time 61 us, min 2128, max 2161, scanline
start 1200, end 2165
  [248.536260] xe 0000:00:02.0: [drm] *ERROR* Atomic update failure on
pipe B (start=561 end=562) time 61 us, min 2128, max 2161, scanline
start 2162, end 2167

Here "scanline start 1200" is the vblank_start of a previously
programmed mode on a different transcoder, while "2162" is the current
mode's vblank_start sampled before any real frame has been emitted.
Both indicate a stale read rather than a real evasion miss.

Wait for one vblank after crtc_enable() to give the new transcoder a
chance to start producing live PIPE_SCANLINE/FRMCNT values before any
subsequent atomic commit enters the vblank evasion section. This adds
at most one frame of latency on modeset, which is invisible to users.

Reproduced with igt@kms_rotation_crc@sprite-rotation-180 on a DP-MST
sink; with this patch the failures no longer occur.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Pranay Samala <pranay.samala@intel.com>
Link: https://patch.msgid.link/20260429042650.3335718-1-suraj.kandpal@intel.com

drm/i915/psr: Disable PSR2 on Xiaomi Book Pro 14 2026 as a quirk

Add new quirk (QUIRK_DISABLE_PSR2) for disabling PSR2 as a quirk for
problematic setups. Apply this newly added quirk on Xiaomi Book Pro 14
2026.

v2: logging adjusted

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7677
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260417102350.28328-1-jouni.hogander@intel.com

drm/i915/psr: Disable Panel Replay on Dell XPS 16 DA16260 as a quirk

We are observing same problems with Dell XPS 16 DA16260 as we saw with XPS
14 DA16260. This device seem to have also LGD panel with same feature as in
XPS 14. Due to this disable Panel Replay as a quirk on this setup as well.

Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7682
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260427130554.86040-1-jouni.hogander@intel.com

drm/i915/display: Use ceiling division for NV12 UV surface offset calculation

For LNL+, odd source size and panning for YUV 422/420 surfaces is
supported. However, it requires the UV (chroma) surface Start X/Y and
width/height to be calculated as ceiling(half of Y plane value) rather
than floor.

The current code uses (>> 17) which combines the U16.16 fixed-point to
integer conversion (>> 16) with a divide-by-2 for chroma subsampling
(>> 1) into a single floor division. For odd Y plane values this
produces an off-by-one error in the UV plane offset.

On Android systems we see PLANE ATS fault when NV12 overlays are
used with odd source dimensions:

[  126.854200] xe 0000:00:02.0: [drm:intel_atomic_setup_scaler [xe]] [CRTC:148:pipe A] attached scaler id 0.0 to PLANE:33
[  126.854617] xe 0000:00:02.0: [drm:skl_update_scaler [xe]] [CRTC:148:pipe A] scaler_user index 0.0: staged scaling request for 1279x719->1340x753
[  126.854837] xe 0000:00:02.0: [drm:intel_plane_atomic_check [xe]] UV plane [PLANE:33:plane 1A] using Y plane [PLANE:123:plane 4A]
[  126.854926] xe 0000:00:02.0: [drm] *ERROR* [CRTC:148:pipe A] PLANE ATS fault

With Y plane width 1279:
  floor(1279/2) = 639 (current)
  ceil(1279/2)  = 640 (required)

Introduce fp_16_16_div2() and fp_16_16_to_int_ceil() helpers to cleanly
separate the two operations: first halve the U16.16 fixed-point value
for chroma subsampling (staying in fixed-point domain), then convert
to integer with ceiling rounding.

v2: Use DIV_ROUND_UP(value, 1 << 17) to preserve sub-pixel precision
    while making the ceiling division readable (Jani, Uma)

v3: Split into two helpers - fp_16_16_div2() for fixed-point division
    by 2 and fp_16_16_to_int_ceil() for ceiling conversion to integer,
    cleanly separating chroma subsampling from fixed-point to integer
    conversion (Jani)

Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260415165849.187693-1-vidya.srinivas@intel.com

drm/i915/display: enable ccs modifiers on dg2

Since Xe driver aux ccs enablement dg2 ccs modifiers have been
disabled on i915 driver. Here allow dg2 to use ccs again for framebuffers.

Fixes: 6a99e91a6ca8 ("drm/i915/display: Detect AuxCCS support via display parent interface")
Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260427165715.864721-1-juhapekka.heikkila@gmail.com

drm/i915/dp: Skip AS SDP for DP branch devices

Currently, VRR is not implmented for DP branch devices.
So skip sending AS SDP for them.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260424090942.3060291-4-ankit.k.nautiyal@intel.com

drm/i915/dp: Add a helper to decide if AS SDP can be used

Add a helper that determines whether AS SDP can be used for the
current DP configuration. For now this is true only when the sink
supports AS SDP and VRR is enabled, but more conditions may be added
later.

v2:
 - Rename to intel_dp_needs_as_sdp(). (Ville)
 - Add a #FIXME documenting non-atomic of DP SDP updates. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260424090942.3060291-3-ankit.k.nautiyal@intel.com

drm/i915/vrr: Avoid vrr for PCON with HDMI2.1 sink

Currently we do not support VRR with HDMI so skip vrr compute
config step for all DP branch devices.

v2: Restrict VRR on all DP branch devices instead for checking only for
    HDMI. (Ville)

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260424090942.3060291-2-ankit.k.nautiyal@intel.com

drm/i915/dp: Change drm_err to drm_dbg_kms

Change the drm_err to drm_dbg_kms when we fail to read the FEC
capability. This is mainly because this is called from intel_dp_detect.
Which ends up in race more frequently in case of MST scenarios,
when we are disabling streams but the downstream Dock still sends
signals which causes intel_dp_detect to be invoked which has DPCD
reads. These pass until the Transcoder and DPLL go down causing
AUX to go down too. At this point AUX Timeouts are expected and not
an issue. But this drm_err gets flagged in CI causing noise even
for passing scenarios.

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patch.msgid.link/20260423080355.2744117-1-suraj.kandpal@intel.com

drm/i915/dmc: use display instead of dereferencing dmc in intel_dmc_update_dc6_allowed_count()

There is no need for dereferencing the dmc pointer if the display is
already in the scope of intel_dmc_update_dc6_allowed_count function.

No functional change.

Signed-off-by: Desnes Nunes <desnesn@redhat.com>
Link: https://patch.msgid.link/20260423201020.506908-1-desnesn@redhat.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/ddi: add wrapper for calling ->get_buf_trans() hook

Add intel_ddi_buf_trans_get() wrapper for calling the
encoder->get_buf_trans() hooks, allowing for a centralized place to
e.g. check for VBT overrides for the buf translations.

Cc: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260415115104.1721008-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Don't pass the framebuffer to low level pinning functions

Now that we have the pin_params the low level pinning code no
longer needs the entire framebuffer structure. The gem object
alone (along with the pin_params) is enough.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-12-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/xe: Eliminate intel_fb_uses_dpt() call from __xe_pin_fb_vma()

Move the intel_fb_uses_dpt() out from __xe_pin_fb_vma() into
intel_plane_pin_fb() so that we don't do have display stuff
that deep in the pinning code.

And intel_fb_pin_to_ggtt() can just say "this does not need DPT"
always since it's specifically about pinning the fb into GGTT.
The previous logic here was kinda insane with the high level code
assuming GGTT, and low level code potentially deciding otherwise.
In practice it should have been fine because intel_fb_pin_to_ggtt()
only gets used from the initial_plane code, and there we are
not supposed to be have a framebuffer that needs DPT.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce pin_params.needs_fence

Add a new flag pin_params.needs_fence to inform the pinning
code that the display needs a fence for tiled scanout.

The goal is to eliminate all display specific stuff from
the low level pinning code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract intel_plane_needs_fence()

Extract the naked DISPLAY_VER<4 checks into a descriptive little
helper (intel_plane_needs_fence()).

And while at it document the reason why the check is what it is.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce pin_params.needs_physical

Add a new flag pin_params.needs_physical to inform the pinning
code that the display needs a physical address and not GGTT
address.

This isn't strictly necessary as the current phys_alignment!=0
check is enough in practice. But theoretically one could have
needs_physical==true without any alignment requirements. And
having an explicit flag feels a bit less magical.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce pin_params.needs_low_address

Add a new flag pin_params.needs_low_address to inform the pinning
code that the display needs a low ggtt address.

The goal is to eliminate all display specific stuff from
the low level pinning code (the direct intel_plane_needs_low_addres())
call in this case).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract intel_plane_needs_low_address()

Extract the naked "gmch? -> need a low ggtt address" check into
a more descriptive helper (intel_plane_needs_low_address()).
The goal being to eliminate all display specific stuff from the
low level pinning code.

The actual implementation still abuses PIN_MAPPABLE to achieve
this goal. I'm not entire convinced that this whole thing even
needs to exist, and the original issue wasn't just caused by
some other bug. But no time to dig into it right now, so let's
keep going.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce pin_params.needs_cpu_lmem_access

Add a new flag pin_params.neeeds_cpu_lmem_access so that the
low level pinning code doesn't need to peek into the display
driver's framebuffer structure.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Extract intel_fb_needs_cpu_access()

Replace the naked "does the framebuffer have a clear color
plane?" checks with a more abstract helper that simply tells
us whether we require CPU access to the framebuffer's memory.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce struct intel_fb_pin_params

We need to pass a lot of information between the display driver
and the core driver to get framebuffers mapped into GGTT/DPT
correctly. Rather than passing around a swarm of integers and
boolean as function arguments, let's collect it all into a
structure (struct intel_fb_pin_params).

Start by moving the gtt view, alignment, phys_alignment,
and vtd_guard there. Going forward additional things need
to added as well (mainly various boolean flags).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/xe/fb: Use the correct gtt view for remapped FBs

Use the proper gtt view from the plane state rather than always
assuming that it came directly from the FB. This is in the DPT
codepath so the view should currently always come from the FB,
but in the future we may also want per-plane remapping with DPT.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-2-ville.syrjala@linux.intel.com

drm/i915/reset: Disable execlist per-engine reset for display reset tests

The display reset only happens from the full reset path. We must
therefore force execlist submission to always take the full reset
path and not the per-engine reset path. Currently the display
reset tests are in fact not testing display resets at all on
platforms using execlist submission. Ring submission and GuC
submission always take the full path anyway.

Also disable the engine reset inside __intel_gt_set_wedged() so
that we simulate the intel_gt_gpu_reset_clobbers_display() behavior
as closely as possible also when taking the full wedge path.

The slight race between the separate intel_display_reset_test()
calls in the overall reset path is harmless. kms_busy will keep
the modparam fixed during the test, and even if someone were to
fiddle with the modparam manually nothing bad should happen if
the calls return different values.

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-8-ville.syrjala@linux.intel.com

drm/i915/reset: Add "intel_display_reset_count" debugfs file

Expose the number of display resets performed in a new
"display_reset_count" debugfs file. kms_busy can use this to
confirm that the kernel actually took the full display reset path.

v2: Give the file an "intel_" namespace (Jani)

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Testcase: igt/kms_busy/*-with-reset
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-7-ville.syrjala@linux.intel.com

drm/xe/display: Add init_clock_gating.h stubs

Add static inline stubs for init_clock_gating.h functions
so that we don't need ifdefs in the actual code. We already
have one in intel_display_power.c, and now I need to bring
over intel_display_reset.c.

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-6-ville.syrjala@linux.intel.com

drm/i915/reset: Move pending_fb_pin handling to i915

Only i915 uses the pending_fb_pin counter to potentially whack
the GPU harder if the display gets nuked during a GPU reset.
Move the atomic counter into the i915 specific bits of code, so
that we don't need to worry about on the display side.

For some reason the overlay code kept the pending_fb_pin counter
elevated for longer than just for the pin, but from now on it'll
just cover the actual pinning part.

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-5-ville.syrjala@linux.intel.com

drm/i915/reset: Reorganize display reset code

Stop returning the "is there a display?" status from
intel_display_reset_prepare(). I plan to move the pending_fb_pin
into the i915 code, so I need to make that determination already
before intel_display_reset_prepare() is called. Add a new
intel_display_reset_supported() function for that.

v2: Also check display!=NULL for mock tests

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-4-ville.syrjala@linux.intel.com

drm/xe: Clear xe->display when no longer valid

Don't leave a stale xe->display pointer hanging around after
the display driver has been torn down.

While xe shouldn't hit the display reset related issue that
affects i915, leaving stale pointer floating around still
seems like a bad idea.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Clear i915->display when no longer valid

Don't leave a stale i915->display pointer hanging around after
the display driver has been torn down. Apparently the gt code
calls into the reset codepaths after this, and if the display
pointer is still around we may try to access freed memory.

The whole teardown sequence here seems rather suspect. Why is
display done first and then everything else via the managed
release? Who the heck knows. Someone really needs to dig into
this stuff and figure out the proper init/cleanup sequence for
both i915 (real and mock) and xe...

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Merge tag 'topic/pipe-reorder-2026-04-15' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-intel-next

drm/i915/display: change pipe allocation order for discrete platforms

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/d69501d53c233386d70ed10290af24aafebf434f@intel.com

drm/i915/lt_phy: Update the Tx Swing for DP 1.4

Changes have been introduced in Bspec regarding the Tx Swing level,
Tx pre/post coefficients. Update the Tx Swing Level and the Tx
pre/post-cursor co-effecients to incorporate these changes

v2: Updated the commit message (Suraj)

BSpec: 74493
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260415043952.3189598-1-arun.r.murthy@intel.com

drm/i915: Remove the vma parent interface

With the fb pinning stuff directly returning the fence_id
there is no longer any need for the vma parent interface.
Get rid of it.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407170942.16515-2-ville.syrjala@linux.intel.com

drm/i915: Track fence region ID in plane state

Get rid of the needlessly complicated PLANE_HAS_FENCE +
intel_parent_vma_fence_id() dance by simply tracking the
fence_id directly in the plane state.

v2: Don't request the redundant fence for fbdev (Jani)
    Assign *out_fence_id with '=' instead of '|=' (Sashiko,Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260407170942.16515-1-ville.syrjala@linux.intel.com

drm/i915/display: change pipe allocation order for discrete platforms

When big joiner is enabled, it reserves the adjacent pipe as the
secondary pipe. This happens without the user space knowing, and
subsequent attempts at using the CRTC with that pipe will fail. If the
user space does not have a coping mechanism, i.e. trying another CRTC,
this leads to a black screen.

Try to reduce the impact of the problem on discrete platforms by mapping
the CRTCs to pipes in order A, C, B, and D. If the user space reserves
CRTCs in order, this should trick it to using pipes that are more likely
to be available for and after joining.

Limit this to discrete platforms, which have four pipes, and no eDP, a
combination that should benefit the most with least drawbacks.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260413081609.969342-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Reject BIOS FB rotation in common code

Reject 90/270 degree rotated BIOS framebuffers in common
code. Currently skl_get_initial_plane_config() already rejects
these, but we may want to implement the missing parts there
so that skl_get_initial_plane_config() could be reused for
general plane state verification purposes.

90/270 degree rotated framebuffers require two completely
separate GGTT mappings (0 degree for the CPU, 270 degree
for the display engine), and the rest of the BIOS FB
takeover code is not prepared for that.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Completely reject DPT BIOS FBs.

Our BIOS FB handling can't deal with DPT, and instead everything
just assumes a direct GGTT mapping. Reject any BIOS FB using DPT.
Most likely this should never happen anyway.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Reject X/Y tiled BIOS FB if we don't have fenced regions

The CPU always needs linear view into the BIOS FB, and for X/Y tiled
buffers that is achieved by the use of a fenced region. If the
underlying driver doesn't support fenced regions then we can't keep
the X/Y tiled BIOS FB. i915 has fenced regions, xe does not.

Probably not a big deal since I don't think we've seen tiled BIOS
FBs outside of some MacBooks. See eg. commit d9a515867bdb
("drm/i915/gen9+: Fix initial readout for Y tiled framebuffers").

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Reject tile4 BIOS FB

There is no such thing as tile4 fenced region, so there is no
way to have a linear view of the tile4 framebuffer for the CPU.
Thus we should never encounter a tile4 BIOS FB, but if we somehow
do, then reject it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use a 1 second timeout for the polling vblank wait

40 msec seems like a very random number for a vblank wait timeout.
Considering ~24Hz display modes are definitely a thing this seems
way too low. Just bump it to a full second to match what we've been
using for normal vblank waits.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Move initial plane vblank wait into display code

The initial plane vblank wait operates on display registers,
so it really belongs in the display code proper. Move it there.

We can use intel_parent_irq_enabled() to determine if we can
rely on interrupts or not.

On average we should end up waiting half a frame here, so the
polling interval can be fairly long. 1 ms (which actually
makes poll_timeout_us() use ~250-1000 usec) seems good enough
to me.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Make plane_config->fb a struct drm_framebuffer*

There's no need to use the intel specific struct intel_framebuffer*
type in the initial plane_config structure. Just make it a
struct drm_framebuffer*.

I think the fewer special types we expose in the interface (even
if just pointers) the better. At least then there is no need to
change the interface definition if we ever change the internal
types. And I hope that the existing examples will generally
encourage people to not expose more special types unless
absolutely necessary.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Don't pass the whole plane_config to initial_plane_phys()

initial_plane_phys() only needs the 'base' (== ggtt virtual address)
from the plane_config. Stop passing the whole plane_config and just
pass the 'base'.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Remove 'mem' and 'phy_base' from struct intel_initial_plane_config

The 'mem' and 'phy_base' members of struct intel_initial_plane_config
only exist to be passed from initial_plane_phys() to its sole caller.
Just return them via function arguments.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Introduce sanity to the plane_config pointer vs. array thing

The "plane_config" vs. "plane_configs" naming difference is very
subtle, making it far too easy to use the wrong thing by accident.
Introduce a separate type for the array, making it impossible to
pass in the wrong thing. And while at it name the variable
"all_plane_configs" to help the poor reader make sense of things.

The .config_fini() prototype also mistakenly used the plural
form despite only taking in a singular plane_config. So fix that
one up as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260410150449.9699-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/psr: Init variable to avoid early exit from et alignment loop

Uninitialized boolean variable may cause unwanted exit from et alignment
loop. Fix this by initializing it as false.

Fixes: 681e12440d8b ("drm/i915/psr: Repeat Selective Update area alignment")
Cc: <stable@vger.kernel.org> # v6.9+
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260413112345.88853-1-jouni.hogander@intel.com

drm/i915/dp: Make the RGB fallback for "4:2:0 only" modes the last resort

Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes
already during the first pass when respect_downstream_limits==true.
It seems better to try everything else first (like ignoring TMDS
clock limits) while still preferring 4:2:0, and only if everything
else has failed fall back to RGB.

Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260409101539.22032-10-ville.syrjala@linux.intel.com
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>