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
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
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
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
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
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
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>
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
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
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
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
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_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>
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>
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>
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
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
